SSRF
Monthly
Server-side request forgery in YesWiki before 4.6.7 allows unauthenticated attackers to make the WebFinger subscription ('abonnements') view issue outbound HTTPS requests to attacker-supplied numeric internal hosts and ports, enabling blind probing of internal services. The flaw sits in WebfingerService, which processes a POSTed actor_handle without validating the destination host, and carries a CVSS 4.0 base score of 6.9 (independent assessment: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), confirming no authentication or user interaction is required wherever the ActivityPub/WebFinger feature is reachable. Impact is constrained to triggering outbound HTTPS connection attempts - an information-disclosure/port-probing primitive rather than full-response or arbitrary-scheme SSRF - and no public exploit code has been identified at time of analysis, although the request pattern is straightforward to script. This is a moderate-priority vulnerability.
Unauthenticated server-side request forgery in YesWiki before 4.6.7 lets remote attackers force the wiki server to fetch arbitrary URLs by supplying a syndication action through the content parameter of the render handler. The CVSS vector indicates PR:N and UI:N, so any network-reachable instance running a default configuration can be triggered without credentials or victim interaction; fetched feed content is echoed back into the rendered page, and feed enclosures are written into the files directory, yielding an internal-network read primitive plus a limited file-write side effect. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, but the low complexity and unauthenticated reach make exposed instances a practical target; the vendor has released YesWiki 4.6.7 to remediate the flaw.
Unauthenticated server-side request forgery in YesWiki before 4.6.7 allows remote attackers to make the server fetch arbitrary hosts and ports via the {{valeur}} action's url parameter, submitted through the content parameter of handlers/page/render.php. This can be used to probe internal HTTP services and read back responses matching fiche markup, though impact is limited to information disclosure and no public exploit code is identified at time of analysis. The vulnerability is medium severity (CVSS 4.0 base 6.9) and is unauthenticated (PR:N).
Unauthenticated blind server-side request forgery (SSRF) in YesWiki versions prior to 4.6.7 allows remote attackers to coerce the server into making arbitrary outbound HTTP requests through the idtypeannonce parameter of the /api/entries/bazarlist endpoint. Because the isValidURL() validation routine unconditionally returns true, any attacker-supplied URL - including internal network addresses and cloud metadata endpoints - is accepted and then fetched by curl inside loadURLContent(). The vulnerability is network-reachable and requires no authentication (CVSS v4.0 PR:N/UI:N), but its practical impact is limited by the blind nature of the flaw, since response content is not returned to the attacker; assessment scores it medium severity, and no public exploit code has been identified at time of analysis.
Server-side request forgery (SSRF) in HAVELSAN's Sef AI Chatbot Platform before version 2.1 allows an authenticated attacker with high privileges (PR:H) to cause the server to make requests to arbitrary URLs, potentially reading internal resources reachable from the server. This moderate-severity flaw (CVSS 4.9) is network-reachable without user interaction, but requires a privileged session, limiting exploitation to trusted or compromised elevated accounts. No public exploit code or confirmed active exploitation has been identified at time of analysis.
Server-side request forgery in the Model Context Protocol reference Fetch Tool (mcp-server-fetch, and the related mcp-server-everything) up to 2026.6.4 lets unauthenticated remote callers direct the fetch_url function at internal or otherwise restricted destinations by supplying a crafted url/path argument, with no destination validation in the default configuration. Impact is bounded but real: the assessed vector rates confidentiality and integrity impact as low with no availability impact, and the primary abuse case is reaching loopback services, private RFC1918 ranges, and cloud instance metadata endpoints (for example 169.254.169.254 and 100.100.100.100) from the server's network position rather than executing code. Publicly available exploit code exists (a public GitHub issue plus a VulDB entry) and the CVSS 4.0 vector carries an E:P proof-of-concept maturity flag, but there is no confirmed active exploitation (no CISA KEV listing); exposure depends on whether the Fetch Tool and its URL argument are reachable by an attacker, since these are reference servers frequently run locally beside an AI assistant.
Wormhole.app deployments built before 2026-08-22 ship with a misconfigured coturn TURN server that fails to restrict TCP relay peers, allowing an unauthenticated remote attacker to pivot through the relay to reach internal resources such as cloud instance metadata or to source TCP connections from the relay's own IP address. Because the TURN endpoint is reachable over the network with no credentials or user interaction required (CVSS:4.0 base 6.9; independently assessed as CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), impact is bounded by what the relay host's network position can reach - meaningful information disclosure and limited integrity impact rather than full compromise. This is a moderate-priority issue: it is not in CISA KEV and no public exploit code was identified at time of analysis, and the vendor has made a fixed build available.
Server-side request forgery in Ghost 3.20.2 through 6.50.x allows authenticated staff users to trigger outbound HTTP requests to arbitrary URLs via the image dimension refetching feature. Attackers can point image cards at internal network endpoints or cloud metadata services (e.g., 169.254.169.254) to access resources unavailable from the public internet. No public exploit code identified at time of analysis; the vendor has released a patch in Ghost 6.51.0.
Server-side request forgery in Ghost (TryGhost) versions 1.18.0 through 6.27.0 allows an authenticated staff-level user with permission to create or edit webhooks to make the Ghost server send requests to internal network resources, including cloud metadata services. Vendor scoring is CVSS 5.1 with PR:H, reflecting that the attacker must already hold privileged access; no public exploit code was identified at time of analysis and there is no CISA KEV listing.
Server-side request forgery in JetBrains YouTrack before 2026.2.19422 allows an authenticated user holding administrative or project-level privileges to abuse the GitHub VCS integration and coerce the YouTrack server into issuing requests to destinations of the attacker's choosing. With a CVSS 3.1 base score of 5.5 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N), the impact is bounded to limited confidentiality and integrity loss with a scope change, and the high privilege prerequisite is the dominant limiting factor - this is a moderate-severity, low-real-world-priority issue rather than an anonymous or default-configuration exposure. At the time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis.
Server-side request forgery in Form Tools through 3.1.1 allows an authenticated low-privileged user to make the server issue arbitrary outbound HTTP requests by supplying a crafted 'url' argument to the smart_fill function in /global/code/actions.php, with no user interaction required. Impact is confined to low confidentiality (probing internal services and cloud metadata endpoints reachable from the host) rather than code execution, so realistic risk is modest and depends heavily on what the server can reach. Publicly available exploit code exists, the flaw is not confirmed as actively exploited (no CISA KEV listing), and no vendor-released patch has been identified at time of analysis.
Server-side request forgery in decolua 9Router (versions up to and including 0.5.55) lets a remote attacker steer the server's outbound HTTP requests by controlling the provider_options.baseUrl argument handled by the Search Endpoint and its fetch path in src/shared/utils/ssrfGuard.js, potentially reaching loopback services, internal networks, or cloud metadata endpoints such as 169.254.169.254. The vulnerable code is a pre-patch guard that can be defeated through several documented bypass classes (trailing-dot FQDNs like 'localhost.', IPv4-mapped IPv6 addresses in hex form such as '::ffff:7f00:1', wildcard-DNS hostnames that resolve to private addresses, and public URLs that 30x-redirect to internal targets). Per the vendor vector the flaw is unauthenticated (PR:N) and exploitable in default configurations; no public exploit code was identified at time of analysis and CISA KEV does not list this issue, while the upstream project has published a fixing pull request (PR #3723) referencing the reporter's bypass analysis in issue #3714.
Server-side request forgery in Kiteworks Core before 9.5.1 lets an authenticated administrator on a node with the separately licensed gateway role enabled supply a connector URL that the server fetches without adequately validating the URL scheme or destination, causing outbound requests to internal network services. Exploitation requires two prerequisites: a valid administrative session (CVSS PR:H) and an active optional gateway role, which is not a default configuration, and the resulting impact is constrained to limited confidentiality and integrity with no availability effect (CVSS 3.3, AC:H). No public exploit code has been identified at time of analysis and there is no evidence of active exploitation; the vendor has released a fixed version, 9.5.1, and the issue was reported through CISA's coordinated disclosure channel.
Server-side request forgery in OpenClaw Windows Node through 2026.9.4 allows an attacker who already holds gateway or agent access to invoke the canvas.present capability and make the node's WebView issue requests to localhost, RFC1918 private ranges, link-local/cloud-metadata addresses, CGNAT and Tailscale (100.64/10) services from the user's machine - destinations that canvas.navigate would reject through its URL risk evaluation, which canvas.present bypasses entirely. The prerequisite is an authenticated control channel to the node (CVSS vector PR:L), so this is not exploitable by anonymous external attackers and yields only limited confidentiality and integrity impact (VC:L/VI:L, no availability impact); a prompt-injected but legitimately connected agent is a realistic delivery path. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, but it is a genuine, bounded SSRF risk in deployments that expose the gateway/agent channel. An upstream fix commit exists, though a tagged released version is not independently confirmed in the supplied data.
Credential disclosure in JetBrains YouTrack before 2026.2.19197 lets an authenticated user who can edit an existing integration's configuration URL redirect the integration's stored credentials to an attacker-controlled endpoint by simply changing that URL. The CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects a network-reachable, low-complexity, low-privilege flaw with high confidentiality impact and no integrity or availability effect, consistent with a credential-theft bug rather than code execution or full takeover; no public exploit identified at time of analysis, and no exploitation status is confirmed by CISA KEV for this CVE.
Server-side request forgery in JetBrains YouTrack before 2026.2.18991 lets an authenticated user coerce the server-side PDF export renderer into making outbound requests to attacker-influenced URLs by storing crafted XHTML content that is rendered when that content is exported to PDF. The assessed impact is confidentiality-only (CVSS 3.1 base 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), and the attack requires a valid YouTrack account plus write access to a stored field that reaches the PDF renderer; no public exploit identified at time of analysis, and the issue is not in CISA KEV.
LightLLM through version 1.2.0 accepts image_url and audio_url parameters on its multimodal inference endpoints without validating or restricting the supplied URLs, allowing unauthenticated remote attackers to coerce the server into making arbitrary outbound HTTP requests (CWE-918 server-side request forgery). An attacker who can reach an instance configured to serve a vision or audio model can point those parameters at internal-only resources, and because the fetched content is passed into model processing, the results (or the resulting error messages) can leak internal content and network topology back to the caller. Impact is limited to confidentiality and topology disclosure rather than code execution; the issue is a genuine but moderate-severity exposure, no public exploit code has been identified at time of analysis, and it has not been confirmed actively exploited (no CISA KEV listing). Deployments that only serve text models, or that do not expose multimodal endpoints to untrusted networks, are out of scope.
Server-side request forgery in the @astrojs/netlify adapter (5.2.0 through 8.2.3) lets unauthenticated remote attackers make the Netlify Image CDN fetch URLs whose host they control, by embedding an allowlisted origin inside the path or query string of a request to the public /.netlify/images endpoint. The impact is limited: Netlify egress protections restrict which internal or external targets are actually reachable and image-transformation handling prevents fetched response bodies from being returned to the attacker, so no confidentiality or integrity impact has been demonstrated and only low availability impact is assessed (CVSS 6.3 per the 4.0 vector; independent assessment CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L). No public exploit code has been identified at time of analysis, and the flaw is fixed in @astrojs/netlify 8.2.4.
Authenticated remote users of Moodle can bypass the URL downloader's host-blocking logic by encoding a restricted destination as an IPv4-mapped IPv6 address (for example ::ffff:<internal-ip>), causing the server to fetch resources from internal or otherwise blocked hosts on the attacker's behalf. Successful abuse yields Server-Side Request Forgery limited to confidentiality impact (CVSS 3.1 base 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), meaning the practical damage depends on what the Moodle server itself can reach - typically cloud instance-metadata endpoints or internal-only services - and is reduced on segmented networks. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), so this is a genuine but modest-priority issue that should be scheduled alongside routine patch cycles rather than treated as an emergency.
Server-side request forgery in the Broken Link Notifier WordPress plugin (versions 1.3.1 up to but not including 2.0.0.1) allows unauthenticated remote attackers to bypass the plugin's internal-address filter and make the WordPress host send requests to internal services. The plugin validates the URL it is given but does not re-validate the destination after an HTTP redirect, so an attacker-supplied link that redirects to a loopback, RFC1918, or cloud metadata address slips past the SSRF guard. The issue is rated CVSS 3.1 5.8 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N) with scope change into internal services but only low confidentiality impact and no integrity or availability impact; no public exploit identified at time of analysis, and CISA's SSVC assessment records no exploitation with partial technical impact.
Authenticated users can bypass server-side request forgery (SSRF) protections in ClaraVerse through version 0.3.1 by exploiting flaws in hostname validation and IPv6 transition address filtering within the download_file and scrape_web agent tools, enabling the server to make requests to internal services and cloud instance metadata endpoints. This medium-severity vulnerability (CWE-918, CVSS 5.3) requires a valid ClaraVerse account and is only impactful when the server runs in a network environment where such internal endpoints are reachable. No public exploit code has been identified at time of analysis.
Server-side request forgery in Fider before 0.38.0 lets an authenticated administrator who controls DNS for a configured hostname redirect the server's outbound HTTP requests to internal services or cloud metadata endpoints by exploiting a time-of-check/time-of-use gap between URL validation and the actual connection. The exposure is narrow: only webhook URLs and custom OAuth provider token/profile URLs are user-configurable outbound targets, the attacker needs admin privileges and must win a DNS-rebinding race (high attack complexity), and instances with AllowPrivateNetworkTargets deliberately enabled are out of scope, so this remains a low-priority issue despite the network vector (CWE-918). No public exploit code has been identified at time of analysis and there is no evidence of active exploitation; v0.38.0 fixes the flaw by re-checking the resolved IP at dial time.
Server-side request forgery in Anjvision YSSD-RTMP-H5 firmware 3.3.2.4 allows unauthenticated remote attackers to invoke the device's built-in network-check/connectivity-probe function and make it issue requests to arbitrary hosts reachable from the camera's internal network. The resulting impact is limited to low-confidentiality disclosure -- internal host enumeration and small data leaks via DNS resolution -- with no integrity or availability effect, consistent with the assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation; the issue was reported through CISA's ICS-CERT program as ICSA-26-272-05.
The FTP client component of Eclipse ThreadX NetX Duo trusts the IPv4 address returned in a server's 227 PASV reply, performing only parse and non-zero checks before opening a data connection to that address, which lets a malicious or man-in-the-middle FTP server redirect the client's data transfer to any host it names (CWE-918 server-side request forgery class). Only the IPv4 passive-mode path is affected; the client must itself initiate an FTP control session to a hostile or intercepted endpoint and then request a passive transfer. No authentication or user interaction beyond starting the session is required (CVSS:4.0 base 6.9; independent assessment CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), and no public exploit code or active exploitation has been identified at time of analysis.
Dell Secure Connect Gateway (SCG) Policy Manager versions prior to 5.34.00.16 contain an open redirect vulnerability that allows unauthenticated remote attackers to craft a link which, when followed by a victim user, redirects to an untrusted site and can lead to server-side request forgery (SSRF). The CVSS 3.1 base score is 5.4 (medium) due to the requirement for user interaction (UI:R) and low confidentiality/integrity impact. No public exploit code has been identified at time of analysis, and the vulnerability is not known to be actively exploited.
Server-side request forgery (SSRF) in MODSetter SurfSense 0.0.36 and earlier allows an authenticated, low-privilege user to make the backend dereference attacker-influenced URLs by supplying crafted content to the Document Export Feature (the export_document route in surfsense_backend/app/routes/editor_routes.py). Because the server-side export/conversion pipeline (pypandoc/typst) fetches or processes references embedded in document content, a malicious export request can cause the server to issue outbound requests to resources it can reach. Publicly available exploit code exists and the flaw is remotely reachable, but the assessed impact is confidentiality-limited (VC:L) with no integrity or availability effect, making this a genuinely low-severity issue despite remote reachability.
The JavaScript library ip-address (npm) fails to treat the NAT64 local-use prefix 64:ff9b:1::/48 as private, so applications that lean on Address6.isPrivate - typically together with isLoopback and isLinkLocal - to enforce an SSRF or trust-boundary policy can be tricked into reading an internal IPv4 destination as external. Unauthenticated network attackers can exploit this (CVSS v4.0 6.9; independent assessment CVSS v3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N) only when the target server's network actually uses an operator-chosen NAT64 prefix carved from the RFC 8215 local-use range, and only when the consuming application composes these classifiers as a security control; information disclosure is the realistic outcome, with no impact on integrity or availability. Versions 10.2.0 through 10.5.0 are affected and the issue is fixed in 10.5.1; no public exploit code or confirmed active exploitation was identified at time of analysis, and exploitation is further gated by the non-default NAT64 deployment and by the application's use of these methods for enforcement.
Server-side request forgery (SSRF) in October CMS 4.3.4 and earlier allows unauthenticated remote attackers to bypass the validateExternalImageHost protection in System/Classes/ResizeImages.php by supplying a crafted IPv6-mapped IPv4 host, causing the server to fetch attacker-controlled or internal URLs. Publicly available exploit code exists (no CISA KEV confirmation of active exploitation), and the assessed impact is a largely blind SSRF with Low confidentiality, integrity and availability impact, so real-world severity depends on what internal services or cloud metadata endpoints the server can reach. October CMS 4.3.5 resolves the bypass; the issue is genuine but should be treated as low-to-moderate priority.
Incomplete scheme validation in October CMS's image resizer (getSourcePathForResize() in modules/system/classes/ResizeImages.php) allows non-HTTP PHP stream wrappers such as phar://, file:// and ftp:// to be stored in the resize cache and later handed to the underlying image library, producing a server-side request forgery condition that on phar:// paths can trigger metadata deserialization during subsequent file operations. Affected builds are 4.1.x up to 4.1.19, 4.2.x up to 4.2.25 and 4.3.0 through 4.3.4; upgrading to 4.3.5 or 4.4.0 resolves the issue (patch commit 0e9736aa2c6d6bd3d60ff6ef9e0b4d32ce387f58). Publicly available exploit code exists (reported by 0xGenesi, tracked as CVE-2026-100909), but no confirmed active exploitation has been observed; reachability is narrow because the flaw only matters where a pre-existing injection primitive already pipes untrusted input into the |resize Twig filter or the ResizeImages::resize() API without validating the scheme, so default templates and trusted-value usages (uploaded file models, theme assets, static URLs) are not exposed.
Server-side request forgery in athlon1600 youtube-downloader up to 4.0.1 lets remote, unauthenticated attackers make the server issue attacker-controlled HTTP/HTTPS requests by manipulating the url argument of public/stream.php. Publicly available exploit code exists (per VulDB and the linked exploit gist), but there is no CISA KEV confirmation of active exploitation, and assessed impact is limited to low confidentiality and integrity effects against internal services and cloud metadata endpoints reachable from the host. The vendor was contacted early and never responded, and the only code change tied to this component (commit 6ffe823, 'better security for public/stream.php') is a partial hardening rather than a fix.
Server-side request forgery in DevaslanPHP project-management affects versions 1.2.1 through 1.2.4 and v2.0.0-beta1 and allows an authenticated, low-privileged user to make the application issue requests to attacker-chosen destinations. The flaw sits in the updateJiraProjects function of the /jira-import endpoint, where host, username and token parameters are accepted without an adequate authorization check (per the independent assessment, a missing canAccess check), so any user who can reach the Jira Import feature can force outbound connections from the server while only obtaining limited read/write effect. Publicly available exploit code exists (also reflected by the E:P metric in the vendor-supplied CVSS 4.0 vector), but there is no indication of confirmed active exploitation, and the vendor was contacted early and did not respond. This is a genuine but low-priority issue: the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, i.e. partial confidentiality and integrity impact only, gated behind authenticated access to the import feature.
Server-side request forgery in Privoce VoceChat Server 0.5.36 and earlier lets unauthenticated remote attackers force the server to issue outbound HTTP requests to arbitrary URLs through the OpenGraph link-preview endpoint, potentially reaching internal services or cloud metadata endpoints reachable from the server's network position. Publicly available exploit code exists, and the vendor was notified early but did not respond, so no vendor-released patch has been confirmed. Per the assessed vector (AV:N/AC:L/PR:N/UI:N) this is a real but moderate-priority SSRF - no credentials or user interaction are required, but impact is bounded to low confidentiality, integrity and availability effects and depends on whether fetch responses or errors are reflected back to the attacker (blind vs non-blind is not confirmed in the source data).
Authenticated users of the Nezha monitoring dashboard (versions 2.0.10 through 2.3.2) who can configure notification or DDNS webhook URLs can bypass the dashboard's SSRF denylist by supplying an IPv6 literal in the 6to4 prefix 2002::/16 or the local-use NAT64 prefix 64:ff9b:1::/48, causing the server to issue outbound HTTP requests to those endpoints. Exploitation is heavily constrained: the CVSS vector is PR:L, meaning an attacker must already hold a webhook-configuring account, and meaningful impact depends on the deployment's network providing unusual or non-standards-compliant routing for these transition ranges; the advisory confirms no path to IPv4 metadata, loopback, or private-network requests was demonstrated. No public exploit code has been identified at time of analysis and the issue is not known to be exploited, but the vendor has shipped a fix in version 2.3.3 (commit d1fcde8e) that explicitly blocks both prefixes. The independent assessment rates this as a low-priority, high-caveat SSRF with AC:H and only low confidentiality impact.
Server-side request forgery in the UTCP Python GraphQL (utcp-gql) and WebSocket (utcp-websocket) plugins at 1.1.0 and earlier lets unauthenticated attackers (CVSS 4.0 vector PR:N, and the assessed 3.1 vector AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N) force the host to open outbound connections to internal services and cloud metadata endpoints such as 169.254.169.254. utcp-gql still relies on a startswith prefix check for http://localhost and http://127.0.0.1, so crafted hostnames like http://127.0.0.1.attacker.example or http://localhost.evil.com satisfy the check and then resolve to any address the attacker's DNS returns, while utcp-websocket performs no URL validation at all despite docstrings claiming it enforces 'WSS or localhost only'. Both plugins attach the call template's configured auth headers to the outbound connection, so a successful SSRF also exfiltrates configured API keys and OAuth tokens to the attacker-controlled host; risk is genuine but low urgency, exploitation requires the victim to ingest an attacker-supplied tool or manual call-template URL (UI:P/UI:R) and, for the GraphQL path, attacker-controlled DNS resolution, and no public exploit identified at time of analysis (no CISA KEV entry, no POC reported).
Cloudreve before 4.17.0 applies only the Admin.Read OAuth scope to the admin node test endpoints (POST /api/v4/admin/node/test and POST /api/v4/admin/node/test/downloader), while the sibling node create, update, and delete routes correctly demand Admin.Write. An authenticated holder of an admin-authorized OAuth token carrying only Admin.Read can therefore submit crafted node definitions and force the Cloudreve server to make outbound requests to arbitrary URLs, yielding blind server-side request forgery, internal service probing, and delivery of signed Cloudreve slave-style requests to attacker-chosen hosts; because the responses are not returned to the caller, impact is limited to blind SSRF and availability-adjacent network effects rather than direct data disclosure. No public exploit code was identified at time of analysis, exploitation is not confirmed in CISA KEV, and the practical prerequisite is an environment where an administrator has granted an OAuth client the Admin.Read scope - a real but bounded prerequisite that is consistent with the medium (5.3) severity rating and the authenticated (PR:L) nature of the flaw. The vendor has released a patch in 4.17.0 and upstream fix commit 332a9d800205082a2469e555fd66a63f18d9d5dc.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.27 lets an authenticated user holding contributor-level access or higher supply an arbitrary URL through the plugin's feed-fetch feature, causing the web server to request that URL and return the response body back to the requester; the plugin performs no capability check on that action. Because the request originates from the server, the attacker can reach internal-only or loopback services that are otherwise unreachable from the internet - most notably cloud instance metadata endpoints and internal administrative interfaces - but the impact is limited to confidentiality, since no code execution or write capability is demonstrated. Publicly available exploit code exists (the WPScan entry documents the issue), CISA KEV does not list the CVE, and EPSS is 0.13% (2nd percentile), indicating low near-term exploitation likelihood; the assessed severity is low-to-moderate, contingent on the site allowing low-trust contributor registrations and on which internal services are reachable from the web server.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before version 2.8.27 allows an authenticated attacker holding contributor-level access or higher to direct the web server to fetch an arbitrary attacker-supplied feed URL and read the response back, enabling internal-only reconnaissance and retrieval of sensitive data such as cloud instance metadata. The plugin performs neither a capability check nor any validation of the destination before issuing the server-side request, and because the retrieval is non-blind the attacker receives the fetched content rather than learning only success or failure. Exploitation is constrained by the contributor-role prerequisite and by read-only impact (no write, no code execution), and public exploit code exists via the WPScan disclosure while EPSS remains very low at 0.13% (2nd percentile) and CISA's SSVC assessment records exploitation as none; this is a genuine but low-priority issue.
Server-side request forgery in Heym 0.0.90 and earlier lets a caller-controlled workflow input steer an outbound HTTP fetch to loopback, RFC1918, link-local, or cloud metadata endpoints such as 169.254.169.254. Two distinct egress gaps exist: the LLM image-edit loader (_load_image_bytes) issues a bare httpx.get that skips the egress-pinning client, and _is_public_address only unwraps IPv4-mapped IPv6, so NAT64 (64:ff9b::/96), IPv4-compatible (::x.x.x.x), and 6to4 (2002::/16) encodings can smuggle internal IPv4 destinations past both URL validation and the dial-time IP pin. Exploitation is not automatic: an authenticated workflow author must have deliberately wired a caller-controlled expression such as "imageInput": "$userInput.body.imageUrl" before an unauthenticated webhook or API caller can pick the target, and this is best treated as a low-to-medium priority SSRF issue; no public exploit code was identified at time of analysis. The second, IPv6-based gap additionally depends on the Python 3.11.0 through 3.11.9 behavior that classifies 6to4 as globally routable.
SSRF protections can be bypassed in heym before 0.0.105 by authenticated users who configure integration service credentials with base URLs pointing to internal or cloud-metadata addresses, enabling them to read internal service responses through workflow node output. This moderate-severity issue requires low-privileged authentication and has no public exploit identified at time of analysis.
AzuraCast deployments before 0.23.8 expose a server-side request forgery and local file read flaw in the AutoDJ remote playlist fetcher, letting an authenticated user who holds the station Media permission point a remote_url playlist at a file:// path or an internal/loopback HTTP endpoint and have the backend fetch it with file_get_contents(). The retrieved lines are stored as queue entries and then disclosed through GET /api/station/{station_id}/queue to any user with the Broadcasting permission, exposing host files readable by the web container (such as /etc/passwd or the application .env) and the bodies of non-blind internal HTTP requests. Exploitation is bounded by valid low-privilege authentication and by the privileges of the web container, and no public exploit code was identified at time of analysis; the advisory data states that no patched version was available at publication, so mitigation depends on disabling PHP allow_url_fopen or tightening Media-permission access.
Server-side request forgery in Adminer 5.5.1 through 6.0.1 lets a remote, unauthenticated attacker force the server to open outbound TCP connections to arbitrary internal hosts and privileged ports before any credentials are validated, by supplying a crafted login 'server' value such as '127.0.0.1:80/x'. The flaw is a regression that re-opens the privileged-port bypass originally fixed in 5.5.0, and because the connection is blind - the attacker only observes refused/handshake/timeout states - impact is limited to internal port scanning and SSRF probing rather than data disclosure or code execution. No public exploit code has been identified at time of analysis and there is no evidence of active exploitation; the vendor-released fix is Adminer 6.0.2.
Unauthenticated server-side request forgery in Adminer 6.0.0 and 6.0.1, when the optional ClickHouse driver plugin is loaded, allows remote attackers to make the server send HTTP POST requests containing 'SELECT version()' to arbitrary internal URLs and read the response bodies of services that return non-2xx/401/403 status codes, potentially exposing internal error pages with sensitive information. The vulnerability is gated by the presence of the ClickHouse driver plugin and does not affect default Adminer installations. No public exploit code has been identified at time of analysis, and the vendor has released Adminer 6.0.2 to fix the issue.
Server-side request forgery in Adminer's optional Elasticsearch driver (plugins/drivers/elastic.php) lets unauthenticated remote attackers force the Adminer host to issue HTTP GET requests to arbitrary reachable hosts and ports, because include/auth.inc.php calls Driver::connect() before it validates the submitted login result. Versions 4.16.0 through 6.0.1 are affected and the issue is conditional: it requires that the optional Elasticsearch driver be explicitly deployed (via the adminer/elastic.php template or an adminer_object() configuration) and that PHP allow_url_fopen be enabled so get_url()/file_get_contents() can send the outbound request. Impact is limited to low-confidentiality reconnaissance - a port-scanning oracle built from leaked JSON error fields and connection-failure text rendered on the login page - with no integrity or availability impact, and the independent assessment rates the issue MEDIUM, consistent with the vendor's CVSS 4.0 base score of 6.9; fixed in 6.0.2 and no public exploit identified at time of analysis.
Unauthenticated server-side request forgery in Budibase's Microsoft Teams webhook endpoint (all Budibase Server releases before 3.45.0) lets remote attackers submit a forged Bot Framework activity containing an arbitrary serviceUrl that the server persists and then reuses for every subsequent outbound bot reply. Those replies carry live Microsoft OAuth access tokens in their Authorization headers, so the server ultimately transmits credentials to the attacker's host and can also be steered into blind requests against internal network resources. The flaw is network-reachable and needs no authentication or user interaction (CVSS 4.0 PR:N/UI:N/AV:N), but exploitation is tempered by high attack complexity (AC:H) because a structurally valid activity payload is required and the attacker must win the persistence-then-reply flow; the endpoint is only exposed where the Microsoft Teams bot integration is configured and reachable, and no public exploit has been identified at time of analysis.
Server-side request forgery in ClawHub's public profile preview allows unauthenticated remote attackers to supply an image URL whose hostname passes the textual private-address check but whose DNS resolution points to an internal, loopback, or rebinding-controlled destination, causing the backend to issue outbound requests to attacker-chosen internal targets. The flaw affects self-hosted ClawHub (openclaw/clawhub) application/backend deployments at revision cbfee7343ddc867316dd9b3de6fa8856730f9f41 or unfixed ancestors; the hosted clawhub.ai instance was patched on 2026-09-11, so only unpatched self-hosted instances remain exposed, and the npm CLI and OpenClaw runtime are separate, unaffected products. No public exploit code and no CISA KEV entry were identified at time of analysis, and the reporting researcher demonstrated only a loopback listener connection - access to production internal services, credential disclosure, and code execution were not demonstrated.
Server-side request forgery (SSRF) in the Testimonials Widget WordPress plugin through version 4.0.4 allows unauthenticated remote attackers to make the server fetch arbitrary URLs and store the responses as publicly accessible files. This enables reading responses from internal services reachable from the WordPress server, though the impact is confidentiality-only and practical value depends on internal network reachability. Publicly available exploit code exists, and the EPSS score is 0.14% (3rd percentile), indicating a low predicted likelihood of exploitation.
Server-side request forgery in OpenClaw before 2026.8.1 allows a malicious or compromised video-asset provider to point the CLI at private or loopback URLs, causing requests to internal services reachable from the OpenClaw host. The attacker cannot reach OpenClaw directly: exploitation depends on the attacker controlling or compromising a provider the host already trusts and queries, on the video-fetch code path being exercised, and on an internal service being reachable, which is why our assessment rates exploitability as high-complexity with only low confidentiality impact. No public exploit code has been identified at time of analysis and there is no KEV designation; the vendor has released a patch, and EPSS does not flag this as a high-likelihood target.
Server-side request forgery in OpenClaw before 2026.8.1 allows an attacker who can already drive the agent to make it reach loopback or private-network destinations through the browser `wait --fn` predicate function, bypassing the navigation-time SSRF checks that guard other browser actions. The prerequisite is meaningful: the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) requires low-privilege access to the agent plus an existing or active browser session, so this is not exploitable by unauthenticated external users or against default deployments without agent access. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, and the vendor's own low score (5.3) is consistent with the limited confidentiality and integrity impact assessed here.
Blind server-side request forgery in OpenMetadata through 2.0.2 allows an authenticated user holding permission to create or update an EventSubscription to point a WEBHOOK destination at internal hosts, loopback addresses, or the cloud metadata endpoint 169.254.169.254, because URLValidator.validateURL neither resolves DNS hostnames nor rejects internal/private addresses. Only the resulting HTTP status code is returned to the caller, so the leak is blind internal probing rather than response-body exfiltration or code execution. Publicly available exploit code exists (a proof-of-concept gist is linked from the vendor advisory) and the assessed CVSS 4.0 base score is 5.1; no confirmed active exploitation (CISA KEV) is referenced in the available intelligence.
Server-side request forgery in Zammad (versions prior to 7.0.2) lets a user who controls their own profile at a connected federated identity provider (OAuth, OIDC, or SAML) make the helpdesk server issue outbound HTTP requests to attacker-chosen addresses, including internal network locations, by supplying a crafted profile image URL. Because the fetch is blind, the attacker infers internal reachability only from differences in response timing and error patterns, and each probe can block a worker process for several seconds, producing a minor availability side effect. No public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited; exploitation requires a non-default deployment where federated login is configured and the attacker can edit their provider-side profile image URL. Fixed in Zammad 7.0.2.
Server-side request forgery in the WordPress plugin Asset CleanUp: Page Speed Booster (versions up to and including 1.4.0.5) lets an authenticated attacker with administrator-level access trick the site's server into issuing HTTP requests to arbitrary internal or external locations through the 'page_url' parameter, potentially allowing them to probe or interact with internal services. Exploitation is doubly gated: the attacker must already hold admin privileges, and the plugin's dom_get_type setting must be configured to 'wp_remote_post', a non-default administrator-controlled option, so untargeted opportunistic abuse is unlikely and no public exploit code has been identified at time of analysis. The result is a genuine but low-priority issue rather than an urgent one.
Server-side request forgery in the Link Library WordPress plugin versions 7.8.8 through 7.9.5 allows unauthenticated visitors to make the site issue outbound requests to hosts on its internal network and to observe from the response whether an internal service answered. The flaw is an incomplete fix for CVE-2025-68600 and only manifests when the plugin's protected 'safe request' is rejected and it falls back to an unprotected fetch, so sites must have published the plugin's public link submission form with reciprocal-link validation enabled to be exposed. Publicly available exploit code exists, but EPSS is only 0.13% (2nd percentile) and the independent assessment rates this as a genuinely low-priority, information-only issue with a non-default configuration prerequisite.
Server-side request forgery in the Image API (v2) of OpenStack Glance allows an authenticated tenant user (CVSS vector PR:L, network reachable) to make the glance-api service issue HTTP requests to attacker-chosen URLs by manipulating the 'locations' attribute of an image that is in the 'queued' state via a crafted PATCH request, potentially exposing internal-only services or cloud metadata (high confidentiality impact, limited integrity impact per the assessed vector). The vulnerability is strictly gated: it only functions when the non-default, deprecated 'show_multiple_locations' option is explicitly enabled in glance-api.conf, so standard OpenStack deployments that leave this setting off are not exploitable, and the attacker must hold valid tenant credentials and network access to the Glance API endpoint. Scoring is 8.1 with a low EPSS of 0.31% (21st percentile); the issue is not confirmed actively exploited (CISA KEV) and no public exploit identified at time of analysis, although a GitHub repository referencing this CVE and the companion CVE-2026-51773 has appeared and should be treated as a possible proof-of-concept.
Server-side request forgery in the chat-server component of songxinjianqwe Chat (ChatServer.java) allows remote, unauthenticated attackers to coerce the server into issuing HTTP requests to attacker-chosen URLs. The flaw is reachable over the network with low complexity and no user interaction (CVSS:4.0 AV:N/AC:L/PR:N/UI:N), but all impact metrics are rated Low (VC:L/VI:L/VA:L) with no downstream-system impact, so practical damage is limited to constrained or blind SSRF-style information leakage and internal-network probing rather than full internal pivoting. Publicly available exploit code exists (referenced from a GitHub issue), and VulDB reports that the vendor was contacted but did not respond; the project uses a rolling release model, so no specific fixed version is documented. Affected deployments are typically hobbyist Java chat-server instances rather than internet-exposed production services.
The MongoDB Python Driver (PyMongo) versions 3.9.0 through 4.18.1 can be induced to open connections to local Unix domain sockets on the application host when an attacker who already holds write access to the encryption key metadata in the database alters a key management (KMS) endpoint value so that it ends in '.sock' - a string the client-side field level encryption (CSFLE) code path mistakes for a local socket path instead of a remote host. Exploitation requires the opt-in, non-default CSFLE feature to be in use and an authenticated attacker with database-side write access to the key vault, and it is only reachable over the network in the sense that CVSS scores the vector AV:N/PR:L; the transmitted bytes are restricted to the beginning of a TLS handshake, so no attacker-chosen content reaches the socket and data exfiltration or arbitrary remote-host reachability is not achievable. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; despite the CWE-918 (SSRF) classification, this is a low-priority, low-impact defect. Vendor-released patch: 4.18.2.
Server-side request forgery in the AI Knowledge Module of ruoyi-vue-pro (versions through 2026.08) allows an authenticated low-privilege user to coerce the application server into issuing arbitrary outbound HTTP requests via the AiKnowledgeDocumentServiceImpl.readUrl document-import function, which fetches a caller-supplied URL without adequate validation. Exploitation is remote and low-complexity and requires only a valid low-privilege account plus an enabled/reachable AI Knowledge feature; the practical impact is bounded by what the server can reach on the internal network, such as internal HTTP services, admin panels, or cloud instance-metadata endpoints, resulting in limited confidentiality and integrity exposure. Publicly available exploit code exists, no CISA KEV entry confirms active exploitation, and the vendor was contacted about the disclosure but did not respond, so an upstream patch is not available and this is a genuine but moderate-priority issue whose real-world severity depends on the operator's outbound egress controls.
Server-side request forgery in TREK (versions prior to 3.4.0) allows an authenticated user to reach internal services or cloud metadata by supplying a URL whose DNS AAAA answer is a NAT64, 6to4, or Teredo IPv6 transition address that encodes a private, loopback, or link-local IPv4 target, bypassing the checkSsrf guard in server/src/utils/ssrfGuard.ts. Exploitation is conditional rather than automatic: it requires a valid TREK account, attacker control of a DNS record, a feature that performs server-side egress (imports, webhooks, integrations, or plugin egress), and a hosting environment that actually routes the chosen transition format - the reason the assessed CVSS is 6.3 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N) with high attack complexity and confidentiality-only impact. No public exploit code has been identified at time of analysis, and TREK 3.4.0 fixes the flaw.
Server-side request forgery in Termix 2.5.0 lets authenticated users make the Termix server issue outbound HTTP requests to arbitrary destinations, including internal services that are normally unreachable from outside the host network. An attacker with a low-privileged account can register a webhook or ntfy notification channel pointing at an internal address and then trigger it through the notification-channel test endpoint, which reaches the request-sending code in src/backend/utils/notification-sender.ts without any destination allowlisting or private-address blocking. Because webhook mode also honors attacker-chosen HTTP methods and headers, the requests are blind but not strictly read-only: an internal service that accepts the fixed notification body may still change state, though response bodies are never returned to the attacker. No public exploit code has been identified at time of analysis and the issue is fixed in version 2.5.1.
Blind server-side request forgery in the Kirki - Freeform Page Builder, Website Builder & Customizer plugin for WordPress, affecting all versions up to and including 6.2.0, allows unauthenticated remote attackers to make the WordPress server issue HTTP requests to arbitrary locations by supplying an attacker-controlled URL in the 'kirki_data' parameter. Because the SSRF is blind (no response body is returned to the attacker), exploitation is assessed as high-complexity: the attacker must already know or correctly guess reachable internal hosts or services, so the practical impact is limited to internal service enumeration, state-changing requests against unauthenticated internal endpoints, and access to cloud instance-metadata addresses that the host can reach. There is no public exploit identified at time of analysis and the vulnerability is not confirmed actively exploited (CISA KEV), making this a moderate-risk, not top-priority, issue for most deployments - though it becomes materially more serious on hosts with broad outbound network reachability or attached cloud IAM roles.
Server-side request forgery in Red Hat Ansible Automation Platform 2's automation-controller email notification backend lets an authenticated user holding organization notification-admin permission point an email notification template's SMTP host and port at arbitrary internal, loopback, link-local or reserved addresses; the controller task process then opens a raw TCP connection to that target when the notification test is triggered. Because the resulting connection error is surfaced through the notification record, an attacker gains a three-state internal port-scan oracle (open, closed, filtered) over the control-plane cluster network, including the in-cluster Kubernetes API, and if a shared organization template stores an SMTP password, redirecting the host can leak that credential to an attacker-controlled server. Impact is moderate (vendor CVSS 6.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) and requires a privileged, already-authenticated role rather than anonymous access; no public exploit code has been identified at time of analysis and CISA KEV does not list this CVE.
Server-side request forgery in Plex Media Server before 1.43.3.10861 allows any authenticated user - including a low-trust account invited only to a shared library - to coerce the server into issuing HTTP requests to arbitrary internal or external addresses through the path parameter of the '/video/:/transcode/universal' endpoint. The attacker gains no code execution and the assessed impact is confidentiality-only and limited (CVSS 4.3, C:L/I:N/A:N), but the flaw is a useful internal-network reconnaissance and pivot primitive on internet-facing or flat-network deployments. No public exploit identified at time of analysis; exploitation requires a valid authenticated session and a server running a version prior to 1.43.3.10861.
Server-side request forgery in Plex Media Server before 1.43.3.10861 allows a low-privileged, token-bearing caller to force the server to POST to an arbitrary destination by putting a full URL in the 'protocol' parameter of the '/player/timeline' endpoint. Because any X-Plex-Token value is accepted, the authentication barrier is effectively trivial, but the assessed impact is limited to a blind outbound request (confidentiality-low, no integrity or availability effect) against hosts reachable by the Plex process. No CISA KEV entry and no confirmed exploitation have been reported, and no public exploit code was identified at time of analysis; the practical risk is a genuine but low-priority SSRF that matters most for internet- or DMZ-exposed servers that can reach sensitive internal services.
Server-side request forgery (SSRF) in the Weoll collaboration platform (Global IT Informatics Technology Services Inc.) allows remote attackers to coerce the server into making crafted outbound requests against internal or back-end resources. Only deployments running Weoll before 3.2.45.44 are affected; the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) places the flaw at 6.5 with a high confidentiality impact but no integrity or availability effect and no scope change. Exploitation requires the application to expose a server-side URL-fetching or resource-retrieval feature and, per UI:R, depends on a user being induced to trigger the crafted request rather than fully autonomous attacker action; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis.
Server-side request forgery in the Directorist: AI-Powered Business Directory, Listings & Classified Ads WordPress plugin (versions before 8.9.5) lets any authenticated user with subscriber-level access or above supply a URL that the server then fetches without validation, causing the WordPress host to issue requests to internal addresses and services. Exploitation requires only a low-privilege account, which is realistic on directory and classified-ad sites that typically enable open registration, and the request succeeds without any victim interaction. Impact is limited to confidentiality (CVSS 5.0, C:L), there is no public exploit identified at time of analysis, and updating to 8.9.5 remediates the issue.
Server-side request forgery (SSRF) in iFlytek astron-agent through version 1.0.6 lets an authenticated console user steer server-side HTTP requests to internal or otherwise restricted destinations by supplying a crafted endPoint argument to the debugToolV2 API, which reaches UrlCheckTool.checkUrl. The weakness is a redirect-handling gap: the pre-patch validator followed only a single 301/302/303 hop and ignored 307/308, so a URL that passes the initial blacklist/whitelist check can still bounce the request to an internal target; the vendor fixed this in release reward-1575 with a bounded 5-hop chain that revalidates every hop and detects loops. Impact is limited (CVSS 4.0 score 5.3; independent assessment CVSS 3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), requiring valid console credentials, and no public exploit identified at time of analysis.
Server-side request forgery in IBM Concert 1.0.0 through 3.0.0 allows an attacker who holds valid credentials to make the application issue HTTP requests to URLs of their choosing, which can be used to enumerate internal network services and set up follow-on attacks. The impact is bounded: the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, 6.5 by the vendor) reflects limited confidentiality and integrity loss rather than code execution or arbitrary file read, and exploitation requires a reachable Concert feature that dispatches server-side requests to a user-influenced URL. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (it is not in CISA KEV); IBM has published a fix via its support advisory.
Server-side request forgery in Mattermost (11.7.x through 11.7.10, 11.8.x through 11.8.5, 11.9.x through 11.9.1, and 11.10.x through 11.10.1) allows an authenticated System Administrator to set the OAuth token or userinfo endpoint to an internal network address, causing the Mattermost server to issue that request because the platform's internal-connection filter is not applied to OAuth endpoint traffic, and then read the internal response back through the configured OAuth flow. Impact is bounded: the attacker must already hold the highly-trusted System Administrator role (CVSS PR:H), confidentiality and integrity effects are Low with no availability impact, and the flaw only matters where the Mattermost server has network reachability to sensitive internal services. There is no public exploit identified at time of analysis, no CISA KEV listing, and the vendor CVSS of 5.5 (Medium) is well-calibrated - this is a genuinely low-priority issue despite the CWE-918 classification. The assessment vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N matches the vendor.
Server-side request forgery in the Home Assistant IPP integration allows an attacker on the same local network to coerce the platform's shared HTTP client into issuing requests to loopback or other internal services, affecting Home Assistant Core versions prior to 2026.2.3. The attacker needs only to broadcast a crafted unauthenticated _ipp._tcp.local mDNS announcement whose host, port, and base_path values are consumed by async_step_zeroconf in homeassistant/components/ipp/config_flow.py, which then hands them to validate_input for printer metadata retrieval; the shared aiohttp client followed cross-origin redirects without blocking loopback targets, so no prior IPP configuration, no authentication (PR:N), and no user interaction (UI:N) are required. Impact is bounded by the adjacent-network vector (AV:A) and by the constrained confidentiality and integrity effects of the coerced internal request - no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); exploitation conditions are local-network only, not internet-reachable. Fixed in 2026.2.3.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an MCP caller who controls the public Jira base URL have a Jira user-lookup request redirected to an internal address, bypassing the SSRF redirect protections previously added for CVE-2026-27826. The vulnerable path is JiraUserMixin._lookup_user_by_permissions, which calls the module-level requests.get instead of the fetcher's protected session, so the response hook that enforces redirect validation is never applied. Impact is limited and blind (confidentiality-only, no integrity or availability effect) and, per the independent assessment, requires the attacker to control the Jira endpoint plus a server that issues a redirect to an internal target, making it most realistic in HTTP/multi-user or shared-credential deployments rather than single-user stdio setups with a fixed trusted Jira URL. No public exploit code was identified at time of analysis and there is no KEV listing; v0.22.0 resolves the issue.
Server-side request forgery in changedetection.io's Add Watch preview endpoint (/add_watch_ui/snapshot) allows remote attackers to force the server's browser fetcher to request attacker-chosen http(s) URLs, including loopback services, RFC1918 hosts, and the 169.254.169.254 cloud metadata address, because the url argument is validated only for an http:// or https:// prefix. The route is wrapped in login_optionally_required, so it can be reached unauthenticated on default installs that have no password set and requires credentials only where an operator has configured one; publicly available exploit code exists, and it is not confirmed as actively exploited (no CISA KEV entry). This is a moderate, credible risk rather than a critical one, with impact bounded to what the returned screenshot and rendered page data expose about internal targets; the vendor-released fix is version 0.60.1 (commit 71d332d5a0d3da2a0fe89a392413bf4b7d27c84e).
Server-side request forgery in FastGPT versions prior to 4.15.2 lets an authenticated user with access to any server-side URL-consuming feature - a safe-Axios-backed HTTP tool, workflow HTTP node, external file-fetch integration, or similar integration - bypass the platform's built-in private-address block and reach loopback, private, link-local, or cloud instance-metadata services. The bypass works because the safe Axios interceptor in packages/service/common/api/axios.ts validates the hostname with isInternalAddress() before a separate HTTP connection performs its own DNS lookup, opening a time-of-check/time-of-use (DNS rebinding) window in which an attacker-controlled hostname resolves publicly during validation and to an internal address at connection time; the same independent re-resolution occurs after each manual redirect hop. Exploitation requires authentication, attacker-controlled authoritative DNS, and winning the resolution race, so while impact is high (read access to internal services and metadata, scope-changed), practical exploitation is non-trivial; no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in Novu prior to 3.18.0 allows an authenticated user to make the notification worker issue attacker-directed POST requests to internal or otherwise restricted network services by supplying a chat webhook URL through subscriber credentials.webhookUrl, channel endpoint.url, event payload.webhookUrl, or event overrides.webhookUrl. The Slack, Discord, Mattermost, Microsoft Teams, Grafana On-Call, Ryver, Rocket.Chat, GetStream, and Zulip chat providers pass that URL straight into raw HTTP requests in send-message-chat.usecase.ts without the normalizeOutboundHttpUrl, assertSafeOutboundUrl, or DNS-pinned safeOutboundJsonRequest guards that protect Novu's generic webhook providers, resulting in a largely blind, POST-only SSRF whose impact is bounded to interactions or actions offered by the reached internal service (CVSS 5.3; assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N). Exploitation requires a valid authenticated account and worker-level network reachability to the intended target; no public exploit code has been identified at time of analysis and there is no confirmation of active exploitation (CISA KEV). The issue is fixed in version 3.18.0.
Server-side request forgery in Cloudreve prior to 4.18.0 allows an authenticated user with remote-download privileges to bypass the ValidateExternalURL guard and make the server fetch loopback, private, link-local, or cloud-metadata IPv4 addresses that are wrapped inside IPv4-in-IPv6 transition forms - NAT64 64:ff9b::/96, 6to4 2002::/16, Teredo 2001:0000::/32, or the deprecated IPv4-compatible ::a.b.c.d - because the guard classifies the wrapper rather than the address actually reached. The vulnerability is reachable through SrcUri in RemoteDownloadTask.createDownloadTask and requires authentication (CVSS PR:L), so it is not remotely exploitable by an anonymous attacker; exploitation also depends on the fetch host's network actually routing the chosen transition form to the embedded IPv4, making NAT64, dual-stack, and cloud-hosted deployments the realistic targets. Where a cloud metadata service is reachable, a successful request can return internal service responses and expose instance credentials; no public exploit code has been identified at time of analysis, and the issue is fixed in version 4.18.0.
Blind server-side request forgery in MISP allows unauthenticated remote attackers to coerce the MISP server into making outbound HTTPS requests to arbitrary internal or external targets by POSTing a crafted XML body containing a bare HTTPS URL to the unauthenticated cspReport endpoint. The flaw arises because PHP operator precedence in Xml::build()'s readFile guard (`readFile && http || https`) leaves the HTTPS locator fetch path ungated, and RequestHandlerComponent automatically decodes XML request bodies on write requests. Exploitation is constrained to blind SSRF with no response body returned to the attacker, so it primarily enables probing, timing-based reconnaissance, and triggering GET-style actions on reachable HTTPS services; no public exploit code was identified at time of analysis, and a vendor patch commit is available.
Server-side request forgery in the Tauri HTTP plugin (tauri-plugin-http) before http-v2.7.0 lets any host the plugin's scope allowlist permits - a host the attacker controls or one hosting an open redirect - bounce the request onward to destinations the scope explicitly denies, including cloud metadata endpoints such as 169.254.169.254, localhost services, and internal network hosts. The plugin's reqwest client follows HTTP 3xx redirects internally and the scope allowlist was only evaluated against the frontend's original URL, so the redirect target is never re-checked; the response is then returned to the webview. Rated CVSS 5.6 (assessed AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N), it is unauthenticated but requires an attacker-influenced allowlisted origin and a frontend that actually issues the fetch; there is confirmed actively exploited (CISA KEV) status, no public exploit identified at time of analysis, and the vendor fix is opt-in.
Server-side request forgery in MaxKB 2.10.3-lts and earlier allows an authenticated low-privileged workspace user (CVSS PR:L, no user interaction) to make the MaxKB server issue arbitrary HTTP requests by supplying a URL to the knowledge-base web-document import or synchronization crawler, whose Fork.fork routine calls requests.get with certificate verification disabled and no scheme, loopback, link-local, private, or reserved-address filtering. Because the fetched response body is stored as imported document content, the attacker can read the responses of reachable internal HTTP services or cloud instance metadata (e.g. AWS/GCP IMDS) rather than merely triggering blind requests, making this a full-read SSRF with confidentiality impact. There is no public exploit identified at time of analysis and no CISA KEV listing; the vendor advisory (GHSA-ffxw-frpx-8rww) reports no fixed version, so exploitation requires valid workspace credentials and reachability of interesting internal targets from the MaxKB host.
InvenTree versions prior to 1.4.0 render report and label templates with WeasyPrint's default URL fetcher, so an authenticated staff user who can author templates can make the server fetch attacker-chosen resources over http/https or read local files through the file:// scheme and later recover the fetched bytes from the stored PDF attachment. This yields full-read server-side request forgery, local file disclosure (potentially including application credentials), and in the worst case compromise of a superuser account. The issue is access-gated and not a broad internet-facing threat: it requires staff-level template-authoring privileges (CVSS 3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N, base 6.5) plus the ability to retrieve the generated attachment, and no public exploit has been identified at time of analysis. A vendor-released fix is available in InvenTree 1.4.0.
Server-side request forgery in HomeBox prior to 0.26.0 allows an authenticated user with permission to create or test notifiers to reach internal IPv4 destinations that the default BlockBogonNets and BlockCloudMetadata guards are meant to stop, because those guards do not decode IPv4 addresses embedded in NAT64/DNS64 prefixes. Impact is real but conditionally gated: exploitation requires the HomeBox instance's outbound traffic to egress through a NAT64/DNS64 gateway, since without such a gateway the crafted IPv6 destination is unroutable; where present, an attacker can direct the generic:// notifier at cloud metadata or localhost and use the notifier-test response (propagated by Shoutrrr) to read back retrieved data such as temporary credentials. No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the vendor has released a fix in version 0.26.0.
Server-side request forgery in CKAN MCP Server (ondata/@aborruso ckan-mcp-server) before version 0.4.108 allows an attacker who can influence the caller-supplied server_url parameter to force the server to issue requests to loopback addresses and to the cloud instance metadata service at 169.254.169.254. The flaw is the third bypass of the same validateServerUrl guard: because that guard only inspects the hostname string and never resolves DNS, any hostname that resolves to an internal address (documented examples lvh.me to 127.0.0.1 and *.nip.io to IMDS) slips through, and exploitation realistically requires prompt injection into content the victim's AI assistant processes while the MCP server is connected (CVSS UI:R). No confirmed active exploitation (CISA KEV) and no public exploit identified at time of analysis, though a proof-of-concept for an earlier, related SSRF variant in the same package is published; impact is highest for cloud-hosted deployments where IMDS returns IAM credentials.
Server-side request forgery in self-hosted draw.io deployments prior to 30.2.7 allows unauthenticated remote attackers to make the server fetch attacker-chosen URLs that resolve to private, link-local, or cloud-metadata addresses, returning internal HTTP responses or instance metadata through the image proxy. The flaw only exists when the server is started with ENABLE_DRAWIO_PROXY=1; the SaaS and desktop editions and default installs are unaffected. Successful exploitation depends on a DNS-rebinding timing race (the hostname must resolve to a public address during validation and to an internal address at connection time), which is why the assessed severity is 6.8 with AC:H rather than a high-severity rating; there is no public exploit code identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 30.2.7.
Server-side request forgery in Hatchet versions prior to 0.91.1 lets an authenticated tenant of the platform coerce the SNS ingest service into issuing an outbound HTTP request to an arbitrary URL, because the SNS UnsubscribeConfirmation handler calls http.Get() against the payload's UnsubscribeURL even though that field is excluded from the AWS signature verification performed by BuildSignature(). Successful exploitation allows the server to reach internal-only endpoints such as the EC2 Instance Metadata Service, internal HTTP APIs, and other services on the deployment's network, with the practical payoff limited to information disclosure (for example, potentially exposing IAM credentials) rather than code execution or data modification. Exploitation requires the SNS integration to be enabled and reachable and the attacker to already hold a Hatchet tenant account; there is no public exploit identified at time of analysis, and no confirmable tracking in CISA KEV.
Server-side request forgery in NocoBase v2.1.21 lets an authenticated, low-privilege user drive the server's serverRequest function to issue outbound HTTP requests to arbitrary destinations, enabling internal reachability scanning and probing of services that are not exposed externally. Because exploitation requires a valid low-privilege account (per the CVSS vector PR:L) and the value of the attack depends on the NocoBase host having network access to internal-only resources, the practical impact is internal reconnaissance and reachability enumeration, with fuller information disclosure only where serverRequest returns response bodies to the caller. No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and EPSS is low (0.18%, 8th percentile), so near-term mass exploitation is unlikely; the vendor scored this 6.5 (C:H) while our independent assessment rates confidentiality impact lower (5.0, C:L).
Server-side request forgery in the pdf-tools-mcp MCP server bundled with the 0717376/cowork_bench project lets an attacker who can call its ControlFlowNode tool supply a crafted pdf_file_path argument and cause the server to issue requests to attacker-chosen destinations, yielding low confidentiality, integrity, and availability impact. The repository is a rolling-release personal project with no tagged versions, so all revisions up to commit d943e75bc0fc8e3b27141979300cd8cbcd1e890d are presumed affected, and the CVSS 4.0 vector (PR:L, E:P) indicates the tool interface requires some authenticated or privileged access rather than fully anonymous reach. Publicly available exploit code exists (published in a separate GitHub proof-of-concept repository), but there is no evidence of confirmed active exploitation, and the practical risk is heavily constrained by the product's negligible deployment footprint and the maintainer's failure to respond to the original issue report.
Server-side request forgery in vas3k TaxHacker up to and including 0.8.5 lets an attacker who can reach the LLM-provider configuration function force the server to issue requests to an arbitrary URL of their choosing. The flaw lives in the testLLMProviderAction server action in app/(app)/apps/settings/actions.ts, where the attacker-supplied baseUrl is used as the destination of an outbound HTTP request without validation; publicly available exploit code exists and the project has not responded to the reported issue. Independent assessment places the realistic severity lower than the vendor's CVSS 4.0 score of 5.5: because TaxHacker is a self-hosted, login-gated application, practical exploitation requires an authenticated session and a working LLM-configuration screen, and the achievable impact is limited to confidentiality (reading responses from internal endpoints the server can reach) rather than code execution or data modification.
Server-side request forgery in vas3k TaxHacker up to 0.8.5 lets an attacker control the businessLogo argument passed to the generateInvoicePDF function in /apps/invoices/actions.ts and force the server-side invoice PDF renderer to fetch an arbitrary URL. The independent assessment rates this as moderate severity (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), with exploitation requiring an account on the self-hosted instance that can configure business branding and trigger invoice generation, rather than an anonymous internet attacker. Publicly available exploit code exists, the issue was reported to the project early via GitHub issue #186 without a vendor response, and no CISA KEV listing was identified - impact is limited to low confidentiality, integrity, and availability with no code execution.
Server-side request forgery in NonceGeek dim-sum-app's Deno backend lets remote, unauthenticated attackers redirect outbound requests to an arbitrary host by supplying a crafted supabase_url query parameter to the textSearchV2Handler endpoint (deno/main.tsx). Because the handler builds a Supabase client from that attacker-controlled URL and passes the deployment's SUPABASE_SERVICE_ROLE_KEY as the credential, a successful attack both forces the server to issue requests to attacker-chosen destinations and discloses the service-role key to that endpoint, which in standard deployments can be leveraged for full privileged access to the backing Supabase project and, from there, potential impact on any data or services reachable with that key. The issue is confirmed with publicly available exploit code (disclosed via the project's GitHub issue tracker) but is not listed in CISA KEV, so no confirmed in-the-wild exploitation is established; the vendor has published a fix commit.
Server-side request forgery in Mealie up to 3.25.1 lets an authenticated user with permission to create or edit Recipe Actions coerce the server into making outbound HTTP requests to an arbitrary url argument, with no destination validation applied. Because Recipe Actions are outbound webhook POSTs, the flaw is effectively blind SSRF, so the primary risk is reaching internal-only services or the cloud metadata endpoint rather than directly exfiltrating data back to the attacker. Publicly available exploit code exists, and upgrading to 3.26.0 resolves the issue.
Server-side request forgery in the WordPress plugin Import and Export Users and Customers (versions before 2.4.5) causes the server to fetch an attacker-supplied URL during a CSV import because the plugin fails to validate that URL before making the request. Exploitation is gated behind a high-privileged, authenticated WordPress user with the capability to run the plugin's user/customer CSV import (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N), so a successful attack yields read-only SSRF probing and limited data reflection rather than code execution or data modification. Publicly available exploit code exists, but there is no confirmed active exploitation (CISA KEV), and the practical impact depends entirely on whether internal services or a cloud metadata endpoint are reachable from the web server - making this a genuinely low-priority issue.
Server-side request forgery in the Wow Elements Addons for Elementor WordPress plugin (all versions up to and including 1.11.2) lets an authenticated attacker with Contributor-level access or higher coerce the site's web server into issuing HTTP requests to arbitrary attacker-chosen destinations. The flaw is in the plugin's Changelog widget, which passes the user-controlled 'Changelog File' setting directly into wp_remote_get() with no URL validation or sanitisation, allowing requests to be aimed at internal-only resources such as cloud metadata endpoints or intranet APIs. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis; the Contributor authentication prerequisite and the bounded, low-level confidentiality/integrity/availability impact keep this a genuine but moderate-priority issue rather than an emergency patch item.
CordysCRM 1.7.3 and earlier allows an authenticated user holding the PROCESS_SETTING_ADD permission to store an attacker-chosen webhook URL in an approval-flow node and then cause the server to issue outbound HTTP requests to that URL when an approval action is approved, turning the application into a proxy for reaching internal-only services. The assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N - high confidentiality impact against the attacked component with no integrity or availability impact - and the practical payoff is cloud metadata access (for example 169.254.169.254) and internal network reconnaissance, bounded by the server's network reach and by the multi-step trigger (configure via POST /approval-flow/add, fire via POST /approval-action/approve). The flaw is fixed in 1.7.4 per vendor advisory GHSA-fg6q-pfj7-fghw, PR #2966 and commit e0ae23e; no public exploit code and no confirmed active exploitation were identified at time of analysis, and exploitation requires a low-privileged authenticated account plus a second in-application approval step.
Server-side request forgery in YesWiki before 4.6.7 allows unauthenticated attackers to make the WebFinger subscription ('abonnements') view issue outbound HTTPS requests to attacker-supplied numeric internal hosts and ports, enabling blind probing of internal services. The flaw sits in WebfingerService, which processes a POSTed actor_handle without validating the destination host, and carries a CVSS 4.0 base score of 6.9 (independent assessment: CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), confirming no authentication or user interaction is required wherever the ActivityPub/WebFinger feature is reachable. Impact is constrained to triggering outbound HTTPS connection attempts - an information-disclosure/port-probing primitive rather than full-response or arbitrary-scheme SSRF - and no public exploit code has been identified at time of analysis, although the request pattern is straightforward to script. This is a moderate-priority vulnerability.
Unauthenticated server-side request forgery in YesWiki before 4.6.7 lets remote attackers force the wiki server to fetch arbitrary URLs by supplying a syndication action through the content parameter of the render handler. The CVSS vector indicates PR:N and UI:N, so any network-reachable instance running a default configuration can be triggered without credentials or victim interaction; fetched feed content is echoed back into the rendered page, and feed enclosures are written into the files directory, yielding an internal-network read primitive plus a limited file-write side effect. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, but the low complexity and unauthenticated reach make exposed instances a practical target; the vendor has released YesWiki 4.6.7 to remediate the flaw.
Unauthenticated server-side request forgery in YesWiki before 4.6.7 allows remote attackers to make the server fetch arbitrary hosts and ports via the {{valeur}} action's url parameter, submitted through the content parameter of handlers/page/render.php. This can be used to probe internal HTTP services and read back responses matching fiche markup, though impact is limited to information disclosure and no public exploit code is identified at time of analysis. The vulnerability is medium severity (CVSS 4.0 base 6.9) and is unauthenticated (PR:N).
Unauthenticated blind server-side request forgery (SSRF) in YesWiki versions prior to 4.6.7 allows remote attackers to coerce the server into making arbitrary outbound HTTP requests through the idtypeannonce parameter of the /api/entries/bazarlist endpoint. Because the isValidURL() validation routine unconditionally returns true, any attacker-supplied URL - including internal network addresses and cloud metadata endpoints - is accepted and then fetched by curl inside loadURLContent(). The vulnerability is network-reachable and requires no authentication (CVSS v4.0 PR:N/UI:N), but its practical impact is limited by the blind nature of the flaw, since response content is not returned to the attacker; assessment scores it medium severity, and no public exploit code has been identified at time of analysis.
Server-side request forgery (SSRF) in HAVELSAN's Sef AI Chatbot Platform before version 2.1 allows an authenticated attacker with high privileges (PR:H) to cause the server to make requests to arbitrary URLs, potentially reading internal resources reachable from the server. This moderate-severity flaw (CVSS 4.9) is network-reachable without user interaction, but requires a privileged session, limiting exploitation to trusted or compromised elevated accounts. No public exploit code or confirmed active exploitation has been identified at time of analysis.
Server-side request forgery in the Model Context Protocol reference Fetch Tool (mcp-server-fetch, and the related mcp-server-everything) up to 2026.6.4 lets unauthenticated remote callers direct the fetch_url function at internal or otherwise restricted destinations by supplying a crafted url/path argument, with no destination validation in the default configuration. Impact is bounded but real: the assessed vector rates confidentiality and integrity impact as low with no availability impact, and the primary abuse case is reaching loopback services, private RFC1918 ranges, and cloud instance metadata endpoints (for example 169.254.169.254 and 100.100.100.100) from the server's network position rather than executing code. Publicly available exploit code exists (a public GitHub issue plus a VulDB entry) and the CVSS 4.0 vector carries an E:P proof-of-concept maturity flag, but there is no confirmed active exploitation (no CISA KEV listing); exposure depends on whether the Fetch Tool and its URL argument are reachable by an attacker, since these are reference servers frequently run locally beside an AI assistant.
Wormhole.app deployments built before 2026-08-22 ship with a misconfigured coturn TURN server that fails to restrict TCP relay peers, allowing an unauthenticated remote attacker to pivot through the relay to reach internal resources such as cloud instance metadata or to source TCP connections from the relay's own IP address. Because the TURN endpoint is reachable over the network with no credentials or user interaction required (CVSS:4.0 base 6.9; independently assessed as CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), impact is bounded by what the relay host's network position can reach - meaningful information disclosure and limited integrity impact rather than full compromise. This is a moderate-priority issue: it is not in CISA KEV and no public exploit code was identified at time of analysis, and the vendor has made a fixed build available.
Server-side request forgery in Ghost 3.20.2 through 6.50.x allows authenticated staff users to trigger outbound HTTP requests to arbitrary URLs via the image dimension refetching feature. Attackers can point image cards at internal network endpoints or cloud metadata services (e.g., 169.254.169.254) to access resources unavailable from the public internet. No public exploit code identified at time of analysis; the vendor has released a patch in Ghost 6.51.0.
Server-side request forgery in Ghost (TryGhost) versions 1.18.0 through 6.27.0 allows an authenticated staff-level user with permission to create or edit webhooks to make the Ghost server send requests to internal network resources, including cloud metadata services. Vendor scoring is CVSS 5.1 with PR:H, reflecting that the attacker must already hold privileged access; no public exploit code was identified at time of analysis and there is no CISA KEV listing.
Server-side request forgery in JetBrains YouTrack before 2026.2.19422 allows an authenticated user holding administrative or project-level privileges to abuse the GitHub VCS integration and coerce the YouTrack server into issuing requests to destinations of the attacker's choosing. With a CVSS 3.1 base score of 5.5 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N), the impact is bounded to limited confidentiality and integrity loss with a scope change, and the high privilege prerequisite is the dominant limiting factor - this is a moderate-severity, low-real-world-priority issue rather than an anonymous or default-configuration exposure. At the time of analysis there is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis.
Server-side request forgery in Form Tools through 3.1.1 allows an authenticated low-privileged user to make the server issue arbitrary outbound HTTP requests by supplying a crafted 'url' argument to the smart_fill function in /global/code/actions.php, with no user interaction required. Impact is confined to low confidentiality (probing internal services and cloud metadata endpoints reachable from the host) rather than code execution, so realistic risk is modest and depends heavily on what the server can reach. Publicly available exploit code exists, the flaw is not confirmed as actively exploited (no CISA KEV listing), and no vendor-released patch has been identified at time of analysis.
Server-side request forgery in decolua 9Router (versions up to and including 0.5.55) lets a remote attacker steer the server's outbound HTTP requests by controlling the provider_options.baseUrl argument handled by the Search Endpoint and its fetch path in src/shared/utils/ssrfGuard.js, potentially reaching loopback services, internal networks, or cloud metadata endpoints such as 169.254.169.254. The vulnerable code is a pre-patch guard that can be defeated through several documented bypass classes (trailing-dot FQDNs like 'localhost.', IPv4-mapped IPv6 addresses in hex form such as '::ffff:7f00:1', wildcard-DNS hostnames that resolve to private addresses, and public URLs that 30x-redirect to internal targets). Per the vendor vector the flaw is unauthenticated (PR:N) and exploitable in default configurations; no public exploit code was identified at time of analysis and CISA KEV does not list this issue, while the upstream project has published a fixing pull request (PR #3723) referencing the reporter's bypass analysis in issue #3714.
Server-side request forgery in Kiteworks Core before 9.5.1 lets an authenticated administrator on a node with the separately licensed gateway role enabled supply a connector URL that the server fetches without adequately validating the URL scheme or destination, causing outbound requests to internal network services. Exploitation requires two prerequisites: a valid administrative session (CVSS PR:H) and an active optional gateway role, which is not a default configuration, and the resulting impact is constrained to limited confidentiality and integrity with no availability effect (CVSS 3.3, AC:H). No public exploit code has been identified at time of analysis and there is no evidence of active exploitation; the vendor has released a fixed version, 9.5.1, and the issue was reported through CISA's coordinated disclosure channel.
Server-side request forgery in OpenClaw Windows Node through 2026.9.4 allows an attacker who already holds gateway or agent access to invoke the canvas.present capability and make the node's WebView issue requests to localhost, RFC1918 private ranges, link-local/cloud-metadata addresses, CGNAT and Tailscale (100.64/10) services from the user's machine - destinations that canvas.navigate would reject through its URL risk evaluation, which canvas.present bypasses entirely. The prerequisite is an authenticated control channel to the node (CVSS vector PR:L), so this is not exploitable by anonymous external attackers and yields only limited confidentiality and integrity impact (VC:L/VI:L, no availability impact); a prompt-injected but legitimately connected agent is a realistic delivery path. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, but it is a genuine, bounded SSRF risk in deployments that expose the gateway/agent channel. An upstream fix commit exists, though a tagged released version is not independently confirmed in the supplied data.
Credential disclosure in JetBrains YouTrack before 2026.2.19197 lets an authenticated user who can edit an existing integration's configuration URL redirect the integration's stored credentials to an attacker-controlled endpoint by simply changing that URL. The CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects a network-reachable, low-complexity, low-privilege flaw with high confidentiality impact and no integrity or availability effect, consistent with a credential-theft bug rather than code execution or full takeover; no public exploit identified at time of analysis, and no exploitation status is confirmed by CISA KEV for this CVE.
Server-side request forgery in JetBrains YouTrack before 2026.2.18991 lets an authenticated user coerce the server-side PDF export renderer into making outbound requests to attacker-influenced URLs by storing crafted XHTML content that is rendered when that content is exported to PDF. The assessed impact is confidentiality-only (CVSS 3.1 base 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), and the attack requires a valid YouTrack account plus write access to a stored field that reaches the PDF renderer; no public exploit identified at time of analysis, and the issue is not in CISA KEV.
LightLLM through version 1.2.0 accepts image_url and audio_url parameters on its multimodal inference endpoints without validating or restricting the supplied URLs, allowing unauthenticated remote attackers to coerce the server into making arbitrary outbound HTTP requests (CWE-918 server-side request forgery). An attacker who can reach an instance configured to serve a vision or audio model can point those parameters at internal-only resources, and because the fetched content is passed into model processing, the results (or the resulting error messages) can leak internal content and network topology back to the caller. Impact is limited to confidentiality and topology disclosure rather than code execution; the issue is a genuine but moderate-severity exposure, no public exploit code has been identified at time of analysis, and it has not been confirmed actively exploited (no CISA KEV listing). Deployments that only serve text models, or that do not expose multimodal endpoints to untrusted networks, are out of scope.
Server-side request forgery in the @astrojs/netlify adapter (5.2.0 through 8.2.3) lets unauthenticated remote attackers make the Netlify Image CDN fetch URLs whose host they control, by embedding an allowlisted origin inside the path or query string of a request to the public /.netlify/images endpoint. The impact is limited: Netlify egress protections restrict which internal or external targets are actually reachable and image-transformation handling prevents fetched response bodies from being returned to the attacker, so no confidentiality or integrity impact has been demonstrated and only low availability impact is assessed (CVSS 6.3 per the 4.0 vector; independent assessment CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L). No public exploit code has been identified at time of analysis, and the flaw is fixed in @astrojs/netlify 8.2.4.
Authenticated remote users of Moodle can bypass the URL downloader's host-blocking logic by encoding a restricted destination as an IPv4-mapped IPv6 address (for example ::ffff:<internal-ip>), causing the server to fetch resources from internal or otherwise blocked hosts on the attacker's behalf. Successful abuse yields Server-Side Request Forgery limited to confidentiality impact (CVSS 3.1 base 4.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), meaning the practical damage depends on what the Moodle server itself can reach - typically cloud instance-metadata endpoints or internal-only services - and is reduced on segmented networks. No public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV), so this is a genuine but modest-priority issue that should be scheduled alongside routine patch cycles rather than treated as an emergency.
Server-side request forgery in the Broken Link Notifier WordPress plugin (versions 1.3.1 up to but not including 2.0.0.1) allows unauthenticated remote attackers to bypass the plugin's internal-address filter and make the WordPress host send requests to internal services. The plugin validates the URL it is given but does not re-validate the destination after an HTTP redirect, so an attacker-supplied link that redirects to a loopback, RFC1918, or cloud metadata address slips past the SSRF guard. The issue is rated CVSS 3.1 5.8 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N) with scope change into internal services but only low confidentiality impact and no integrity or availability impact; no public exploit identified at time of analysis, and CISA's SSVC assessment records no exploitation with partial technical impact.
Authenticated users can bypass server-side request forgery (SSRF) protections in ClaraVerse through version 0.3.1 by exploiting flaws in hostname validation and IPv6 transition address filtering within the download_file and scrape_web agent tools, enabling the server to make requests to internal services and cloud instance metadata endpoints. This medium-severity vulnerability (CWE-918, CVSS 5.3) requires a valid ClaraVerse account and is only impactful when the server runs in a network environment where such internal endpoints are reachable. No public exploit code has been identified at time of analysis.
Server-side request forgery in Fider before 0.38.0 lets an authenticated administrator who controls DNS for a configured hostname redirect the server's outbound HTTP requests to internal services or cloud metadata endpoints by exploiting a time-of-check/time-of-use gap between URL validation and the actual connection. The exposure is narrow: only webhook URLs and custom OAuth provider token/profile URLs are user-configurable outbound targets, the attacker needs admin privileges and must win a DNS-rebinding race (high attack complexity), and instances with AllowPrivateNetworkTargets deliberately enabled are out of scope, so this remains a low-priority issue despite the network vector (CWE-918). No public exploit code has been identified at time of analysis and there is no evidence of active exploitation; v0.38.0 fixes the flaw by re-checking the resolved IP at dial time.
Server-side request forgery in Anjvision YSSD-RTMP-H5 firmware 3.3.2.4 allows unauthenticated remote attackers to invoke the device's built-in network-check/connectivity-probe function and make it issue requests to arbitrary hosts reachable from the camera's internal network. The resulting impact is limited to low-confidentiality disclosure -- internal host enumeration and small data leaks via DNS resolution -- with no integrity or availability effect, consistent with the assessed vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation; the issue was reported through CISA's ICS-CERT program as ICSA-26-272-05.
The FTP client component of Eclipse ThreadX NetX Duo trusts the IPv4 address returned in a server's 227 PASV reply, performing only parse and non-zero checks before opening a data connection to that address, which lets a malicious or man-in-the-middle FTP server redirect the client's data transfer to any host it names (CWE-918 server-side request forgery class). Only the IPv4 passive-mode path is affected; the client must itself initiate an FTP control session to a hostile or intercepted endpoint and then request a passive transfer. No authentication or user interaction beyond starting the session is required (CVSS:4.0 base 6.9; independent assessment CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), and no public exploit code or active exploitation has been identified at time of analysis.
Dell Secure Connect Gateway (SCG) Policy Manager versions prior to 5.34.00.16 contain an open redirect vulnerability that allows unauthenticated remote attackers to craft a link which, when followed by a victim user, redirects to an untrusted site and can lead to server-side request forgery (SSRF). The CVSS 3.1 base score is 5.4 (medium) due to the requirement for user interaction (UI:R) and low confidentiality/integrity impact. No public exploit code has been identified at time of analysis, and the vulnerability is not known to be actively exploited.
Server-side request forgery (SSRF) in MODSetter SurfSense 0.0.36 and earlier allows an authenticated, low-privilege user to make the backend dereference attacker-influenced URLs by supplying crafted content to the Document Export Feature (the export_document route in surfsense_backend/app/routes/editor_routes.py). Because the server-side export/conversion pipeline (pypandoc/typst) fetches or processes references embedded in document content, a malicious export request can cause the server to issue outbound requests to resources it can reach. Publicly available exploit code exists and the flaw is remotely reachable, but the assessed impact is confidentiality-limited (VC:L) with no integrity or availability effect, making this a genuinely low-severity issue despite remote reachability.
The JavaScript library ip-address (npm) fails to treat the NAT64 local-use prefix 64:ff9b:1::/48 as private, so applications that lean on Address6.isPrivate - typically together with isLoopback and isLinkLocal - to enforce an SSRF or trust-boundary policy can be tricked into reading an internal IPv4 destination as external. Unauthenticated network attackers can exploit this (CVSS v4.0 6.9; independent assessment CVSS v3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N) only when the target server's network actually uses an operator-chosen NAT64 prefix carved from the RFC 8215 local-use range, and only when the consuming application composes these classifiers as a security control; information disclosure is the realistic outcome, with no impact on integrity or availability. Versions 10.2.0 through 10.5.0 are affected and the issue is fixed in 10.5.1; no public exploit code or confirmed active exploitation was identified at time of analysis, and exploitation is further gated by the non-default NAT64 deployment and by the application's use of these methods for enforcement.
Server-side request forgery (SSRF) in October CMS 4.3.4 and earlier allows unauthenticated remote attackers to bypass the validateExternalImageHost protection in System/Classes/ResizeImages.php by supplying a crafted IPv6-mapped IPv4 host, causing the server to fetch attacker-controlled or internal URLs. Publicly available exploit code exists (no CISA KEV confirmation of active exploitation), and the assessed impact is a largely blind SSRF with Low confidentiality, integrity and availability impact, so real-world severity depends on what internal services or cloud metadata endpoints the server can reach. October CMS 4.3.5 resolves the bypass; the issue is genuine but should be treated as low-to-moderate priority.
Incomplete scheme validation in October CMS's image resizer (getSourcePathForResize() in modules/system/classes/ResizeImages.php) allows non-HTTP PHP stream wrappers such as phar://, file:// and ftp:// to be stored in the resize cache and later handed to the underlying image library, producing a server-side request forgery condition that on phar:// paths can trigger metadata deserialization during subsequent file operations. Affected builds are 4.1.x up to 4.1.19, 4.2.x up to 4.2.25 and 4.3.0 through 4.3.4; upgrading to 4.3.5 or 4.4.0 resolves the issue (patch commit 0e9736aa2c6d6bd3d60ff6ef9e0b4d32ce387f58). Publicly available exploit code exists (reported by 0xGenesi, tracked as CVE-2026-100909), but no confirmed active exploitation has been observed; reachability is narrow because the flaw only matters where a pre-existing injection primitive already pipes untrusted input into the |resize Twig filter or the ResizeImages::resize() API without validating the scheme, so default templates and trusted-value usages (uploaded file models, theme assets, static URLs) are not exposed.
Server-side request forgery in athlon1600 youtube-downloader up to 4.0.1 lets remote, unauthenticated attackers make the server issue attacker-controlled HTTP/HTTPS requests by manipulating the url argument of public/stream.php. Publicly available exploit code exists (per VulDB and the linked exploit gist), but there is no CISA KEV confirmation of active exploitation, and assessed impact is limited to low confidentiality and integrity effects against internal services and cloud metadata endpoints reachable from the host. The vendor was contacted early and never responded, and the only code change tied to this component (commit 6ffe823, 'better security for public/stream.php') is a partial hardening rather than a fix.
Server-side request forgery in DevaslanPHP project-management affects versions 1.2.1 through 1.2.4 and v2.0.0-beta1 and allows an authenticated, low-privileged user to make the application issue requests to attacker-chosen destinations. The flaw sits in the updateJiraProjects function of the /jira-import endpoint, where host, username and token parameters are accepted without an adequate authorization check (per the independent assessment, a missing canAccess check), so any user who can reach the Jira Import feature can force outbound connections from the server while only obtaining limited read/write effect. Publicly available exploit code exists (also reflected by the E:P metric in the vendor-supplied CVSS 4.0 vector), but there is no indication of confirmed active exploitation, and the vendor was contacted early and did not respond. This is a genuine but low-priority issue: the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, i.e. partial confidentiality and integrity impact only, gated behind authenticated access to the import feature.
Server-side request forgery in Privoce VoceChat Server 0.5.36 and earlier lets unauthenticated remote attackers force the server to issue outbound HTTP requests to arbitrary URLs through the OpenGraph link-preview endpoint, potentially reaching internal services or cloud metadata endpoints reachable from the server's network position. Publicly available exploit code exists, and the vendor was notified early but did not respond, so no vendor-released patch has been confirmed. Per the assessed vector (AV:N/AC:L/PR:N/UI:N) this is a real but moderate-priority SSRF - no credentials or user interaction are required, but impact is bounded to low confidentiality, integrity and availability effects and depends on whether fetch responses or errors are reflected back to the attacker (blind vs non-blind is not confirmed in the source data).
Authenticated users of the Nezha monitoring dashboard (versions 2.0.10 through 2.3.2) who can configure notification or DDNS webhook URLs can bypass the dashboard's SSRF denylist by supplying an IPv6 literal in the 6to4 prefix 2002::/16 or the local-use NAT64 prefix 64:ff9b:1::/48, causing the server to issue outbound HTTP requests to those endpoints. Exploitation is heavily constrained: the CVSS vector is PR:L, meaning an attacker must already hold a webhook-configuring account, and meaningful impact depends on the deployment's network providing unusual or non-standards-compliant routing for these transition ranges; the advisory confirms no path to IPv4 metadata, loopback, or private-network requests was demonstrated. No public exploit code has been identified at time of analysis and the issue is not known to be exploited, but the vendor has shipped a fix in version 2.3.3 (commit d1fcde8e) that explicitly blocks both prefixes. The independent assessment rates this as a low-priority, high-caveat SSRF with AC:H and only low confidentiality impact.
Server-side request forgery in the UTCP Python GraphQL (utcp-gql) and WebSocket (utcp-websocket) plugins at 1.1.0 and earlier lets unauthenticated attackers (CVSS 4.0 vector PR:N, and the assessed 3.1 vector AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N) force the host to open outbound connections to internal services and cloud metadata endpoints such as 169.254.169.254. utcp-gql still relies on a startswith prefix check for http://localhost and http://127.0.0.1, so crafted hostnames like http://127.0.0.1.attacker.example or http://localhost.evil.com satisfy the check and then resolve to any address the attacker's DNS returns, while utcp-websocket performs no URL validation at all despite docstrings claiming it enforces 'WSS or localhost only'. Both plugins attach the call template's configured auth headers to the outbound connection, so a successful SSRF also exfiltrates configured API keys and OAuth tokens to the attacker-controlled host; risk is genuine but low urgency, exploitation requires the victim to ingest an attacker-supplied tool or manual call-template URL (UI:P/UI:R) and, for the GraphQL path, attacker-controlled DNS resolution, and no public exploit identified at time of analysis (no CISA KEV entry, no POC reported).
Cloudreve before 4.17.0 applies only the Admin.Read OAuth scope to the admin node test endpoints (POST /api/v4/admin/node/test and POST /api/v4/admin/node/test/downloader), while the sibling node create, update, and delete routes correctly demand Admin.Write. An authenticated holder of an admin-authorized OAuth token carrying only Admin.Read can therefore submit crafted node definitions and force the Cloudreve server to make outbound requests to arbitrary URLs, yielding blind server-side request forgery, internal service probing, and delivery of signed Cloudreve slave-style requests to attacker-chosen hosts; because the responses are not returned to the caller, impact is limited to blind SSRF and availability-adjacent network effects rather than direct data disclosure. No public exploit code was identified at time of analysis, exploitation is not confirmed in CISA KEV, and the practical prerequisite is an environment where an administrator has granted an OAuth client the Admin.Read scope - a real but bounded prerequisite that is consistent with the medium (5.3) severity rating and the authenticated (PR:L) nature of the flaw. The vendor has released a patch in 4.17.0 and upstream fix commit 332a9d800205082a2469e555fd66a63f18d9d5dc.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before 2.8.27 lets an authenticated user holding contributor-level access or higher supply an arbitrary URL through the plugin's feed-fetch feature, causing the web server to request that URL and return the response body back to the requester; the plugin performs no capability check on that action. Because the request originates from the server, the attacker can reach internal-only or loopback services that are otherwise unreachable from the internet - most notably cloud instance metadata endpoints and internal administrative interfaces - but the impact is limited to confidentiality, since no code execution or write capability is demonstrated. Publicly available exploit code exists (the WPScan entry documents the issue), CISA KEV does not list the CVE, and EPSS is 0.13% (2nd percentile), indicating low near-term exploitation likelihood; the assessed severity is low-to-moderate, contingent on the site allowing low-trust contributor registrations and on which internal services are reachable from the web server.
Server-side request forgery in the WPeMatico RSS Feed Fetcher WordPress plugin before version 2.8.27 allows an authenticated attacker holding contributor-level access or higher to direct the web server to fetch an arbitrary attacker-supplied feed URL and read the response back, enabling internal-only reconnaissance and retrieval of sensitive data such as cloud instance metadata. The plugin performs neither a capability check nor any validation of the destination before issuing the server-side request, and because the retrieval is non-blind the attacker receives the fetched content rather than learning only success or failure. Exploitation is constrained by the contributor-role prerequisite and by read-only impact (no write, no code execution), and public exploit code exists via the WPScan disclosure while EPSS remains very low at 0.13% (2nd percentile) and CISA's SSVC assessment records exploitation as none; this is a genuine but low-priority issue.
Server-side request forgery in Heym 0.0.90 and earlier lets a caller-controlled workflow input steer an outbound HTTP fetch to loopback, RFC1918, link-local, or cloud metadata endpoints such as 169.254.169.254. Two distinct egress gaps exist: the LLM image-edit loader (_load_image_bytes) issues a bare httpx.get that skips the egress-pinning client, and _is_public_address only unwraps IPv4-mapped IPv6, so NAT64 (64:ff9b::/96), IPv4-compatible (::x.x.x.x), and 6to4 (2002::/16) encodings can smuggle internal IPv4 destinations past both URL validation and the dial-time IP pin. Exploitation is not automatic: an authenticated workflow author must have deliberately wired a caller-controlled expression such as "imageInput": "$userInput.body.imageUrl" before an unauthenticated webhook or API caller can pick the target, and this is best treated as a low-to-medium priority SSRF issue; no public exploit code was identified at time of analysis. The second, IPv6-based gap additionally depends on the Python 3.11.0 through 3.11.9 behavior that classifies 6to4 as globally routable.
SSRF protections can be bypassed in heym before 0.0.105 by authenticated users who configure integration service credentials with base URLs pointing to internal or cloud-metadata addresses, enabling them to read internal service responses through workflow node output. This moderate-severity issue requires low-privileged authentication and has no public exploit identified at time of analysis.
AzuraCast deployments before 0.23.8 expose a server-side request forgery and local file read flaw in the AutoDJ remote playlist fetcher, letting an authenticated user who holds the station Media permission point a remote_url playlist at a file:// path or an internal/loopback HTTP endpoint and have the backend fetch it with file_get_contents(). The retrieved lines are stored as queue entries and then disclosed through GET /api/station/{station_id}/queue to any user with the Broadcasting permission, exposing host files readable by the web container (such as /etc/passwd or the application .env) and the bodies of non-blind internal HTTP requests. Exploitation is bounded by valid low-privilege authentication and by the privileges of the web container, and no public exploit code was identified at time of analysis; the advisory data states that no patched version was available at publication, so mitigation depends on disabling PHP allow_url_fopen or tightening Media-permission access.
Server-side request forgery in Adminer 5.5.1 through 6.0.1 lets a remote, unauthenticated attacker force the server to open outbound TCP connections to arbitrary internal hosts and privileged ports before any credentials are validated, by supplying a crafted login 'server' value such as '127.0.0.1:80/x'. The flaw is a regression that re-opens the privileged-port bypass originally fixed in 5.5.0, and because the connection is blind - the attacker only observes refused/handshake/timeout states - impact is limited to internal port scanning and SSRF probing rather than data disclosure or code execution. No public exploit code has been identified at time of analysis and there is no evidence of active exploitation; the vendor-released fix is Adminer 6.0.2.
Unauthenticated server-side request forgery in Adminer 6.0.0 and 6.0.1, when the optional ClickHouse driver plugin is loaded, allows remote attackers to make the server send HTTP POST requests containing 'SELECT version()' to arbitrary internal URLs and read the response bodies of services that return non-2xx/401/403 status codes, potentially exposing internal error pages with sensitive information. The vulnerability is gated by the presence of the ClickHouse driver plugin and does not affect default Adminer installations. No public exploit code has been identified at time of analysis, and the vendor has released Adminer 6.0.2 to fix the issue.
Server-side request forgery in Adminer's optional Elasticsearch driver (plugins/drivers/elastic.php) lets unauthenticated remote attackers force the Adminer host to issue HTTP GET requests to arbitrary reachable hosts and ports, because include/auth.inc.php calls Driver::connect() before it validates the submitted login result. Versions 4.16.0 through 6.0.1 are affected and the issue is conditional: it requires that the optional Elasticsearch driver be explicitly deployed (via the adminer/elastic.php template or an adminer_object() configuration) and that PHP allow_url_fopen be enabled so get_url()/file_get_contents() can send the outbound request. Impact is limited to low-confidentiality reconnaissance - a port-scanning oracle built from leaked JSON error fields and connection-failure text rendered on the login page - with no integrity or availability impact, and the independent assessment rates the issue MEDIUM, consistent with the vendor's CVSS 4.0 base score of 6.9; fixed in 6.0.2 and no public exploit identified at time of analysis.
Unauthenticated server-side request forgery in Budibase's Microsoft Teams webhook endpoint (all Budibase Server releases before 3.45.0) lets remote attackers submit a forged Bot Framework activity containing an arbitrary serviceUrl that the server persists and then reuses for every subsequent outbound bot reply. Those replies carry live Microsoft OAuth access tokens in their Authorization headers, so the server ultimately transmits credentials to the attacker's host and can also be steered into blind requests against internal network resources. The flaw is network-reachable and needs no authentication or user interaction (CVSS 4.0 PR:N/UI:N/AV:N), but exploitation is tempered by high attack complexity (AC:H) because a structurally valid activity payload is required and the attacker must win the persistence-then-reply flow; the endpoint is only exposed where the Microsoft Teams bot integration is configured and reachable, and no public exploit has been identified at time of analysis.
Server-side request forgery in ClawHub's public profile preview allows unauthenticated remote attackers to supply an image URL whose hostname passes the textual private-address check but whose DNS resolution points to an internal, loopback, or rebinding-controlled destination, causing the backend to issue outbound requests to attacker-chosen internal targets. The flaw affects self-hosted ClawHub (openclaw/clawhub) application/backend deployments at revision cbfee7343ddc867316dd9b3de6fa8856730f9f41 or unfixed ancestors; the hosted clawhub.ai instance was patched on 2026-09-11, so only unpatched self-hosted instances remain exposed, and the npm CLI and OpenClaw runtime are separate, unaffected products. No public exploit code and no CISA KEV entry were identified at time of analysis, and the reporting researcher demonstrated only a loopback listener connection - access to production internal services, credential disclosure, and code execution were not demonstrated.
Server-side request forgery (SSRF) in the Testimonials Widget WordPress plugin through version 4.0.4 allows unauthenticated remote attackers to make the server fetch arbitrary URLs and store the responses as publicly accessible files. This enables reading responses from internal services reachable from the WordPress server, though the impact is confidentiality-only and practical value depends on internal network reachability. Publicly available exploit code exists, and the EPSS score is 0.14% (3rd percentile), indicating a low predicted likelihood of exploitation.
Server-side request forgery in OpenClaw before 2026.8.1 allows a malicious or compromised video-asset provider to point the CLI at private or loopback URLs, causing requests to internal services reachable from the OpenClaw host. The attacker cannot reach OpenClaw directly: exploitation depends on the attacker controlling or compromising a provider the host already trusts and queries, on the video-fetch code path being exercised, and on an internal service being reachable, which is why our assessment rates exploitability as high-complexity with only low confidentiality impact. No public exploit code has been identified at time of analysis and there is no KEV designation; the vendor has released a patch, and EPSS does not flag this as a high-likelihood target.
Server-side request forgery in OpenClaw before 2026.8.1 allows an attacker who can already drive the agent to make it reach loopback or private-network destinations through the browser `wait --fn` predicate function, bypassing the navigation-time SSRF checks that guard other browser actions. The prerequisite is meaningful: the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) requires low-privilege access to the agent plus an existing or active browser session, so this is not exploitable by unauthenticated external users or against default deployments without agent access. There is no public exploit identified at time of analysis and the issue is not listed in CISA KEV, and the vendor's own low score (5.3) is consistent with the limited confidentiality and integrity impact assessed here.
Blind server-side request forgery in OpenMetadata through 2.0.2 allows an authenticated user holding permission to create or update an EventSubscription to point a WEBHOOK destination at internal hosts, loopback addresses, or the cloud metadata endpoint 169.254.169.254, because URLValidator.validateURL neither resolves DNS hostnames nor rejects internal/private addresses. Only the resulting HTTP status code is returned to the caller, so the leak is blind internal probing rather than response-body exfiltration or code execution. Publicly available exploit code exists (a proof-of-concept gist is linked from the vendor advisory) and the assessed CVSS 4.0 base score is 5.1; no confirmed active exploitation (CISA KEV) is referenced in the available intelligence.
Server-side request forgery in Zammad (versions prior to 7.0.2) lets a user who controls their own profile at a connected federated identity provider (OAuth, OIDC, or SAML) make the helpdesk server issue outbound HTTP requests to attacker-chosen addresses, including internal network locations, by supplying a crafted profile image URL. Because the fetch is blind, the attacker infers internal reachability only from differences in response timing and error patterns, and each probe can block a worker process for several seconds, producing a minor availability side effect. No public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited; exploitation requires a non-default deployment where federated login is configured and the attacker can edit their provider-side profile image URL. Fixed in Zammad 7.0.2.
Server-side request forgery in the WordPress plugin Asset CleanUp: Page Speed Booster (versions up to and including 1.4.0.5) lets an authenticated attacker with administrator-level access trick the site's server into issuing HTTP requests to arbitrary internal or external locations through the 'page_url' parameter, potentially allowing them to probe or interact with internal services. Exploitation is doubly gated: the attacker must already hold admin privileges, and the plugin's dom_get_type setting must be configured to 'wp_remote_post', a non-default administrator-controlled option, so untargeted opportunistic abuse is unlikely and no public exploit code has been identified at time of analysis. The result is a genuine but low-priority issue rather than an urgent one.
Server-side request forgery in the Link Library WordPress plugin versions 7.8.8 through 7.9.5 allows unauthenticated visitors to make the site issue outbound requests to hosts on its internal network and to observe from the response whether an internal service answered. The flaw is an incomplete fix for CVE-2025-68600 and only manifests when the plugin's protected 'safe request' is rejected and it falls back to an unprotected fetch, so sites must have published the plugin's public link submission form with reciprocal-link validation enabled to be exposed. Publicly available exploit code exists, but EPSS is only 0.13% (2nd percentile) and the independent assessment rates this as a genuinely low-priority, information-only issue with a non-default configuration prerequisite.
Server-side request forgery in the Image API (v2) of OpenStack Glance allows an authenticated tenant user (CVSS vector PR:L, network reachable) to make the glance-api service issue HTTP requests to attacker-chosen URLs by manipulating the 'locations' attribute of an image that is in the 'queued' state via a crafted PATCH request, potentially exposing internal-only services or cloud metadata (high confidentiality impact, limited integrity impact per the assessed vector). The vulnerability is strictly gated: it only functions when the non-default, deprecated 'show_multiple_locations' option is explicitly enabled in glance-api.conf, so standard OpenStack deployments that leave this setting off are not exploitable, and the attacker must hold valid tenant credentials and network access to the Glance API endpoint. Scoring is 8.1 with a low EPSS of 0.31% (21st percentile); the issue is not confirmed actively exploited (CISA KEV) and no public exploit identified at time of analysis, although a GitHub repository referencing this CVE and the companion CVE-2026-51773 has appeared and should be treated as a possible proof-of-concept.
Server-side request forgery in the chat-server component of songxinjianqwe Chat (ChatServer.java) allows remote, unauthenticated attackers to coerce the server into issuing HTTP requests to attacker-chosen URLs. The flaw is reachable over the network with low complexity and no user interaction (CVSS:4.0 AV:N/AC:L/PR:N/UI:N), but all impact metrics are rated Low (VC:L/VI:L/VA:L) with no downstream-system impact, so practical damage is limited to constrained or blind SSRF-style information leakage and internal-network probing rather than full internal pivoting. Publicly available exploit code exists (referenced from a GitHub issue), and VulDB reports that the vendor was contacted but did not respond; the project uses a rolling release model, so no specific fixed version is documented. Affected deployments are typically hobbyist Java chat-server instances rather than internet-exposed production services.
The MongoDB Python Driver (PyMongo) versions 3.9.0 through 4.18.1 can be induced to open connections to local Unix domain sockets on the application host when an attacker who already holds write access to the encryption key metadata in the database alters a key management (KMS) endpoint value so that it ends in '.sock' - a string the client-side field level encryption (CSFLE) code path mistakes for a local socket path instead of a remote host. Exploitation requires the opt-in, non-default CSFLE feature to be in use and an authenticated attacker with database-side write access to the key vault, and it is only reachable over the network in the sense that CVSS scores the vector AV:N/PR:L; the transmitted bytes are restricted to the beginning of a TLS handshake, so no attacker-chosen content reaches the socket and data exfiltration or arbitrary remote-host reachability is not achievable. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; despite the CWE-918 (SSRF) classification, this is a low-priority, low-impact defect. Vendor-released patch: 4.18.2.
Server-side request forgery in the AI Knowledge Module of ruoyi-vue-pro (versions through 2026.08) allows an authenticated low-privilege user to coerce the application server into issuing arbitrary outbound HTTP requests via the AiKnowledgeDocumentServiceImpl.readUrl document-import function, which fetches a caller-supplied URL without adequate validation. Exploitation is remote and low-complexity and requires only a valid low-privilege account plus an enabled/reachable AI Knowledge feature; the practical impact is bounded by what the server can reach on the internal network, such as internal HTTP services, admin panels, or cloud instance-metadata endpoints, resulting in limited confidentiality and integrity exposure. Publicly available exploit code exists, no CISA KEV entry confirms active exploitation, and the vendor was contacted about the disclosure but did not respond, so an upstream patch is not available and this is a genuine but moderate-priority issue whose real-world severity depends on the operator's outbound egress controls.
Server-side request forgery in TREK (versions prior to 3.4.0) allows an authenticated user to reach internal services or cloud metadata by supplying a URL whose DNS AAAA answer is a NAT64, 6to4, or Teredo IPv6 transition address that encodes a private, loopback, or link-local IPv4 target, bypassing the checkSsrf guard in server/src/utils/ssrfGuard.ts. Exploitation is conditional rather than automatic: it requires a valid TREK account, attacker control of a DNS record, a feature that performs server-side egress (imports, webhooks, integrations, or plugin egress), and a hosting environment that actually routes the chosen transition format - the reason the assessed CVSS is 6.3 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N) with high attack complexity and confidentiality-only impact. No public exploit code has been identified at time of analysis, and TREK 3.4.0 fixes the flaw.
Server-side request forgery in Termix 2.5.0 lets authenticated users make the Termix server issue outbound HTTP requests to arbitrary destinations, including internal services that are normally unreachable from outside the host network. An attacker with a low-privileged account can register a webhook or ntfy notification channel pointing at an internal address and then trigger it through the notification-channel test endpoint, which reaches the request-sending code in src/backend/utils/notification-sender.ts without any destination allowlisting or private-address blocking. Because webhook mode also honors attacker-chosen HTTP methods and headers, the requests are blind but not strictly read-only: an internal service that accepts the fixed notification body may still change state, though response bodies are never returned to the attacker. No public exploit code has been identified at time of analysis and the issue is fixed in version 2.5.1.
Blind server-side request forgery in the Kirki - Freeform Page Builder, Website Builder & Customizer plugin for WordPress, affecting all versions up to and including 6.2.0, allows unauthenticated remote attackers to make the WordPress server issue HTTP requests to arbitrary locations by supplying an attacker-controlled URL in the 'kirki_data' parameter. Because the SSRF is blind (no response body is returned to the attacker), exploitation is assessed as high-complexity: the attacker must already know or correctly guess reachable internal hosts or services, so the practical impact is limited to internal service enumeration, state-changing requests against unauthenticated internal endpoints, and access to cloud instance-metadata addresses that the host can reach. There is no public exploit identified at time of analysis and the vulnerability is not confirmed actively exploited (CISA KEV), making this a moderate-risk, not top-priority, issue for most deployments - though it becomes materially more serious on hosts with broad outbound network reachability or attached cloud IAM roles.
Server-side request forgery in Red Hat Ansible Automation Platform 2's automation-controller email notification backend lets an authenticated user holding organization notification-admin permission point an email notification template's SMTP host and port at arbitrary internal, loopback, link-local or reserved addresses; the controller task process then opens a raw TCP connection to that target when the notification test is triggered. Because the resulting connection error is surfaced through the notification record, an attacker gains a three-state internal port-scan oracle (open, closed, filtered) over the control-plane cluster network, including the in-cluster Kubernetes API, and if a shared organization template stores an SMTP password, redirecting the host can leak that credential to an attacker-controlled server. Impact is moderate (vendor CVSS 6.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) and requires a privileged, already-authenticated role rather than anonymous access; no public exploit code has been identified at time of analysis and CISA KEV does not list this CVE.
Server-side request forgery in Plex Media Server before 1.43.3.10861 allows any authenticated user - including a low-trust account invited only to a shared library - to coerce the server into issuing HTTP requests to arbitrary internal or external addresses through the path parameter of the '/video/:/transcode/universal' endpoint. The attacker gains no code execution and the assessed impact is confidentiality-only and limited (CVSS 4.3, C:L/I:N/A:N), but the flaw is a useful internal-network reconnaissance and pivot primitive on internet-facing or flat-network deployments. No public exploit identified at time of analysis; exploitation requires a valid authenticated session and a server running a version prior to 1.43.3.10861.
Server-side request forgery in Plex Media Server before 1.43.3.10861 allows a low-privileged, token-bearing caller to force the server to POST to an arbitrary destination by putting a full URL in the 'protocol' parameter of the '/player/timeline' endpoint. Because any X-Plex-Token value is accepted, the authentication barrier is effectively trivial, but the assessed impact is limited to a blind outbound request (confidentiality-low, no integrity or availability effect) against hosts reachable by the Plex process. No CISA KEV entry and no confirmed exploitation have been reported, and no public exploit code was identified at time of analysis; the practical risk is a genuine but low-priority SSRF that matters most for internet- or DMZ-exposed servers that can reach sensitive internal services.
Server-side request forgery (SSRF) in the Weoll collaboration platform (Global IT Informatics Technology Services Inc.) allows remote attackers to coerce the server into making crafted outbound requests against internal or back-end resources. Only deployments running Weoll before 3.2.45.44 are affected; the CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) places the flaw at 6.5 with a high confidentiality impact but no integrity or availability effect and no scope change. Exploitation requires the application to expose a server-side URL-fetching or resource-retrieval feature and, per UI:R, depends on a user being induced to trigger the crafted request rather than fully autonomous attacker action; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis.
Server-side request forgery in the Directorist: AI-Powered Business Directory, Listings & Classified Ads WordPress plugin (versions before 8.9.5) lets any authenticated user with subscriber-level access or above supply a URL that the server then fetches without validation, causing the WordPress host to issue requests to internal addresses and services. Exploitation requires only a low-privilege account, which is realistic on directory and classified-ad sites that typically enable open registration, and the request succeeds without any victim interaction. Impact is limited to confidentiality (CVSS 5.0, C:L), there is no public exploit identified at time of analysis, and updating to 8.9.5 remediates the issue.
Server-side request forgery (SSRF) in iFlytek astron-agent through version 1.0.6 lets an authenticated console user steer server-side HTTP requests to internal or otherwise restricted destinations by supplying a crafted endPoint argument to the debugToolV2 API, which reaches UrlCheckTool.checkUrl. The weakness is a redirect-handling gap: the pre-patch validator followed only a single 301/302/303 hop and ignored 307/308, so a URL that passes the initial blacklist/whitelist check can still bounce the request to an internal target; the vendor fixed this in release reward-1575 with a bounded 5-hop chain that revalidates every hop and detects loops. Impact is limited (CVSS 4.0 score 5.3; independent assessment CVSS 3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), requiring valid console credentials, and no public exploit identified at time of analysis.
Server-side request forgery in IBM Concert 1.0.0 through 3.0.0 allows an attacker who holds valid credentials to make the application issue HTTP requests to URLs of their choosing, which can be used to enumerate internal network services and set up follow-on attacks. The impact is bounded: the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, 6.5 by the vendor) reflects limited confidentiality and integrity loss rather than code execution or arbitrary file read, and exploitation requires a reachable Concert feature that dispatches server-side requests to a user-influenced URL. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (it is not in CISA KEV); IBM has published a fix via its support advisory.
Server-side request forgery in Mattermost (11.7.x through 11.7.10, 11.8.x through 11.8.5, 11.9.x through 11.9.1, and 11.10.x through 11.10.1) allows an authenticated System Administrator to set the OAuth token or userinfo endpoint to an internal network address, causing the Mattermost server to issue that request because the platform's internal-connection filter is not applied to OAuth endpoint traffic, and then read the internal response back through the configured OAuth flow. Impact is bounded: the attacker must already hold the highly-trusted System Administrator role (CVSS PR:H), confidentiality and integrity effects are Low with no availability impact, and the flaw only matters where the Mattermost server has network reachability to sensitive internal services. There is no public exploit identified at time of analysis, no CISA KEV listing, and the vendor CVSS of 5.5 (Medium) is well-calibrated - this is a genuinely low-priority issue despite the CWE-918 classification. The assessment vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N matches the vendor.
Server-side request forgery in the Home Assistant IPP integration allows an attacker on the same local network to coerce the platform's shared HTTP client into issuing requests to loopback or other internal services, affecting Home Assistant Core versions prior to 2026.2.3. The attacker needs only to broadcast a crafted unauthenticated _ipp._tcp.local mDNS announcement whose host, port, and base_path values are consumed by async_step_zeroconf in homeassistant/components/ipp/config_flow.py, which then hands them to validate_input for printer metadata retrieval; the shared aiohttp client followed cross-origin redirects without blocking loopback targets, so no prior IPP configuration, no authentication (PR:N), and no user interaction (UI:N) are required. Impact is bounded by the adjacent-network vector (AV:A) and by the constrained confidentiality and integrity effects of the coerced internal request - no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV); exploitation conditions are local-network only, not internet-reachable. Fixed in 2026.2.3.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an MCP caller who controls the public Jira base URL have a Jira user-lookup request redirected to an internal address, bypassing the SSRF redirect protections previously added for CVE-2026-27826. The vulnerable path is JiraUserMixin._lookup_user_by_permissions, which calls the module-level requests.get instead of the fetcher's protected session, so the response hook that enforces redirect validation is never applied. Impact is limited and blind (confidentiality-only, no integrity or availability effect) and, per the independent assessment, requires the attacker to control the Jira endpoint plus a server that issues a redirect to an internal target, making it most realistic in HTTP/multi-user or shared-credential deployments rather than single-user stdio setups with a fixed trusted Jira URL. No public exploit code was identified at time of analysis and there is no KEV listing; v0.22.0 resolves the issue.
Server-side request forgery in changedetection.io's Add Watch preview endpoint (/add_watch_ui/snapshot) allows remote attackers to force the server's browser fetcher to request attacker-chosen http(s) URLs, including loopback services, RFC1918 hosts, and the 169.254.169.254 cloud metadata address, because the url argument is validated only for an http:// or https:// prefix. The route is wrapped in login_optionally_required, so it can be reached unauthenticated on default installs that have no password set and requires credentials only where an operator has configured one; publicly available exploit code exists, and it is not confirmed as actively exploited (no CISA KEV entry). This is a moderate, credible risk rather than a critical one, with impact bounded to what the returned screenshot and rendered page data expose about internal targets; the vendor-released fix is version 0.60.1 (commit 71d332d5a0d3da2a0fe89a392413bf4b7d27c84e).
Server-side request forgery in FastGPT versions prior to 4.15.2 lets an authenticated user with access to any server-side URL-consuming feature - a safe-Axios-backed HTTP tool, workflow HTTP node, external file-fetch integration, or similar integration - bypass the platform's built-in private-address block and reach loopback, private, link-local, or cloud instance-metadata services. The bypass works because the safe Axios interceptor in packages/service/common/api/axios.ts validates the hostname with isInternalAddress() before a separate HTTP connection performs its own DNS lookup, opening a time-of-check/time-of-use (DNS rebinding) window in which an attacker-controlled hostname resolves publicly during validation and to an internal address at connection time; the same independent re-resolution occurs after each manual redirect hop. Exploitation requires authentication, attacker-controlled authoritative DNS, and winning the resolution race, so while impact is high (read access to internal services and metadata, scope-changed), practical exploitation is non-trivial; no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in Novu prior to 3.18.0 allows an authenticated user to make the notification worker issue attacker-directed POST requests to internal or otherwise restricted network services by supplying a chat webhook URL through subscriber credentials.webhookUrl, channel endpoint.url, event payload.webhookUrl, or event overrides.webhookUrl. The Slack, Discord, Mattermost, Microsoft Teams, Grafana On-Call, Ryver, Rocket.Chat, GetStream, and Zulip chat providers pass that URL straight into raw HTTP requests in send-message-chat.usecase.ts without the normalizeOutboundHttpUrl, assertSafeOutboundUrl, or DNS-pinned safeOutboundJsonRequest guards that protect Novu's generic webhook providers, resulting in a largely blind, POST-only SSRF whose impact is bounded to interactions or actions offered by the reached internal service (CVSS 5.3; assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N). Exploitation requires a valid authenticated account and worker-level network reachability to the intended target; no public exploit code has been identified at time of analysis and there is no confirmation of active exploitation (CISA KEV). The issue is fixed in version 3.18.0.
Server-side request forgery in Cloudreve prior to 4.18.0 allows an authenticated user with remote-download privileges to bypass the ValidateExternalURL guard and make the server fetch loopback, private, link-local, or cloud-metadata IPv4 addresses that are wrapped inside IPv4-in-IPv6 transition forms - NAT64 64:ff9b::/96, 6to4 2002::/16, Teredo 2001:0000::/32, or the deprecated IPv4-compatible ::a.b.c.d - because the guard classifies the wrapper rather than the address actually reached. The vulnerability is reachable through SrcUri in RemoteDownloadTask.createDownloadTask and requires authentication (CVSS PR:L), so it is not remotely exploitable by an anonymous attacker; exploitation also depends on the fetch host's network actually routing the chosen transition form to the embedded IPv4, making NAT64, dual-stack, and cloud-hosted deployments the realistic targets. Where a cloud metadata service is reachable, a successful request can return internal service responses and expose instance credentials; no public exploit code has been identified at time of analysis, and the issue is fixed in version 4.18.0.
Blind server-side request forgery in MISP allows unauthenticated remote attackers to coerce the MISP server into making outbound HTTPS requests to arbitrary internal or external targets by POSTing a crafted XML body containing a bare HTTPS URL to the unauthenticated cspReport endpoint. The flaw arises because PHP operator precedence in Xml::build()'s readFile guard (`readFile && http || https`) leaves the HTTPS locator fetch path ungated, and RequestHandlerComponent automatically decodes XML request bodies on write requests. Exploitation is constrained to blind SSRF with no response body returned to the attacker, so it primarily enables probing, timing-based reconnaissance, and triggering GET-style actions on reachable HTTPS services; no public exploit code was identified at time of analysis, and a vendor patch commit is available.
Server-side request forgery in the Tauri HTTP plugin (tauri-plugin-http) before http-v2.7.0 lets any host the plugin's scope allowlist permits - a host the attacker controls or one hosting an open redirect - bounce the request onward to destinations the scope explicitly denies, including cloud metadata endpoints such as 169.254.169.254, localhost services, and internal network hosts. The plugin's reqwest client follows HTTP 3xx redirects internally and the scope allowlist was only evaluated against the frontend's original URL, so the redirect target is never re-checked; the response is then returned to the webview. Rated CVSS 5.6 (assessed AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N), it is unauthenticated but requires an attacker-influenced allowlisted origin and a frontend that actually issues the fetch; there is confirmed actively exploited (CISA KEV) status, no public exploit identified at time of analysis, and the vendor fix is opt-in.
Server-side request forgery in MaxKB 2.10.3-lts and earlier allows an authenticated low-privileged workspace user (CVSS PR:L, no user interaction) to make the MaxKB server issue arbitrary HTTP requests by supplying a URL to the knowledge-base web-document import or synchronization crawler, whose Fork.fork routine calls requests.get with certificate verification disabled and no scheme, loopback, link-local, private, or reserved-address filtering. Because the fetched response body is stored as imported document content, the attacker can read the responses of reachable internal HTTP services or cloud instance metadata (e.g. AWS/GCP IMDS) rather than merely triggering blind requests, making this a full-read SSRF with confidentiality impact. There is no public exploit identified at time of analysis and no CISA KEV listing; the vendor advisory (GHSA-ffxw-frpx-8rww) reports no fixed version, so exploitation requires valid workspace credentials and reachability of interesting internal targets from the MaxKB host.
InvenTree versions prior to 1.4.0 render report and label templates with WeasyPrint's default URL fetcher, so an authenticated staff user who can author templates can make the server fetch attacker-chosen resources over http/https or read local files through the file:// scheme and later recover the fetched bytes from the stored PDF attachment. This yields full-read server-side request forgery, local file disclosure (potentially including application credentials), and in the worst case compromise of a superuser account. The issue is access-gated and not a broad internet-facing threat: it requires staff-level template-authoring privileges (CVSS 3.1 AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N, base 6.5) plus the ability to retrieve the generated attachment, and no public exploit has been identified at time of analysis. A vendor-released fix is available in InvenTree 1.4.0.
Server-side request forgery in HomeBox prior to 0.26.0 allows an authenticated user with permission to create or test notifiers to reach internal IPv4 destinations that the default BlockBogonNets and BlockCloudMetadata guards are meant to stop, because those guards do not decode IPv4 addresses embedded in NAT64/DNS64 prefixes. Impact is real but conditionally gated: exploitation requires the HomeBox instance's outbound traffic to egress through a NAT64/DNS64 gateway, since without such a gateway the crafted IPv6 destination is unroutable; where present, an attacker can direct the generic:// notifier at cloud metadata or localhost and use the notifier-test response (propagated by Shoutrrr) to read back retrieved data such as temporary credentials. No confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the vendor has released a fix in version 0.26.0.
Server-side request forgery in CKAN MCP Server (ondata/@aborruso ckan-mcp-server) before version 0.4.108 allows an attacker who can influence the caller-supplied server_url parameter to force the server to issue requests to loopback addresses and to the cloud instance metadata service at 169.254.169.254. The flaw is the third bypass of the same validateServerUrl guard: because that guard only inspects the hostname string and never resolves DNS, any hostname that resolves to an internal address (documented examples lvh.me to 127.0.0.1 and *.nip.io to IMDS) slips through, and exploitation realistically requires prompt injection into content the victim's AI assistant processes while the MCP server is connected (CVSS UI:R). No confirmed active exploitation (CISA KEV) and no public exploit identified at time of analysis, though a proof-of-concept for an earlier, related SSRF variant in the same package is published; impact is highest for cloud-hosted deployments where IMDS returns IAM credentials.
Server-side request forgery in self-hosted draw.io deployments prior to 30.2.7 allows unauthenticated remote attackers to make the server fetch attacker-chosen URLs that resolve to private, link-local, or cloud-metadata addresses, returning internal HTTP responses or instance metadata through the image proxy. The flaw only exists when the server is started with ENABLE_DRAWIO_PROXY=1; the SaaS and desktop editions and default installs are unaffected. Successful exploitation depends on a DNS-rebinding timing race (the hostname must resolve to a public address during validation and to an internal address at connection time), which is why the assessed severity is 6.8 with AC:H rather than a high-severity rating; there is no public exploit code identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 30.2.7.
Server-side request forgery in Hatchet versions prior to 0.91.1 lets an authenticated tenant of the platform coerce the SNS ingest service into issuing an outbound HTTP request to an arbitrary URL, because the SNS UnsubscribeConfirmation handler calls http.Get() against the payload's UnsubscribeURL even though that field is excluded from the AWS signature verification performed by BuildSignature(). Successful exploitation allows the server to reach internal-only endpoints such as the EC2 Instance Metadata Service, internal HTTP APIs, and other services on the deployment's network, with the practical payoff limited to information disclosure (for example, potentially exposing IAM credentials) rather than code execution or data modification. Exploitation requires the SNS integration to be enabled and reachable and the attacker to already hold a Hatchet tenant account; there is no public exploit identified at time of analysis, and no confirmable tracking in CISA KEV.
Server-side request forgery in NocoBase v2.1.21 lets an authenticated, low-privilege user drive the server's serverRequest function to issue outbound HTTP requests to arbitrary destinations, enabling internal reachability scanning and probing of services that are not exposed externally. Because exploitation requires a valid low-privilege account (per the CVSS vector PR:L) and the value of the attack depends on the NocoBase host having network access to internal-only resources, the practical impact is internal reconnaissance and reachability enumeration, with fuller information disclosure only where serverRequest returns response bodies to the caller. No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and EPSS is low (0.18%, 8th percentile), so near-term mass exploitation is unlikely; the vendor scored this 6.5 (C:H) while our independent assessment rates confidentiality impact lower (5.0, C:L).
Server-side request forgery in the pdf-tools-mcp MCP server bundled with the 0717376/cowork_bench project lets an attacker who can call its ControlFlowNode tool supply a crafted pdf_file_path argument and cause the server to issue requests to attacker-chosen destinations, yielding low confidentiality, integrity, and availability impact. The repository is a rolling-release personal project with no tagged versions, so all revisions up to commit d943e75bc0fc8e3b27141979300cd8cbcd1e890d are presumed affected, and the CVSS 4.0 vector (PR:L, E:P) indicates the tool interface requires some authenticated or privileged access rather than fully anonymous reach. Publicly available exploit code exists (published in a separate GitHub proof-of-concept repository), but there is no evidence of confirmed active exploitation, and the practical risk is heavily constrained by the product's negligible deployment footprint and the maintainer's failure to respond to the original issue report.
Server-side request forgery in vas3k TaxHacker up to and including 0.8.5 lets an attacker who can reach the LLM-provider configuration function force the server to issue requests to an arbitrary URL of their choosing. The flaw lives in the testLLMProviderAction server action in app/(app)/apps/settings/actions.ts, where the attacker-supplied baseUrl is used as the destination of an outbound HTTP request without validation; publicly available exploit code exists and the project has not responded to the reported issue. Independent assessment places the realistic severity lower than the vendor's CVSS 4.0 score of 5.5: because TaxHacker is a self-hosted, login-gated application, practical exploitation requires an authenticated session and a working LLM-configuration screen, and the achievable impact is limited to confidentiality (reading responses from internal endpoints the server can reach) rather than code execution or data modification.
Server-side request forgery in vas3k TaxHacker up to 0.8.5 lets an attacker control the businessLogo argument passed to the generateInvoicePDF function in /apps/invoices/actions.ts and force the server-side invoice PDF renderer to fetch an arbitrary URL. The independent assessment rates this as moderate severity (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), with exploitation requiring an account on the self-hosted instance that can configure business branding and trigger invoice generation, rather than an anonymous internet attacker. Publicly available exploit code exists, the issue was reported to the project early via GitHub issue #186 without a vendor response, and no CISA KEV listing was identified - impact is limited to low confidentiality, integrity, and availability with no code execution.
Server-side request forgery in NonceGeek dim-sum-app's Deno backend lets remote, unauthenticated attackers redirect outbound requests to an arbitrary host by supplying a crafted supabase_url query parameter to the textSearchV2Handler endpoint (deno/main.tsx). Because the handler builds a Supabase client from that attacker-controlled URL and passes the deployment's SUPABASE_SERVICE_ROLE_KEY as the credential, a successful attack both forces the server to issue requests to attacker-chosen destinations and discloses the service-role key to that endpoint, which in standard deployments can be leveraged for full privileged access to the backing Supabase project and, from there, potential impact on any data or services reachable with that key. The issue is confirmed with publicly available exploit code (disclosed via the project's GitHub issue tracker) but is not listed in CISA KEV, so no confirmed in-the-wild exploitation is established; the vendor has published a fix commit.
Server-side request forgery in Mealie up to 3.25.1 lets an authenticated user with permission to create or edit Recipe Actions coerce the server into making outbound HTTP requests to an arbitrary url argument, with no destination validation applied. Because Recipe Actions are outbound webhook POSTs, the flaw is effectively blind SSRF, so the primary risk is reaching internal-only services or the cloud metadata endpoint rather than directly exfiltrating data back to the attacker. Publicly available exploit code exists, and upgrading to 3.26.0 resolves the issue.
Server-side request forgery in the WordPress plugin Import and Export Users and Customers (versions before 2.4.5) causes the server to fetch an attacker-supplied URL during a CSV import because the plugin fails to validate that URL before making the request. Exploitation is gated behind a high-privileged, authenticated WordPress user with the capability to run the plugin's user/customer CSV import (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N), so a successful attack yields read-only SSRF probing and limited data reflection rather than code execution or data modification. Publicly available exploit code exists, but there is no confirmed active exploitation (CISA KEV), and the practical impact depends entirely on whether internal services or a cloud metadata endpoint are reachable from the web server - making this a genuinely low-priority issue.
Server-side request forgery in the Wow Elements Addons for Elementor WordPress plugin (all versions up to and including 1.11.2) lets an authenticated attacker with Contributor-level access or higher coerce the site's web server into issuing HTTP requests to arbitrary attacker-chosen destinations. The flaw is in the plugin's Changelog widget, which passes the user-controlled 'Changelog File' setting directly into wp_remote_get() with no URL validation or sanitisation, allowing requests to be aimed at internal-only resources such as cloud metadata endpoints or intranet APIs. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis; the Contributor authentication prerequisite and the bounded, low-level confidentiality/integrity/availability impact keep this a genuine but moderate-priority issue rather than an emergency patch item.
CordysCRM 1.7.3 and earlier allows an authenticated user holding the PROCESS_SETTING_ADD permission to store an attacker-chosen webhook URL in an approval-flow node and then cause the server to issue outbound HTTP requests to that URL when an approval action is approved, turning the application into a proxy for reaching internal-only services. The assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N - high confidentiality impact against the attacked component with no integrity or availability impact - and the practical payoff is cloud metadata access (for example 169.254.169.254) and internal network reconnaissance, bounded by the server's network reach and by the multi-step trigger (configure via POST /approval-flow/add, fire via POST /approval-action/approve). The flaw is fixed in 1.7.4 per vendor advisory GHSA-fg6q-pfj7-fghw, PR #2966 and commit e0ae23e; no public exploit code and no confirmed active exploitation were identified at time of analysis, and exploitation requires a low-privileged authenticated account plus a second in-application approval step.