top of page

Hunt Rejetto HFS CVE-2026-61500: forged admin cookie

Writer: Inception Security
Inception Security
10 minutes ago
7 min read
Inceptor vs Glitch comic: hunt the cookie that signed itself, Rejetto HFS CVE-2026-61500

On 1 October 2026, VulnCheck Canary Intelligence began seeing probes against Rejetto HTTP File Server for CVE-2026-61500. The activity was small-scale reconnaissance. SecurityWeek and The Hacker News, citing VulnCheck, describe a China Telecom-hosted source hitting canaries in Japan and the United States. No named victims are published, and VulnCheck's advisory and Initial Access pages do not list concrete source IPs, so the hunts below stay on behavior.

Horizon3.ai researcher Zach Hanley disclosed the flaw on 30 September 2026. Horizon3 found it with Anthropic Mythos under Project Glasswing. The fixed build, HFS 3.2.1, had already shipped on 13 July 2026. VulnCheck added the CVE to VulnCheck KEV after the canary hits. As of CISA's catalog version 2026.10.04, CVE-2026-61500 is not on CISA KEV. Rejetto HFS is on CISA KEV for an older bug, CVE-2024-23692.

Carry two questions. Do you run Rejetto HFS 3.0.0 through 3.2.0 where the internet can reach it? And if an admin session appeared without a matching password login, would any log leave the box to tell you?

How the attack works

A signing key built from Math.random

When COOKIE_SIGN_KEYS is unset, HFS builds the Koa keygrip session signing key with randomId(30), and that helper is built from Math.random(). In V8, Math.random() uses the xorshift128+ PRNG. Horizon3 and VulnCheck describe that generator as non-cryptographic and invertible. The weakness is tracked as CWE-338.

A login path that leaks the same stream

The unauthenticated login path loginSrp1 also stores a raw Math.random() value in the session. Koa session cookies are signed base64 JSON, not encrypted, so a client that starts a login handshake receives exact PRNG outputs. Horizon3's write-up and the VulnCheck advisory say an attacker who collects a small number of those login responses can reconstruct generator state, recover the signing key, and mint a valid admin cookie.

From forged admin to remote code execution

With an admin cookie, the attacker reaches HFS administrative features. Horizon3 and VulnCheck both name the built-in server_code configuration path, and Horizon3 notes that the administrative API allows custom endpoints that execute server-side JavaScript. That is the remote code execution step.

Risk: what the file server holds

A file server that faces the internet concentrates shared files, credentials, and whatever the process account can reach. VulnCheck Target Intelligence counts roughly 100 internet-facing HFS instances. Forged admin access plus server_code is host compromise as the HFS process account.

No named victims or success counts are published for CVE-2026-61500. We cite none. Prior mass exploitation of Rejetto HFS via CVE-2024-23692 is useful history for prioritization, not evidence that this CVE produced the same outcome.

Our reading: if this host also holds sync credentials or service tokens, the investigation does not stop at HFS itself.

Mitigate and reduce risk

Patch status today

  • Affected: Rejetto HFS 3.0.0 through 3.2.0 (the Node and TypeScript 3.x line).

  • Fixed: HFS 3.2.1, released 13 July 2026. The release notes say multiple security vulnerabilities in all previous versions could allow an attacker to gain administrative access to HFS, and they credit Zach Hanley of Horizon3.ai with Claude and Anthropic Research.

  • Recheck the vendor release and advisories before you act, in case a later build supersedes 3.2.1 for your install path.

What to do now

  • Inventory every Rejetto HFS instance, its version, and whether the internet can reach it. Pull any 3.0.0 through 3.2.0 hosts offline or behind trusted networks until upgraded.

  • Upgrade to HFS 3.2.1 or later.

  • After the upgrade, invalidate sessions and rotate the admin password so a recovered signing key is useless.

  • Review admin accounts, custom endpoints, and server_code for unexpected changes during the exposure window.

  • Preserve reverse-proxy, WAF, and application logs before rebuilding anything.

Our reading: an upgrade closes the weak key path. Session invalidation and an admin password change close what a recovered key could still unlock.

How to hunt the activity

These threat hunting queries bind to published behaviors from Horizon3 or VulnCheck: bursts of unauthenticated login or SRP sampling from one source, an admin session or admin API success without a matching password auth, unexpected server_code or custom-endpoint config changes, and inventory of internet-facing HFS versions. The query text and field names are ours, so every hunt is marked test first. Prefer behavior over IP lists. Specific probe IPs are not on VulnCheck's advisory or Initial Access pages today. The table under the hunts, "Interpret before you escalate", says what is benign and what is not.

Hunt in Splunk: bursts of unauthenticated login or SRP sampling (test first)

index=YOUR_HFS_HTTP_INDEX
| eval path=coalesce(uri_path, uri, url, http_uri)
| eval client=coalesce(src_ip, src, clientip, client_ip)
| eval method=upper(coalesce(http_method, method, request_method))
| where like(path, "%login%") OR like(path, "%srp%") OR like(path, "%loginSrp%")
| bin _time span=5m
| stats count as requests, dc(path) as paths, values(path) as path_list by client, _time
| where requests>=8
| sort 0 -requests

Field mapping: Horizon3 describes repeated calls to the unauthenticated login path that leaks PRNG outputs. Map path and client fields to your reverse-proxy or HFS HTTP log. The threshold and path substrings are ours. Test first against a known login event.

