1. Overview
- Article Title: Horizon3’s Tales from the Trenches: Anthropic’s Mythos and Rejetto HFS
- Source: Horizon3.ai
- Publication Date: 2026-09-30
- Updated Date: Unknown (not specified in primary source)
- Report Revision Reason: Technical review: Clarified exploitation prerequisites involving signing keys, usernames, and administrative APIs; corrected descriptions of cookie fields, session investigation, and invalidation; and distinguished code execution demonstrated in a test environment from subsequent compromise.
- Primary Source: Horizon3’s Tales from the Trenches: Anthropic’s Mythos and Rejetto HFS
- Related Sources: Rejetto HFS v3.2.1 release, VulnCheck Advisory, VulnCheck Initial Access: 2026-10-02, SecurityWeek, Rejetto HFS v3.2.0: Session Implementation, Rejetto HFS v3.2.0: SRP Login, Rejetto HFS v3.2.0: Admin API Restrictions, Rejetto HFS v3.2.1: Signing Key Generation, VulnCheck Caitlin Condon: Canary Observation
- Related Malware, Threat Groups, CVEs, and Products: CVE-2026-61500, Rejetto HFS 3.0.0–3.2.0, Rejetto HFS 3.2.1
- Severity: Critical (Unauthenticated remote attackers can recover the V8 PRNG state from login cookies, forge an administrator session, and achieve server-side JavaScript or OS command execution. VulnCheck has observed exploitation attempts against Internet-facing canaries.)
2. Quick Summary
Unauthenticated attackers can recover the Koa signing key from V8 PRNG output exposed in login cookies, forge an administrative session, and execute OS commands on the HFS server. The vulnerability is patched in version 3.2.1, and exploitation attempts have been observed against Internet canaries.
3. Attack Flow
From PRNG State Recovery to Admin Session Forgery and RCE
- The attacker repeatedly sends unauthenticated requests to
loginSrp1using a valid username for a login-enabled account and collects PRNG output from theloggingIn.sidfield in the returned session cookies. No password is required. - The attacker recovers the xorshift128+ state, rolls it backward in time, and determines the Koa signing key generated at HFS startup.
- Using the signing key, the attacker forges a session cookie for an administrator user and sets attributes to bypass IP binding for the session. This does not bypass the
admin_netrestriction on administrative APIs. - The attacker registers JavaScript via
server_codewith administrative privileges and executes OS commands under the HFS process permissions.
4. Attacker Position and Execution Environment
- An unauthenticated remote attacker with HTTP access to the public HFS instance.
- Final commands are executed on the HFS server under the privileges of the HFS process.
5. Visibility for Victims and Administrators
Victims
- Standard file-sharing interfaces may not reveal session forgery or server-side code modifications.
Administrators
- Indicators include repeated login requests over a short period, repeated issuance of session cookies carrying successive
loggingIn.sidvalues, unknown administrator sessions, modifiedserver_codesettings, and child processes spawned by HFS.
6. Success and Failure Conditions
Success Conditions
- HTTP reachability to HFS versions 3.0.0 through 3.2.0, with
COOKIE_SIGN_KEYSunset and signing keys derived fromMath.random(). - Ability to reach
loginSrp1using a valid username for a login-enabled account, satisfy the account's source-address restrictions, and obtain sufficient PRNG output. - Successful recovery of the signing key from the process PRNG state, forgery of a session for an existing administrator account, and utilization of administrative APIs and the
server_codefeature while satisfying administrative access restrictions such asadmin_net.
Failure Conditions and Risk Mitigation
- Update to HFS 3.2.1 or later and restart the updated process.
- Restrict public Internet exposure to the absolute minimum and limit administrative interfaces using a reverse proxy or ACL.
- Rotate signing keys to stop accepting old keys and invalidate existing cookies. In default configurations, restarting the patched version generates a new key. If
COOKIE_SIGN_KEYSis explicitly configured, verify it separately. Compareserver_codeand configuration files against a trusted backup.
7. Impact of Successful Exploitation
- Administrative session forgery grants administrative access to HFS settings and shared data.
- Server-side JavaScript enables OS command execution and potential compromise of the HFS host.
8. Observable Logs
- Email: No reports indicate email was used for initial intrusion.
-
Proxy / SWG / DNS: Rapid login retries from the same source, cookie issuance containing
loggingIn.sid, and subsequent administrative requests. - Endpoint / EDR: Child shells or PowerShell processes spawned by the HFS process, script execution, file downloads, and file modifications.
- Identity / IdP: Inference: Review existing HFS or proxy logs to identify administrative API users, source IP addresses, and user agents. Acceptance of a forged cookie does not necessarily generate a standard successful login event.
- SaaS / Cloud: Relevant SaaS or cloud audit logs can be used to verify related authentication, configuration changes, and external API usage.
- Network: Outbound connections from HFS to unknown hosts, payload retrieval, and internal reconnaissance.
9. Attack Success Assessment
-
Attack Attempt Observed (Success Unconfirmed): Public Information: VulnCheck observed a small volume of reconnaissance probes against canaries in the United States and Japan. This does not establish successful RCE in victim environments. Criteria: Verify
loginSrp1requests and cookie issuance, then separately investigate subsequent administrative API activity and code execution. - Initial Execution Confirmed: Public Information: Horizon3 reproduced cookie forgery through server-side code and OS command execution in a test environment. Criteria: Correlate administrative API actions using forged sessions with evidence of attacker-supplied code execution. Do not conclude CVE exploitation based solely on child processes or outbound traffic; independently verify subsequent data theft or lateral movement.
10. Investigation Playbook
-
Investigation Origin: Repeated HFS logins, unknown administrator sessions, modified
server_code, and HFS child processes. - Initial Verification: Check version, exposure duration, process start time, login and cookie history, and administrative settings.
-
Endpoint and Server Investigation: Preserve the HFS data directory, configurations,
server_code, process tree, memory, and downloaded files. - Authentication and Cloud Investigation: Because HFS sessions are stored in cookies, do not assume that a complete server-side session list is available. Correlate administrative API activity with cookies using retained access logs and network records, and document any gaps that cannot be reconstructed.
- Tracking Subsequent Activity: Track OS commands, credential theft, internal reconnaissance, and outbound communication.
- Containment: Isolate HFS, preserve evidence, update to version 3.2.1 or later, revoke sessions and credentials, and restore a clean host.
- Assessment Categories: Distinguish between login contact, PRNG observation, cookie forgery, administrative actions, server code execution, and subsequent compromise.
11. Defense and Detection Ideas
- Single Event: Prioritize events where shells or PowerShell processes are spawned by the HFS process.
- Time-Series Correlation: Correlate rapid consecutive issuances of login cookies with subsequent administrative actions.
-
Threat Hunting: Search for Internet-facing HFS instances running affected versions 3.0.0 through 3.2.0, unknown
server_code, administrator sessions, and child processes. - Log Limitations: Cookie contents and HFS configuration changes may not be captured in standard proxy or OS logs.
- Priority Mitigations: Prioritize updating to version 3.2.1 or later, restricting administrative network reachability, invalidating sessions, and monitoring child processes.
12. Facts / Inference / Hypothesis
Facts
- In HFS versions 3.0.0 through 3.2.0, when
COOKIE_SIGN_KEYSis not set, Koa cookie signing keys are generated using V8’sMath.random(), which is not cryptographically secure. - When conditions such as a valid username for a login-enabled account are met, the unauthenticated
loginSrp1endpoint returns a session cookie containing a subsequent PRNG output in itsloggingIn.sidfield. Multiple responses from the same HFS process can be collected to recover the xorshift128+ state and reconstruct the signing key generated at startup. - Horizon3 recovered the state using Z3 from 12 login responses, forged an administrator session cookie, and executed commands via the HFS
server_codefeature. - Rejetto patched the vulnerability in version 3.2.1. On October 1, VulnCheck observed probes from a China Telecom IP address against US and Japanese canaries, describing the activity as light reconnaissance. Successful compromise in victim environments remains unconfirmed.
Inference
- Rapid acquisition of multiple login cookies followed by transitions to administrative sessions can provide detection opportunities if rate-limiting or cookie telemetry is present.
Hypothesis
No additional hypotheses. Unverified items are listed in "Open Questions and Further Investigation."
13. MITRE ATT&CK Mapping
| ID | Technique | Confidence | Basis |
|---|---|---|---|
| T1190 | Exploit Public-Facing Application | high | Compromises public HFS instances using unauthenticated login endpoints and predictable signing keys. |
| T1059.007 | Command and Scripting Interpreter: JavaScript/JScript | high | Proceeds to OS command execution using server-side JavaScript via administrative features. |
14. Open Questions and Further Investigation
- Number of successful compromises in victim environments, threat actors, and subsequent payloads.
- Version breakdown of approximately 100 Internet-facing HFS instances identified by VulnCheck, and the count of unpatched instances meeting CVE criteria.
- Whether canary traffic represents simple testing or part of a campaign targeting operational deployments.
15. Impact on SOCs and Organizations
Exploit traffic has reached Japanese canaries, and Internet-facing HFS deployments require urgent verification even in low numbers. Update to version 3.2.1 or later, and preserve login requests, cookies, administrative sessions, server_code modifications, and HFS child processes prior to updating.
16. Summary by Target Audience
-
For SOC Teams: Correlate rapid login retries, cookie issuance, administrative sessions,
server_codemodifications, and child processes. - For Administrators: Update to HFS 3.2.1 or later, restrict exposure scope and administrative functions, and invalidate existing sessions.
- For Users: No end-user action is required. Administrators must update the servers and check for evidence of compromise.
Top comments (0)