Back to Intelligence

CVE-2026-61500: Rejetto HFS Weak Signing Key Under Active Scanning — Detection and Remediation Guide

SA
Security Arsenal Team
October 5, 2026
12 min read

Threat actors are actively scanning the internet for Rejetto HTTP File Server (HFS) instances vulnerable to CVE-2026-61500, a critical weak signing key vulnerability that chains session forgery into account takeover and, ultimately, unauthenticated remote code execution. If you run HFS anywhere in your environment — and many organizations do, often as a forgotten file-drop server stood up by a single department — you need to treat this as an active exploitation event, not a theoretical patching exercise.

HFS is a lightweight, popular file-sharing server. That popularity, combined with its frequent exposure directly to the internet and its history as an exploitation target, makes it exactly the kind of edge asset scanning botnets and initial access brokers prioritize. When scanning activity is confirmed against a critical RCE, the window between "vulnerable" and "compromised" is typically measured in hours. This post breaks down the vulnerability, gives you production-ready detection content, and walks through remediation.

Technical Analysis

Affected Product

  • Product: Rejetto HTTP File Server (HFS) — the Node.js-based HFS 3.x line, distributed for Windows, Linux, and macOS
  • Component: Session token signing/verification logic
  • Attack vector: Network, unauthenticated
  • Impact: Session forgery → account takeover → remote code execution in the context of the HFS service account

Vulnerability Breakdown

CVE-2026-61500 is rooted in a weak or predictable signing key used to protect HFS session tokens. From a defender's perspective, the attack chain is straightforward and dangerous:

  1. Key recovery or prediction. Because the signing key protecting session tokens is weak (hardcoded, low-entropy, or derivable), an attacker can forge a cryptographically valid session token offline — no interaction with the target server is required to mint the token itself.
  2. Session forgery / account takeover. The attacker presents the forged session to the HFS web interface or API. The server accepts it as legitimate, granting authenticated access — up to and including administrator-level sessions — without ever needing credentials. This bypasses password authentication entirely and leaves no failed-login artifacts.
  3. Unauthenticated code execution. With an administrative session, the attacker abuses legitimate HFS functionality — such as plugin installation, custom command/script execution features, or upload of executable content served by the server — to execute arbitrary code as the HFS service account.

The critical defensive takeaway: this chain produces almost no traditional authentication telemetry. There are no brute-force failures, no anomalous login successes tied to credential guessing. The first observable signal is often the forged session being used, or the HFS process doing something it should never do — spawning shells, writing executables, or making outbound connections.

Exploitation Status

  • Active scanning confirmed. Internet-wide scanning for vulnerable HFS instances is occurring now. This is the reconnaissance phase that precedes mass exploitation.
  • Unauthenticated RCE. No credentials, no user interaction, no prior access required.
  • Severity: Critical. Given the pre-auth RCE impact over the network, defenders should treat this with the same urgency as any CVSS 9.x-class edge vulnerability.
  • CISA KEV: Monitor the CISA Known Exploited Vulnerabilities catalog — vulnerabilities of this class (pre-auth RCE on internet-facing file servers under active scanning) are frequently added with short federal remediation deadlines.

History tells us how this plays out: HFS has been a repeat target for botnets and cryptomining operations precisely because instances are often unmanaged, internet-exposed, and running with excessive privileges. Assume exploitation follows scanning quickly.

Detection & Response

The most reliable detection strategy here focuses on behavior, not signatures of the forged token itself. You cannot easily distinguish a forged session from a legitimate one at the network layer — but you can catch what attackers do with it: HFS spawning child processes, writing unexpected files, and receiving scanning/exploitation traffic.

Sigma Rules

YAML
---
title: Rejetto HFS Process Spawning Shell or Script Interpreter
id: 3f8a2c91-6b47-4d5e-9a1c-7e2f4b8d0a35
status: experimental
description: Detects the HFS server process spawning command shells or script interpreters, consistent with post-exploitation activity following CVE-2026-61500 session forgery and code execution.
references:
  - https://www.bleepingcomputer.com/news/security/rejetto-hfs-servers-now-actively-scanned-for-critical-rce-flaw/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
  - attack.exploitation_for_client_execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\hfs.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
      - '\wget.exe'
  condition: selection_parent and selection_child
