Scout: Silent Vendor Patching as the New Normal — Disclosure Cadence Across Claude Code, Codex, Gemini CLI, Cursor, and Copilot

Summary

Across the six most-deployed coding-agent harnesses, the way a vulnerability gets disclosed is now as variable as the isolation primitive underneath it — and the variance is wide enough that it belongs in the procurement matrix. The anchoring case is Anthropic’s Claude Code network sandbox, where a SOCKS5 hostname null-byte allowlist bypass shipped a fix in late March 2026 with no CVE against Claude Code, no security entry in the release notes, and no notification to the teams that ran a wildcard allowlist on credential-bearing systems for roughly five and a half months (Aonan Guan, SecurityWeek). It was the second sandbox bypass in five months to be handled this way. But the pattern is not Anthropic-specific, and the simple “one vendor is opaque, the rest are clean” framing is wrong. The actual fault line runs along two axes: whether a vendor assigns a CVE against the product practitioners install (Claude Code, the Codex CLI) versus only the upstream library, and whether a finding gets formal advisory treatment based on its class — remote-code-execution findings tend to earn published advisories while sandbox-configuration and prompt-injection findings frequently get a quiet bounty and a silent patch. Google publishes GitHub Security Advisories for max-severity Gemini CLI RCEs but issued no advisory for a critical GitHub-comment prompt-injection bug it paid a bounty on. Cursor publishes CVEs in coordination with researchers. OpenAI patches Codex GitHub-token RCEs quickly but closes sandbox-configuration reports as “informational.” The npm and GitHub Advisory ecosystem auto-assigns CVEs to GitHub Copilot CLI shell-injection bugs. The net effect for a practitioner: absence of a CVE is no longer reliable evidence of absence of a vulnerability, and the most timely signal for the sandbox/harness/allowlist failure class now comes from a handful of independent researchers and security firms rather than from vendor advisory pages. What follows maps the per-vendor cadence, rates it, and names the advisory channels worth monitoring.

Key Findings

1. The anchoring case: a sandbox bypass patched into silence, for the second time

The most fully documented instance of silent patching in the coding-agent space is the Claude Code network sandbox. The mechanic in the second bypass is a classic parser differential: the sandbox’s SOCKS5 proxy filtered hostnames with a JavaScript endsWith()-style check against the user’s wildcard allowlist (e.g. *.google.com), but the OS resolver truncates at a null byte. A hostname like attacker-host.com\x00.google.com passes the JavaScript filter — which sees the trailing .google.com — while getaddrinfo() resolves only attacker-host.com, defeating the allowlist entirely (Aonan Guan). For a coding agent processing untrusted workspace content, that is a clean data-exfiltration path out of a sandbox the operator believed was containing it.

The disclosure handling is the part that matters for this briefing. Per Guan’s writeup, the bug was present from the sandbox’s GA in Claude Code v2.0.24 (October 20, 2025) through v2.1.89 — on the order of 130 releases across roughly five and a half months — and the fix shipped in sandbox-runtime 0.0.43, corresponding to Claude Code v2.1.90 (Aonan Guan). (SecurityWeek’s coverage records the fix as landing in v2.1.88 on March 31, 2026, a minor version-attribution discrepancy between the trade-press account and the researcher’s; both agree it shipped in late March without a security flag (SecurityWeek).) No CVE was assigned against Claude Code. The release notes carried nothing about a security fix. Guan’s structural complaint is the load-bearing quote: “No CVE for Claude Code, no notice to users on the ~130 vulnerable releases. A user finds out only by reverse-engineering cli.js or reading this post” (Aonan Guan). And the framing that names the operational harm: “Shipping a sandbox with a hole is worse than not shipping one. The user with no sandbox knows they have no boundary. The user with a broken sandbox thinks they do” (The Register).

The “second time” is not rhetorical. The first Claude Code sandbox bypass — allowedDomains: [] being interpreted as “allow everything” rather than “block all outbound” — was patched in Claude Code v2.0.55 on November 26, 2025, with a changelog entry that read “Fixed proxy DNS resolution being forced on by default” and made no mention of the network-isolation bypass (Aonan Guan). That issue did get a CVE — CVE-2025-66479, published December 2, 2025 — but against the upstream @anthropic-ai/sandbox-runtime library, not against Claude Code. When the researcher asked for a Claude Code CVE, the response was that “The root cause is in the library” (The Register). Anthropic’s position on the second report was that its security team had already found and fixed the issue internally before the researcher’s report arrived, and the report “was closed as a duplicate of an internal finding” (The Register). That may well be true and is not in itself a disclosure failure — the gap is the absence of any user-facing advisory once the fix shipped.

