CVE-2026-97359: HFS2 Filename Injection

What Happened?

CVE-2026-97359 is a critical HFS2 vulnerability involving template injection in the multipart upload handler. An attacker can place template syntax in an uploaded filename, terminate the expected template context, and introduce an exec macro. The resulting template evaluation can execute arbitrary commands on the HFS2 host.

The NVD description identifies the flaw as exploitable without authentication. The vulnerability was published on September 24, 2026, and affects HFS2 version 2.4.0 and earlier. CISA’s Known Exploited Vulnerabilities catalog does not currently list this CVE.

The absence of a confirmed fixed version creates an immediate verification problem. Organizations should not assume that a current-looking HFS2 installation is safe unless its version is newer than 2.4.0 and the project advisory confirms that version as fixed. Until then, treat every HFS2 2.4.0-and-earlier deployment as vulnerable.

Analyst’s Take: The first decision is containment, not exploit confirmation. Because the vulnerable input is the multipart filename and the reported path requires no authentication, exposed upload handling should be restricted while teams verify the fixed release and review logs.

Who Needs to Act?

Administrators running HFS2 version 2.4.0 or any earlier version need to act. This includes internet-facing file-sharing services, internally hosted HFS2 instances reachable by untrusted users, and deployments placed behind a reverse proxy where the upload endpoint remains accessible.

The reported vulnerability is unauthenticated, so an assumption that only trusted accounts can upload is not sufficient unless the access-control layer is verified.

The vulnerable product and version range are specific: HFS2 2.4.0 and earlier. The reviewed NVD record and source material do not provide a verified fixed version number. Check the GitHub project advisory directly for the authoritative remediation commit or release before declaring an installation remediated.

Why Is the CVSS Score 10.0?

The assigned base score is 10.0, the maximum CVSS severity. That rating is consistent with the reported characteristics: remote exploitation, no authentication requirement, and arbitrary command execution on the host.

Remote code execution generally affects confidentiality, integrity, and availability because an attacker may read data, modify application or system state, and disrupt services.

However, the exact CVSS vector was not returned in the NVD record used for this assessment. The individual CVSS component values, such as attack complexity, user interaction, scope, and confidentiality, integrity, and availability impacts, should not be reconstructed as fact.

The 10.0 score is authoritative as reported. Obtain the full NVD record for the complete CVSS metadata when it becomes available.

A maximum score does not prove that exploitation is occurring. It describes the potential severity of successful exploitation. CISA KEV status and exploitation evidence are separate questions, and this CVE is not currently listed in the KEV catalog.

Has CVE-2026-97359 Been Exploited?

Confirmed active exploitation in the wild was not established from the reviewed sources. CVE-2026-97359 is not listed in CISA KEV as of September 24, 2026. Therefore, there is no CISA-provided date added, remediation due date, required action, or ransomware-campaign indicator for this CVE.

Public technical details do exist. The NVD record points to a GitHub-hosted HFS2 advisory and a VulnCheck advisory. The available description identifies the injection mechanism involving a closing template sequence and an exec macro.

A confirmed public exploit implementation was not verified from the retrieved material. The current assessment is:

• Technical details are public.
• Confirmed exploit code was not verified.
• Confirmed in-the-wild exploitation was not established.

The absence of KEV inclusion is not proof that exploitation has never occurred. It means only that CISA has not included the vulnerability in that catalog at the time of assessment. Organizations with exposed HFS2 services should use their own access logs, endpoint telemetry, and threat intelligence to determine whether their systems were targeted.

How Do I Know If I’m Affected?

Start by inventorying all HFS2 installations and identifying their exact versions. Include systems deployed as standalone services, containers, virtual machines, and behind reverse proxies. Pay particular attention to internet-facing listeners and any service account with write access, shell access, or access to sensitive files.

Next, review HTTP access logs for multipart upload requests and suspicious filename values. Look for:

• Template delimiters
• Closing-template sequences
• exec tokens
• Unusual quoting
• URL encoding
• Abnormal filename lengths
• Filenames that are substantially more complex than normal operational uploads

Because the vulnerable value is in multipart metadata, ensure your logging pipeline records request headers and multipart filenames where privacy and retention policies permit.

Detection Query

A generic detection query for a web gateway or SIEM can identify candidate requests. Adapt field names to the logging platform:

http.method = "POST"
AND http.content_type CONTAINS "multipart/form-data"
AND (
  http.request_body CONTAINS "{{"
  OR http.request_body CONTAINS "}}"
  OR http.request_body CONTAINS "exec"
  OR http.request_body CONTAINS "%7B%7B"
  OR http.request_body CONTAINS "%7D%7D"
)

A simple command-line review of retained access logs can help locate likely requests, although it is not a substitute for structured parsing:

grep -Eai 'multipart/form-data|filename=.*(\{\{|\}\}|exec|%7b|%7d)' /var/log/nginx/access.log

The pattern is intentionally broad and can produce false positives. Correlate matches with the request source address, response status, upload endpoint, user-agent, request size, and timing.

Then inspect host telemetry for the HFS2 process spawning shells, interpreters, download tools, or unexpected child processes. Examples include:

• sh
• bash
• cmd.exe
• powershell.exe
• curl
• wget
• python
• perl

The correct process set depends on the host operating system and deployment.

For endpoint triage on systems where it is already approved and deployed, Malwarebytes or an equivalent security product may help identify suspicious persistence, malware, or post-exploitation activity. Endpoint tooling does not replace application patching or log review.

What Should I Do About CVE-2026-97359?

The preferred action is to upgrade to the fixed HFS2 release identified by the project advisory. The exact fixed version number was not available in the reviewed NVD data, so it would be unsafe to invent a target version or claim that a particular release is patched.

Consult the project advisory, verify the release or remediation commit, and record the installed version after upgrading.

Until that information is confirmed, remove untrusted access to multipart uploads. If the application supports disabling uploads, disable that feature. Otherwise, place HFS2 behind an access-control layer that blocks unauthenticated access and restrict the service to trusted management networks.

If neither control is possible, stop the affected service while preserving logs and forensic data for investigation.

Temporary Containment

There is no verified universal HFS2 package-manager command because the installation method and fixed version are not specified. Administrators should first identify the process and service definition rather than running an unverified upgrade command:

ps -ef | grep -i '[h]fs2'
systemctl list-units --type=service | grep -i hfs
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i hfs

If the HFS2 service is managed by systemd and upload functionality cannot be restricted safely, a temporary containment action is:

sudo systemctl stop hfs2.service
sudo systemctl disable hfs2.service

Use the actual unit name shown by the discovery command. Do not assume hfs2.service is the correct name on every installation.

For reverse-proxy deployments, block the upload route or require authentication at the proxy, but confirm the application’s actual upload path before applying a rule. A broad temporary block is safer than a guessed narrow rule if the service is exposed:

location / {
    deny all;
}

That example disables proxy access to the entire HFS2 location and should be replaced with a narrowly scoped upload restriction once the correct route is known.

After containment, review:

• Child-process creation
• Outbound connections
• New files
• Account changes
• Modifications to the HFS2 data directory
• Shell or interpreter execution
• Unexpected scheduled tasks or services

If command execution is suspected, isolate the host and preserve volatile and disk evidence before rebuilding or restoring service.

Where Does This Information Come From?

The primary technical sources are the NVD CVE record, the HFS2 project advisory, and the VulnCheck advisory.

The NVD record supplies the affected range, severity, unauthenticated exploitation description, and publication metadata. The project advisory should be treated as the authoritative source for the fixed release or remediation commit.

CISA KEV is relevant for exploitation tracking, but its current absence should be interpreted narrowly. It does not downgrade the vulnerability or demonstrate that affected systems are safe. Recheck the catalog and the project advisory before finalizing remediation status.

• NVD: CVE-2026-97359
• HFS2 project advisory: upload filename template injection
• VulnCheck advisory: HFS2 RCE via multipart upload filename template injection
• CISA Known Exploited Vulnerabilities Catalog

Bottom Line

CVE-2026-97359 is a critical unauthenticated RCE affecting HFS2 2.4.0 and earlier. Malicious multipart-upload filenames can inject template syntax and execute commands on the underlying host.

Confirmed in-the-wild exploitation was not established in the reviewed sources, but exposed upload endpoints should be restricted immediately. Verify the project’s fixed release, upgrade when confirmed, and investigate relevant application and host logs rather than waiting for KEV inclusion.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.