Can Attackers Exploit a Vulnerability Before It Is Disclosed?

Yes. Attackers can exploit a flaw before anyone discloses it (a true zero-day), during an embargo if details leak, and in the hours after a fix appears, because the patch itself points at the bug. Defenders cannot close that window alone, but they can shrink it: know exactly where each component runs, reduce exposure before a fix exists, and pre-stage the change so patch day takes hours.

This guide is for the people who own the patch queue and the incident pager. It explains how each window opens, how fast attackers move now that AI models can read a patch diff, and what to do before, during and after disclosure.

Key takeaways

• There are three windows: before anyone knows (zero-day), while a fix is prepared under embargo, and between a public fix and your deployment of it. Most damage happens in the third.
• Embargoes are short by design. The Linux distros list caps them at 14 days and prefers under 7; the kernel holds fixes for at most 7 days from the start of the release process, extendable to 14.
• Details leak through public patches, test cases, rumours and the growing circle of people pre-notified. In October 2026 a forum post announced PHP's coming security release before PHP did.
• Anthropic's Frontier Red Team reported in June 2026 that a model built a working Firefox exploit within an hour of Mozilla issuing a patch, 18 days before the patched browser shipped.
• Before a patch exists, your levers are inventory, exposure reduction, temporary filtering rules and feature switches. They buy time; they do not fix the bug.
• Patch day speed is decided weeks earlier, by whether you can answer "where does this run?" in minutes and whether the emergency change is already written and rehearsed.
• Patching does not evict an attacker who got in first. Hunt back through logs to before the fix date.

Can attackers really exploit a vulnerability before it is disclosed?

They can, and it helps to separate three situations that people lump together as "before disclosure".

The true zero-day. Someone outside the vendor finds the bug and uses it before the vendor knows. No advisory or patch exists, and no scanner can match it by version. It is real, but for most organisations it is the rarest case, because good zero-days are expensive and usually spent on high value targets.

The embargo window. The vendor knows, a fix is being written, and a small group has been told privately. Attackers have no official information, but a rumour, a public commit or a test case can let a capable team work out the bug before the advisory is published.

The n-day gap. The fix and advisory are public, but not yet deployed everywhere. Anyone who compares the old and new code can see what changed, and that comparison is now fast enough that "after disclosure" and "before you patched" overlap almost completely.

The rest of this guide covers the second and third rows, because those are the windows a defender can influence.

What is an embargo, and how do details leak?

How embargoes are supposed to work

An embargo is an agreement to keep a vulnerability confidential until a fixed date, so fixes can be prepared before attackers learn the details. It is part of coordinated vulnerability disclosure: the reporter tells the maintainer privately, the maintainer fixes the bug, downstream packagers are told shortly before release, and everything becomes public together. The rules are tight:

• The distros list. The private list used to warn Linux and BSD distributions accepts embargoes of at most 14 days and prefers under 7. Once the issue is public, the reporter must post enough detail to oss-security for non-members to fix it, and a member who leaks must tell the reporter and the list at once. We cover the mechanics in how the linux-distros embargo works.
• The Linux kernel. The kernel security team holds fixes for up to 7 calendar days from the start of the release process, extendable to 14 only when criticality requires it. It describes its list as "not a disclosure channel" and releases fixes as soon as they are ready.
• Research teams. Google's Project Zero follows a "90+30" policy: 90 days for the vendor to ship a fix, then details 30 days after the fix is available. For bugs already exploited in the wild the deadline drops to 7 days.
• Open source projects generally. The OpenSSF maintainer guide notes that CERT/CC publishes 45 days after a report by default, that 45 to 90 days is the normal range, and that GitHub projects can develop fixes in private security advisory forks. It suggests telling downstream providers roughly 1 to 30 working days before disclosure.

Embargoes are a trade. Every day of secrecy gives packagers time, and every day also adds people who know. OpenSSF quotes Project Zero's warning that pre-notification brings an "increased risk of leaks."

How details leak

Most leaks come from the ordinary mechanics of shipping software in public.

Public patches. In open source projects the fix often lands in a public repository before the advisory, sometimes with a bland commit message. Anyone watching can see a bounds check appear in a parser and draw conclusions.