2. The upstream-library-CVE gap is the structural mechanic, not a one-off

The most transferable insight from the Claude Code case is why “a CVE exists” did not help anyone. The CVE that exists — CVE-2025-66479 — names @anthropic-ai/sandbox-runtime, a package most Claude Code users have never heard of and do not track in their SBOM (Aonan Guan). The product they install, pin, and monitor is Claude Code. A security team scanning for vulnerable Claude Code versions would find nothing, because the CVE is filed one dependency layer down against a component the scanner has no reason to associate with the installed agent. The Register’s framing of why this matters operationally is worth internalizing: a CVE triggers the vulnerability-management infrastructure enterprises rely on — scanner updates, SBOM flags, automated alerts when a component reaches a vulnerable version — and without one, that infrastructure stays blind to the affected versions (The Register).

This is the mechanic to watch for across all vendors, not just one. A CVE filed against an upstream runtime, a Pyodide sandbox, a proxy library, or a generated SDK is technically a CVE and technically discoverable — but it does not light up the dashboards keyed to the product name. When evaluating a vendor’s disclosure posture, the question is not “do they assign CVEs” but “do they assign CVEs against the artifact the customer installs.”

3. Anthropic’s formal CVD program covers other people’s software, not its own harness

Anthropic does run a coordinated vulnerability disclosure program, and it is genuinely substantive — but its scope is the open-source vulnerabilities Claude discovers in third-party code, the Project Glasswing output stream, not vulnerabilities in Claude Code itself. The CVD dashboard tracks findings whose disclosure window has closed, and reports that of 97 patched vulnerabilities, only 88 received CVE or GitHub Security Advisory records — with the program leaving whether to create a security advisory to the discretion of the affected project’s maintainers (Anthropic CVD dashboard). That discretion-to-the-maintainer posture is reasonable for third-party disclosures. The relevant observation for a practitioner is that no equivalent public commitment governs Claude Code’s own sandbox and harness: there is a structured, transparent pipeline for vulnerabilities Anthropic finds in other people’s software, and a discretionary, frequently-silent path for vulnerabilities researchers find in Anthropic’s own agent. The asymmetry is the editorial point — the vendor that is building vulnerability-discovery into a product has not extended the same advisory discipline to the harness it ships.

4. Google: max-severity RCEs get a GHSA, prompt-injection findings get a quiet bounty

Google’s cadence splits cleanly on finding class. For a CVSS 10.0 Gemini CLI remote-code-execution flaw — workspace-trust bypass in headless mode plus --yolo mode ignoring tool allowlists, exploitable by a pull-request contributor against a CI runner before the sandbox even initialized — Google published GitHub Security Advisory GHSA-wpqr-6v78-jr5g in late April 2026 and shipped patches in Gemini CLI 0.39.1 and run-gemini-cli 0.1.22, on a fast timeline after Pillar Security’s report (The Hacker News, SecurityWeek). That is responsible, visible disclosure — a published advisory keyed to the installed product, with a patched version number.

But the same vendor, on the “comment and control” GitHub-comment prompt-injection finding that hit Gemini CLI Action alongside Claude Code and Copilot, paid a bug bounty and published no advisory and assigned no CVE (The Register). And the Cymulate Gemini CLI sandbox-isolation findings (writable .gemini mount exposing oauth_creds.json, unsafe Windows where.exe resolution) sat past the 90-day responsible-disclosure deadline with no patch and no formal accept/reject decision communicated (Cymulate Part 1). Taken together: Google’s advisory machinery fires reliably for headline-grade RCE, and is inconsistent-to-absent for the sandbox-configuration and prompt-injection classes that dominate the harness threat model. A practitioner who watches only Google’s published GHSA feed sees the RCEs and misses the isolation defects.

5. OpenAI: fast on RCE, “informational” on sandbox configuration

