Why Do Critical Vulnerabilities Take Weeks to Patch After a Report?

Critical vulnerabilities usually take weeks to patch because a fix is more than a code change. Maintainers have to confirm the bug, write a fix that does not break anything, backport it to every supported version, and line up a release with the distributions and vendors that ship their code. The part you control starts when that fix is public.

This week gave everyone a live example. Two critical flaws in PHP were reported privately in August, according to reporting by Fortune and The State of AI, and fixed releases shipped on 21 October 2026. People outside security asked two reasonable questions: why did it take so long, and were we exposed the whole time? This post answers both, using the published disclosure policies of PHP, the Linux kernel, curl, OpenSSL and the Linux distributions' private coordination list as the primary evidence. Then it moves to the gap that nobody else can close for you: the time between a fix being published and that fix running in your production systems.

Key takeaways

• There are two gaps, not one. The first runs from private report to public fix and belongs to the maintainers. The second runs from public fix to your production and belongs to you. In most organisations the second gap is longer.
• Weeks is normal and often deliberate. Projects publish their limits. The Linux kernel delays publication by at most 7 days, 14 in exceptional cases, once a fix exists. The distros list allows at most 14 days. OpenSSL aims to keep High severity issues private for under about a month. A common outside deadline for vendors is 90 days.
• Most of the time goes into work you cannot see. Reproducing the bug, writing a fix that does not break users, backporting to several branches, and getting packages built for many distributions in parallel.
• Runtimes and embedded code take longest. A flaw in PHP, OpenSSL or the kernel is shipped by hundreds of downstream packagers who all need to be ready at the same moment.
• You may have been exposed before disclosure. Leaks, independent rediscovery and pre-disclosure exploitation all happen. Treat a critical disclosure as a prompt to check, not only to patch.
• AI is speeding up both sides. Discovery is faster, and attackers can turn a published patch into a working attack sooner.
• Measure "fix available to fix deployed". If you do not know that number per critical finding, you cannot tell whether you are improving.

The two gaps at a glance

Before going deep, here is the whole timeline in one table. The stages are drawn from the coordinated vulnerability disclosure phases that the CERT Coordination Center describes in its guide: discovery, reporting, validation and prioritisation, remediation, public awareness, and deployment.

People complain about the first seven rows. Most real exposure builds up in the last two, because once the advisory is public, attackers know exactly what to look for.

What happens between a private report and a public fix?

From the outside, a security fix looks like a one line diff that took six weeks. From the inside, it is a small project with several hand offs. Here is what each step actually involves, using the projects' own documentation.

Step 1: The report arrives through a private channel

Every serious project asks for security reports privately. PHP asks reporters to use GitHub's security advisory form for php-src or to email security@php.net, and its policy states that reports "remain private until published". curl only accepts vulnerability reports through HackerOne and says plainly that it cannot handle reports sent by email. The Linux kernel has its own security team address, and the kernel documentation is explicit that the security list is not a disclosure channel.

curl's process starts with an acknowledgement that a person has seen the report. For volunteer projects, that can take a day or two.

Step 2: Triage, reproduction and severity

Next, the maintainers have to decide whether the report is real, whether it is a security issue under their own definition, and how bad it is. This is where a lot of time disappears, and for good reason.

Projects define "security issue" narrowly. PHP's policy lists categories it does not treat as security bugs at all, such as malicious input to unserialize(), bypasses of open_basedir or disable_functions, and code that the attacker must already be able to run. PHP's classification document then sorts real issues into High, Medium and Low. High means the issue can compromise most PHP installations, allow arbitrary code execution, or expose any file a local PHP user can read. Medium means similar impact under a less common condition. Low issues may even be disclosed publicly before a fix.

curl uses four levels, Low, Medium, High and Critical, and does not use CVSS scoring. Its Critical bar is a flaw that is easy to exploit remotely, without authentication or user interaction, leading to code execution in common configurations. OpenSSL also sets its own severity rather than relying on CVSS, and warns that third party scores may differ significantly from its own.