falsepositives:
  - HFS administrator-configured event scripts or plugins that legitimately invoke commands — audit and baseline any configured HFS plugins/scripts
level: high
---
title: Rejetto HFS Scanning and Exploitation Probe Patterns in Web Logs
id: 9d1e5a47-2c83-4f6b-b8e0-5a3c7d1f9e24
status: experimental
description: Detects inbound requests to HFS administrative and session endpoints from single sources at high frequency, consistent with active scanning for CVE-2026-61500 vulnerable instances and forged session usage.
references:
  - https://www.bleepingcomputer.com/news/security/rejetto-hfs-servers-now-actively-scanned-for-critical-rce-flaw/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.t1078
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/~/admin'
      - '/~/login'
      - '/api/'
  selection_cookie:
    cs-cookie|contains:
      - 'hfs.sess'
      - 'session='
  condition: selection_uri and selection_cookie
falsepositives:
  - Legitimate administrator access to the HFS admin console — filter on known admin source IPs
level: medium
---
title: Suspicious File Write by HFS Server Process
id: 5c7b3e12-8f49-4a2d-9e61-2b4d6f8a0c17
status: experimental
description: Detects the HFS server process writing executable or script files to disk, consistent with payload staging after CVE-2026-61500 account takeover.
references:
  - https://www.bleepingcomputer.com/news/security/rejetto-hfs-servers-now-actively-scanned-for-critical-rce-flaw/
  - https://attack.mitre.org/techniques/T1105/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1105
logsource:
  category: file_event
  product: windows
detection:
  selection:
    Image|endswith: '\hfs.exe'
    TargetFilename|endswith:
      - '.exe'
      - '.dll'
      - '.ps1'
      - '.bat'
      - '.cmd'
      - '.vbs'
      - '.js'
  filter_upload_dirs:
    TargetFilename|contains:
      - '\uploads\'
      - '\files\'
  condition: selection and not filter_upload_dirs
falsepositives:
  - Legitimate executable uploads to designated HFS share directories — tune the filter to your actual shared folder paths
level: high

A note on tuning: the first rule (HFS spawning shells) is your highest-fidelity signal. HFS has almost no legitimate reason to spawn cmd.exe or PowerShell outside of explicitly configured admin plugins. If that fires and you haven't configured event scripts, treat it as an incident.

KQL — Microsoft Sentinel / Defender

This query hunts across endpoint process telemetry for HFS post-exploitation behavior, and includes a Syslog/CommonSecurityLog branch for environments ingesting HFS or perimeter web logs:

KQL — Microsoft Sentinel / Defender
// Hunt 1: HFS spawning suspicious child processes (Defender endpoint telemetry)
let suspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "wscript.exe", "cscript.exe", "rundll32.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "wget.exe", "whoami.exe", "net.exe", "nltest.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "hfs.exe"
| where FileName in~ (suspiciousChildren)
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256, RemoteIP
| order by TimeGenerated desc;

// Hunt 2: Scanning/probing against HFS admin and login endpoints via ingested web/firewall logs
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any ("/~/admin", "/~/login", "/api/")
| summarize RequestCount = count(), DistinctURLs = dcount(RequestURL), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort
| where RequestCount > 50
| order by RequestCount desc;

// Hunt 3: HFS service making unexpected outbound network connections
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName =~ "hfs.exe"
| where RemoteIP !startswith "10." and RemoteIP !startswith "192.168." and RemoteIP !startswith "172.16."
| summarize Connections = count(), RemoteIPs = make_set(RemoteIP), Ports = make_set(RemotePort) by DeviceName, AccountName
| order by Connections desc

Hunt 3 requires a baseline — HFS legitimately serves inbound file transfers, but the service initiating outbound connections to untrusted public IPs (especially on ports like 443 to unknown hosts, or 4444/5555-style listener callbacks) is a strong compromise indicator.

