SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

CVE-2026-61500 was fixed on 13 July. Exploitation was reported 80 days later, within 39 hours of a write-up

Rejetto fixed the HFS session-forgery flaw in 3.2.1 on 13 July. VulnCheck says it saw exploitation on 1 October, at most 38 hours 58 minutes after Horizon3 published how an AI model found it, and no source says who attacked.

By Parminder Kumar Sharma · · 20 min read

Editorial illustration for the briefing: CVE-2026-61500 was fixed on 13 July. Exploitation was reported 80 days later, within 39 hours of a write-up

The gap that matters is 80 days, and the gap everyone quotes is 39 hours

VulnCheck's Patrick Garrity posted at 00:57 UTC on Friday 2 October that his firm had started detecting exploitation of CVE-2026-61500, a session-forgery flaw in the Rejetto HTTP File Server (HFS). Horizon3's write-up on how an AI model found the flaw carries a publication time of 10:00 UTC on Wednesday 30 September. The difference is 38 hours 58 minutes, and because the post says detection began 'this evening', that is the longest the gap can have been (derived). The fixed release, HFS 3.2.1, was published on GitHub at 15:31 UTC on 13 July, which is 80 days 9 hours before the post (derived).

What that does not establish. It does not say who attacked, or that the attacker read Horizon3's write-up or watched its video: neither VulnCheck nor The Register says so, and the CVE record had described the mechanism in one sentence since 13 July. It does not say how many hosts were hit or whether any was compromised. It does not show that 'found by an AI model' changed the risk to a defender: the weakness class is old, and the AI claim is Horizon3's own. And the exploitation evidence is one security firm's account of its own sensors, from a firm that also runs the catalogue listing the flaw as exploited and sells the data.

The Register's report of 3 October, which pointed us to the story, frames a new bug 'under attack'. The record shows an old fix. Six CVEs were published on 13 July alongside HFS 3.2.1, and every server running HFS 3.0.0 to 3.2.0 has had all six flaws open for as long as it has run one of those builds. The sections below keep what each source states apart from what it leaves open.

The record, to scale

Two timelines to scale, UTC. Upper: 82 days from the HFS 3.2.1 release on 13 July 2026 to 3 October, with an 80 days 9 hours bracket to VulnCheck's post on 2 October. Lower: 26 September to 3 October, showing a public repository on 26 September, Horizon3's write-up on 30 September, HFS 3.3.4 that afternoon, VulnCheck's KEV date on 1 October, its post at 00:57 on 2 October, and The Register on 3 October. A bracket shows at most 38 hours 58 minutes from write-up to post.
Drawn from GitHub release data, CVE.org, Horizon3's page metadata, Garrity's LinkedIn post and VulnCheck's tracker data, and The Register. Both panels are to scale.

On the 82-day scale, everything public about exploitation or a proof of concept that we found sits in the last eight days, days 75 to 82 after the fix. The record cannot show whether anyone used the flaw earlier: VulnCheck's own sensors are the only source, and they report from 1 October. A public repository that calls itself a proof of concept and lab for the CVE was created on 26 September, four days before the write-up. We read its metadata only. We did not open, run or link it, so we cannot say whether it works. Horizon3's write-up and a video followed on 30 September. HFS 3.3.4, which the project describes only as 'Security fixes', was released 3 hours 48 minutes after the write-up's stamped time (derived).

The write-up's 10:00 UTC is the page's own metadata. The same page carries an earlier 'modified' stamp of 20:07 UTC on 29 September, which suggests the post was scheduled in advance. We have no second source for the minute it went live, and The Register says only 'Wednesday', so the 'at most' of 38 h 58 m rests on that stamp.