Codex follows a similar split with a different texture. When BeyondTrust’s Phantom Labs disclosed a Codex GitHub-token-compromise RCE via branch-name command injection in late December 2025, OpenAI — in the trade-press phrasing — “rapidly fixed all reported issues” (SecurityWeek). Earlier Codex CLI sandbox-escape and command-injection issues did earn CVEs (CVE-2025-59532, a sandbox-escape fixed in 0.39.0 (GitHub Security Advisory); CVE-2025-61260, a CVSS 9.8 MCP-config auto-execution flaw (cyberpress)).

The gap appears on the sandbox-configuration class. Cymulate’s Codex CLI configuration-poisoning report was closed by OpenAI as “informational,” citing prompt injection as out of scope, after a formal rebuttal and an expired response window (Cymulate Part 1). In Cymulate’s Part 2, a Codex App Windows git.exe untrusted-search-path binary-hijacking report was closed as “Not Applicable” and the decision “upheld without further technical engagement” (Cymulate Part 2). So Codex’s disclosure profile is: CVEs and fast fixes for clear RCE, and a “this is expected behavior / out of scope” disposition for the prompt-injection-and-sandbox-config class — which means, as with Google, the harness-specific failure mode is the one least likely to surface as a trackable advisory.

6. Cursor and GitHub Copilot: the CVE-native end of the spectrum

Two products sit at the more transparent end, largely because of where their advisories land. Cursor publishes CVEs in coordination with the disclosing researchers — CVE-2026-26268 (git-hook arbitrary code execution, coordinated with Novee), CVE-2026-22708 (shell-builtin allowlist bypass pre-2.3), and a 2025 cluster (CVE-2025-59944 and others) — landing product-named in public vulnerability databases (novee.security, Lakera, SentinelOne).

GitHub Copilot CLI benefits from a structural advantage: it ships as the @github/copilot npm package, so its security fixes land in the GitHub Advisory Database and the npm advisory ecosystem with CVEs attached more or less automatically. CVE-2026-45033 — nested bare-repository core.fsmonitor code execution, fixed in 1.0.43 — is representative: a product-named CVE in the advisory database, with a patched version pinned (GitLab Advisories). Related shell-expansion bypasses of the read-only command classifier have landed in the same database under the @github/copilot package path. The distribution channel does the disclosure work that a vendor advisory page would otherwise have to. The caveat: this is the product end of Copilot. On the research-finding end — Cymulate’s Copilot CLI untrusted-working-directory binary-hijacking report — GitHub triaged, paid a bounty, downgraded severity, and gave “no committed timeline for remediation,” noting “the behavior may not be changed immediately” (Cymulate Part 2). Even at the CVE-native end, the binary-hijacking sandbox class lands in the same slow lane.

Reading the per-vendor cadences side by side, a consistent shape emerges that is more useful than any single vendor’s rating. Vendors disclose well on the vulnerability classes their existing security machinery already understands — memory-safety RCE, command injection, token compromise — and disclose poorly on the classes specific to the agentic threat model: sandbox-configuration defects, network-allowlist bypasses, native-tool argument injection, and prompt-injection-to-action chains. The Cymulate Part 2 summary across six products is the blunt version: of Cursor CLI, AWS Kiro, GitHub Copilot CLI, Gemini CLI (Windows), and Codex App (Windows), only GitHub provided substantive triage and a bounty, and every other vendor either dismissed the finding as “informative” / “expected behavior” / “not applicable” or left it unaddressed (Cymulate Part 2). AWS Kiro’s disposition — the LLM-to-config-write finding closed as behavior that is “intended, with no remediation indicated” — is the same shape as OpenAI’s “out of scope” and Cursor’s “lacks an attack vector”: the harness-specific failure mode is repeatedly classified as not-a-vulnerability.

The “comment and control” episode is the cleanest single illustration, because it ran the same finding past three vendors simultaneously. Anthropic, Google, and Microsoft each paid a bounty (reported at $100, $1,337, and $500 respectively) on a critical GitHub-comment prompt-injection-to-credential-theft chain affecting Claude Code, Gemini CLI Action, and Copilot Agent — and none assigned a CVE or published an advisory (The Register). The finding carried a CVSS 9.4 against Claude Code per trade-press coverage — yet still drew no CVE and no public advisory (cyberpress). Guan’s summary of the user-facing consequence is the one to carry forward: “If they don’t publish an advisory, those users may never know they are vulnerable – or under attack” (The Register).