Reproduction is often the slowest part. A report might describe a crash on one build with one configuration. Maintainers need to confirm that it is exploitable rather than a harmless crash, find every code path that reaches the bug, and decide which supported versions are affected. If the reporter's proof only works on one platform, someone has to build and test on others.

Step 3: Writing a fix that does not break everyone

A security fix has to close every path to the bug, not just the one in the report, without changing behaviour applications depend on. And it is often written in private, by a small group, without the usual public review and continuous integration.

PHP's classification policy describes this directly: fixes for High and Medium issues are merged into a private security repository first, then into the main repository before the release is tagged. curl commits the fix to a private branch and only merges and pushes it to the public repository no more than 48 hours before release. Working in private keeps the bug secret, but it also means fewer reviewers and less automated testing, so maintainers tend to be careful and slow rather than fast and wrong.

Step 4: Backporting to every supported release line

Most projects support several release lines at once. PHP fixed this week's issues in four supported branches, 8.5, 8.4, 8.3 and 8.2, with releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 according to reporting that cited the PHP release. OpenSSL's policy says Critical and High issues trigger a new release for all supported versions.

Each backport is its own small engineering task. Code has moved between versions. A fix that applies cleanly to the newest branch may need to be rewritten for an older one. Every branch needs its own test run. Multiply that by four or five branches and a "simple" fix becomes days of work.

Distributions add another layer. Debian's security FAQ explains that Debian does not move users to a new upstream version to fix a vulnerability. It backports the fix into the version already in stable, so that it "changes as little as possible" and nothing breaks. That is why a Debian package can show an old version number and still be patched. It is also extra work that happens in parallel for every distribution that ships the code.

Step 5: Coordinating with downstream packagers

This is the step that makes runtime and library fixes take weeks rather than days. If PHP released a fix on a Tuesday without warning, every Linux distribution, container image maintainer, hosting company and appliance vendor would scramble, and attackers would compare the old and new code within hours. So projects give trusted downstream parties a short, private head start.

The main channel for open source is the distros and linux-distros mailing lists run on Openwall. Members include Debian, Red Hat, SUSE, Ubuntu, Amazon Linux, Arch, Gentoo, Oracle Linux, AlmaLinux, Rocky Linux and others, with the wider distros list adding FreeBSD, NetBSD and others. The list has hard rules: the maximum embargo is 14 days, under 7 days is preferred, and a reporter must post full details publicly to the oss-security list when the issue goes public.

curl notifies the distros list no more than 7 days before release, with the draft advisory, CVE and patch. OpenSSL gives selected organisations, including general purpose operating system distributors, more detail and patches about two weeks before a release that fixes Critical, High or Moderate issues, and announces the date and severity, without details, about one week before.

Step 6: Release, advisory and CVE

Finally, the fixed versions ship along with an advisory. curl is a CVE Numbering Authority, so it requests its own CVE and writes the advisory itself. The Linux kernel takes a different approach: its CVE team assigns identifiers after a fix is already in a stable kernel tree, tracked by the git commit of the fix. That is one reason the kernel produces a large volume of CVEs. Its own documentation says the assignment team is "overly cautious" and advises users to take all stable updates because they are tested together.

PHP's policy says fixes usually go into the next monthly release, though some take longer, and that releases usually happen on Thursdays. A report that arrives just after a release, needs careful work, and then waits for a coordinated date can easily take two months before a fixed version is public.

Why do fixes for runtimes and widely embedded code need longer coordination?

A library used by one application can be fixed in an afternoon. A language runtime, a TLS library or a kernel subsystem is different, for four reasons.

The number of downstream builders is enormous. PHP is compiled and shipped by every major Linux distribution, by container base images, by hosting control panels, by commercial appliances and by countless internal build systems. Each of those builders has to be ready on the same day, or the first one to ship reveals the bug to everyone else.

The code is often copied, not linked. Libraries like curl and OpenSSL are vendored into other projects, statically linked into binaries and bundled into firmware. A fix in the upstream repository does nothing for a copy inside a router or a desktop application until that vendor rebuilds. Coordination gives the larger of those vendors time to prepare.

