DEV Community

Anoymask
Anoymask

Posted on

Rejetto HFS CVE-2026-61500: Predictable Signing Key Enables Admin Session Forgery and RCE

1. Overview

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

  1. The attacker repeatedly sends unauthenticated requests to loginSrp1 using a valid username for a login-enabled account and collects PRNG output from the loggingIn.sid field in the returned session cookies. No password is required.
  2. The attacker recovers the xorshift128+ state, rolls it backward in time, and determines the Koa signing key generated at HFS startup.
  3. 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_net restriction on administrative APIs.
  4. The attacker registers JavaScript via server_code with 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.sid values, unknown administrator sessions, modified server_code settings, 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_KEYS unset and signing keys derived from Math.random().
  • Ability to reach loginSrp1 using 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_code feature while satisfying administrative access restrictions such as admin_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_KEYS is explicitly configured, verify it separately. Compare server_code and 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 loginSrp1 requests 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_KEYS is not set, Koa cookie signing keys are generated using V8’s Math.random(), which is not cryptographically secure.
  • When conditions such as a valid username for a login-enabled account are met, the unauthenticated loginSrp1 endpoint returns a session cookie containing a subsequent PRNG output in its loggingIn.sid field. 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_code feature.
  • 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_code modifications, 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)