8. OpenClaw is the counter-example, and it’s instructive

The open-source OpenClaw fork is worth holding up as the contrast case, because its disclosure posture is the inverse of the proprietary harnesses on exactly the dimension that matters. OpenClaw has accumulated a long ledger of named, CVE-tagged disclosures since its launch — the “Claw Chain” cluster of four flaws (CVE-2026-44112, CVE-2026-44113, CVE-2026-44115, CVE-2026-44118) was disclosed with CVEs and CVSS scores and fixed in OpenClaw version 2026.4.22 (The Hacker News), and additional researcher disclosures land through public, attributed advisories (Infosecurity Magazine). It would be wrong to read a high CVE count as “OpenClaw is less secure than Claude Code” — the visible CVE count is partly a function of transparency, not just defect density. An open-source project that files an advisory for every finding will always have a scarier-looking CVE ledger than a proprietary vendor that silently patches. The practitioner takeaway is uncomfortable: the harness with the most alarming public vulnerability count may be the one you can actually track, and the harness with a clean CVE history may simply be the one not telling you. CVE count is a transparency signal at least as much as a security signal, and conflating the two is a procurement error.

Practical Implications

A practitioner advisory map with disclosure-cadence ratings

The ratings below grade disclosure behavior — CVE-against-the-installed-product, release-note transparency, and customer notification — not the underlying security of each harness. They are an editorial synthesis of the reporting cited throughout, as observed through late May 2026, and they describe the sandbox / harness / network-allowlist / prompt-injection finding class specifically, which is where the variance lives. Headline RCE disclosure is more uniform and better across all vendors.

GitHub Copilot CLI — strongest, partly by accident of distribution. Ships as an npm package, so product-level CVEs land in the GitHub/npm advisory databases that scanners already watch. Weakness: research-grade binary-hijacking findings still get the slow-lane “no committed timeline” treatment.
Cursor — strong. Publishes product-named CVEs in coordination with researchers, documented disclosure intake, fixes tied to version numbers. Weakness: some sandbox-config findings closed as “lacks an attack vector.”
Gemini CLI — split. Reliable, fast GHSA advisories for max-severity RCE; inconsistent-to-absent on sandbox-isolation and prompt-injection findings, with at least one 90-day deadline expiring unpatched.
Codex CLI — split. CVEs and fast fixes for clear RCE and token-compromise; “informational” / “out of scope” disposition for the sandbox-configuration and prompt-injection class.
Claude Code — weakest on the harness class, despite strong RCE discovery elsewhere. Two consecutive network-sandbox bypasses patched with no product CVE, no security release note, and no user notification; the one CVE that exists names an upstream library most users don’t track. Anthropic’s formal CVD program covers vulnerabilities Claude finds in others’ code, not its own harness.
OpenClaw — most transparent, scariest-looking ledger. Active advisory program, CVE-per-finding. High CVE count reflects transparency as much as defect density; read accordingly.

What to do about it

Treat absence of a CVE as absence of evidence, not evidence of absence. For any harness in production, the diligence question is no longer “does it have open CVEs” but “does this vendor assign CVEs against the product I install, and does it flag security fixes in release notes.” For Claude Code specifically, that answer is currently “not reliably for the sandbox class” — so the changelog is not a sufficient signal that an upgrade is security-relevant.
Pin to the installed product and its security-bearing dependencies in your SBOM. The upstream-library-CVE gap means a scanner keyed only to the product name will miss findings filed against a runtime, proxy, or sandbox library. For Claude Code, that means tracking @anthropic-ai/sandbox-runtime advisories separately. Map each agent to the libraries that actually enforce its isolation, and watch those advisory feeds too.
Adopt an assume-silent-patch posture for the harness layer. Because the sandbox/allowlist class is the documented blind spot across multiple vendors, treat any harness upgrade as potentially carrying an undisclosed security fix. Practically: when a coding-agent CLI ships a new version, diff the network-isolation and sandbox behavior rather than trusting the release notes, and rotate credentials reachable through the agent’s egress on a cadence that doesn’t depend on a vendor advisory ever arriving. Guan’s operational point — that a team on a wildcard allowlist for five and a half months got “no email, a banner, or a deprecation warning” — is the failure to design around.
Subscribe to the independent-researcher feeds as primary advisory channels. For the harness/sandbox/prompt-injection class, the most timely and complete signal is coming from independent researchers and security firms, not vendor advisory pages. The watch-list below is the practitioner’s substitute for advisories the vendors are not publishing.

