Most AI Coding Tools Fix Security Bugs Without Advisories

On September 2 at 17:19 UTC, Hermes Agent's release lead opened a pull request titled "GitSpawn RCE no longer executes from a malicious repo's .git/config (GHSA-7x36-8jrh-v4pw)". He merged it fourteen minutes later.

Manifold Security had published GitSpawn the day before: eight findings across seven command-line AI coding agents. By then the Hermes report had been sitting privately for 44 days, through what the firm's disclosure log describes as six contact attempts over five channels, none of them triaged.

The patch itself took a day once the report was public. The release that carried it, five days later, never uses the word security. The CVE was issued by a company with no connection to Hermes. And GHSA-7x36-8jrh-v4pw, the advisory identifier the vendor printed in its own pull request title, returns a 404.

We re-checked every tool in that disclosure on September 13 against primary records: fix commits and their git ancestry, release tags and notes, MITRE CVE records, NVD, the GitHub Advisory Database, the OSV database behind most dependency scanners, and CISA's catalog of known exploited vulnerabilities. Every status below is as of that date, and this story ages faster than most.

The mechanism is already public and we covered it when the disclosure landed: a malicious git config can hijack your AI coding agent, including the clone-versus-copy distinction and what to actually do about it. Nothing here adds operational detail. The subject is what the vendors did after they wrote the fix.

Where each of the seven stood on September 13

Speed was not the problem. Most of these vendors patched quickly once they engaged, and one had already fixed the bug before Manifold got there. A quiet fix is also not a negligent one; security work ships in ordinary commits all the time, for ordinary reasons. What is thin, in almost every case, is the public record the fix left behind.

Two caveats on that table. Everything in the "reported" and "duplicate" columns comes from Manifold, which disclosed the findings and is an interested party, and cannot be independently confirmed. Grok Build is the one row we could only half check. Its repository, `xai-org/grok-build`, is public, and the CLI ships on npm as `@xai-official/grok`, but nothing in that public record establishes whether the reported finding is fixed, and testing it ourselves is not what this piece does. The only claim about its status is still Manifold's, dated September 1. What is checkable is the paper trail, and the paper trail is thin: there is a `SECURITY.md`, no published advisory, no CVE, and zero results in OSV for the package.

Everything else in the table was verified against vendor-side records directly.

GHSA-7x36-8jrh-v4pw returns a 404

The Hermes pull request and its merge commit both cite GHSA-7x36-8jrh-v4pw. GitHub's advisory API returns `{"message":"Not Found","status":"404"}` for that identifier, and the public advisory page 404s as well. The CVE record for the same bug does not reference the GHSA anywhere in its citation list; it points to Manifold, the pull request, the commit and VulnCheck.

A GHSA ID appearing in a commit message usually means someone opened a draft advisory in the repository's security tab, since GitHub allocates the identifier at draft time. A draft that is never published never gets a public page, never reaches the GitHub Advisory Database, and never syncs onward to OSV.

Manifold's account supplies a detail that fits. One of the five channels it says it tried was a private GitHub advisory, and it writes that "the private GHSA advisory was never triaged." Opening a private report allocates a GHSA identifier, so on Manifold's telling the ID quoted in the fix is most likely that report, referenced in public and never published. That chain is TechCurrent's reading. It rests on the disclosing party's own account of its contact attempts, and GitHub does not expose draft state, so we cannot confirm it. The verifiable part is narrower: the identifier is printed in two public places on the vendor's own repository, and it leads nowhere.

The repository, for what it is worth, has a `SECURITY.md`. It has zero published security advisories.

The CVE tells a similar story from the other end. CVE-2026-71963, CVSS 4.0 8.6 High, CWE-78, was reserved on August 8 and published on September 3. The assigner is VulnCheck, a third-party CNA. August 8 is three and a half weeks before the disclosure went public and, on Manifold's account, while the vendor was still not responding. An outside organization was performing the vendor's role in the CVE system before the vendor had said a word.

VulnCheck's own advisory page says nothing about vendor contact or coordination, so the only account of the silence remains Manifold's. There is corroboration of the pattern from an unrelated reporter, though. Ten older advisories in the GitHub Advisory Database affect `hermes-agent`, all of them published in May and June, and one of them, GHSA-238w-f66p-w349, states plainly that "The vendor was contacted early about this disclosure but did not respond in any way." None of those ten is the GitSpawn CVE. Ten advisories reached the database that developers query. The eleventh bug, the one the vendor patched itself, did not.