Many supported versions run in production at once. Runtimes are pinned for years because upgrading them risks breaking applications. Every one of those lines needs a fix, and the distributions often carry their own long term versions on top of the upstream ones.

The maintainers are few and often volunteers. PHP's classification policy notes that PHP is a volunteer project and does not pay bounties. Security work competes with everything else, and a flood of reports, real or not, slows everything.

The PHP case shows how these pressures stack up. Fortune reported that the first issue was found on 1 August and that another research team independently found issues starting 19 August. The State of AI reported that the first flaw was reported to PHP on 11 August. That leaves roughly ten weeks to the fixed release on 21 October. Reporting also says the release was originally planned for 22 October and was brought forward after details leaked online on 20 October. Ten weeks is long by the standards below, but it reflects a coalition of maintainers, researchers, infrastructure providers and government agencies preparing protections at once.

What are the common disclosure windows and who sets them?

There is no single global rule. The window is set by whoever holds the information at that moment: the project, the coordinating list, the reporter, or a regulator. Here are the published numbers from primary sources.

A few things stand out.

Project windows are short; the overall timeline is long. The kernel and distros limits are measured in days, but those days start only once a fix exists. The weeks before that, spent triaging and writing the fix, are not counted. That is why a seven day embargo can sit inside a two month timeline.

Reporters set outer deadlines. The widely used 90 day deadline from Google's Project Zero sets an upper bound on how long a vendor can sit on a report before details are published. If there is evidence of active exploitation, the deadline shrinks to 7 days. Project Zero may grant a short grace period if a vendor asks for one.

Embargoes are meant to be short. OpenSSL's policy says embargoes should be measured in days and weeks, not months or years. The distros list does not allow requests beyond 14 days. The aim is to give packagers enough time to build and test, not to keep users in the dark.

Regulators set deadlines for users, not maintainers. CISA's Binding Operational Directive 22-01 gave federal agencies two weeks to fix most entries in the Known Exploited Vulnerabilities catalog. CISA's page now says that directive has been revoked and superseded by BOD 26-04. According to coverage by BleepingComputer, the new directive weighs public exposure, known exploitation, automatable exploitation and level of control, with three days for the highest risk combination and two weeks for less urgent cases. We could not retrieve the directive text itself from cisa.gov, so check the official page before you rely on the exact tiers. Either way, those clocks start after the fix is public. They are about the second gap.

Were you exposed during that window, and how would you know?

Honestly, you might have been. A private report does not mean nobody else knows. There are three common ways attackers get ahead of a coordinated release.

Independent discovery. If one team found a bug, another can too. In the PHP case, reporting says two separate research efforts found issues within weeks of each other. Attackers with the same tools can do the same.

Leaks. Embargoes involve many people across many organisations. The distros list rules require members to report leaks immediately. In the PHP case, CVE identifiers and a demonstration video appeared online the day before the planned release, according to reporting that cited Infosecurity Magazine.

Pre-disclosure exploitation. Fortune reported that one large cloud provider saw some exploit attempts in the days before the 20 October disclosure. Separately, a widely used remote support product was exploited as a zero-day starting in late August, according to The Hacker News weekly recap. In both cases, organisations were exposed before any patch existed.

For a related question, see Can attackers exploit a vulnerability before it is disclosed?.

How to check whether you were hit

You will not know for certain unless you look. When a critical flaw becomes public, run a short compromise check alongside the patch:

1. Confirm exposure first. Was the vulnerable version actually running, and was the vulnerable feature reachable from the network? An internal service with no inbound path carries much less risk than an internet facing one.
2. Read the advisory for indicators. Good advisories and follow up posts from providers and national CERTs describe request patterns, file paths or process behaviour to look for.
3. Search logs back to before the report date, not only the disclosure date. If the bug existed for years, exploitation could have started at any time. At minimum, cover the window from the earliest known report.
4. Look for persistence. New files in web roots, new scheduled jobs, new user accounts, new outbound connections from servers that normally do not make them.
5. Rotate credentials that the affected service could read if you find any sign of access, and treat the host as untrusted until rebuilt.