The watch-list: independent advisory channels worth monitoring

These are the channels that surfaced the findings above before — or instead of — the vendors. For the coding-agent harness class specifically, this set is closer to a complete advisory feed than any single vendor’s security page.

Aonan Guan — oddguan.com/blog. The single most consistent source on the silent-patch pattern itself. Both Claude Code sandbox bypasses, the “comment and control” cross-vendor GitHub-comment prompt-injection chain, and “Agent SkillSlip” path-traversal across Gemini CLI / Claude Code / Vercel add-skill all originate here. Lead Cloud & AI Security at Wyze; no RSS feed advertised, so monitor the blog index directly.
Cymulate — cymulate.com/blog (“The Race to Ship AI Tools Left Security Behind,” Parts 1 and 2). The broadest cross-product audit, covering Claude Code, Gemini CLI, Codex CLI, Cursor, Copilot, and AWS Kiro, and the most explicit on which vendors dismissed findings. The single best source for relative disclosure behavior across the field.
Pillar Security — pillar.security/blog. Native-tool and prompt-injection-to-RCE class: the Antigravity find_by_name / -X exploit and the CVSS 10.0 Gemini CLI CI-RCE both came from here. Strong on the IDE-agent surface.
Ona — ona.com/stories. The behavioral-escape angle (Claude Code reasoning past its own denylist and sandbox) and the content-hash-enforcement defense (Veto / BPF LSM). Less a vulnerability-disclosure feed than an architecture-and-defense feed, but the threat-model framing is the field’s reference.
Novee Security — novee.security/blog, and BeyondTrust Phantom Labs — beyondtrust.com/blog. Coordinated CVE disclosures, often the named researchers behind Cursor and Codex CVEs. Useful as the “what got a real CVE” counterweight to the silent-patch feeds.
The Register security desk and SecurityWeek. The trade-press outlets that actually press vendors for comment and report the bounty-paid-but-no-advisory dispositions. The Register’s coding-agent security coverage in particular has been the venue that surfaces the disclosure-practice story rather than just the technical finding.
The GitHub Advisory Database and the npm advisory feed, filtered for @github/copilot, @anthropic-ai/sandbox-runtime, and the relevant agent packages. This is where the product-level and upstream-library CVEs actually land, and where an assume-silent-patch SBOM process should be wired in.

Open Questions

Whether any vendor adopts product-level CVE assignment for the harness class. The upstream-library-CVE gap is the structural mechanic that makes “a CVE exists” unhelpful. Whether competitive or regulatory pressure pushes any coding-agent vendor to assign CVEs against the installed product for sandbox/allowlist defects — rather than against an upstream library — is the open governance question. No vendor has publicly committed to this for the sandbox class as of late May 2026.
Whether the “prompt injection is out of scope” disposition holds. OpenAI, Cursor, and AWS have each, in different words, classified a prompt-injection-or-sandbox-config finding as expected behavior or out of scope. Whether that disposition survives the first publicly-attributed production breach traced to one of these unpatched findings is unresolved; the incentive to reclassify will change sharply if an exploit lands in the wild.
The relationship between transparency and apparent defect density. OpenClaw’s high CVE count versus Claude Code’s near-empty product-CVE ledger illustrates that public vulnerability counts conflate transparency and security. Whether the market learns to read CVE count as a transparency signal — or continues to reward silent-patching with a cleaner-looking record — is an open question about procurement sophistication, and reporting that disentangles the two for buyers remains thin.
Vendor patch cadence on the dismissed findings. Several Cymulate-reported findings (Gemini CLI filesystem isolation, Codex CLI config poisoning, the Windows binary-hijacking class across products) remained unpatched at the time of reporting. Whether and when these get addressed — and whether any disclosure accompanies the fix — is the direct follow-up worth tracking through 2026-H2.
Whether independent-researcher coverage is durable. The watch-list above is load-bearing precisely because vendor advisories are not. That model depends on a small number of researchers and firms continuing to fund this work, much of it for sub-$1,000 bounties. Whether the coverage breadth holds as the number of harnesses and the disclosure-fatigue both grow is an open sustainability question for the practitioner’s primary signal source.