--- slug: embargoed-disclosure type: pattern summary: "The Chromium project holds confirmed high- and critical-severity vulnerabilities private for a window after a fix lands, so downstream consumers can integrate the patch before attackers reverse-engineer it from the public commit." created: 2026-05-12 updated: 2026-05-16 last_link_verified: 2026-05-16 related: downstream-advance-access: relation: complements note: "The pattern names the upstream half of the same disclosure mechanism that Downstream Advance Access lets vendors register into." supply-chain-lag: relation: prevents note: "Embargo windows exist precisely to let downstream vendors ship a patched build before public disclosure; failing to act inside the window produces the supply-chain lag antipattern." escape-chain: relation: related note: "The vulnerabilities most commonly embargoed are bugs that contribute a link to a full sandbox-escape chain." exploit-chain: relation: related note: "The three-link structure of a modern browser exploit chain shapes which bugs receive the longest embargoes and the strictest confidentiality." v8-heap-sandbox: relation: related note: "The V8 heap sandbox constrains many high-severity bugs to a single link of a chain, which shortens the average embargo by reducing the blast radius any single bug carries." vrp-bug-bounty: relation: uses note: "The Vulnerability Rewards Program is the reporting channel that feeds the embargo pipeline; severity calibration there determines embargo length here." stable-trust-boundary: relation: produces note: "The embargo ends when the patched build reaches Stable; the channel transition is the trust-boundary event that public disclosure aligns to." --- # Embargoed Disclosure > **Pattern** > > A named solution to a recurring problem. *The Chromium project holds confirmed high- and critical-severity vulnerabilities private for a defined window after a fix lands, so downstream consumers can integrate the patch before attackers can reverse-engineer it from a public commit.* A patched commit in a public repository is a public commit. The moment a security fix lands in `chromium/src` it is visible by URL, in CI logs, and on Gerrit. A careful reader can recover the underlying vulnerability from the surrounding test, the modified bounds check, or the removed dereference. The embargo is the project's answer to that asymmetry: hold the fix and its reasoning private for a fixed window, give downstream vendors a head start on integration, then release everything together when Chrome stable ships. ## Context Chromium is shipped by Chrome but also by every downstream consumer whose product embeds the engine: Microsoft Edge, Brave, Vivaldi, Opera, Samsung Internet, Electron applications, WebView2-based integrations, enterprise browser forks, and AI-coding editors built on Electron. Each downstream consumer pins to a specific Chromium milestone or specific commit range and rolls forward on its own schedule, which is rarely Chrome's schedule. When the upstream project patches a high-severity vulnerability and rolls a Chrome stable update, the downstream consumer's product is still on the unpatched version for hours, days, or weeks until that vendor's own build, sign, and release pipeline catches up. The window between Chrome's stable update and the downstream catching up is the window in which attackers know the bug and downstream users don't have the fix. The Chromium security team operates the embargo through a small set of mailing lists and the security-private bug-tracker view. Reporters file through the Vulnerability Rewards Program. Triage assigns severity; severity determines embargo length. The fix lands on a private security branch, is ported to the affected release branches, and is released to Chrome stable on a schedule the security team coordinates against the embargo end. The blink-dev list, the chromestatus surface, and the public bug tracker carry nothing about the bug until the embargo lifts. ## Problem A reporter (internal Project Zero researcher, external VRP submitter, or a downstream vendor's security team) has just confirmed a critical bug in V8 or the renderer that yields remote code execution given a single user navigation to an attacker-controlled page. Two options exist. The first is immediate public disclosure: file the bug in the public tracker, land the fix on `main`, and let Chrome stable pick it up on the next release. That treats the patched commit as the disclosure event, which means Chrome users, downstream vendors, and attackers all learn about the bug at the same moment, and downstream vendors who build on a four-week cadence have nothing to ship for a month while attackers have a working bug for the same month. The second is immediate quiet patching with no notification at all: land the fix, say nothing, hope nobody notices it. That deprives downstream vendors of the signal they need to prioritize their own roll-forward. The recurring problem is how a project whose source is public can release a security fix without the act of release being the act of disclosure to attackers. ## Forces - **Reverse-engineering risk.** A landed commit is reverse-engineerable. The more substantive the fix, the more legible the underlying bug. Holding the fix private buys time but raises the cost of a leak. - **Downstream consumer breadth.** Hundreds of downstream products embed Chromium. Each has its own build and release pipeline; collectively their patch-integration latencies span hours (rolling distributions, Brave on its own faster cadence) to weeks (enterprise browsers with QA gates, Electron applications that pin to a stale milestone, WebView2-based integrations bound to OS update cycles). - **Active-exploitation evidence.** When the security team has evidence the bug is being exploited in the wild, the calculus inverts: the cost of leaving downstream users unpatched for the full embargo window exceeds the cost of disclosing to attackers who've already found it. - **Specification and certainty.** The project commits publicly to fixed embargo windows so reporters, downstream vendors, and the standards community can plan against them. A window that flexes case-by-case loses the predictability that gives the program its operational value. - **Reporter expectation.** External reporters operate against industry-standard 90-day disclosure norms (Project Zero's published policy, Trail of Bits, NCC Group). The project's embargo policy must be legible to a reporter deciding whether to file with Chromium or publish on their own schedule. ## Solution The Chromium security team holds confirmed High- and Critical-severity vulnerabilities private for a defined embargo window measured from the moment a fix is committed to a private security branch, then lifts the embargo in a coordinated public disclosure that lands together with Chrome's patched stable release. The mechanism has four moving parts. First, **severity calibration determines window length**. The Chromium security severity guidelines define Critical, High, Medium, and Low severity by exploit primitive and target. Critical-severity bugs (typically a single-step path from a web page to remote code execution outside the renderer sandbox) carry the longest embargo and the strictest confidentiality. High-severity bugs (renderer sandbox escapes, universal cross-site scripting that bypasses Site Isolation, V8 type-confusion bugs that yield arbitrary read/write in the V8 heap) carry a shorter window. Medium and Low severity bugs receive shorter holds or no embargo at all, and are often disclosed at the time the fix lands. Second, **the fix lands on a private branch first**. The patched code is committed to the Chromium security team's private repository, ported to each affected release branch (the M-release branches Chrome stable is built from), and validated against the security team's regression tests, before any public branch sees the change. The CI surface for these private branches is also private. Third, **registered downstream vendors receive advance notification**. Vendors who have applied and been accepted as Chromium downstream consumers — see the *Downstream Advance Access* pattern — get a notification that contains the bug class, the severity rating, the planned public-disclosure date, and the Chromium-stable channel version that will ship the fix. The notification carries an obligation: the recipient must keep the contents confidential until embargo end and must integrate the fix into their own build pipeline on a schedule that aligns to the public release. Fourth, **embargo can be broken early**. The published trigger is evidence of active exploitation in the wild. The Chrome Security blog and the public bug tracker carry the standing language that the Chromium project reserves the right to disclose immediately when in-the-wild exploitation is observed, in which case the embargo collapses to whatever timeline the security team can execute. That language exists so the contract with the reporter community is legible: the project won't sit on a bug that's already being weaponized. The window lengths the project actually operates against are not always the same as the windows it publishes. The published target for High and Critical bugs has historically been described as "approximately one to two weeks" in Chrome Security communications. In practice the window varies with the complexity of the port across affected release branches, the difficulty of regression testing on every supported platform, and whether downstream vendors have requested extension to absorb a complex change. The single fixed number is the maximum: 90 days from report to disclosure, aligned to the Project Zero industry norm. ## How It Plays Out A security researcher at a university files a Project Zero report on a V8 type-confusion bug that yields arbitrary read/write inside the V8 heap. The proof-of-concept escalates to host code execution by chaining the V8 bug with a known WebAssembly compiler bug and a Mojo IPC validation gap. The report goes through the Vulnerability Rewards Program. The Chromium security team confirms within forty-eight hours, rates it Critical (the chain reaches host execution from a single navigation), and lands the V8 fix on the private security branch over the next three days. A notification then goes to the registered downstream-consumer list. It names the affected component (V8), the Chrome stable version that will ship the fix (M-numbered), and the planned public-disclosure date (the second Tuesday of the following month, aligning with Chrome stable's release calendar). Microsoft Edge's security team begins porting the fix into Edge's downstream branch. The Electron security maintainers schedule a coordinated release across the two Electron milestones whose embedded Chromium falls inside the affected range. On the disclosure date, Chrome stable ships the patched build, the public bug-tracker entry becomes visible, the Chrome Security blog publishes a release-notes post, the NVD record is created, and the Edge and Electron releases ship within hours. A second scenario inverts the timeline. The security team receives credible evidence (a third-party threat-intel feed, a customer report, a researcher's exploit reproduction against an in-the-wild URL) that the bug is being exploited before the embargo's planned end. The team breaks embargo on a four-day timeline. Downstream vendors who had been planning against the original window receive an emergency notification with a compressed integration deadline. The Chrome Security blog post that publishes alongside the out-of-band stable release names the bug as observed in active exploitation, and the public CVE entry carries the "exploited in the wild" tag. Vendors who were ready, because they had begun integration on the original notification, ship within a day. Vendors who had been deferring integration ship later and absorb the cost of explaining the gap to their users. ## Consequences **Benefits.** Downstream consumers who participate in the advance-access program have a documented window in which to integrate the fix before public disclosure. The window's existence is what makes the supply-chain story work at all: without an embargo, every Chromium-based product is unpatched at the moment the patched commit lands in the public source tree, because attackers and downstream vendors discover the bug at the same instant. With an embargo, downstream consumers have a head start measured in days to weeks. The published embargo policy also gives external reporters confidence that the project will treat their disclosure responsibly, which keeps the reporter community filing through the Vulnerability Rewards Program rather than publishing independently on their own schedule. **Liabilities.** An embargo is a confidentiality regime, and confidentiality regimes have costs. A patched commit on a private branch is invisible to public CI; bugs that depend on cross-branch test coverage or on downstream-test feedback get caught later than they would on an open branch. Reporters whose findings sit under embargo for weeks experience the silence as a loss of credit and occasionally publish on their own timeline anyway, which destabilizes the embargo for everyone else. The downstream-vendor list itself is a population with conflicting incentives — a vendor who receives a notification has a window in which they could in principle deploy a detection rule or signature without disclosing the bug; the obligation to honor the embargo rests on the contractual relationship with the project, not on the technical infrastructure of the notification. The most acute liability is that an embargo only protects users when downstream vendors actually act inside the window. A notification that arrives at a downstream consumer with a four-week release cadence and a manual QA gate produces no operational benefit unless the consumer treats the notification as an emergency. The pattern's defense against that failure mode is named in *Supply-Chain Vulnerability Lag*: the antipattern is what happens when the embargo's mechanism exists but the downstream consumer's process cannot use it. ## Notes for Agent Context When an AI coding agent is asked to review or comment on a Chromium security-fix commit, the agent must not infer or speculate about an underlying vulnerability whose public disclosure date has not yet passed. A landed commit on `main` that is silent about its security impact may be a quiet fix; do not write public commentary, blog drafts, social posts, or commit-message suggestions that name the bug class or speculate about exploitability until the public bug-tracker entry and CVE record are visible. When asked to triage a CVE, cite the NVD record's severity and the Chromium security severity guidelines' calibration; do not assign the agent's own severity. When asked to summarize the embargo window for a downstream vendor's process documentation, name the published window and the early-break trigger (active exploitation); do not invent a vendor-specific window from the agent's training data, which is likely to be stale relative to the project's current policy. ## Sources The Chromium security team's published policy on disclosure and embargo windows is the canonical primary source for the windows the project operates against; the document at `chromium.org` on security and disclosure policy describes the population of recipients, the severity calibration, and the active-exploitation early-break trigger. The Chromium security severity guidelines define the Critical / High / Medium / Low categories that determine embargo length. The Vulnerability Rewards Program's public terms describe the reporting workflow and the relationship between reporter, security team, and public disclosure. Project Zero's published 90-day disclosure policy is the industry-standard benchmark against which the Chromium program's published windows are calibrated; Tavis Ormandy's and Ben Hawkes's public writing on the policy at Google's Project Zero blog provides the operational context. The cited URLs are listed in Technical Drill-Down below; each was verified on the `last_link_verified` date in this file's front matter. ## Technical Drill-Down - [Chromium security and disclosure policy](https://www.chromium.org/Home/chromium-security/) — the canonical public policy page; the severity calibration, the embargo window guidance, and the active-exploitation early-break trigger are stated here. - [Chromium security severity guidelines](https://chromium.googlesource.com/chromium/src/+/main/docs/security/severity-guidelines.md) — the public definition of Critical / High / Medium / Low; the severity rating determines embargo length and downstream-notification urgency. - [Chrome Vulnerability Rewards Program](https://bughunters.google.com/about/rules/chrome-friends/5745167867576320/chrome-vulnerability-reward-program-rules) — the reporting-channel rules; describes the relationship between reporter and security team during embargo. - [Project Zero disclosure policy](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html) — the 90-day industry-standard policy against which Chromium's published windows are calibrated. - [Chrome Security blog](https://security.googleblog.com/search/label/Chrome%20Security) — release-notes posts publish alongside the lifted embargo; the public record of which bugs were disclosed when. - [Chromium bug-tracker security view](https://issues.chromium.org/issues?q=componentid:1456245%20status:open) — the public bug-tracker entries become visible at embargo end; the entry's restriction history records the embargo timeline. --- - [Next: Downstream Advance Access](downstream-advance-access.md) - [Previous: Security Response and Vulnerability Classes](security-response.md)