Ghost CVE-2026-26980: Exploited SQL Injection Fixed in 6.19.1

Anthropic’s 225-CVE tally measures disclosures, not attacker demand​

According to The Register, Garrity began tracking vulnerabilities credited to Anthropic or Project Glasswing shortly after the initiative’s April announcement. His tracker compares those records with VulnCheck’s known-exploited-vulnerability index. As of September 21, the comparison reportedly produced one match: CVE-2026-26980, a critical SQL-injection vulnerability in Ghost. The September tally rests on Garrity’s findings as reported by The Register; the other available coverage repeats that reporting rather than independently confirming the count.

That method answers a specific and useful question: how many vulnerabilities in this attributed collection also have recorded evidence of exploitation? It does not establish that attackers considered the remaining 224 and rejected them. Nor does an absence of recorded exploitation establish that none has occurred. “One with confirmed exploitation” is the supported finding; “attackers are uninterested in AI-discovered vulnerabilities” would require evidence about attacker behavior that this count does not provide.

The collection’s attribution boundary matters just as much. Garrity is tracking CVEs—public identifiers for disclosed vulnerabilities—credited to the Anthropic team and/or Project Glasswing. That is broader than a list of defects independently discovered by Claude Mythos Preview. The reporting does not establish that all 225 came from the same model, involved the same degree of automation, or followed the same research process. Treating the collection as a controlled test of Mythos would therefore overstate what it measures.

Garrity’s interpretation is that discovery does not automatically translate into utility for threat actors. “There's a big difference between finding vulnerabilities and whether they're actually useful to and will be used by threat actors,” he told The Register. He put the historical proportion of vulnerabilities weaponized and used in the wild at just under one percent to two percent, and said the Anthropic-linked findings did not appear to produce different threat outcomes from other vulnerabilities. Those are his assessment and historical estimate, rather than a demonstrated statistical comparison in the published figures.

There is an additional reason to avoid declaring victory from the percentage. The September snapshot does not present a comparison group with matched disclosure dates, affected products, exposure, or observation periods. Without that information, 0.44 percent cannot establish that AI-discovered vulnerabilities are intrinsically less likely to be exploited. For administrators, the number is a useful correction to the assumption that every new discovery becomes an attack—not a replacement for assessing each relevant advisory.

Project Glasswing’s restricted preview changes the comparison​

Anthropic announced Project Glasswing on April 7, 2026, as a defensive initiative built around Claude Mythos Preview. Its launch announcement said the model had found thousands of high-severity vulnerabilities, including flaws in major operating systems and browsers, and could develop exploits for many findings with little human steering. Those were Anthropic’s capability claims. They described what the company observed in research, rather than a count of criminal campaigns or compromises.

The access model followed that risk assessment. Anthropic said it did not plan to make Mythos Preview generally available and instead provided a gated research preview to selected organizations. The launch partners included Microsoft, alongside companies such as Apple, Google, AWS, Cisco, and Palo Alto Networks. More than 40 additional organizations maintaining critical software infrastructure were also given access, according to Anthropic.

Microsoft’s participation makes this directly relevant to enterprise technology teams, but it needs the right scope. Anthropic lists Microsoft Foundry as an access route for participating organizations, alongside the Claude API, Amazon Bedrock, and Google Cloud Vertex AI. That does not establish that an ordinary Azure customer can enable Mythos Preview, or that the model is a generally available Windows security feature. The documented arrangement is restricted participant access for defensive work.

These boundaries complicate any attempt to compare Anthropic’s warning with the observed exploitation tally. The vendor warned about what advanced models could enable as their capabilities spread. Garrity’s count concerns recorded exploitation of a particular set of publicly attributed vulnerabilities during a period when Mythos Preview was restricted. A low count in that collection cannot by itself settle the broader question of what publicly available models with similar capabilities would enable. Equally, a warning about future capabilities does not demonstrate that the predicted increase in attacks has already happened.

The two accounts can therefore coexist without a manufactured contradiction. Anthropic reports a substantial increase in its ability to find vulnerabilities; Garrity reports limited confirmed exploitation among the CVEs his tracker associates with Anthropic and Glasswing. For IT departments, the immediate consequence is a potentially larger flow of advisories to evaluate. Whether any individual advisory deserves emergency treatment still depends on the affected software, the impact, the available fix, and evidence of exploitation.

Ghost CVE-2026-26980 makes the aggregate percentage personal​