State of the records when read on Saturday 3 October 2026. Sources: CISA KEV feed, NVD API, CVE.org API, GitHub API, VulnCheck advisory page, Garrity's tracker repository.

  1. Record
    CISA KEV catalogue
    State when read
    Version 2026.10.02, released 2 October at 15:19 UTC, 1,733 entries. CVE-2026-61500 is not listed. Rejetto HFS appears twice, for older flaws (see below).
    Read (UTC)
    19:35, again 20:02
  2. Record
    NVD, CVE-2026-61500
    State when read
    Published 13 July 18:16 UTC, last modified 15 July, status Deferred (NVD has not analysed it). Scores of 9.8 (CVSS 3.1) and 9.3 (CVSS 4.0) are VulnCheck's. CISA-ADP, whose NVD source ID is 134c704f-9b21-4f2e-91b3-4a467353bcc0, adds only an SSVC entry dated 15 July: exploitation none, automatable yes, technical impact total.
    Read (UTC)
    19:34, again 20:02
  3. Record
    CVE.org, CVE-2026-61500
    State when read
    Published 13 July 17:21 UTC by VulnCheck as the numbering authority, reserved 10 July, last updated 1 October 15:20 UTC. The record does not say what changed. Credit: a Horizon3 researcher 'in collaboration with Claude and Anthropic Research'. The word Mythos does not appear.
    Read (UTC)
    19:35, again 20:02
  4. Record
    VulnCheck advisory page
    State when read
    Dated 13 July. Says the advisory is in the VulnCheck KEV database. The catalogue itself needs a community sign-in and was not read.
    Read (UTC)
    19:35
  5. Record
    Rejetto GitHub releases
    State when read
    3.2.1 published 13 July 15:31 UTC. Latest stable release is 3.3.4, published 30 September 13:48 UTC. A 3.4.0 alpha 2 pre-release followed on 1 October.
    Read (UTC)
    19:46, again 20:02
  6. Record
    Garrity's tracker
    State when read
    300 rows after its 3 October 16:30 UTC regeneration, 286 after its 2 October 19:25 UTC regeneration. Two rows are ticked as in VulnCheck's KEV.
    Read (UTC)
    19:36, again 20:02

One headline, six CVEs, no advisory

The Register names one CVE. The release that fixed it fixed six. The project's commit messages for 3.2.1 name CVE-2026-61500 to CVE-2026-61505. VulnCheck, as the numbering authority, published all six records on 13 July, each crediting the same Horizon3 researcher. NVD lists all six as Deferred, so every score below is VulnCheck's. Rejetto's 3.2.1 release notes name none of them: 'Multiple security vulnerabilities have been found in all previous versions, potentially allowing an attacker to gain administrative access to HFS.' The project's repository lists one published security advisory, from August 2025, and none for these.

The six CVEs fixed in HFS 3.2.1, as VulnCheck's CVE records word them. Sources: CVE.org and NVD records read on 3 October 2026. Scores are VulnCheck's, as numbering authority.

  1. CVE
    CVE-2026-61500
    What the record says
    Session-cookie signing key comes from a non-cryptographic generator, and login discloses outputs of that generator. A forged administrator session leads to code execution.
    CVSS 3.1 / 4.0
    9.8 / 9.3
  2. CVE
    CVE-2026-61501
    What the record says
    Admin panel shows log entries as HTML without sanitising. A failed login with a crafted username runs script in an administrator's browser when logs are viewed.
    CVSS 3.1 / 4.0
    6.1 / 5.3
  3. CVE
    CVE-2026-61502
    What the record says
    State-changing API requests are accepted by GET and exempt from the anti-CSRF check. Reachable through a logged-in administrator's browser, or without credentials from the server's own machine on default installs.
    CVSS 3.1 / 4.0
    4.3 / 5.1
  4. CVE
    CVE-2026-61503
    What the record says
    The login endpoint answers differently depending on whether the username exists, confirming valid names including the default admin.
    CVSS 3.1 / 4.0
    5.3 / 6.9
  5. CVE
    CVE-2026-61504
    What the record says
    File names are not escaped in the fallback 'basic' listing. Script runs in a viewer's browser. Needs upload permission or an open upload folder.
    CVSS 3.1 / 4.0
    5.4 / 5.1
  6. CVE
    CVE-2026-61505
    What the record says
    Path traversal through the lang query parameter reads certain JSON files outside the shared folders. Narrow pattern, limited impact.
    CVSS 3.1 / 4.0
    5.3 / 6.9