Our guide on whether you were exploited before the patch goes deeper on log sources and decision points. If you need to find which products contain the vulnerable component in the first place, see SBOM incident response: finding affected products fast.

How is AI changing both sides of the window?

AI is changing this timeline from both ends at once, and the effects do not cancel out.

On the discovery side

The PHP flaws were found with AI assisted tools, according to every report we read. Fortune quoted one research team saying AI changed "the ability to understand the weaknesses" and turn them into working exploits. The State of AI reported a researcher's view that one person with frontier models could do in a week what used to take a top team months. It also reported that the underlying memory handling weakness had been flagged before, in 2020 and again in a 2024 audit, but was left because nobody had shown it was exploitable.

That has three consequences for the first gap:

• More real reports. Old, quiet bugs in mature code are being found and proven exploitable.
• More noise. Maintainers also receive AI generated reports that are wrong, and every one still has to be read, which slows triage for the real ones.
• A defender head start, sometimes. Reporting on the PHP case says the coalition behind the disclosure described the roughly ten weeks before release as a "Defender's Window", time used by maintainers and infrastructure providers to prepare fixes and protections before attackers knew. That only works if defenders find the bug first and the secret holds.

On the exploitation side

The same tools help attackers read a public patch, work out what it fixes and build a working attack. Industry studies of "time to exploit" disagree on the exact number because they measure different things, but they agree on the direction: the time from public disclosure to first exploitation has been shrinking for years, and some measurements now show exploitation starting before disclosure on average. In the PHP case, reporting cited exploit attempts in the tens of thousands within 45 minutes of the news breaking.

Put simply, AI is compressing the second gap from the attacker's side. A team that used to have a few weeks to roll out a fix before mass exploitation may now have days or hours. That makes your own intake and rollout speed the most important number you can change.

For more on this, see AI is finding vulnerabilities faster than we can patch.

What is the second gap, and why is it the one you control?

The second gap is the time from "a fixed version is publicly available" to "the fixed code is running in every place you run the vulnerable code". It is usually longer than the first gap, and it is entirely inside your organisation and your suppliers.

It has more layers than most people expect:

Each layer has its own owner and its own queue. A fix can sit for weeks because nobody rebuilt the base image, or stay "deployed" while the old process keeps running because nobody restarted the PHP-FPM pool or rebooted into the new kernel.

You cannot make maintainers work faster or shorten an embargo. You can decide how quickly you notice, how quickly a pull request appears, and how quickly a change ships.

How do you measure your own "fix available to fix deployed" time?

If you only measure "time to close the ticket", you measure your ticketing process, not your exposure. The useful metric is the time from the moment a fixed version is publicly available to the moment that version is running in production. Break it into stages so you can see where time goes.

Step by step: measuring it with tools you already have

The walkthrough below uses public data and your own git and deployment history. Adjust names to your stack.

1. Get the date the fix became public. The OSV database exposes published and modified timestamps for each advisory. Query it for a package and version you run:

curl -s -X POST https://api.osv.dev/v1/query \
  -d '{"package":{"name":"lodash","ecosystem":"npm"},"version":"4.17.20"}' \
  | jq '.vulns[] | {id, published, modified, summary}'

For language packages, the registry also tells you when the fixed version was released:

# npm: release time of each version
npm view lodash time --json | jq '."4.17.21"'

# PyPI: release dates per version
curl -s https://pypi.org/pypi/requests/json | jq '.releases["2.32.0"][0].upload_time'

# Go: when a module version was published
curl -s https://proxy.golang.org/golang.org/x/net/@v/v0.33.0.info

2. Get the date the fix entered your repository. Find the commit that changed the lockfile or manifest to the fixed version:

# First commit where package-lock.json mentions the fixed version
git log --reverse --format='%H %cI %s' -S '"version": "4.17.21"' -- package-lock.json | head -1

# Python, requirements or lock file
git log --reverse --format='%H %cI %s' -S 'requests==2.32.0' -- requirements.txt | head -1

# Maven
git log --reverse --format='%H %cI %s' -S '<version>2.17.1</version>' -- pom.xml | head -1