Velociraptor VQL

Use this hunt artifact across your fleet to identify HFS instances, their running context, and any suspicious child processes or network connections — it doubles as an inventory sweep to find forgotten HFS deployments:

VQL — Velociraptor
-- Security Arsenal: Rejetto HFS CVE-2026-61500 exposure and compromise hunt
-- Identifies running HFS processes, their privilege context, children, and network connections

LET hfs_procs = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)hfs' OR Exe =~ '(?i)hfs\.exe$' OR CommandLine =~ '(?i)hfs'

SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       'HFS_PROCESS' AS FindingType
FROM hfs_procs

UNION ALL

-- Child processes spawned by HFS (post-exploitation indicator)
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       'HFS_CHILD_PROCESS' AS FindingType
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM hfs_procs)
  AND Name =~ '(?i)(cmd|powershell|pwsh|mshta|wscript|cscript|rundll32|certutil|curl|wget|sh|bash)'

UNION ALL

-- Network connections held by HFS processes
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       'HFS_NETWORK' AS FindingType
FROM netstat()
WHERE Pid IN (SELECT Pid FROM hfs_procs)

Run this fleet-wide. Every HFS_PROCESS hit is an asset that must be patched or decommissioned. Any HFS_CHILD_PROCESS hit warrants immediate host isolation and DFIR triage.

Verification and Hardening Script

HFS 3.x runs cross-platform. Use the appropriate script to inventory exposure, verify version status, and apply interim hardening while you patch.

PowerShell
# Security Arsenal - CVE-2026-61500 HFS exposure check and interim hardening (Windows)
# Run elevated on suspected hosts or via your RMM/SCCM across the fleet

$report = @()

# 1. Find running HFS processes and their privilege context
$hfsProcs = Get-Process -Name "hfs" -ErrorAction SilentlyContinue
foreach ($p in $hfsProcs) {
    $owner = (Get-CimInstance Win32_Process -Filter "ProcessId=$($p.Id)").GetOwner()
    $report += [PSCustomObject]@{
        Host        = $env:COMPUTERNAME
        PID         = $p.Id
        Path        = $p.Path
        RunAsUser   = "$($owner.Domain)\$($owner.User)"
        StartTime   = $p.StartTime
        Finding     = "RUNNING_HFS"
    }
    Write-Warning "HFS RUNNING: PID $($p.Id) | $($p.Path) | User: $($owner.User)"

    # Flag if running as SYSTEM or Administrator - massive blast radius for RCE
    if ($owner.User -in @("SYSTEM", "Administrator")) {
        Write-Error "CRITICAL: HFS running as privileged account $($owner.User) - RCE = full host compromise"
    }
}

# 2. Find on-disk HFS installations (including dormant ones)
$hfsPaths = Get-ChildItem -Path "C:\", "$env:ProgramFiles", "${env:ProgramFiles(x86)}", "C:\Users" `
    -Recurse -Filter "hfs.exe" -ErrorAction SilentlyContinue -Depth 4
foreach ($f in $hfsPaths) {
    $report += [PSCustomObject]@{
        Host = $env:COMPUTERNAME; PID = $null; Path = $f.FullName
        RunAsUser = $null; StartTime = $null; Finding = "HFS_BINARY_ON_DISK"
    }
}

# 3. Check for HFS listening ports (default 80/8080 - confirm against your config)
$listeners = Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
    Where-Object { $_.OwningProcess -in ($hfsProcs.Id) }
$listeners | ForEach-Object {
    Write-Warning "HFS LISTENING on port $($_.LocalPort) - verify firewall exposure"
}

# 4. Export findings for central collection
$report | Export-Csv -Path "C:\Windows\Temp\hfs_exposure_$env:COMPUTERNAME.csv" -NoTypeInformation
Write-Output "Inventory complete. Remediate: update HFS per vendor advisory, rotate all sessions, restrict service account, firewall the admin console."
Bash / Shell
#!/bin/bash
# Security Arsenal - CVE-2026-61500 HFS exposure check (Linux)
# Run via SSH/Ansible across your Linux estate