False positives: load balancers, health checks, and users who mistype passwords in a short window.

Empty result: confirm HFS or proxy HTTP logs reach this index and that login paths are not rewritten away.

Hunt in Kibana: admin session or admin API without matching password auth (test first)

server.domain: "YOUR_HFS_HOST"
AND (
  url.path: (*admin* OR *server_code* OR *~/api/*)
  OR user.name: "admin"
)
AND http.response.status_code: (200 OR 201 OR 204)

Field mapping: VulnCheck and Horizon3 describe a forged admin cookie that grants administrative access without a normal password login. In Discover, sort chronologically and check whether the same client has a successful password auth shortly before the admin activity. ECS field names are ours. Test first.

False positives: legitimate admin work, API tokens you issued, and shared jump hosts.

Empty result: confirm Elastic has HFS or proxy events with status and path fields for the exposure period.

Hunt in Falcon CQL: unexpected server_code or custom-endpoint changes (test first)

#event_simpleName=ProcessRollup2 OR #event_simpleName=*File*
| ComputerName="YOUR_HFS_HOST"
| (
    CommandLine=/(server_code|custom.?endpoint|COOKIE_SIGN_KEYS)/i
    OR (
      FileName=/(\.json|\.yaml|\.yml|config)/i
      AND (ParentBaseFileName=/^(node|hfs)/i OR CommandLine=/hfs/i)
    )
  )
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName, CommandLine], limit=1000)

Field mapping: Horizon3 ties impact to server_code and custom endpoints that execute server-side JavaScript. Endpoint telemetry will not see the cookie forge itself. It can surface config edits tied to the HFS or Node parent process. Matching every Node binary on the host is too noisy, so this search requires a CommandLine clue or a config-looking file under an HFS or Node parent. Field names and regexes are ours. Test first. Handle CommandLine carefully if it can carry secrets, and restrict who can view results.

False positives: your own upgrades, config backups, and admin maintenance.

Empty result: confirm a CrowdStrike Falcon sensor covers the HFS host, or fall back to Falcon LogScale on the HTTP and config logs if that is where the evidence lives.

Hunt in KQL: inventory internet-facing HFS and version clues (test first)

let Window = ago(30d);
DeviceNetworkEvents
| where Timestamp >= Window
| where ActionType == "InboundConnectionAccepted" or ActionType == "ConnectionSuccess"
| where LocalPort in (80, 443, 8080, 8443)
| where InitiatingProcessFileName =~ "node.exe"
    or InitiatingProcessFileName =~ "node"
    or InitiatingProcessFolderPath has "hfs"
| summarize First=min(Timestamp), Last=max(Timestamp),
    Ports=make_set(LocalPort, 10),
    Processes=make_set(InitiatingProcessFileName, 10)
    by DeviceName, LocalIP
| order by Last desc

Field mapping: VulnCheck Target Intelligence puts roughly 100 HFS instances on the internet. This Microsoft Sentinel and Defender-oriented inventory is ours. It finds hosts where a Node or HFS-named process accepts common web ports. It does not prove version 3.0.0 through 3.2.0 by itself. Confirm version on the host or from release artifacts, then upgrade anything below HFS 3.2.1. Test first.

False positives: other Node services on the same ports.

Empty result: confirm Defender for Endpoint covers the hosts, or inventory from your CMDB and external scans instead.

Interpret before you escalate

Finding

Benign read

Escalate when

Burst of login or SRP requests from one client

User retries, scanner noise you already know

High volume with no successful password auth, then admin activity

Admin API or admin identity succeeds

A documented admin session

No matching password login in the same window, or the client is unfamiliar

server_code or custom-endpoint change

Change you can match to a ticket

No change record, or it follows a login burst

Node or HFS process on an internet port

An approved share

Version is 3.0.0 through 3.2.0, or ownership is unclear

Empty results

Nothing matched

Logs, fields, sensors, or retention are missing, so fix coverage first

Sources

What This Means for Your Team

Find every Rejetto HFS instance you run and note its version and exposure. Upgrade anything on 3.0.0 through 3.2.0 to HFS 3.2.1 or later, invalidate sessions, rotate the admin password, and review server_code and custom endpoints. Then run the four hunts against your proxy and host telemetry. If admin activity appears without a matching login, treat the host as compromised and rotate what it could reach.

Inception Protection

Inception Protection is our managed detection and response service, and it works with the Microsoft licenses you already have. A file server only helps us if its HTTP, identity, and endpoint signals reach us, so we start there. Then we read those signals as one story, and you keep the decisions.

Inception Foresight

If you want to see how well your Microsoft environment would surface activity like this, the free Inception Foresight M365 Assessment is a good place to start: https://www.inceptionsecurity.com/m365assessment. You can also follow Inception Security on LinkedIn and @inceptionsec on X.

bg-map-white.png

INCEPTION SECURITY™

A cybersecurity company with in depth knowledge of the threat landscape and security controls.

NAVIGATION

Home

About 

Services

Partners

Privacy

Contact us

Cyber Incident

Terms and Conditions

GET IN TOUCH

Phone: +1 (888) 427-2937

© 2025 All Rights Reserved by INCEPTION SECURITY™ .

bottom of page