Three of the five siblings matter for the same reason as the headline. The records for 61501 and 61502 both describe routes to administrator action. The record for 61503 is the username check that Horizon3 says was part of its chain, and it says the check helps 'session-forgery attacks'. A team that patches to 3.2.1 closes all six together, which is why the version is the control and not the single CVE. Only 61500 is ticked as exploited in VulnCheck's tracker, and none of the six is in CISA's catalogue.

The mechanism, at the level a defender needs

The CVE record is one sentence long and already holds the whole class. HFS 3.0.0 through 3.2.0 derives the key that signs session cookies from Math.random(), the non-cryptographic generator in Node.js, and discloses outputs of the same generator to unauthenticated clients during login. A remote attacker can collect a small number of login responses, rebuild the generator's state, recover the key and forge an administrator cookie, which leads to code execution through the server_code configuration feature. The weakness is filed as CWE-338, use of a cryptographically weak pseudo-random number generator.

The mistake is two facts that each look minor alone: a predictable secret, and a leak of the source it was made from. Horizon3's point is that the model recognised the two as a chain. For a defender the lesson is older than any model: a signing secret and a leak of its generator should never share a process.

The fix. The public diff from 3.2.0 to 3.2.1 shows three changes that cut the chain, read in full for the three files involved: the cookie signing key now comes from the platform's cryptographic random source, the identifier handed out in the login step no longer comes from Math.random(), and login replies for unknown users now look like replies for known ones. The commit that fixes the signing key is titled with the CVE number and carries an author date of 10 July. The release followed on 13 July.

Why a restart matters. The release notes say nothing about sessions or restarts. The line the fix removed carries the developer's own comment that generating the key at start-up 'also invalidates existing sessions'. So the key is per process. That is inference from the source, not a vendor statement, and it has two consequences. Restarting an unfixed build only makes a new key from the same weak generator, so it is not a fix. And a fixed build that was updated on disk but not restarted still holds the old key in memory. The removed code also used a value from the COOKIE_SIGN_KEYS environment variable if one was set, so a deployment with its own strong key did not depend on the weak generator for it. We have not tested any of this.

Four steps. One: HFS builds its cookie-signing key at start-up from Math.random, a weak generator. Two: login gives unauthenticated clients raw outputs of that generator. Three: the CVE record says a few login responses let an attacker rebuild the key. Four: a forged administrator cookie is accepted and an admin feature runs script. Below: upgrading to 3.2.1 or later cuts steps one and two, limiting admin access by address probably cuts step four, restarting an unfixed build does not.
Drawn from the CVE record, Horizon3's write-up, the public 3.2.0 to 3.2.1 diff and HFS's config.md at 3.3.4. Inference is labelled in the figure.

Did 'found by AI' change the risk? Horizon3 says so. The record does not.

Who says it, and what they sell. The claim that Anthropic's Mythos model found this flaw is Horizon3's. Its write-up says the 'cryptographic weakness analysis agent' in its harness surfaced the flaw, and that Horizon3 has used Mythos since joining Project Glasswing in July. The write-up ends with an offer to book a demonstration of NodeZero, the platform Horizon3 sells. VulnCheck, whose researcher publicised the exploitation, sells exploit intelligence and runs the KEV catalogue that 'exploited' rests on. Anthropic's Glasswing page, dated 7 April, names eleven partners besides Anthropic, says access went to 'over 40' further organisations, and says Anthropic does not plan to make Claude Mythos Preview generally available. It does not name Horizon3, so Horizon3's membership rests on its own post. Anthropic, whose model and programme are being credited, has a stake too. None of these interests makes a statement false. Each is a reason to check a statement against something that does not sell it.

What the records credit. The CVE records, the 3.2.1 release notes and VulnCheck's advisory credit the researcher 'in collaboration with Claude and Anthropic Research'. The word Mythos appears in Horizon3's write-up and in Garrity's LinkedIn post, not in the CVE record. That is not a contradiction, and it is why this briefing attributes 'found with Mythos' to Horizon3.