3. Get the date it reached production. Use whatever records deployments. For Kubernetes, check which image is running and when the pod started:

kubectl get pods -n prod -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

For GitHub deployments:

gh api repos/OWNER/REPO/deployments --jq '.[] | select(.environment=="production") | {sha, created_at}' | head -20

4. Confirm the running version, not the declared version. A manifest can say one thing while the process runs another:

# Inside a running container
kubectl exec -n prod deploy/web -- php -v
kubectl exec -n prod deploy/api -- node -e "console.log(require('lodash/package.json').version)"

# On a host
uname -r          # running kernel, compare with the installed one
openssl version   # OpenSSL actually on the path
curl --version    # libcurl version in use

5. Compute the gap and track it. Subtract the publication time from the production time for each critical finding. Track the median and the slowest 10 percent per quarter. The slow tail is where incidents come from.

6. Automate the record. A small GitHub Actions job can stamp the time a fix lands so you do not have to reconstruct it later:

name: record-security-fix
on:
  push:
    branches: [main]
    paths: ['package-lock.json', 'requirements*.txt', 'pom.xml', 'go.sum']
jobs:
  record:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 2
      - name: Log dependency changes with timestamp
        run: |
          echo "commit=${GITHUB_SHA} time=$(date -u +%FT%TZ)"
          git diff HEAD~1 -- package-lock.json requirements*.txt pom.xml go.sum | grep '^[+-]' | head -50

The point is a timestamp for every stage, so the conversation moves from "it felt slow" to "merge took four hours and deployment took nine days".

For benchmarks and context on remediation time, see mean time to remediation benchmarks.

What can you do during an embargo you are not part of?

Most organisations are not on the distros list and will not get a private heads up. But projects often announce that a release is coming. OpenSSL announces the date and severity about a week ahead. Other projects post pre-announcements on their own lists or blogs. In the PHP case, a release was announced ahead of the fix. That notice is your window to prepare.

Here is a checklist for the days between "a critical fix is coming" and "the fix is out":

1. Find every place you run it. Search SBOMs, container images, hosts and vendor appliances for the component and version. This is the step that takes longest if you have no inventory, so do it before the release, not after.
2. Rank exposure. Internet facing first, then internal systems that process untrusted input, then everything else.
3. Line up the change. Pre-approve an emergency change window. Make sure the people who can build and deploy each affected service are available on release day.
4. Check your build pipeline. Confirm you can rebuild base images and services from scratch. A stale cache or a broken pipeline costs hours on release day.
5. Prepare compensating controls. Know how you would restrict access, disable a feature, or add a filtering rule if the patch cannot go out immediately. For the most severe cases, decide in advance whether you would take a system offline, as several government websites reportedly did with PHP this week.
6. Subscribe to the right feeds. The oss-security mailing list, project announcement lists such as openssl-announce, your distribution's security announcements, and national CERT advisories.
7. Prepare a compromise check. Decide which logs you will search and who will do it once indicators are published.

If you want a fuller version of this checklist, read Pre-announced security release: what to do this week. For how the private distribution list works, see How the linux-distros embargo works.

Which response fits your situation?

Common mistakes

• Treating the CVE publish date as the start of exposure. The bug existed before the report. Exploitation may have started before disclosure. Search logs further back.
• Measuring time to close the ticket. A ticket marked done while the old process still runs is not a fix. Measure running versions in production.
• Waiting for the distribution package when you build from upstream anyway. If your image compiles PHP or bundles OpenSSL yourself, the distribution package is irrelevant. Know which components you build and which you consume.
• Upgrading the package but not restarting the process. PHP-FPM pools, language workers and kernels keep running old code until restarted. Check uname -r against the installed kernel, and restart services after library updates.
• Assuming an old version number means unpatched. Debian and other distributions backport fixes without changing the upstream version. Check the distribution advisory or changelog, not just the version string.
• Patching only the main application. Sidecars, batch jobs, build agents and internal tools often run the same runtime and get forgotten.
• Ignoring Low and Medium fixes for years. Skipping routine releases leaves you several versions behind, which makes the next critical upgrade bigger and riskier.
• Not practising. If your first emergency rebuild of every service happens on the day a critical flaw goes public, it will be slow.

