Rejetto HFS CVE-2026-61502

Two distinct exploitation paths exist with different prerequisites. Path 1 (CSRF): requires a human administrator who is currently authenticated to HFS to navigate to an attacker-controlled URL or load attacker-controlled content - exploitation is limited by the requirement for active admin session and social engineering or malicious content delivery. Path 2 (localhost unauthenticated): requires only that the HTTP request originate from the server's own loopback interface (127.0.0.1); default HFS installations exempt such requests from authentication, so any SSRF vulnerability, server-side script execution, or local process on the same host can trigger full administrative access with no credentials and no user interaction. Path 2 is not limited by user interaction but requires the attacker to already have some form of server-local or SSRF access.

The provided CVSS 4.0 base score of 5.1 (AV:N/AC:L/AT:N/PR:N/UI:A) reflects only the user-interaction-dependent CSRF vector and scores the integrity impact conservatively at VI:L. However, the description explicitly states the vulnerability leads to code execution and covers a second, unauthenticated localhost vector - both factors that make real-world risk materially higher than the base score implies. The unauthenticated localhost path is particularly dangerous: any co-located SSRF vulnerability, server-side scripting capability, or internal network pivot can trigger full administrative compromise of HFS without any user interaction. No EPSS data was provided, no CISA KEV listing exists, and no public POC has been confirmed, suggesting exploitation has not yet been observed at scale. Nonetheless, Horizon3.ai - a firm that regularly publishes working exploits - discovered this issue, and the RCE capability combined with the unauthenticated localhost path warrants treating this as higher priority than the CVSS 4.0 score alone implies for any deployment where HFS is accessible or where SSRF risk exists on the same host.

An attacker identifies an organization running HFS 3.x and sends a phishing email to an administrator containing an innocuous-looking link or embeds a hidden image tag pointing to a crafted URL such as http://hfs-host/api/create-account?user=attacker&pass=pwned; when the logged-in admin's browser fetches the URL (even passively), HFS processes the GET request as a legitimate administrative action, creates a backdoor account, and the attacker subsequently authenticates and leverages HFS configuration access to achieve code execution. Alternatively, if the attacker has exploited an SSRF vulnerability in any application running on the same server, they can directly call the HFS API on localhost without credentials, bypassing authentication entirely.