Was the class new? No. Horizon3 itself says it had met insecure cryptographic usage many times and dropped the research for want of mathematical expertise and for economics, and that the model removes both obstacles. It adds that it does not recall seeing this kind of attack on a cryptographic flaw in a real application. Those are claims about cost and about its own experience, made by a pentesting vendor, with no independent measurement and no survey. CVE.org shows the number reserved on 10 July, just under three days before the release and 81 days before the write-up (derived). Whatever the model did, disclosure ran through a conventional process: a human researcher, a numbering authority and a fix before publication.

What it changes for a defender. For this flaw, nothing: it needs no credentials, it runs over the network and a fixed build exists. What the claim may change is how many flaws of this kind exist and how soon after disclosure they are weaponised. That is a forecast, and this case offers one data point and no rate, because the sources do not say whether the attacker used the write-up, the video, the diff, the CVE text or something else. Our briefing on a public test of an Apple flaw made the same point: a public test changes who can reach the trigger, not the evidence on who was attacked. Our briefing on DIVD's breach separated how a door was opened from how the intruder was run, and the same separation applies between how a flaw was found and how it is being used.

'Second exploited', and the count. The Register calls this 'the second Anthropic-linked vulnerability known to have been exploited in the wild', and Garrity's post calls it the second Mythos finding reported as exploited. Both are framings. The tracker behind them lists CVE records that credit Anthropic research and are, in its own words, 'possibly discovered by Project Glasswing'. It marks two as being in VulnCheck's KEV: this one, and a Ghost flaw, CVE-2026-26980, whose credit reads 'Nicholas Carlini using Claude, Anthropic' and which NVD shows as published on 20 February 2026, 46 days before Glasswing was announced. Neither is in CISA's catalogue. In the tracker, 'exploited' therefore means 'in VulnCheck's catalogue', and 'Mythos' means 'credited to Anthropic researchers or a collaborator', not 'confirmed as a Mythos find'. The word appears in the credit text of one of the 300 records.

What the published counts measure. Sources: Garrity's tracker on GitHub (its commit history and README, read 3 October), Anthropic's disclosure dashboard (last updated 2 October 19:47 UTC). Derived figures are ours.

  1. Count
    The Register's figure: tracker, Friday 2 Oct, 19:25 UTC
    Figure
    286
    What it counts
    CVE records matched on Anthropic-research credit text. Confirmed in the tracker's own history.
  2. Count
    Tracker, Saturday 3 Oct, 16:30 UTC
    Figure
    300
    What it counts
    Same method, 14 more in 21 hours. Six rows are the HFS records and 49 are Bouncy Castle (derived).
  3. Count
    Of those, ticked as exploited
    Figure
    2
    What it counts
    In VulnCheck's KEV, not CISA's. Two of 300 is 0.7 per cent (derived).
  4. Count
    Anthropic's dashboard, 2 Oct
    Figure
    219 CVE records
    What it counts
    Among 6,157 disclosed vulnerabilities in 591 open-source projects, 516 patched. A different net: we found none of the six HFS CVE numbers in its ledger data.

What the exploitation reports state, and what they leave open

The evidence is one LinkedIn post and two remarks Garrity made to The Register. VulnCheck describes its canaries as 'actually vulnerable systems' that it deploys across the internet, so the hosts in Garrity's post are, on the most natural reading, VulnCheck's own. The sources do not say so in terms, and Garrity's phrase 'real vulnerable hosts' leaves room for others.