Test cases. A regression test is a reproducer by another name. On 21 October 2026, Mozilla's security team told Firefox developers that for sec-high and sec-moderate bugs, tests should land in a separate patch no earlier than about a week after the fixing release ships. The post said only that "as AI keeps improving, our security policies are changing in response," but the link is hard to miss.

Rumours and partial leaks. On 20 October 2026 a Hacker News post claimed two critical PHP remote code execution flaws were coming, with a date, a score and two CVE numbers; its author admitted having no evidence beyond an anonymous source. According to The Hacker News, a security firm then said the information was real and under embargo. PHP published an advance notice that evening for a release at 14:00 UTC on 21 October, a day earlier than the rumoured date, and said it might release sooner "should details of either vulnerability become public." The leak said nothing about how the bugs worked, but it told every attacker where to look and when.

The size of the circle. PHP's advisory says Linux distributions and long term support vendors received the patches in advance. That is normal and useful, and it means patched packages and build logs exist in many places before the public date. A sudden out of band release schedule is itself a signal.

Was anything exploited before the October 2026 PHP disclosure?

The primary sources we checked do not say so. The Hacker News reported that one security firm had seen no exploitation in its customer environments as of 20 October, and that another listed exploitation as "none reported" as of 21 October. PHP's advisory describes a demonstrated exploit, which is different from exploitation in the wild.

You may see a claim, repeated in secondary round-ups, that a cloud provider saw exploit attempts several days before disclosure. We could not find a primary source for it, so treat it as unconfirmed. The lesson does not depend on it: once a leak names the product, the severity and the date, behave as if capable attackers are already looking. For PHP hosts specifically, see our PHP2Shell explainer and how to check a PHP server for compromise after patching.

How quickly can attackers turn a patch diff into an exploit in 2026?

The old rhythm

Defenders long assumed that turning a patch into a working exploit is slow, specialised work. Anthropic's June 2026 n-day study summarises the record: WannaCry struck 59 days after the MS17-010 patch in 2017, a public Citrix Bleed exploit appeared about two weeks after disclosure in 2023, and in a 2020 analysis it cites, 16 of 25 n-day vulnerabilities took a month or more to be exploited. That rhythm shaped how most organisations patch: monthly cycles, test windows and staged rollouts over weeks.

What changed

In April 2024, the paper "LLM Agents can Autonomously Exploit One-day Vulnerabilities" reported that a GPT-4 based agent given the CVE description exploited 87 percent of 15 real one-day vulnerabilities, against 7 percent without the description. The advisory text did much of the work.

In October 2025, a study of 100 reproducible web application CVEs found that two widely used models produced working proofs of concept from public data alone in 8 to 34 percent of cases, rising to 68 to 72 percent with code context and iterative refinement.

In June 2026, Anthropic's Frontier Red Team gave its agent public patches and diffs (with the Firefox regression tests removed) and asked it to find and exploit each bug. Anthropic reports that its Claude Mythos Preview model:

• produced working proofs of concept for 14 of 18 SpiderMonkey patches, the first in about 12 minutes and 13 within 40 minutes;
• had its first working Firefox exploit in just under an hour after Mozilla issued the patch, while the patched Firefox 148 release was still 18 days away;
• produced crash-inducing proofs of concept for 18 of 21 Windows kernel privilege escalation bugs, all within six hours, for roughly 2,200 US dollars in API credits;
• built eight full escalation chains to SYSTEM, including one for a bug Microsoft had rated "Exploitation Unlikely".

Anthropic's summary is blunt: "the patch itself provides a roadmap to the bug."

What these numbers mean, and what they do not

These are controlled experiments on selected bugs with generous tooling. Not every patch falls in an hour, and reliable exploitation of hard targets still needs expertise. But the planning conclusion is clear. For a widely deployed component with a public fix, assume a capable attacker can understand the bug within hours of the fix becoming visible, sometimes before the vendor's own release ships. For internet facing systems the deadline moves from "this month" to "today", and the clock starts when the fix lands in a public repository, not when the advisory is published.

