Hfs2
Monthly
Unauthenticated denial of service in Rejetto HFS2 2.4.0 and earlier lets a remote attacker take the entire file server offline with a single crafted request to the getini handling path, which drives a serving thread into an infinite busy loop that consumes CPU and stops the server answering any client. The failure is persistent and self-perpetuating: there is no timeout or automatic recovery, so availability is only restored when an operator manually restarts the service. Publicly available exploit code exists (documented in the referenced researcher advisory and echoed by VulnCheck), and no authentication, user interaction, or non-default feature toggle is required - the only practical prerequisite is network reachability of the HFS2 listener, which matters because HFS2 is a Windows desktop file server frequently bound to a LAN or deliberately published for file sharing.
Unauthenticated arbitrary file read, write, append, and delete in Rejetto HFS2 up to and including 2.4.0 allows remote attackers to compromise the confidentiality, integrity, and availability of the host filesystem. The vulnerability arises because the template engine's macro dispatcher performs no authorization check and the path resolver fails to confine absolute paths to the shared folder, letting attackers manipulate macros to access files anywhere the HFS service account has permissions. Public exploit code exists, and exploitation works against default configurations; the legacy 2.x branch is affected, while HFS 3.x is a separate codebase.
Unauthenticated remote code execution in Rejetto HFS2 (HTTP File Server) through version 2.4.0 lets an attacker execute arbitrary commands on the underlying host by hiding server-side template syntax inside the filename of a multipart file upload. The crafted filename closes the template quoting context and injects an exec macro, which bypasses the dispatcher's authorization check, so no credentials or user interaction are required (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; vendor score 10.0). Publicly available exploit code exists and an advisory with a proof-of-concept walkthrough is referenced by VulnCheck, but no KEV entry was provided, so this is not confirmed as actively exploited; the practical limiting factor is whether the multipart upload endpoint is reachable from the attacker's network.
Unauthenticated denial of service in Rejetto HFS2 2.4.0 and earlier lets a remote attacker take the entire file server offline with a single crafted request to the getini handling path, which drives a serving thread into an infinite busy loop that consumes CPU and stops the server answering any client. The failure is persistent and self-perpetuating: there is no timeout or automatic recovery, so availability is only restored when an operator manually restarts the service. Publicly available exploit code exists (documented in the referenced researcher advisory and echoed by VulnCheck), and no authentication, user interaction, or non-default feature toggle is required - the only practical prerequisite is network reachability of the HFS2 listener, which matters because HFS2 is a Windows desktop file server frequently bound to a LAN or deliberately published for file sharing.
Unauthenticated arbitrary file read, write, append, and delete in Rejetto HFS2 up to and including 2.4.0 allows remote attackers to compromise the confidentiality, integrity, and availability of the host filesystem. The vulnerability arises because the template engine's macro dispatcher performs no authorization check and the path resolver fails to confine absolute paths to the shared folder, letting attackers manipulate macros to access files anywhere the HFS service account has permissions. Public exploit code exists, and exploitation works against default configurations; the legacy 2.x branch is affected, while HFS 3.x is a separate codebase.
Unauthenticated remote code execution in Rejetto HFS2 (HTTP File Server) through version 2.4.0 lets an attacker execute arbitrary commands on the underlying host by hiding server-side template syntax inside the filename of a multipart file upload. The crafted filename closes the template quoting context and injects an exec macro, which bypasses the dispatcher's authorization check, so no credentials or user interaction are required (assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; vendor score 10.0). Publicly available exploit code exists and an advisory with a proof-of-concept walkthrough is referenced by VulnCheck, but no KEV entry was provided, so this is not confirmed as actively exploited; the practical limiting factor is whether the multipart upload endpoint is reachable from the attacker's network.