The Ghost vulnerability is the strongest practical example because its advisory establishes both the affected scope and the available response. The GitHub-reviewed advisory for CVE-2026-26980 identifies an unauthenticated SQL-injection vulnerability in Ghost’s Content API, affecting versions 3.24.0 through 6.19.0. Ghost 6.19.1 contains the fix. The documented impact is that an attacker could read arbitrary data from the database, including site API keys.

SQL injection occurs when attacker-controlled input can alter a database command instead of being handled purely as data. Here, the important operational detail is that the vulnerable interface did not require an authenticated staff account. The advisory also explicitly warns that the Content API key is public by design. Restricting access to that key is therefore not an effective mitigation for this vulnerability.

The advisory’s chronology provides a useful correction to the idea that the September tracker is solely a measure of Project Glasswing’s output. Ghost’s advisory was published in February, before Glasswing’s April 7 launch, and credits “Nicholas Carlini using Claude, Anthropic” for responsible disclosure. It does not identify Mythos Preview as the model used. The exploited exception therefore supports the broader description “Anthropic-linked”; it should not be relabeled as proof that attackers exploited a flaw discovered by the subsequently announced Glasswing program.

For affected Ghost operators, the supported response is concrete:

1. Establish whether the deployed Ghost version falls within 3.24.0 through 6.19.0. Those are the versions the advisory identifies as vulnerable; a generic reference to “Ghost” is not enough to determine whether an installation remains affected.
2. Upgrade to a fixed release. Version 6.19.1 contains the correction for this issue, and the advisory recommends keeping Ghost on its most current version. That fixed-version floor addresses this CVE; it is not a claim that an older fixed release contains every subsequent security update.
3. If an upgrade cannot be completed immediately, consider the advisory’s temporary reverse-proxy or web-application-firewall mitigation. It calls for blocking Content API requests whose query-string filter parameter contains slug%3A%5B or slug:[. The advisory warns that doing so can break legitimate slug-filter functionality, and it provides no application-level workaround.
4. Review staff users and rotate keys, as the advisory recommends, because the vulnerability can expose a site’s API keys. Installing the fix addresses the vulnerable code path; it does not establish that previously accessible secrets remained private.

The temporary filter rule deserves careful handling. A web application firewall, or WAF, can inspect and block requests before they reach the application, but the advisory specifies matching conditions rather than a universal configuration command. Rule syntax and query decoding vary by reverse proxy and WAF, so presenting one copy-and-paste rule for every installation would be unsafe. Its documented role is a temporary mitigation with a functional trade-off, not a substitute for upgrading.

This is where the headline percentage stops being the decision-maker. For an organization running an affected Ghost release, there is a documented unauthenticated database-exposure issue, a fixed version, and a report of exploitation in the wild. The other 224 entries in Garrity’s collection do not reduce that organization’s exposure. Conversely, the Ghost case does not establish that attackers used Mythos, obtained a model-generated exploit, or relied on Anthropic’s research to develop their attack.

Glasswing’s findings pass through several different filters​

Anthropic’s own initial update helps explain why discovery totals and public CVE counts should not be treated as interchangeable. In its update dated May 22, the company said it and approximately 50 partners had found more than 10,000 high- or critical-severity vulnerabilities. It also described a separate effort scanning more than 1,000 open-source projects. These are vendor-reported research results, rather than an independent inventory of every confirmed vulnerability.

The open-source figures show several distinct stages of evaluation. Mythos Preview initially estimated that it had found 23,019 vulnerabilities, including 6,202 rated high or critical. Of 1,752 initially high- or critical-rated findings that had undergone assessment, Anthropic reported that 1,587 were valid vulnerabilities and 1,094 were confirmed as high or critical. The company said six independent security research firms performed most of that assessment, with Anthropic handling a smaller portion.

Those figures separate two tasks that are easy to conflate. First, a researcher must determine whether a reported defect is real. Second, the researcher must determine whether its severity matches the initial assessment. A valid vulnerability can receive a lower severity rating after review; that does not make it a false positive. Equally, a model’s initial severity label is not a completed technical assessment.

Anthropic describes a process that reproduces issues, reassesses severity, checks whether fixes already exist, and prepares detailed reports for maintainers. Its update also says some maintainers requested direct disclosure without the additional assessment stage. That variation is another reason not to treat every finding in a headline total as having undergone an identical process. The vendor’s large research totals and Garrity’s 225 public, attributed CVEs are different collections at different stages; dividing one by the other would not produce a meaningful success rate.

The practical bottleneck appears in Anthropic’s own account. It says some maintainers were severely capacity-constrained and asked the company to slow disclosures so they could develop patches. That supports a narrower, more useful conclusion than either “AI has solved vulnerability research” or “the findings do not matter.” Producing a credible report, designing a correction, releasing it, and getting it deployed remain separate jobs, and increasing the rate of discovery increases the work entering those stages.

AI-generated patches do not remove the remediation workload​

The distinction between finding a defect and fixing it also appears in the research cited by The Register. The publication reports that a 1Password study examined 6,080 patches generated by OpenAI’s ChatGPT-5.5 and Anthropic’s Opus 4.8, with complete remediation in 26 percent of cases. It separately reports a Veracode study spanning more than 100 models and 80 coding tasks, with an average security pass rate of 56 percent. These figures are reported results from different evaluations, not independently verified measurements here or direct tests of Mythos Preview.

They should not be combined into a single score for “AI security.” A study of proposed vulnerability fixes asks whether a patch resolves an existing defect. A study of generated code asks whether the output meets its security criteria. Different models, tasks, and evaluation conditions can answer different questions. Neither percentage establishes the failure rate an organization will experience in its own development pipeline.

Anthropic’s account supplies more direct support for the operational conclusion: remediation involves additional work even after a vulnerability is found. Its triage process requires reproduction and human reassessment, and its update describes patch design and deployment as continuing constraints. A proposed code change is one input to that process. Counting the proposal as a completed remediation would erase the very stages the company says are limiting progress.

For development managers, the implication is to measure completed security work rather than generated output. A discovery count records intake. A confirmed finding records validation. A released fix records a maintainer’s response, while a deployed fix records a change to the systems an organization actually operates. This is an analytical distinction drawn from the documented workflow, not a new benchmark: each measure describes a different outcome, and none can safely substitute for all the others.

The same distinction helps procurement teams assess claims about AI security tools. An advertised increase in findings may be valuable, but it does not establish a corresponding reduction in unresolved exposure. Evidence that findings are valid, that proposed fixes are effective, and that teams can absorb the resulting work is closer to the outcome a buyer needs. Glasswing’s own account gives defenders a reason to ask about those downstream stages without dismissing the discovery capability.

Enterprise patch priorities should follow the affected deployment​

Keep the existing distinction between an advisory that requires urgent action and one that belongs in the normal remediation queue; the fact that AI helped discover it should not decide the category. Garrity’s tally offers a reason to resist treating all Anthropic-linked CVEs as emergencies. The Ghost advisory offers an equally strong reason to avoid treating the low overall exploitation percentage as permission to wait.

For Windows and enterprise administrators, Microsoft’s Glasswing participation is context, not a product-specific deployment instruction. The September report does not identify a Windows build, a Microsoft KB, or an Entra or Intune policy that changes the response. A relevant third-party application still needs to be evaluated on its own version and advisory. Likewise, access to Microsoft Foundry does not establish access to the restricted Mythos Preview.

The useful actions follow directly from those boundaries:

• Match each relevant advisory to software and versions the organization actually operates, rather than assigning urgency from the Anthropic or Glasswing attribution alone.
• Give the reported exploitation of Ghost CVE-2026-26980 weight when scheduling remediation for affected Ghost installations, and use 6.19.1 as the documented fixed-version floor for that vulnerability.
• Do not treat a hidden or restricted Ghost Content API key as protection against this flaw; the advisory explicitly says the key is public by design.
• Use Ghost’s reverse-proxy or WAF mitigation only as a temporary measure, with the documented risk of breaking legitimate slug filtering.
• Keep model findings, validated vulnerabilities, proposed fixes, released patches, and deployed corrections separate in internal reporting, so a rising discovery count does not masquerade as either an attack count or completed remediation.

For teams evaluating AI-assisted code review, the purchasing and staffing decision is consequently broader than model access. Anthropic’s reported experience suggests that additional discovery capacity must be matched with capacity to validate reports and deliver fixes. For teams consuming software rather than developing it, the decision is more immediate: establish applicability, follow the vendor’s supported remediation, and do not infer safety from an aggregate statistic.

The September snapshot supports a measured conclusion: Anthropic-linked vulnerability disclosures have accumulated faster than confirmed exploitation has appeared in Garrity’s tracked collection. It does not settle the future threat from more capable models, and it does not diminish the urgency of an exploited flaw in software an organization runs. The concrete security benefit will come from turning validated findings into deployed corrections; for affected Ghost operators, that work already has a documented starting point.