US federal policy has moved the same way. CISA's Binding Operational Directive 26-04, issued on 10 June 2026, sets remediation timelines from four factors: public exposure, presence in the Known Exploited Vulnerabilities (KEV) catalog, whether exploitation can be automated, and how much control exploitation gives. Its tightest tier requires remediation or mitigation within three days plus a forensic triage. Secondary reporting describes longer tiers of about two weeks and two months; the directive presents the full matrix as a table image, so check it directly before copying numbers into policy.

What can you do before a patch exists?

With only an advance notice or a rumour, you cannot remove the bug. You can make it harder to reach, easier to see and faster to fix.

1. Confirm you run it, and where. Everything else depends on this; the next section covers how to answer it in advance.
2. Reduce exposure. Move admin interfaces and management planes behind a VPN or identity aware proxy, restrict services that do not need to be public to known address ranges, and shut down idle instances and old staging copies that still answer on the internet.
3. Disable the affected module. Many critical bugs live in optional parsers, upload handlers or protocol extensions. If you do not need the feature, turn it off.
4. Deploy temporary filtering rules, with care. A web application firewall or proxy rule can buy hours or days. Before details are public, rules are guesses that may break legitimate traffic, and attackers probe for bypasses. Keep the rule, patch, then remove the rule.
5. Use feature switches. If your own application exposes the functionality, a flag that turns off uploads, previews or an import endpoint is often faster and safer than any network rule. Build these switches before you need them.
6. Raise detection. Turn on full request logs at the proxy, process creation logs and outbound connection logs for systems in scope, and alert on what "bad" looks like for this component.
7. Prepare the change. Write the upgrade pull request, line up the image rebuild and book the window before the fixed version exists. When it lands, you change one number.

Why does knowing exactly where a component runs decide how fast you can move?

When an advisory lands, the first question is "where are we affected?" If answering takes a week of spreadsheets, your patch speed is capped at a week however fast your pipelines are.

Components hide. A library may be a direct dependency in one service, a transitive dependency four levels down in another, vendored into a third, statically linked into a Go binary in a fourth and baked into a base image a dozen teams inherit. Runtimes such as PHP, Node.js and OpenSSL appear in operating system packages, container layers and vendor appliances at once.

A useful inventory is built from software bills of materials (SBOMs) generated automatically for every repository and built image, refreshed on every build and searchable by name, version and package URL. It should tell you within minutes which repositories, images and services contain the affected version, which are internet facing, and who owns each one.

Checking at the source

These read-only commands confirm "do I have it, and which version?":

npm ls lodash --all                                   # every copy, including transitive
pip show requests                                     # installed Python version
mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core
go version -m ./bin/server | grep golang.org/x/net   # modules compiled into a binary
php -v; openssl version                               # runtimes on a host
dpkg -l | grep -i openssl    # Debian and Ubuntu (rpm -q openssl on RHEL family)
docker run --rm --entrypoint php myorg/web:2026.10.20 -v   # inside an image

If you already produce CycloneDX SBOMs, search all of them at once:

for f in sboms/*.cdx.json; do
  jq -r --arg n "openssl" '.components[]? | select(.name == $n)
    | "\(input_filename)\t\(.name)\t\(.version)\t\(.purl // "")"' "$f"
done

With the Safeguard CLI, the same inventory comes from scanning directories, images or existing SBOM files, with results written as JSON under ./output:

safeguard scan --dir .
safeguard scan --image myorg/web:2026.10.20
safeguard scan --sbom ./sboms/payments-api.cdx.json

In the Safeguard platform, the component view shows which projects contain a given component and version, so "where do we run it?" becomes a search rather than a survey. For a fuller walkthrough, see SBOM incident response: finding affected products fast.

Be honest about blind spots. SBOMs from your repositories and images will not see the kernel on a host you do not build, appliance firmware or the stack inside a SaaS product. Those need a vendor inventory and a way to ask vendors whether they are affected.

How do you pre-stage an emergency change so patch day takes hours, not weeks?

Teams that patch critical bugs within a day did the slow parts in advance. NIST's patch management guide, SP 800-40 Revision 4, frames patching as routine preventive maintenance rather than a crisis activity, and that is the right mindset. Here is a setup you can build in a quarter.

Step 1: Agree an emergency change class in advance

Write down what counts as an emergency security change, for example a critical or known exploited flaw on an internet facing system. For that class, pre-approve a short path: one technical reviewer, tests passing, a named approver on call, and change records completed afterwards. Have that argument in a calm month, not during an incident.

Step 2: Make builds reproducible and pinned

Commit lockfiles and pin base images by digest, so a rebuild changes only what you meant to change.

npm ci                                                    # install exactly the lockfile
pip-compile --generate-hashes -o requirements.txt requirements.in
pip install --require-hashes -r requirements.txt

# php:8.4-apache as of 2026-10-01, pinned by digest
FROM php@sha256:<digest-from-your-registry>

Step 3: Script the bump for each ecosystem

Keep these in the on call runbook. The versions are examples; use the fixed version from the advisory.

# npm: direct dependency, then force transitive copies with overrides
npm install lodash@4.17.21 --save-exact
npm pkg set overrides.lodash=4.17.21 && npm install

# Python
pip install --upgrade "requests==2.32.4"   # then re-run pip-compile

# Maven
mvn versions:use-dep-version -Dincludes=org.apache.logging.log4j:log4j-core \
    -DdepVersion=2.17.1 -DforceVersion=true

# Go
go get golang.org/x/net@v0.38.0 && go mod tidy

# Containers: pull the patched base and rebuild without cache
docker build --pull --no-cache -t myorg/web:2026.10.21-sec .

Step 4: Build a one-click bump workflow

A manually triggered CI workflow that bumps, tests and opens a pull request removes the slowest manual steps. A minimal GitHub Actions sketch:

name: emergency-dependency-bump
on:
  workflow_dispatch:
    inputs:
      package: { description: "npm package", required: true }
      version: { description: "Fixed version from the advisory", required: true }
permissions:
  contents: write
  pull-requests: write
jobs:
  bump:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Bump and force transitive copies
        run: |
          npm pkg set "overrides.${{ inputs.package }}=${{ inputs.version }}"
          npm install "${{ inputs.package }}@${{ inputs.version }}" --save-exact
          npm ls "${{ inputs.package }}" --all
      - run: npm test
      - name: Open pull request
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          git checkout -b "sec/${{ inputs.package }}-${{ inputs.version }}"
          git commit -am "Security: bump ${{ inputs.package }} to ${{ inputs.version }}"
          git push origin HEAD
          gh pr create --fill --label security --base main

Your normal deployment pipeline takes over after merge. On Kubernetes, make sure rolling out a new image tag is one command and that you have practised rolling back.

Step 5: Subscribe to the signals that arrive first

Subscribe to security announcement lists for the runtimes and frameworks in your inventory, to oss-security, to your distribution's advisories and to the CISA KEV feed, and route them to a channel someone reads. When a project announces "a critical release is coming on Wednesday", run steps 1 to 4 for that component before Wednesday.

Step 6: Rehearse with a fake advisory

Twice a year, declare a fictional critical advisory for a common component and time how long it takes to find every instance, open pull requests, pass tests and deploy. The first rehearsal usually finds an image nobody owns or an approver nobody can reach.

A realistic patch day timeline

Where Safeguard fits in pre-staging

Safeguard helps with the parts that sit in your own code and images. SBOM and dependency scanning keeps the inventory current, vulnerability matching runs against vulnerability databases, reachability analysis ranks findings where your code calls the vulnerable path, and policies and gates can stop a known vulnerable version from shipping again. When a fixed version exists, autonomous remediation can open fix pull requests across affected repositories; it ships switched off, so your team chooses what runs on its own. In CI, safeguard exec runs the same checks non-interactively.

Safeguard also runs Zero-Day Discovery, a continuous research pipeline whose findings go through coordinated disclosure. That is a research programme, not a promise that any particular bug will be found first. Safeguard does not reach host kernels you do not build, appliance firmware or a SaaS provider's stack, and it cannot make a vendor ship faster.

How do you detect exploitation that happened before you patched?

Patching closes the door. It does nothing about anyone who came through while it was open.

Define the look-back window

Start the window at the earliest moment an attacker could plausibly have known: the first public commit, leak or rumour, or the advisory, whichever came first. End it when your fix went live on that system. For a leaked embargo, that can mean several days before official disclosure, which is why log retention matters.

What to look for

• Process lineage. A web server, PHP-FPM worker, application server or parser spawning a shell, downloader or compiler.
• New or changed files. Scripts in upload directories or web roots, changed configuration, new scheduled tasks, new SSH keys.
• Outbound connections. Servers that normally only answer requests suddenly opening connections to unfamiliar hosts.
• Unusual requests. Spikes of malformed requests to the affected endpoint or requests matching the shape in the advisory.
• Identity changes. New accounts, API keys or permissions, and unusual token use from servers.

Read-only checks on Linux hosts

# Files changed since a reference point, for example the first leak
touch -d '2026-10-19 00:00' /tmp/leak_ref
find /var/www /etc /usr/local/bin -newer /tmp/leak_ref -type f -ls

# Verify installed package files against the package database
rpm -Va 2>/dev/null | grep -v '^.......T'   # RHEL family
debsums -c 2>/dev/null                        # Debian and Ubuntu

# Scheduled tasks and keys that should not be there
crontab -l -u www-data; ls -la /etc/cron.* /var/spool/cron 2>/dev/null
find / -name authorized_keys -newer /tmp/leak_ref 2>/dev/null

# Outbound connections owned by the web server
ss -tnp | grep -E 'www-data|apache|nginx|php-fpm'

Keep the output and do not clean anything up before evidence is preserved. If you find signs of compromise, switch to incident response: isolate, collect, then rebuild from known good images rather than repairing in place. Our incident response playbook for a compromised dependency applies the same discipline to supply chain cases.

Make it policy, not heroics

BOD 26-04 pairs its shortest tier with a requirement to "carry out a forensic triage of the asset to assess whether the system is compromised." Even outside government, that is a sensible rule: a critical, remotely exploitable flaw on an internet facing system gets a patch and a compromise check. NIST SP 800-61 Revision 3 (April 2025) places this work inside cybersecurity risk management under CSF 2.0, a useful frame when you ask for log retention budget.

What does this mean for open versus private handling of security fixes?

The October 2026 week showed projects pulling in opposite directions, both for good reasons.

More private. Mozilla now holds back regression tests for sec-high and sec-moderate bugs until about a week after the fixing release. The fix code still ships openly, but the ready-made reproducer waits. Given that Anthropic's agent often succeeded from the diff alone, this narrows the gap rather than closing it; Anthropic points to faster vendor releases, such as Mozilla's move toward roughly weekly dot releases, as the bigger lever.

More open. curl announced that from 26 October 2026 it will ask for low and medium severity reports as public GitHub issues and keep only high and critical reports private. Daniel Stenberg cites a flood of AI-assisted reports, notes that more than 90 percent of recent submissions were assessed as below high, and argues that public discussion brings more eyes to fixes. He acknowledges the cost: attackers get a slightly longer window, which he calls unfortunate but unavoidable below high severity.

Fast and unlabelled. The Linux kernel ships fixes as soon as they are ready, so downstream users must treat every stable update as potentially security relevant.

For consumers the conclusion is the same under every model: the advisory is no longer the starting gun. A public fix, an advance notice or a credible leak should all start your clock.

Common mistakes

Waiting for the scanner. If your process starts when a scanner shows a finding, you have lost the advance notice and possibly the first day after the fix.

Treating a filtering rule as the fix. Temporary rules are guesses. Track the real upgrade to completion, then remove them.

Patching only the direct dependency. The vulnerable copy is often transitive or inside a base image. Confirm with npm ls --all, mvn dependency:tree or an SBOM search after the change.

Forgetting rebuilds. A new lockfile does nothing for running containers. Rebuild with --pull, redeploy, and confirm the running image digest changed.

Patching and moving on. If a system was exposed during a leak or before you patched, look for compromise.

Short log retention. Size retention to cover the longest embargo plus your slowest patch time.

Trusting one score as a schedule. Labels like "exploitation unlikely" were calibrated for slower attackers. Combine exposure, KEV status and FIRST's EPSS, which estimates the probability of exploitation in the next 30 days, rather than relying on a single severity number.

Leaving the emergency path untested. A pre-approved change class that nobody has used is a document, not a capability.

FAQ

Can a vulnerability be exploited before it has a CVE?

Yes. A CVE is an identifier, not a condition for exploitation. Zero-days are exploited with no CVE at all, and during an embargo a CVE may be reserved but unpublished.

What is the difference between a zero-day and an n-day?

A zero-day is exploited before the vendor knows or has a fix. An n-day has a public fix that some systems have not applied. Most real exploitation hits n-days, and AI-assisted patch diffing is shrinking the time from fix to first exploit.

How long do vulnerability embargoes usually last?

The Linux distros list allows at most 14 days and prefers under 7. The kernel holds fixes up to 7 days from the start of the release process, extendable to 14. Project Zero gives vendors 90 days, or 7 if the bug is already exploited. CERT/CC defaults to 45 days.

Can attackers find a bug just by reading the patch?

Often, yes. In June 2026 Anthropic's Frontier Red Team reported a model building a working Firefox exploit from a patch diff in under an hour, with the regression test removed.

What should I do when a vendor announces a critical fix is coming?

Treat the notice as the start of your response. Find every place the component runs, reduce exposure on the riskiest systems, prepare upgrade pull requests and rebuilds, and schedule deployment for the release time.

Does a WAF protect me until I can patch?

Partly. A good rule blocks known request shapes and buys time, but rules written before details are public are guesses and can be bypassed. Use them as a bridge to the patch.

How do I know if I was hacked before I patched?

Look back from the first leak or public commit to when your fix went live. Check for the vulnerable process spawning shells, new files in web roots, unexpected outbound connections and new accounts or keys. If you find anything, move to incident response.

How fast should we patch critical vulnerabilities now?

For a critical, remotely exploitable flaw on an internet facing system, plan in hours to a few days. CISA's BOD 26-04 sets three days plus a compromise check for its highest risk tier, a reasonable benchmark for anyone.

Do SBOMs help with vulnerabilities that are not disclosed yet?

Indirectly. An SBOM cannot reveal an unannounced bug, but it tells you where every component and version runs, so when a notice names a component, a week of searching becomes a query.

Fix it without waiting for upstream

The pre-disclosure window and the n-day gap are both about time you do not control. The steps below are about the time you do.

In incidents like this one, 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.

See how Safeguard would help

These are real product sessions. None of them stops a zero-day or speeds up a vendor's release; they show the inventory and fix steps from this guide with the tooling doing the repetitive parts and a person approving each action.

In this Safeguard CLI session you run safeguard and ask it to fix the lodash CVE in a repository. It 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. On patch day the same flow applies to whatever component the advisory names.

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

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. It is a quick way to answer "where do we run it?" for code and images that never leave your network, the first question after any advance notice.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. When a critical release lands out of hours, an on call engineer can approve a pre-staged upgrade without opening a laptop, and every command still waits for a human decision.

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

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli.

Quick check

Sources

• PHP: news archive 2026 (advance notice and security advisory)
• The Hacker News: PHP2Shell, two unpatched critical PHP flaws
• Hacker News: "Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming"
• Mozilla firefox-dev: Firefox security patch tests are now private for at least a week
• Daniel Stenberg: Do minor curl vulnerabilities in the open
• Openwall: distros mailing list policy
• Linux kernel documentation: Security bugs
• Project Zero: Vulnerability disclosure policy
• OpenSSF: Guide to coordinated vulnerability disclosure for open source maintainers
• Anthropic Frontier Red Team: N-days
• Fang et al.: LLM Agents can Autonomously Exploit One-day Vulnerabilities (arXiv 2404.08144)
• Zhao et al.: A Systematic Study on Generating Web Vulnerability Proof-of-Concepts Using Large Language Models (arXiv 2510.10148)
• CISA: Known Exploited Vulnerabilities catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• FIRST: Exploit Prediction Scoring System (EPSS)
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management

Last reviewed: 22 October 2026.