Stated and not stated, as of 21:02 BST on Saturday 3 October 2026. Sources: Garrity's LinkedIn posts (public profile page), The Register, VulnCheck's advisory page, tracker and Canary Intelligence page, CISA KEV feed, NVD, GitHub.

  1. Topic
    When it began
    Stated
    Garrity, 00:57 UTC on 2 October: 'We started detecting exploitation' that evening. VulnCheck's KEV date for the CVE is 1 October.
    Not stated
    The first time anyone attacked an HFS server. Only that VulnCheck's sensors had seen it by then.
  2. Topic
    Who, and from where
    Stated
    One IP address in China on Thursday night. On Friday four hits from two US addresses in one subnet that 'appear to be coming from a proxy' (Garrity to The Register).
    Not stated
    Who runs any of them, or that they are one actor. A hosting location is not an operator, and the source itself says the Friday traffic looks proxied.
  3. Topic
    Which hosts
    Stated
    Garrity: VulnCheck's 'canaries detected an actor in China targeting real vulnerable hosts in the US'. The Register adds Japan, from Garrity.
    Not stated
    That any third-party server was attacked, how many hosts were hit, whether any was compromised, or what an attacker did after logging in.
  4. Topic
    Link to the write-up
    Stated
    Timing: the first report follows the write-up by at most 38 h 58 m.
    Not stated
    That the attacker used the write-up or the video. The CVE text gave the mechanism on 13 July, and a repository calling itself a proof of concept was created on 26 September.
  5. Topic
    AI discovery
    Stated
    Horizon3: the model found the flaw. The CVE credit: 'Claude and Anthropic Research'.
    Not stated
    Independent confirmation of how it was found, any sign the attacker used AI, or evidence that AI discovery made it easier to attack than a human-found flaw.
  6. Topic
    Official listing
    Stated
    VulnCheck's advisory page says the CVE is in the VulnCheck KEV.
    Not stated
    A CISA listing. Not in catalogue 2026.10.02 at 20:02 UTC on 3 October, so no federal deadline. NVD still carries CISA-ADP's 15 July entry, 'exploitation none'.
  7. Topic
    Exposure
    Stated
    No figure from any source we fetched.
    Not stated
    How many HFS 3 servers face the internet, how many run a fixed build, how many are in the UK.

The 'four hits' and the two US addresses rest on The Register's report of a conversation. They are not on any page we could read. The addresses it gives are 173.239.211[.]248 and 173.239.211[.]249. They belong in a log search. They do not belong in a blocklist you rely on, because the source itself describes a proxy, and a clean result proves nothing about the next address. A search for a UK NCSC or CISA alert naming CVE-2026-61500 found none at the time of reading.

Labels that are not controls

A label is not a control. Six are in circulation, and each supports less than it sounds, as our briefing on a Citrix bulletin argued about patching the product and not the list.

Labels in circulation and what each supports. Sources: NVD, CVE.org, Rejetto releases and source, VulnCheck's tracker, The Register.

  1. Label
    'Found by an AI model'
    Where it appears
    Horizon3, VulnCheck's post, The Register
    What it supports
    A vendor claim about method. The CVE credit says Claude and Anthropic Research. It says nothing about what to patch or how fast.
  2. Label
    'Fixed in 3.2.1'
    Where it appears
    The Register, the CVE records
    What it supports
    The first fixed release, 13 July. The current stable build, 3.3.4, adds fixes the project calls only 'Security fixes'. The control is the version, a restart, an instance that does not face the internet, and a check of what happened before the update.
  3. Label
    'Critical, 9.8'
    Where it appears
    NVD
    What it supports
    VulnCheck's own score as numbering authority. NVD has not analysed the record. The CVSS 4.0 score is 9.3.
  4. Label
    'Exploitation: none'
    Where it appears
    NVD, from CISA-ADP
    What it supports
    A snapshot stamped 15 July 2026 14:14 UTC, 78 days before the exploitation post (derived). Accurate then. Do not read it as current.
  5. Label
    'Not in CISA's KEV'
    Where it appears
    Absence from the catalogue
    What it supports
    Not evidence of safety. The catalogue was cut 14 h 22 m after Garrity's post and was still version 2026.10.02 at 20:02 UTC on 3 October.
  6. Label
    'Second exploited Mythos bug'
    Where it appears
    The Register, Garrity
    What it supports
    Two credit-matched records ticked in VulnCheck's catalogue, one of which predates Glasswing.

A separate flaw in HFS 2 is also reported as exploited