Hermes did ship the fix. Checking git ancestry rather than trusting the notes, the merge commit is absent from 0.21.0 and present in 0.21.1, released September 7 under the tag `v2026.9.7`. The v0.21.1 notes describe themselves as a rollup: "This patch does not attempt to enumerate or announce every feature in the window." They mention 5,139 non-merge commits and 632 merged pull requests. They do not mention security, git config, a CVE or an advisory.

The project does label security work in release notes when it decides to. The release immediately before this one, v0.21.0 on August 31, carries a heading reading "Security & Reliability" and a bullet on protected agent-instruction files now always requiring write approval. Earlier releases in 2026 carry the same heading. The release containing the GitSpawn fix does not use the word security once, and neither it nor v0.21.2, which followed on September 11, mentions git config, the CVE or an advisory.

There is one more piece of friction, small but real. Hermes tags releases by date (`v2026.9.7`) and names them by semver ("Hermes Agent v0.21.1"), while the CVE's affected range is expressed in semver, 0.18.2 through 0.21.0. A developer holding a checkout tagged `v2026.8.31` has to already know those are the same numbering scheme to work out whether they are exposed. Separately, the `hermes-agent` package on npm is not the vendor's: it is an unofficial third-party bridge, and Hermes itself distributes from GitHub and PyPI.

Qwen Code shipped four releases without the fix

Qwen Code's fix merged to `main` on September 12 at 21:25 UTC, in PR #11669, titled "fix(core): guard internal git calls against configured helper programs".

Neither the commit title nor the long commit body uses the words security, vulnerability, CVE, advisory, GitSpawn or Manifold. The PR description uses two of them, once each, both in passing: a note that one guard "has nothing to do with security," and an out-of-scope caveat beginning "whether the vulnerability is reachable before authentication." No CVE, no advisory, no mention of the disclosure or the firm that made it, and no credit to a reporter anywhere. The engineering itself is documented carefully, at length, in two languages. The PR opens: "Internal Git calls disable configured fsmonitor helpers, external diff/textconv programs, and signature programs at the relevant command boundaries." The commit body even states the underlying problem in one line: "A repository can name a program in its own .git/config and have git run it on the next index refresh." It never says where that line came from.

The version timeline is the harder fact. Qwen Code was not sitting frozen while it worked on this. Between the public disclosure and the fix it shipped four stable releases: 0.23.0 on September 3, 0.23.1 on September 8, 0.23.2 on September 9, and 0.23.3 on September 10. GitHub's compare API confirms the fix is contained in none of them. It is not in the nightly published 38 minutes after the merge either, because that nightly was cut from a commit dated 19:56 UTC, earlier the same evening. As of September 13, the fix exists in `main` and nowhere a user can install from.

Manifold's log records the Qwen Code report as accepted by Alibaba SRC on July 7. If that is accurate, the vendor's security response team acknowledged the report 67 days before the fix reached `main`, and the last 11 of those days ran with the bug already public. The repository has a `SECURITY.md` and zero published advisories. We found no advisory from Alibaba SRC either, though a regional bulletin outside the databases we checked would not have shown up in our results.

Claude Code has 30 published advisories and none for this

anthropics/claude-code has 30 published security advisories. Seven of them cover this precise class of bug: trust dialog bypasses and repository-controlled configuration causing execution, going back to CVE-2025-59041 in September 2025 and running through CVE-2026-55607 in June. Each one carries a CVE, a CVSS score, an affected range and a credit. It is a mature practice, and better than anyone else's in this disclosure, which is why the two silences here are worth stating precisely.

The most recent of those 30 was published on June 25. None has appeared since, and none covers either GitSpawn finding.

The first finding was fixed fast. Manifold reported it on June 26, and by 2.1.196 on June 29 it re-tested and found it gone. Manifold's own table, though, records that report as closed as a duplicate of a report filed earlier the same day, so the three-day turnaround is real while the causal story is not established. The second finding, involving a different command path, was closed as a duplicate of an internal ticket and recorded as still unpatched at 2.1.252.