echo "=== HFS Exposure Check: $(hostname) ==="

# 1. Running HFS processes and privilege context
ps aux | grep -i [h]fs | while read -r line; do
    echo "[RUNNING] $line"
    if echo "$line" | grep -qE '^root'; then
        echo "[CRITICAL] HFS running as root - RCE yields full host compromise"
    fi
done

# 2. HFS binaries on disk (node-based installs included)
echo "--- On-disk installations ---"
find /opt /srv /home /usr/local /var/www -maxdepth 4 \( -iname "hfs" -o -iname "hfs.exe" -o -path "*/hfs/*" -iname "*.js" \) 2>/dev/null | head -50
npm ls -g 2>/dev/null | grep -i hfs

# 3. Listening sockets owned by node/hfs processes
echo "--- Listeners ---"
ss -tlnp 2>/dev/null | grep -iE 'node|hfs'

# 4. Suspicious children of HFS (post-exploitation indicator)
echo "--- Suspicious HFS child processes ---"
for pid in $(pgrep -i hfs); do
    ps --ppid "$pid" -o pid,comm,args 2>/dev/null | grep -E 'sh|bash|curl|wget|nc|python|perl' && \
        echo "[ALERT] HFS PID $pid spawned suspicious child - investigate immediately"
done

echo "=== Remediation: update HFS, invalidate sessions, run as dedicated low-priv user, restrict admin UI to localhost/VPN ==="

Remediation

Treat this as an emergency change, not a scheduled patch cycle item.

  1. Inventory first. Most HFS deployments are shadow IT. Use the VQL hunt and scripts above fleet-wide before you assume you know where HFS lives. Check with development, QA, and support teams — HFS is a favorite for ad-hoc file transfer.

  2. Patch immediately. Update Rejetto HFS to the latest release per the vendor's advisory. Monitor the official project at github.com/rejetto/hfs and the Rejetto site for the fixed version addressing CVE-2026-61500. Verify the installed version after updating — do not trust auto-update alone.

  3. Invalidate all sessions and rotate credentials. Because this flaw enables session forgery, patching alone does not evict an attacker who has already established access. Force invalidation of all active sessions, reset all HFS account passwords, and audit user accounts for unauthorized additions or privilege changes.

  4. Reduce the blast radius.

    • Run HFS under a dedicated, least-privilege service account — never SYSTEM, Administrator, or root. A successful RCE should land in a cage, not on the throne.
    • Restrict the admin console (/~/admin) to localhost or a management VPN via firewall/reverse-proxy ACLs. There is no legitimate reason for internet-facing administrative access.
    • Firewall HFS to required source networks only. If it's an internal file-drop tool, it should not answer to the internet at all.
    • Disable or audit HFS plugins and event-script functionality — these are the RCE primitives attackers abuse post-takeover.
  5. Assume breach on exposed instances. Any HFS instance that was internet-facing and unpatched since this scanning began requires triage: review HFS logs for admin console access from unknown IPs, hunt for the child-process and file-write behaviors above, check for new local accounts, scheduled tasks, and unexpected services, and inspect egress traffic from the host. If you find post-exploitation indicators, isolate and move to full IR.

  6. Watch CISA KEV. If CVE-2026-61500 is added to the Known Exploited Vulnerabilities catalog, federal civilian agencies will face a binding remediation deadline — and private-sector organizations should treat that deadline as their own. Pre-auth RCE on internet-facing infrastructure under active scanning is exactly the profile KEV was built for.

  7. Longer term: If HFS isn't delivering clear business value, decommission it. Lightweight file servers exposed to the internet have repeatedly proven to be high-value, low-effort targets. Managed file transfer solutions with proper authentication, logging, and patch management are the defensible alternative.

The pattern here is one we've seen repeatedly: a quietly exposed utility server, a session-handling flaw, active scanning, and then mass exploitation. The defenders who win are the ones who inventory fast, patch fast, and hunt for the behavior — not the ones waiting for a signature.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.