HFS has two code lines in use, and the fix for one is not a fix for the other. HFS 3, the TypeScript rewrite, is what 3.2.1 and 3.3.4 patch. HFS 2.x, the older version, has its own flaw, CVE-2026-97359, a template-injection bug in the upload handler that NVD shows as published on 24 September and that VulnCheck scored 10.0. Rejetto's site says 'Version 2.3-2.4 is dangerous and should not be used anymore' and that there is no official fix for version 2. A post shared by Garrity, stamped 15:04 UTC on 3 October, says VulnCheck began seeing exploitation of that flaw on HFS 2 canaries that morning. That rests on the post: we found no second source, and the CVE is not in CISA's catalogue.

HFS has a history with that catalogue. It already lists CVE-2014-6287, added on 25 March 2022, and CVE-2024-23692, added on 9 July 2024 with ransomware use marked 'Known'. Horizon3 and The Register name only the 2024 entry.

What UK organisations should do, in the order worth doing

Take this with you

HFS checklist

  • Find every HFS instance: small teams, shadow IT, test rigs, lab machines and laptops that share files. Ask people as well as scanning. Record whether each is HFS 2.x or HFS 3.
  • Record the version. The process title carries it, because the source sets it to HFS followed by the version number. The vendor says 'all previous versions' have vulnerabilities while the CVE record says 3.0.0 to 3.2.0, so do not read the range as a safe harbour for older 0.x builds.
  • Take any instance off the internet, or put it behind a VPN or other authentication, until it is updated. If it must stay reachable, limit the admin panel to known addresses using admin_net, whose documented default is any. That is our inference, untested.
  • Update to the current stable release. On 3 October that is 3.3.4. Version 3.2.1 is the minimum for all six CVEs, and 3.3.4 adds fixes the project describes only as 'Security fixes'. Do not run the 3.4.0 alpha builds on a server. Restart the process afterwards.
  • Treat any administrator session, and any change made through the admin panel, before the update as untrusted. The release notes do not say sessions are invalidated, so this is our judgement. The source suggests a restart on a fixed build ends old cookies, but it does not undo what a forged session did.
  • Review for what a forged administrator could have left: new or changed accounts, changes to the server_code setting and to installed plugins, changes to shared folders and to options such as admin_net, processes started by the HFS process, and outbound connections from the host. The documented default for log_api is on, so check it still is and keep the logs.
  • Search proxy and server logs for the two US addresses The Register reports, as a hint only, and for failed logins with odd usernames. A negative result proves nothing.
  • If you find HFS 2.x, remove it. The author says there is no official fix and that it should not be used, and a separate flaw in it is reported as exploited.
  • Record the decision for each instance: owner, version, exposure, date patched. For anything in Cyber Essentials scope, the NCSC's v3.3 requirements call for critical or high fixes within 14 days of release and for unsupported software to be removed. For 3.2.1 that window closed on 27 July.
  • Report. Open an incident if any indicator turns up, tell your data protection lead if the server held personal data, and use your usual route to the NCSC.

The question that exposes the gap

Which file-sharing tool on your network has not been updated since July, and who owns it?

Key facts