There is a relevant changelog entry. Claude Code 2.1.265, released September 8, includes this bullet: "Fixed Claude Code's own git status and diff probes running clean filters configured by a nested repository inside the working tree." It sits among roughly fifty undifferentiated bullets, with no security label, no CVE, no advisory and no credit.

Whether that entry is the withheld finding, a different one, or unrelated internal hardening, we do not know and will not guess. Manifold deliberately withheld the configuration key while it was unpatched, and speculating in public would undo exactly the restraint the disclosure showed. What can be said is narrower: no advisory, no CVE, no security label, and no public confirmation that the reported finding is fixed.

Release cadence is not the constraint. Claude Code shipped a new version on almost every one of the twelve days this finding sat unconfirmed.

OSV returns zero vulnerabilities for three of these packages

A fix nobody told you about should still reach you through tooling, so we queried the databases that dependency scanners actually read.

You cannot subscribe to a fix that has no advisory. GitHub's watch-for-security-advisories feature is per repository and fires on published advisories; Hermes and Qwen Code have published none, so there is nothing to subscribe to.

The CVE does not fill the gap. CVE-2026-71963 exists, but it reaches your scanner only if something maps it to a package and version you have installed. In OSV its affected block is a git commit range, in NVD it has no CPE, and almost every scanner in real use matches on package name and version. Nothing maps it. NVD lists it, and CVE-2026-72718, as "Deferred", which is NVD's label for records it does not plan to enrich further and not a comment on severity.

The CVE may also not be in your scanner's database at all. OpenAI published CVE-2026-19592 through its own CNA on September 1, with a full fixed-version matrix across four distribution channels, and OSV returns "Vulnerability not found" for it.

So you are left reading commit logs, and the commits do not say security. Qwen's says "guard internal git calls against configured helper programs." Anthropic's says "clean filters configured by a nested repository." Which sends you to the release notes, and Hermes's say they do not attempt to enumerate or announce every feature in the window.

For two of these tools, the only dependable way to learn you had been running a vulnerable version was to read a security company's blog post.

That gap matters more here than it would for an ordinary command-line tool, because the configuration surface around these agents is already being attacked. The npm worm that spread in August persisted through Claude Code and VS Code hook settings, not through a code bug.

On exploitation, the honest answer is that nobody has claimed any. None of the three CVEs appears in CISA's Known Exploited Vulnerabilities catalog, which had 1,709 entries when we checked. That is not evidence of no exploitation. It means CISA has not added them.

goose published its advisory eleven days after the report

goose received the report on July 13, per Manifold. On July 24 it published GHSA-r5pp-p5r8-466r with the fix already shipped in 1.44.0 the day before, the reporter credited on the advisory, and CVE-2026-72718 assigned by GitHub as CNA.

Because that advisory exists, the CVE is aliased in OSV, discoverable in the GitHub Advisory Database, and watchable from the repository's security tab. goose ships as a binary rather than a package, so its OSV entry is a git range too, exactly like the Hermes record. The alias is what makes the difference. Nothing about goose's engineering made this easier; the difference is procedural.

Publishing the draft advisory is one button

Every step below is one that another vendor in this same disclosure already takes.

Hermes already had a GHSA allocated, and publishing it syncs automatically to the GitHub Advisory Database and onward to OSV. That is the highest-leverage step in the chain. A CVE only becomes something a scanner can act on when its affected block names a package and a version range; a git hash is a document. Anthropic and Hermes both use security labels in release notes elsewhere, and one prefix on one changelog bullet is the difference between a discoverable fix and a silent one. A merge to `main` is not a mitigation for anyone installing from a registry, so the announcement belongs with the release rather than the merge.

That leaves the identifier itself. OpenAI and GitHub both act as CNAs; Hermes's CVE came from VulnCheck instead, from nobody closer to the code. A third-party CNA filling that gap is a healthy backstop. As a default it is not.

The standing objection is that tools shipping several times a week cannot carry the disclosure norms of infrastructure software. Claude Code shipped twelve releases between September 1 and September 12 and has published thirty advisories, so cadence is not what stops it.

goose went from report to published advisory in eleven days. Twelve days after GitSpawn went public, the identifier in Hermes's own pull request title still returns a 404, and Qwen Code's fix is still sitting in a branch nobody can install from.

“For two of these tools, the only dependable way to learn you had been running a vulnerable version was to read a security company's blog post.”

Reporting by TechCurrent Staff · TechCurrent