Is CVE-2014-6287 (Rejetto HTTP File Server (HFS) Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2014-6287 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. The findMacroMarker function in parserLib.pas in Rejetto HTTP File Server (HFS or HttpFileServer) allows remote attackers to execute arbitrary programs.

What makes this KEV listing a practical exploitation signal?

CISA only adds a CVE to the Known Exploited Vulnerabilities catalogue when it has reliable evidence of active exploitation. For this case, that means the question is not whether exploitation is theoretically possible, but whether defenders should treat exposure as an immediate operational concern. The answer is yes, so the issue moves from vulnerability awareness to exposure confirmation and response timing.

For practitioners, the key implication is that a KEV entry is stronger than a generic alert or proof-of-concept notice. It indicates that exploitation has crossed into active abuse in the wild, so patch prioritisation should be driven by exposure and asset criticality rather than routine maintenance cadence.

To confirm whether you are affected, identify any internet-facing or externally reachable HFS instances, verify the exact product in use, and check whether the vulnerable parserLib.pas component is present in the deployed build. If you maintain vulnerability intelligence workflows, treat the CISA KEV record and the vendor advisory as the authoritative sources for remediation tracking and validation.

How attackers get from a vulnerable HFS instance to code execution

The disclosed flaw is a remote code execution condition in Rejetto HTTP File Server, so exploitation can give an attacker arbitrary program execution on the host running the service. That creates a direct path from a web-exposed application weakness to host-level compromise, which is why the issue deserves same-day triage when the service is reachable from untrusted networks.

Remote code execution changes the defensive posture because the attacker no longer needs valid user access once the flaw is reachable and exploitable. In practice, that means the service boundary is the first control point to assess, followed by the host, the local accounts the service runs under, and any adjacent systems reachable from that server.

Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames the triage logic for actively exploited issues, including KEV-driven prioritisation and post-patch hunting. For the same reason, Web Application Attacks Guide helps place this exploit in the broader class of web-delivered code execution weaknesses.

What to do if patching is delayed or compromise is uncertain

If you cannot remediate immediately, the first priority is to reduce exposure. Remove public reachability where possible, restrict access to trusted administrative paths, isolate the service, and monitor for any unusual child processes, command execution, or outbound activity from the HFS host. The objective is to reduce the chance that a known-exploited flaw can be turned into a foothold while you wait for maintenance windows.

When a vulnerable service has been exposed to the internet, assume there is some possibility of pre-patch compromise even if you have not yet found obvious alerts. Review logs, timestamps, process creation, web requests, and recent file changes around the vulnerable period. If the server handled sensitive content or had broad local access, widen the review to adjacent credentials, scripts, scheduled tasks, and remote administration channels that may have been touched after execution.

If the host was reachable externally before remediation, the investigation should not stop at patching. Validate that the attacker did not leave persistence, web shells, modified startup tasks, or other follow-on access paths. Persistence Techniques Guide is the most relevant internal reference for checking those common post-exploitation footholds.

Risk and Threat Considerations

This kind of flaw is high-risk because it turns a file-serving utility into an execution surface. Once a vulnerable HFS instance is reachable, the main threat is not just a crash or data leak, but full host compromise, which can then be used to stage lateral movement, drop malware, or harvest local data and credentials.

Failure mechanism: The vulnerable parser path accepts crafted input that can trigger arbitrary program execution, so a remote request can become a local command or process launch on the server.

Impact: An attacker who lands code execution can install persistence, access files served by the host, use the server as a pivot point, and potentially access nearby systems or secrets that the service can reach.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires rapid vulnerability prioritisation and remediation.
Recommendation — Prioritise and remediate the exposed HFS instance immediately.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A known-exploited RCE requires urgent flaw remediation and exposure reduction.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation review depends on logs and execution evidence after suspected RCE abuse.
Recommendation — Patch or mitigate the vulnerable HFS deployment without delay. Review logs and process evidence for signs of exploitation and persistence.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Managed	The question is about an actively exploited vulnerability and how to prioritise it.
Recommendation — Confirm exposure and manage the vulnerable asset as an active risk.
OWASP ASVS	V15 — Secure Coding and Architecture	The vulnerability is a code-level RCE weakness in a web-facing service component.
Recommendation — Treat the parser flaw as an architectural code defect requiring fix and verification.

Practitioner Guidance

What to prioritise: Prioritise exposure reduction before deep forensic work if the instance is internet-facing. For a KEV-listed RCE, the decision is not whether the issue matters, but whether the server can be taken out of reach or remediated quickly enough to shrink the exploitation window.

What to verify: Verify the exact HFS deployment, the reachable network paths, and whether any evidence suggests process execution outside expected server behaviour. Then check whether local service privileges, stored credentials, or administrative shares increased the blast radius after compromise.

Practitioner takeaway: With a KEV-listed remote code execution flaw, patching is necessary but not sufficient, because the real security question is whether the host was exposed long enough for the attacker to turn initial execution into persistence or lateral movement.