Sources

  1. PrimaryHorizon3's write-up by Zach Hanley, dated 30 September 2026 (page metadata 10:00 UTC), read in full. Used for the claim that Mythos found the flaw, the Glasswing membership claim, the existence of the video, and the commercial context. Its attack sequence and video are deliberately not reproduced or linked.Horizon3accessed 2026-10-03
  2. PrimaryNVD record for CVE-2026-61500, read as raw JSON from the NVD API at 19:34 UTC on 3 October and again at 20:02 UTC. Used for status Deferred, last modified 15 July, VulnCheck's scores, CWE-338 and CISA-ADP's SSVC entry dated 15 July.NIST NVDaccessed 2026-10-03
  3. PrimaryCVE.org record for CVE-2026-61500 (read as JSON from the CVE Services API): reserved 10 July, published 13 July 17:21 UTC by VulnCheck, updated 1 October 15:20 UTC, credit line and affected range. The records for CVE-2026-61501 to CVE-2026-61505 were read the same way.CVE Programaccessed 2026-10-03
  4. PrimaryCISA Known Exploited Vulnerabilities catalogue, read as the JSON feed at 19:35 UTC and 20:02 UTC on 3 October: version 2026.10.02, released 2 October 15:19 UTC, 1,733 entries, no entry for CVE-2026-61500. Used for the two earlier Rejetto HFS entries, CVE-2014-6287 and CVE-2024-23692.CISAaccessed 2026-10-03
  5. PrimaryHFS 3.2.1 release, published 13 July 2026 15:31 UTC. Used for the release time and the release-note wording. Release list and notes for 3.2.2 to 3.4.0 alpha 2 read from the same repository, including 3.3.4 of 30 September ('Security fixes').Rejetto (GitHub)accessed 2026-10-03
  6. PrimaryPublic diff from 3.2.0 to 3.2.1: twelve commits, commit titles naming CVE-2026-61500 to CVE-2026-61505, and the changes to the signing key, the login identifier and the login replies. Read for the fix and for the start-up key comment. The compare from 3.3.3 to 3.3.4 was read for commit titles only.Rejetto (GitHub)accessed 2026-10-03
  7. PrimaryHFS configuration documentation at tag 3.3.4. Used for the documented defaults of admin_net (any), log_api (true), session_duration and the server_code setting.Rejetto (GitHub)accessed 2026-10-03
  8. PrimaryRejetto's HFS page, read 3 October. Used for the statement that version 2.3 to 2.4 is dangerous and has no official fix.Rejettoaccessed 2026-10-03
  9. PrimaryVulnCheck advisory for CVE-2026-61500, dated 13 July 2026, read in a browser session at 19:35 UTC on 3 October. States that the advisory is in the VulnCheck KEV database. The catalogue itself needs a community sign-in and was not read.VulnCheckaccessed 2026-10-03
  10. PrimaryGarrity's public LinkedIn profile page, whose served text and structured data carry his post of 00:57 UTC on 2 October (detection began 'this evening', canaries, China, US hosts) and a shared VulnCheck post of 15:04 UTC on 3 October (HFS 2 canaries, CVE-2026-97359). Read without signing in. Permalinks not opened.LinkedIn (Patrick Garrity, VulnCheck)accessed 2026-10-03
  11. PrimaryGarrity's tracker of CVEs crediting Anthropic research. README, cves.yaml and commit history read 3 October. Used for the count of 286 (commit of 2 October 19:25 UTC) and 300 (3 October 16:30 UTC), the two VulnCheck KEV ticks, the 1 October KEV date and the tracker's own description.Patrick Garrity (GitHub)accessed 2026-10-03
  12. PrimaryGarrity's blog post of 15 April 2026 on CVEs attributed to Anthropic researchers and Project Glasswing. Used for the method and the caveat that credit fields are not standardised.VulnCheckaccessed 2026-10-03
  13. PrimaryVulnCheck's Canary Intelligence product page. Used for its description of canaries as actually vulnerable systems deployed across the internet.VulnCheckaccessed 2026-10-03
  14. PrimaryNVD record for CVE-2026-97359, the HFS 2.x template-injection flaw: published 24 September 2026, scored 10.0 by VulnCheck as numbering authority, CISA-ADP SSVC exploitation poc.NIST NVDaccessed 2026-10-03
  15. PrimaryProject Glasswing announcement, 7 April 2026. Used for what Glasswing is, the launch partners, the extension to over 40 further organisations and the statement that Claude Mythos Preview will not be generally available.Anthropicaccessed 2026-10-03
  16. PrimaryAnthropic's coordinated vulnerability disclosure dashboard, last updated 2 October 2026 19:47 UTC. Used for the headline counts (6,157 disclosed, 516 patched, 219 CVE records). Its ledger data files were searched for the HFS CVE numbers and for rejetto and hfs, with no match.Anthropicaccessed 2026-10-03
  17. PrimaryCyber Essentials: Requirements for IT Infrastructure v3.3, April 2026. Used for the 14-day rule for critical or high fixes and the removal of unsupported software.UK NCSCaccessed 2026-10-03
  18. Reported byThe Register, 3 October 2026 (page metadata 15:27 UTC). The pointer for this briefing. The sole source for the 'four hits' on Friday, the two US addresses, the Japan detail and the 'second Anthropic-linked' framing. Everything else was checked against primaries.The Registeraccessed 2026-10-03

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.