Fix it without waiting for upstream

You cannot shorten the maintainers' window, and you should not try to rush a volunteer project through a careful fix. What you can shorten is everything after the fix is public, and in some cases you do not need to wait for an upstream release at all.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

How this maps to the second gap

Safeguard scans repositories, container images and SBOM files and matches components against vulnerability databases, which shortens time to awareness. The platform shows which projects contain a given component and version. Reachability analysis ranks which pull requests to merge first, fix pull requests shorten time to fix proposed, and the dashboard shows mean time to remediate trends. None of this changes the upstream schedule or restarts a process for you; rollout and verification still sit with your release process.

FAQ

Why does it take so long to patch a critical vulnerability?

Because the fix has to be confirmed, written without breaking users, backported to every supported version, and released at the same moment by many downstream packagers. The code change is often small. The checking, testing and coordination around it take most of the time.

How long is a typical security embargo?

Short, once a fix exists. The Linux kernel delays publication by at most 7 days, 14 in exceptional cases. The distros list allows at most 14 days and prefers under 7. OpenSSL gives distributors about two weeks. The full time from report to public fix is longer because triage and fixing happen before the embargo clock starts.

What is the 90 day disclosure deadline?

It is a common outer deadline set by researchers. Under Project Zero's policy, a vendor has 90 days to ship a patch before details are published, with details released 30 days after a patch if it ships in time. If a flaw is exploited in the wild, the deadline is 7 days.

Was I vulnerable before the vulnerability was announced?

Yes, if you ran the affected version and the vulnerable feature was reachable. The bug existed before anyone reported it. Whether anyone exploited it is a separate question that you answer by checking logs and hosts, not by looking at the disclosure date.

Why does my server still show an old version after patching?

Distributions such as Debian backport security fixes into the version they already ship rather than moving to a new upstream release. The version number can stay the same apart from a distribution suffix. Check the distribution's advisory or package changelog to confirm the fix is included.

Should I take a website offline if I cannot patch?

If the flaw allows remote code execution, the system is internet facing, and exploitation is reported, taking it offline or blocking access until you can patch is a reasonable choice. Several government sites reportedly did this with PHP this week. For lower risk cases, compensating controls such as access restrictions may be enough.

How do I measure mean time to remediate properly?

Start the clock when a fixed version is publicly available, not when a ticket is created. Stop it when the fixed version is running in production. Track the median and the slowest cases, and break the total into awareness, fix proposed, merged and deployed.

Is AI making patch times worse?

AI is finding more real bugs, which increases maintainer workload, and producing more low quality reports, which slows triage. It is also helping attackers turn published patches into attacks faster. The net effect is that the time after a fix is public matters more than ever.

See how Safeguard would help

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal and you ask it to fix the lodash CVE in a repository. The assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. That is the "fix proposed" stage of the second gap done in minutes, with a person approving every step.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. During a pre-announced release, this is a quick way to ask which projects carry a component and version so your inventory step happens before the fix ships, not after.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session. You send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. On a release day that lands outside working hours, this lets the person on call approve a fix without being at a desk.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard or read the CLI documentation.

Quick check

Sources

• Linux kernel documentation: Security bugs
• Linux kernel documentation: CVEs
• Openwall: distros and linux-distros mailing list policy
• curl: Vulnerability disclosure policy
• OpenSSL: Security policy
• PHP: php-src security policy
• PHP: Security classification policy
• Debian: Security FAQ
• Project Zero: Vulnerability disclosure policy
• CERT Coordination Center: Guide to Coordinated Vulnerability Disclosure
• CERT Coordination Center: CVD phases
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
• BleepingComputer: CISA tells government agencies to patch critical exploited flaws in 3 days
• Fortune: AI tools discovered the PHP vulnerability
• The State of AI: NSA PHP warning and AI found flaws
• The Hacker News: Weekly recap, October 2026
• Gold Open Source

Last reviewed: 23 October 2026. Disclosure policies change; check each project's linked policy for the current rules.