Safeguard
Industry Analysis•

Exploited in the wild: why Project Zero uses a 7 day deadline

When a bug is already exploited, Project Zero cuts the vendor deadline from 90 days to 7. What the rule says, the grace period, and what users should do.

Safeguard Security Team
4 min read

Project Zero's policy replaces its 90 day deadline with a 7 day deadline for vulnerabilities that are being exploited in the wild, with a 3 day grace period. The idea is simple: when attackers already use a flaw, secrecy only protects the attackers, so vendors must move much faster.

What the policy says

Under Project Zero's published disclosure policy, vendors normally have 90 days after notification to make a patch available. For vulnerabilities exploited in the wild, a 7 day policy replaces that, with a 3 day grace period. The 30 day window after a patch still applies if a patch is available by the end of the deadline. For in-the-wild grace periods, details are released on day 37 regardless of when the patch ships.

If you want the standard rules and the worked day counts, see disclosure deadlines compared.

Why a shorter clock

A normal report assumes only the finder knows. In the wild exploitation means someone else already does. Waiting 90 days leaves users exposed while attackers use the bug. A short deadline pushes the vendor to ship a fix or a mitigation, and gets information to defenders sooner.

What counts as in the wild

The policy page we fetched does not define the term in detail. Generally it means there is evidence that attackers have used the flaw against real targets, not only a public proof of concept. CISA's Known Exploited Vulnerabilities catalog uses a similar idea, noting that its entries require reliable evidence of exploitation. See what is the CISA KEV catalog.

What this means if you run the software

  1. Expect a short interval between a warning and public details.
  2. Watch for vendor advisories marked as exploited.
  3. Use your emergency patching or mitigation plan, not the routine cycle. NIST SP 800-40 Rev 4 describes emergency patching as the procedure for a vulnerability being actively exploited, and notes that it may be part of incident response if assets are already compromised. See the four patching scenarios.
  4. If a patch is not ready, apply mitigations. See emergency mitigation when no patch exists yet.

What this means if you are the vendor

You may get a week. Have a named incident owner, a way to build and ship a hotfix, and a way to reach customers. A 3 day grace period is not something to plan around. Pre-agree who can approve an out of band release.

What this means if you are a reporter

If you have evidence of exploitation, say so in the report and ask for a short timeline. See what to put in a vulnerability report. Keep the evidence that shows exploitation, with sensitive details redacted.

A caution about policies

A policy from one team is not law. Other groups use different numbers, and a vendor may negotiate. Read the current version of any policy before you rely on it, since it can change.

Safeguard's zero-day discovery and reachability analysis help teams find which of their projects contain an affected package and whether the vulnerable code runs. See also how to handle a zero-day vulnerability.

Quick check

Is the 7 day rule the same for every disclosure program?

No. It is Project Zero's rule. The linux-distros list, CISA and others use different periods.

Does the vendor have to fix it in 7 days?

The deadline is for the vendor to make a patch available, with a 3 day grace period. It is a policy, not a legal duty.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.