SSRF
Monthly
Server-side request forgery in OpenClaw (npm package 'openclaw') versions 2026.4.5 through before 2026.8.1 lets an attacker who controls an approved remote Chrome DevTools Protocol (CDP) hostname, or its DNS answers, use DNS rebinding to steer the Gateway into connecting to SSRF-denied destinations such as loopback, private, link-local, or cloud metadata addresses. The flaw is a check-then-use (TOCTOU) gap: the Gateway validates and pins DNS at configuration time, but the raw WebSocket and Playwright transports independently re-resolve the hostname when the connection is actually made, discarding the pin. Per the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) exploitation is unauthenticated but requires a non-default, operator-configured hostname-based remote CDP endpoint plus a successful rebinding race, so impact is bounded by the internal services reachable from the Gateway host; no public exploit is identified at time of analysis and CISA KEV does not list this issue.
Server-side request forgery in OpenClaw Gateway (npm-distributed, versions 2026.7.1 through 2026.8.0) lets an authenticated, write-scoped caller abuse Synology Chat attachment delivery: the Gateway validates a single DNS lookup for a supplied file URL but then hands the original hostname to the Synology NAS, which resolves it independently and can be steered to a private or policy-denied resource whose contents are returned to the addressed conversation. Reaching that outcome requires remote URL attachment forwarding to be enabled, the Gateway to accept a remotely-influenced hostname, and the attacker to win a DNS rebinding race against the NAS's own resolution, so practical impact hinges on NAS routing, resolver behavior, and whether a useful response exists at the private destination; no public exploit code has been identified at time of analysis. The vendor CVSS 4.0 rating is 7.1 (HIGH), but our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, arguing for a lower real-world priority given the non-default feature-specific pathway, the PR:L authentication requirement, and the narrow affected window that is closed by upgrading to 2026.8.1.
Server-side request forgery in MediaFlow Proxy through 2.4.9 lets remote, unauthenticated attackers force the proxy to fetch arbitrary internal URLs - including loopback services and cloud metadata endpoints such as 169.254.169.254 - and read the full responses back through the d query parameter on the /proxy routes. Two weaknesses combine: the forward route's destination check validated only numeric private/loopback/link-local IP literals, so hostnames like localhost or nip.io-style names that resolve to internal addresses bypassed it, while the /proxy/stream endpoint performed no internal-address check at all, leaving even bare metadata IP literals reachable. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (no CISA KEV listing); practical risk depends heavily on deployment, with the highest impact where the instance is internet-reachable and runs in a cloud environment that exposes a metadata service.
A server-side request forgery in the VMware datastore driver of OpenStack glance_store lets an authenticated OpenStack user supply a crafted image location URI pointing at an attacker-controlled server, causing the driver's _retry_request function to attach sensitive vCenter authentication headers to that outbound request and disclose them. The deployment must be configured with the non-default VMware/vCenter datastore backend, and the attacker needs an account with the ability to set or override image locations (typically gated behind the set_location / show_multiple_locations policy); SSVC rates the issue as Exploitation=poc with publicly available exploit code on GitHub (sadandbset/CVE-2026-51772-CVE-2026-51773), Technical Impact=total, but Automatable=no, so it is a targeted attack rather than a mass-exploitation candidate and there is no confirmed active exploitation (CISA KEV) at time of analysis. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 8.1) reflects high confidentiality impact from credential theft; our independent assessment adjusts the integrity impact to Low because the primary outcome is leakage of authentication material rather than direct modification of data.
Server-side request forgery in TREK before 3.3.0 allows an authenticated user (CVSS PR:L) to persist an attacker-controlled llm_base_url through the settings API whenever the LLM_PARSING feature is enabled, and that stored URL is later fetched by the server with no SSRF guard. Reaching the vulnerable path additionally requires write permission on the target trip instance, after which the server can be pointed at internal services or link-local cloud metadata endpoints (for example 169.254.169.254), with upstream error text reflected back in parsing warnings, creating a credible path to infrastructure credential disclosure and, per the vendor's assessment, modification of protected cloud resources. No public exploit code has been identified at time of analysis, and independent assessment rates the impact as high confidentiality but only low integrity (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so exploitation is bounded by feature configuration, trip permissions, and network egress controls.
XML External Entity (XXE) injection in http4s-scala-xml's EntityDecoder for scala.xml.Elem (all versions before 0.24.1 and 1.0.0-M39) allows unauthenticated remote attackers who can supply XML message bodies to disclose files readable by the service process, perform server-side request forgery (SSRF) against internal network resources, or trigger denial of service via entity expansion. The decoders obtain a javax.xml.parsers.SAXParserFactory through SAXParserFactory.newInstance without configuring secure-processing features, so JDK default behavior resolves DOCTYPE declarations, external general and parameter entities, and external DTDs. Vendor-released fixes are 0.24.1 and 1.0.0-M39; no public exploit code has been identified at time of analysis, and reachability depends on an application actually using these decoders against untrusted XML.
Server-side request forgery in Termix 2.5.0 allows an authenticated user - including a self-registered low-privilege account where open registration is enabled - to make the Termix backend fetch arbitrary internal URLs through the /homepage/proxy endpoint. Because the handler JSON-parses the fetched body and returns the complete response to the caller, an attacker can reach loopback, RFC1918, link-local and cloud metadata destinations (notably 169.254.169.254) and exfiltrate internal service data and cloud credentials. The vulnerable code path existed only in the narrow 2.5.0-to-2.5.1 window, is fixed in 2.5.1, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in the BentoPDF certificate/timestamp CORS proxy (cloudflare/cors-proxy-worker.js) allows unauthenticated remote attackers to relay requests to internal, reserved, or cloud-metadata destinations when the Worker is hosted on a non-Cloudflare runtime. The flaw is a time-of-check/time-of-use gap: isPrivateOrReservedHost() validates the supplied hostname separately from the DNS resolution performed by fetch(targetUrl), so an attacker who controls a domain's DNS with a very low TTL can pass validation with a public address and have the fetch land on a private one; a certificate-like path satisfies ALLOWED_PATH_PATTERNS, and the browser-oriented Origin header can simply be forged by a direct client, with PROXY_SECRET being only an anti-abuse measure that ships in the public client bundle. Affected versions are 2.8.6 and earlier, fixed in 2.8.7; no public exploit code or confirmed active exploitation was identified at time of analysis, and the assessment rates exploitation as high-complexity because it is gated on a non-default off-Cloudflare deployment that can actually route to internal addresses plus a DNS-rebinding timing race.
Server-side request forgery in Logto prior to 1.43.0 allows an authenticated tenant administrator to point outbound connections at internal, loopback, link-local, or cloud metadata addresses and read the resulting response back through API errors, crossing the deployment's network boundary. The flaw affects webhook delivery (including POST /api/hooks/:id/test), custom OAuth2 connectors that forward the OAuth access token in the Authorization header to an attacker-chosen userInfoEndpoint, OIDC SSO discovery/token/userinfo requests and jwksUri fetching, and SAML IdP metadata retrieval. Rated CVSS 4.0 8.5 (HIGH), driven by the high-privilege PR:H precondition and subsequent-system impacts; no public exploit code or confirmed active exploitation was identified at time of analysis, and the highest-impact outcome (credential theft) depends on whether the deployment exposes a reachable cloud metadata endpoint such as 169.254.169.254. Vendor-released patch: 1.43.0.
Server-side request forgery in IBM DataStage on Cloud Pak for Data 5.4.0.0 allows an authenticated remote attacker to make the server issue requests to internal endpoints and return sensitive information by supplying a manipulated X-Forwarded-Proto header that the application fails to validate. Exploitation requires a valid account on the platform (CVSS PR:L) with network access to the DataStage web interface; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV. The vendor/NVD CVSS 3.1 score of 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) reads as Critical, but the independent assessment scores it C:H/I:N - a confidentiality-only SSRF whose real-world impact depends on which internal services the DataStage host can reach and what those endpoints expose.
Server-side request forgery during OAuth authorization-server metadata discovery in geelen mcp-remote 0.1.32 through 0.1.38 allows a remote attacker to obtain sensitive information from the environment where the client runs. The client trusts an attacker-supplied authorization-server metadata/endpoint URL handled in src/lib/authorization-server-metadata.ts and src/lib/utils.ts without adequate validation, so a victim who connects mcp-remote to an attacker-controlled or attacker-influenced remote MCP server triggers requests to internal targets and discloses the responses. The NVD vector scores it 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) while the independent assessment scores UI:R because the victim must initiate the connection to the malicious server; impact is confidentiality-only, with no integrity or availability effect, and no public exploit identified at time of analysis.
Server-side request forgery in mcp-remote 0.1.32 through 0.1.38 allows an unauthenticated remote attacker who controls or compromises the remote MCP server the victim connects to to make the client fetch attacker-chosen internal or metadata URLs during OAuth discovery. The victim must initiate the connection (UI:R), and the attacker supplies a malicious WWW-Authenticate header whose resource_metadata URL is not validated by the client. No public exploit or KEV activity was identified at time of analysis and EPSS is low at 0.17% (5th percentile); our independent assessment rates the issue CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, requiring user interaction and limiting impact to confidentiality, rather than the reported UI:N and integrity impact.
Server-side request forgery (CWE-918) in IBM Financial Transaction Manager (FTM) for Red Hat OpenShift at affected levels allows an authenticated local attacker to coerce the FTM server into issuing attacker-influenced requests, yielding disclosure of sensitive information and enabling unauthorized actions - rated CVSS 3.1 7.1 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), high confidentiality and integrity impact with no availability impact. Exploitation requires a deployed affected FTM instance plus valid low-privilege authenticated access reachable locally (the vector is local, not internet-facing, and user interaction is not required); no public exploit code has been identified at time of analysis and EPSS is 0.15% (5th percentile), while CISA SSVC records Exploitation: none and Automatable: no. This is a moderate-priority, not a drop-everything, issue: the niche financial middleware footprint, locally-scoped vector, and mandatory authentication mean an unauthenticated external attacker cannot exploit it directly against a default internet-facing posture. A vendor patch is available.
Server-side request forgery in the GitHub Enterprise Server notebook viewer allows a remote attacker to direct requests to internal services listening on non-standard ports of the same appliance, because the viewer validated a user-supplied URL's scheme and host but not its port. Response bodies are not returned, but response timing acts as an oracle that can be used to extract instance secrets character by character; an extracted secret can then be used in a separate interaction with an internal service to obtain remote code execution on the appliance. All GitHub Enterprise Server versions 3.17 through 3.22 are affected; exploitation requires network access to the instance and is unauthenticated only when private mode is disabled, otherwise any authenticated user suffices, and no public exploit has been identified at time of analysis. Note that the independent assessment rates this as high difficulty (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), since full impact depends on a multi-step timing-oracle extraction succeeding and a usable internal service being reachable for the follow-on RCE.
Privilege escalation in the Adobe Premiere Pro desktop application is achievable through a server-side request forgery flaw (CWE-918) that Adobe's own PSIRT self-reported in advisory APSB26-157, carrying a CVSS 3.1 base score of 7.1 (AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N). Because the attack vector is Local, successful exploitation requires the victim's installed copy of Premiere Pro to process attacker-supplied content - in practice a crafted project or media file - and the changed scope (S:C) indicates the forged request reaches a component outside Premiere Pro's own security authority, yielding integrity and privilege-escalation impact with no confidentiality or availability loss. No public exploit code and no CISA KEV entry are associated with this CVE, so no public exploit is identified at time of analysis; note also that the vendor's UI:N claim conflicts with the ordinary desktop file-open workflow, which our assessment scores as UI:R, and this discrepancy is the environment mismatch flagged in the source description and should be verified against APSB26-157 before external publication.
Server-side request forgery in Adobe Experience Manager (AEM) 6.5 Forms JEE and AEM 6.5 LTS Forms JEE lets an authenticated low-privilege user coerce the Forms server into making HTTP requests to internal-only resources, which can cross a security boundary (CVSS scope change) and yield elevated access. The flaw is rated 9.6 by the vendor and assessed at 9.6/9.6-class severity with the confidentiality impact confirmed as high, while integrity impact is bounded by what the reachable internal endpoints actually allow. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the EPSS signal was not notable in the supplied data.
Server-side request forgery in Adobe Experience Manager Forms JEE lets an attacker who already holds high-privileged, admin-level application access coerce the AEM Forms JEE server into issuing requests to internal-only resources, achieving privilege escalation and a scope change beyond the original AEM security perimeter. Affected deployments are AEM 6.5 Forms JEE and AEM 6.5 LTS Forms JEE, reachable over the network (AV:N) with no end-user interaction (UI:N) but gated behind the PR:H privileged-authentication requirement, so practical risk concentrates on malicious insiders or attackers who have already compromised an administrative account. Based on the supplied intelligence there is no CISA KEV listing and no public exploit code identified at time of analysis; the high EPSS-style urgency implied by the CVSS 8.7 base score reflects the scope change and confidentiality/integrity impact rather than demonstrated exploitation.
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised the configured Atlassian backend return a 3xx redirect pointing at an internal address (for example the 169.254.169.254 cloud metadata service), which the MCP server's HTTP session then follows - potentially returning cloud IAM credentials or other internal service data to the attacker. Only deployments configured through the basic-auth or oauth_pat branches are exposed, because those fetcher sessions fail to attach the _make_ssrf_safe_hook redirect validator that the header-PAT branch sets via attach_ssrf_hook=True; header-PAT deployments are not affected. Publicly available exploit code exists (no CISA KEV listing, so no confirmed active exploitation), the vendor fix ships in 0.22.0, and EPSS remains low at 0.32% (26th percentile) with the assessed vector requiring high attack complexity and a malicious upstream prerequisite.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 allows unauthenticated callers to reach internal or cloud metadata endpoints by exploiting a DNS-rebinding race, because the server validates a hostname's resolved IP and then lets Requests/urllib3 resolve that same hostname again at connection time. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N (7.5): no authentication is needed, but the attacker must control authoritative DNS for a low-TTL name that answers publicly during validation and privately during connection, and the server must actually be able to reach a valuable internal target for the attack to pay off. This is a bypass of the earlier CVE-2026-27826 hardening rather than a new class of bug, no public exploit code or confirmed active exploitation was identified at time of analysis, and environments already running 0.22.0 or with no reachable internal/metadata endpoints are not exploitable.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticated caller to force the MCP server to send requests to an arbitrary destination of the attacker's choosing by supplying the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers, which are consumed by _process_authentication_headers without passing through validate_url_for_ssrf. A successful attack redirects the server's Atlassian fetchers at internal services or cloud metadata endpoints, leaking response data back to the caller (scope-changing, high confidentiality impact, no integrity or availability impact per the assessed vector); no public exploit code was identified at time of analysis and EPSS data was not supplied. The defect is an incomplete remediation of the earlier SSRF CVE-2026-27826, and the project shipped a fix in version 0.22.0.
Server-side request forgery in MCP Atlassian (sooperset) versions before 0.22.0 lets unauthenticated callers drive the server into issuing HTTP requests to internal or cloud-metadata addresses by exploiting a DNS-rebinding race in the header-based authentication flow. Only deployments on the header_pat branch, which trust caller-supplied X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers, are exposed; the URL is validated for SSRF once and then re-resolved by the HTTP client at connection time, so a low-TTL attacker-controlled hostname can return a public IP during validation and 127.0.0.1 or 169.254.169.254 during the actual request, with roughly 50 percent success per attempt. Publicly available exploit code exists (a DNS-rebinding proof of concept using rbndr.us), EPSS is low at 0.42 percent (36th percentile), there is no KEV listing indicating confirmed actively exploited (CISA KEV) status, and the vendor-released patch is version 0.22.0.
Server-side request forgery in Adobe Campaign Classic (versions up to and including 7.4.4 build 9401) lets remote unauthenticated attackers induce the ACC server to issue arbitrary requests to other systems, which the vendor rates as a privilege-escalation risk with a changed scope and a maximum CVSS 3.1 base score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). No authentication or user interaction is required per the vendor vector, so the practical limiting factor is whether the ACC endpoint is reachable by the attacker and whether exploitable internal services sit behind it; Adobe does not document a non-default configuration prerequisite, so default deployments in the affected range appear exposed. Exploitation status at time of analysis is that no public exploit has been identified, and EPSS is a modest 0.69% (51st percentile), though the vendor's high impact rating and the absence of preconditions justify prompt patching. An independent recalibration prefers C:H/I:L/A:N over the vendor's triple-high impact, so the 10.0 figure should be read as Adobe's upper-bound claim rather than a confirmed blast radius.
Server-side request forgery in Adobe Campaign Classic lets an authenticated, low-privileged user force the ACC application server to issue requests to internal or otherwise unreachable resources, turning the account into a foothold for reading confidential internal services (CWE-918; CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N). Adobe scores the issue 9.9 Critical, while our assessment keeps the scope change and high confidentiality impact but rates integrity as Low - the dominant effect is unauthorized reach into internal resources rather than direct tampering with protected data - which places effective risk in High territory (≈8.5) rather than Critical. Exploitation requires valid low-privileged ACC credentials and network reachability to the application, needs no user interaction, and no public exploit code or CISA KEV listing was identified at time of analysis.
Server-side request forgery in Adobe Campaign Classic (Classic v7), affecting builds up to and including 7.4.4 build 9401, lets an authenticated low-privileged user coerce the ACC server into making requests to internal systems the user cannot reach directly, with the trust-boundary crossing reflected as a scope change (S:C) that can escalate that user's effective access. No user interaction is required, and Adobe rates the issue 9.9, while our independent assessment retains high confidentiality impact but lowers integrity and availability to Low (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L) and stresses that a valid low-privileged account is a prerequisite, so this is not remote-unauthenticated. No public exploit code and no CISA KEV entry have been identified at time of analysis, EPSS is low at 0.73% (53rd percentile), and SSVC marks the issue non-automatable with total technical impact - making the realistic risk targeted insider or post-foothold abuse rather than opportunistic internet-wide scanning.
Server-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0 allows remote, unauthenticated attackers to make the server issue HTTP requests to internal or otherwise protected network resources. The flaw lives in validate_url_for_ssrf, which parses a URL's authority differently from the Requests connection layer when the server runs the header-based Jira/Confluence URL authentication flow, so a crafted backslash-containing URL can pass validation as an external hostname while the HTTP client actually connects to an internal host. Exploitation is limited to deployments that accept client-supplied Atlassian base URLs, requires the attacker to win the parser-versus-connection-layer discrepancy reliably, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery (CWE-918) in LightRAG before 1.5.5 lets an authenticated caller who can upload a Markdown or textpack document point an external image URL at an IPv6 transition-wrapper literal (NAT64 well-known prefix 64:ff9b::/96 or an IPv4-compatible ::a.b.c.d form) that embeds a loopback, RFC1918, CGNAT, or cloud-metadata IPv4 address, causing the parser's image download to fetch the internal resource and ingest its body. The guard in lightrag/parser/markdown/parser.py evaluated only the literal address with ipaddress.is_global, which classifies these wrappers as globally routable, so the embedded internal target was never checked. Exploitation is conditional (AC:H): the deployment must have compatible NAT64/DNS64 routing for the wrapper to be delivered to the embedded target, which is why the assessed vector is AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). The issue is fixed in v1.5.5.
Server-side request forgery in the WebSSH/WebTelnet listener of Lantronix SLC8000 (before firmware 9.7.0.3), EMG8500/EMG7500 (before firmware 9.7.0.1), and all firmware versions of SLB882 allows unauthenticated remote attackers to make the device open outbound Telnet connections to attacker-chosen hosts by tampering with the rooturl parameter, turning the out-of-band management appliance into a pivot for enumerating or reaching internal network endpoints that are otherwise unreachable from the attacker's position. The flaw sits in the custom shellinaboxd component, which trusts the client-supplied rooturl value to determine its own IP address, and it is remotely exploitable without authentication or user interaction (CVSS:4.0 7.7; independent assessment CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N). Impact is bounded to reconnaissance and lateral communication rather than code execution or data corruption; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the practical risk depends on whether the management interface is exposed to an attacker-controlled network segment. This is a genuine but bounded risk.
Unauthenticated server-side request forgery in the Lantronix SLC8000, EMG8500/EMG7500 and SLB882 console servers lets any remote party that can reach the WebSSH/WebTelnet listener coerce the device into opening an SSH session to an arbitrary, attacker-chosen host or IP. The flaw lives in the custom shellinaboxd daemon, which derives its own address from the client-supplied rooturl parameter, so tampering with that parameter redirects the terminal connection elsewhere, allowing attackers to enumerate or talk to internal endpoints that are otherwise unreachable. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, though a detailed technical writeup and a VulnCheck advisory describe the mechanism; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, reflecting low confidentiality impact on the device itself and high confidentiality impact on systems behind it.
Unauthenticated server-side request forgery in the WebSSH/WebTelnet web terminal listener of Lantronix SLC8000 console servers (before firmware v9.7.0.3), EMG8500/EMG7500 out-of-band gateways (before firmware v9.7.0.1), and all firmware versions of the SLB882 lets remote attackers make the device open SSH connections of their choosing, including to hosts on internal networks the device can route to but the attacker cannot. The trigger is an overlong username that overflows a fixed-size buffer in a custom shellinaboxd snprintf call, truncating the device-derived IP suffix of the connection target and redirecting it to an attacker-specified endpoint. The independent assessment rates this High (CVSS 4.0 base 7.7, AV:N/AC:L/AT:N/PR:N/UI:N, VC:L/SC:H), remote, unauthenticated and low-complexity, with blind SSRF impact - connection establishment and internal enumeration rather than direct extraction of device data; no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in self-hosted draw.io (jgraph/drawio) prior to 30.3.8 lets an unauthenticated remote attacker point the /embed2.js?fetch= endpoint at internal IPv6 Unique Local Address (ULA) resources and read the reflected response, including AWS instance metadata served on the fd00:ec2::/32 range, which can expose IAM credentials and other sensitive internal data. The flaw is a filter bypass rather than a missing check: the private-address guard compared the JDK's fully expanded IPv6 text form against the compressed prefixes 'fc00::' and 'fd00::', so the entire fc00::/7 ULA space slipped through. Exploitation requires a reachable self-hosted draw.io instance and an internal target genuinely addressable over IPv6 ULA - IPv4 private ranges remain blocked, and neither authentication nor the ENABLE_DRAWIO_PROXY=1 flag nor DNS rebinding is needed on the primary /embed2.js path. No public exploit code was identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV listing); the CVSS 4.0 base score is 7.7 (High), reflecting a network-vector, scope-changing confidentiality impact.
Server-side request forgery and arbitrary local file read in MISP before 2.5.47 allow an authenticated user holding permission to add or modify data to upload content through the MISP export/import file handler that the server treats as a file locator rather than an XML document, causing MISP to read local files off the server or issue outbound requests to internal-only services. Assessed CVSS 3.1 is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N (8.3 in the CNA's CVSS 4.0 vector), reflecting high confidentiality impact, scope change and no integrity or availability impact, with the blast radius on the SSRF branch bounded by what the MISP host can reach on the internal network. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; exploitation requires a valid MISP account with modify/add privileges (PR:L) and no victim interaction.
Server-side request forgery in CuteNews 2.1.2 (core/modules/media.php, the Media Manager 'Upload by URL' handler upload_from_inet) lets an attacker submit a crafted URL that the PHP backend fetches on the attacker's behalf, exposing internal-only services and cloud instance metadata endpoints to server-side retrieval. Our independent assessment scores this as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N rather than the published 9.1, because the Media Manager panel is a post-login feature, so a valid account is the practical prerequisite even though the published vector lists PR:N; realized impact further depends on internal network reachability and on whether the fetched response is returned or stored where the attacker can read it (blind SSRF only allows probing). No public exploit code or KEV-listed active exploitation was identified at time of analysis, and EPSS is very low at 0.15% (5th percentile), so this is a high-CVSS-but-modest-real-risk issue.
XML external entity injection in getID3 1.9.26 and earlier allows an attacker who can get a crafted media file parsed by the library's XML2array helper to read local files, potentially trigger server-side request forgery, and cause denial of service through entity expansion. The flaw only manifests on PHP versions earlier than 8.0, where libxml does not disable external entity loading by default and getID3's error-suppressed libxml_disable_entity_loader() call can fail silently; on PHP 8.0 and later the vulnerable code path does not trigger at all. No authentication or user interaction is required once those preconditions hold - the only requirement is that the application ingests attacker-influenced media metadata - and no public exploit identified at time of analysis, though the vendor has published a fix. Independent assessment rates the dominant impact as high-confidentiality local file disclosure (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L), with integrity impact absent and availability impact limited.
Unauthenticated HTTP requests to the OpenShift console's /api/devfile/ and /api/devfile/samples/ endpoints let remote attackers trigger server-side request forgery from the console pod into internal cluster services and exhaust console memory through repeated large requests lacking a Content-Length header. Red Hat rates this 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L); our assessment agrees on the unauthenticated, network-reachable SSRF crossing a trust boundary but lowers confidentiality to C:L because only partial internal responses are reflected, producing a lower composite score. Clusters that expose the web console to untrusted networks are most at risk; no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV).
Server-side request forgery in Azure AI Foundry allows remote unauthenticated attackers to cause high confidentiality loss by making the service fetch attacker-controlled URLs. Microsoft applies the fix server-side, requiring no customer action, and no public exploit has been identified at time of analysis.
Server-side request forgery in Prebid Server Java before 3.43.0 allows unauthenticated remote attackers to redirect the server's outbound bidder traffic to arbitrary destinations by injecting values into bidder adapter parameters. Multiple adapters - including acuityads, adhese, adtonos, adview, axonix, bidmachine, blis, clydo, contxtful, elementaltv, and eplanning - interpolate user-supplied imp.ext fields (host, path, sellerId, accountId, supplierId, supplyId, partnerId, customerId, adunit) directly into endpoint URL templates without calling HttpUtil to validate the resulting domain or path segment, so a crafted bid request can make the server reach internal network services, cloud metadata endpoints such as 169.254.169.254, or other sensitive endpoints using its own network position. No public exploit identified at time of analysis; the vendor's CVSS score of 10.0 overstates the assessed impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N), and real-world severity depends on which of the affected adapters are actually enabled and on the network adjacency of the server.
Server-side request forgery in Vvveb CMS versions prior to 1.0.8.5 allows an authenticated admin-panel user holding editor/* permission to make the server issue HTTP or HTTPS requests to arbitrary internal addresses through the oEmbedProxy endpoint (GET /admin/index.php?module=editor/editor&action=oEmbedProxy?url=...), returning the fetched response body to the caller. Because the action is reached over GET, no CSRF token is required, so a logged-in editor can be induced to trigger the request cross-site, and the attacker can reach private, loopback, link-local, or reserved destinations - including cloud instance-metadata endpoints such as 169.254.169.254 - potentially disclosing internal service responses and associated credentials. Storefront visitors and anonymous users cannot reach the endpoint (authentication and editor-level privilege are prerequisites), and no public exploit code has been identified at time of analysis; the issue is resolved in 1.0.8.5, which validates resolved IP addresses and pins the outbound connection to the vetted address with redirects disabled.
Server-side request forgery in the self-hosted Glean RSS reader (all versions prior to 0.2.6) allows an authenticated user to make the backend worker issue HTTP requests to attacker-chosen URLs, including loopback, RFC 1918 private-range, link-local and cloud metadata endpoints such as 169.254.169.254. Because the fetched response is written into Entry.content and can be read back through GET /api/entries/{id}, this is a non-blind SSRF with full response disclosure rather than a timing or error oracle. Exploitation requires a valid Glean account able to reach POST /api/feeds/discover (PR:L) and no user interaction, so the limiting factor is authentication plus the server's own network reachability; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
Server-side request forgery in Dell OpenManage Server Administrator versions prior to 11.1.0.3 lets remote, unauthenticated attackers who can induce a user interaction coerce the management agent into issuing requests to attacker-chosen internal or external targets, exposing sensitive internal services such as management APIs and cloud metadata endpoints. The flaw (CWE-918) is rated CVSS 3.1 7.4 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N), with the scope-change and confidentiality-high components reflecting that forged traffic escapes the OMSA trust boundary while integrity and availability are unaffected. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at the time of analysis, and real-world impact depends on the OMSA web interface being network-reachable and the managed host having line-of-sight to valuable internal targets.
Server-side request forgery in HKUDS nanobot before 0.3.0 allows remote attackers to force the WebFetchTool component to request arbitrary URLs, including cloud metadata endpoints, localhost services, and RFC 1918 addresses, potentially exfiltrating IAM credentials and internal service data. The flaw resides in the _validate_url() function, which fails to block internal IP ranges. No public exploit identified at time of analysis; exploitation requires the WebFetchTool to be enabled and the bot to process attacker-supplied messages, with the CVSS vector indicating PR:N (unauthenticated) if the message interface is exposed without authentication.
Unauthenticated attackers can coerce changedetection.io through 0.60.6 into fetching arbitrary internal network addresses by abusing the 'Goto URL' action inside a browser step, because the application's SSRF guard is applied only to the main watch URL and never to the browser-step optional_value parameter. Successful exploitation returns the raw response from otherwise unreachable internal services, giving high-confidentiality read access with no write or code-execution impact (independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, high confidentiality only, scope unchanged, versus the vendor-scale 8.7 CVSS 4.0 score). Publicly available exploit code exists, and exploitation additionally requires that browser steps be reachable and backed by a configured Playwright/Chrome fetcher; the unauthenticated path applies to default deployments that ship with no access password, while password-protected instances require valid credentials first.
Server-side request forgery in Nango through version 0.70.4 lets an authenticated user steer server-side HTTP requests to attacker-chosen destinations by supplying malicious values in connection configuration fields that Nango interpolates into provider token and proxy URL templates. Successful abuse can reach internal-only services or cloud instance metadata endpoints (for example 169.254.169.254) and potentially exfiltrate provider credentials held by the Nango deployment. Authentication with the ability to supply connection configuration is required (CVSS 4.0 vector shows PR:L), no public exploit code was identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) - the practical risk is rated moderate because the primary limiter is the pre-existing authenticated access and the payoff depends heavily on the deployment's cloud/network egress posture.
Server-side request forgery in Coze Studio through version 0.5.1 allows an authenticated user who can register or configure a plugin tool to supply an arbitrary server URL, causing the backend to issue HTTP requests to internal-only destinations on the attacker's behalf. The primary risk is confidentiality rather than code execution: responses from cloud metadata endpoints (for example 169.254.169.254) or other services reachable only from the backend network can be read back through the plugin mechanism, potentially exposing credentials, tokens, and internal service data. The issue is rated 7.1 in the CVSS 4.0 vector published with the CVE, while the independent assessment scores it as a credentialed SSRF (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with no integrity or availability impact; no public exploit code was identified at time of analysis and no CISA KEV listing applies, so this is a moderate-priority, credentialed SSRF rather than a critical remote-takeover flaw.
Server-side request forgery (SSRF) in Graylog through version 7.1.4 allows an authenticated user who holds lookup table or event notification permissions to coerce the Graylog server into fetching internal services. The flaw occurs because Graylog validates outbound URLs against an allowlist only before the initial request and does not re-validate the destination after an HTTP redirect; an attacker can supply an allowlisted endpoint that redirects to an internal address, and the server returns the internal response. This is a confidentiality-only issue (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with no public exploit identified at time of analysis.
Server-side request forgery in Wiki.js through 2.5.314 lets an authenticated user who holds page-editing permissions force the server to fetch arbitrary URLs on their behalf, including internal services and cloud instance metadata endpoints, with the fetched response returned to the attacker. The flaw sits in the Image Prefetch renderer, which resolves the src of any img element tagged with the prefetch-candidate class without validating protocol, host, or resolved address; publicly available exploit code exists, and the assessed impact is information disclosure only (high confidentiality, no integrity or availability effect). Exploitation is constrained by the need for an account with editing rights and by the server's network reachability to the intended internal or metadata target, making this a genuine but moderate-priority issue rather than a pre-auth or remote-code-execution class bug.
SQL injection in the management APIs of Cisco Identity Services Engine (ISE) allows an authenticated administrator to read arbitrary content from the backend database and to pivot into server-side request forgery (SSRF) against internal services reachable from the ISE node. The flaw stems from insufficient validation of certain API parameters that are concatenated directly into a backend SQL query, and it affects ISE 3.1.x, 3.2.x, 3.3.x, 3.4.x and 3.5.x releases enumerated by EUVD. Exploitation requires valid administrative credentials (CVSS PR:H, scope-changed S:C, confidentiality High), so this is a genuine but privilege-gated issue best treated as a post-compromise or insider-abuse vector; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Server-side request forgery in the UnifiedLogin service of on-premises Altium Enterprise Server lets an unauthenticated network attacker force the server to issue outbound HTTP requests to arbitrary destinations, including internal-only services. By targeting an internal configuration endpoint that exposes credential material without authentication (relying solely on the request originating locally), the attacker inherits that trusted locality, steals stored credentials, and uses them to obtain an administrative session, resulting in full compromise of the server and its services. Altium 365 cloud deployments are not affected because the vulnerable endpoint is disabled in cloud mode; no public exploit code has been identified at time of analysis, though the assessed severity is maximum (CVSS 10.0 / 3.1 base 10.0).
Server-side request forgery in Quickwit through 0.9.0 allows remote attackers to coerce a Quickwit node into issuing HTTP requests to arbitrary internal addresses by supplying a crafted queue_url when creating an SQS file source. Because Quickwit ships without built-in authentication, any deployment whose management/create-source REST API is network-reachable is effectively unauthenticated against this attack; the only real prerequisite is that the SQS file source feature be usable and that a source definition containing an attacker-chosen queue_url can be POSTed. Exploitation is blind - the attacker learns only whether a connection succeeded, timed out, or errored - so impact is confined to internal network scanning and service fingerprinting from the node's network position, and no public exploit was identified at time of analysis.
Authenticated users of TDuck Survey Form through version 5.3 can hijack forms they do not own and redirect their submissions to arbitrary destinations, because WebhookConfigController enforces neither a form-ownership check nor any validation of the webhook URL. The result is a chained broken-access-control/IDOR plus server-side request forgery issue: a low-privilege account can point a victim's webhook at an external collector to exfiltrate form data, or at internal-only addresses to make the TDuck server issue requests on the attacker's behalf, producing high confidentiality impact with only limited integrity impact. Exploitation needs only a valid authenticated session (remote, no victim interaction beyond normal form submissions, no non-default configuration), and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery with a local file inclusion component in Apache MyFaces - the JSF implementation referred to in the CVE text as 'Apache MyFace Core' - allows an unauthenticated remote attacker to send a single crafted request that makes the application server dereference an attacker-controlled address or file path, yielding disclosure of internal service responses and sensitive local files. The vendor rates this 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H); our independent assessment keeps the unauthenticated, network-reachable, low-complexity profile but models the integrity impact as Low rather than High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N), since the disclosed mechanism is primarily read/dereference oriented. Exploitation is constrained only by reachability of a vulnerable JSF endpoint on an affected release (2.2.0-beta-2.2.15, 2.3.0-2.3.11, 2.3-next-M1-M8, 3.0.0-3.0.3, 4.0.0-4.0.3, 4.1.0-4.1.3, plus older unsupported versions) and by the presence of interesting internal targets; vendor patches are already released and no public exploit code was identified at time of analysis.
Unauthenticated server-side request forgery in DataGear through 6.0.0 lets any remote attacker who can reach the web interface force the server to issue arbitrary HTTP requests - GET, POST, PUT, PATCH, or DELETE - to internal hosts and cloud metadata services via the /dataSet/preview/Http endpoint, returning the full response body to the caller. The endpoint is reachable without credentials (it is exempted by the SecurityConfigSupport allowlist), so the only prerequisite is network reachability to the DataGear instance, with impact maximized in cloud deployments where the link-local metadata service at 169.254.169.254 is reachable and can yield IAM credential theft. No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and no vendor-released patch has been identified.
Server-side request forgery in kkFileView 4.2.0 and later lets remote, unauthenticated attackers make the server fetch arbitrary URLs and read the echoed response body via the cross-origin file proxy endpoint /getCorsFile. The flaw is a validation/consumption mismatch: TrustHostFilter checks the first non-empty parameter in a fixed priority order against the trust.host whitelist, while the controller only reads and fetches urlPath, so a request supplying both a whitelisted decoy (url) and the real target (urlPath) passes validation and fetches the unvalidated target. Our independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N - high confidentiality impact with no integrity or availability impact, somewhat lower than the vendor's 9.1 - and no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.
Server-side request forgery in the @zereight/mcp-gitlab Model Context Protocol server (npm versions 0.0.1 through 2.1.26) allows a caller who can reach the server's HTTP/SSE transport to redirect every outbound GitLab API call to an attacker-controlled host - taking the victim's Private-Token with it - by setting a crafted X-GitLab-API-URL request header. The server accepts that header only when the non-default environment variable ENABLE_DYNAMIC_API_URL=true is set, and it validates the value with a syntax-only new URL() check, applying no allowlist or hostname restriction before the token is attached to the redirected fetch. Publicly available exploit code exists, the flaw is credibly rated as a high-impact credential-theft issue (assessed CVSS 3.1 base of 9.6 with scope change, C:H/I:H), and a vendor fix is available in version 2.1.27, so exposure is limited to deployments that have enabled the dynamic-API-URL option and exposed the transport beyond localhost.
Unauthenticated server-side request forgery in Fireshare versions prior to 1.6.16 allows any remote attacker to force the server to send an arbitrary HTTP POST to a URL of their choosing. The endpoints POST /api/test-discord-webhook and POST /api/test-webhook are missing the @login_required decorator, so no session cookie, API token, or prior access is needed. Because the attacker controls the destination, the server can be pointed at RFC1918 addresses, loopback services, or cloud instance metadata endpoints (e.g. 169.254.169.254), turning a self-hosted media-sharing instance into a pivot into the hosting network. Vendor patch: version 1.6.16. No public exploit code or active exploitation is indicated in the provided intelligence.
Server-side request forgery in OpenCTI versions prior to 7.260701.0 lets an authenticated account holding the INGESTION capability force the platform to issue outbound HTTP(S) requests to arbitrary destinations, including loopback, link-local, private-range and cloud metadata endpoints, because the synchronizerFetch GraphQL query only validated that the supplied URL used HTTP or HTTPS and never applied the ingestion deny list. Distinguishable connection errors let the attacker map internal services (open HTTP ports, open non-HTTP ports and closed ports), while responses from compatible endpoints can leak internal data. The vendor released a fix in 7.260701.0, and no public exploit code or active exploitation is identified in the available data.
Server-side request forgery in the EdgeConnect SD-WAN Orchestrator API lets any remote user who already holds valid low-privilege credentials redirect server-side fetches to attacker-chosen internal destinations, mapping the internal structure of the Orchestrator host and disclosing sensitive information beyond that user's authorized privilege level. The issue is network-reachable at low attack complexity with no user interaction (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 8.5), and the scope change reflects the pivot out of the API context into the host/network fabric. No public exploit code was identified at time of analysis and no CISA KEV entry is associated with this CVE; note that the description names the Orchestrator while the ENISA EUVD record lists EdgeConnect SD-WAN Gateway builds 9.4.0 through 9.7.0, so the exact affected component should be confirmed against the HPE advisory before scoping exposure.
Server-side request forgery in mcp-searxng before 1.7.1 lets an unauthenticated network client coerce the MCP server into fetching internal-only resources. The web_url_read tool validates only the literal hostname string before handing the URL to undici's fetch, so an attacker-controlled hostname that DNS-resolves to a loopback, private, link-local, or cloud-metadata address passes the lexical check and is connected to by the OS resolver. Successful abuse can read internal HTTP services, leak credentials or service tokens, and enumerate reachable internal hosts; publicly available exploit code exists and EPSS remains low (0.14%, 3rd percentile), so this is a real but conditional risk concentrated in deployments that expose the default HTTP transport without the MCP_HTTP_HARDEN authorization layer.
URL path injection in the Lokka MCP server for Microsoft 365 (versions prior to 2.1.2) allows a crafted path value passed to the Lokka-Microsoft tool to break out of the management.azure.com base URL, causing a valid Azure Resource Manager bearer token to be transmitted to an attacker-controlled host. The flaw is a classic server-side request forgery / token-exfiltration pattern (CWE-918) caused by string concatenation instead of the standard URL API when building ARM request URLs. The vendor fixed it in 2.1.2 by validating Azure paths and composing URLs via the URL constructor; no public exploit code or CISA KEV entry was identified in the provided intelligence, so exploitation is currently assessed as requiring attacker-controlled input (for example indirect prompt injection) into the tool's path argument.
Server-Side Request Forgery protection bypass in the Elixir safeurl library (versions 0.1.0 and later) allows unauthenticated attackers who can influence a URL passed to SafeURL.get/validate_url to reach internal or reserved network destinations that the library is configured to block. The root cause is IPv4-only blocklist matching: a destination rejected as an IPv4 address is accepted when expressed as an IPv6 literal, IPv6 entries in the blocklist never match, and a hostname that resolves to no IPv4 address is accepted regardless of where it actually points; deployments using the library's allowlist (whitelist) option are not affected because unmatched addresses are rejected there. Exploitation requires an application running safeurl in its default blacklist/blocklist mode with attacker-influenced URLs; there is no public exploit identified at time of analysis, CISA KEV does not list this CVE, and EPSS is low at 0.46% (39th percentile), so urgency is driven by the defensive nature of the component rather than observed attack activity. CVSS is rated 9.0 by the CNA, with an independent assessment of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N reflecting high confidentiality impact, low integrity impact, and changed scope.
Server-side request forgery in Crawl4AI before 0.9.3 lets an authenticated user of the crawling service force the server to fetch arbitrary internal URLs through the PDF scraping path. The PDFContentScrapingStrategy helper _get_pdf_path() re-downloads the target with the Python requests library without applying the crawler's egress validation, so an attacker-supplied URL that redirects to an internal address — or that relies on DNS rebinding — is fetched and its contents returned in the crawl result after PDF text extraction. CVSS 4.0 scoring is 8.3 (AV:N/AC:L/PR:L/UI:N, VC:H/SC:H), no CISA KEV listing or public exploit code was identified at time of analysis, and the fix is available in 0.9.3.
Server-side request forgery in Flowise versions before 3.1.4 allows a low-privileged authenticated user to supply arbitrary URLs to the Cheerio, Playwright, and Puppeteer document loader nodes, bypassing the platform's built-in SSRF protections. Because the fetched response body is returned as document text, the flaw is a full-read SSRF rather than a blind one, exposing cloud instance metadata, internal-only services, and private network resources to the attacker. No public exploit code or CISA KEV entry was identified in the supplied intelligence, and no EPSS score was provided, so real-world exploitation is currently unconfirmed; the vendor has released a patch in 3.1.4.
Server-side request forgery in Flowise (an open-source low-code LLM/chatflow orchestration platform) before 3.1.4 lets an authenticated user point the baseURL parameter of a chat-model node at an arbitrary host, causing the Flowise server itself to issue the outbound request. Because stored LLM provider API keys are attached to those requests, an attacker holding the chatflows:create or chatflows:update permission can harvest credentials by redirecting traffic to cloud instance-metadata endpoints (e.g. 169.254.169.254) or internal services reachable from the Flowise host. The issue is fixed in 3.1.4; no CISA KEV entry, EPSS score, or public exploit code was supplied in the source data.
KubeSphere 4.1.3 and earlier ship a git credential verification endpoint that fetches caller-supplied URLs without any allowlist validation, letting an authenticated user point the server at internal services and capture the basic-auth credentials returned in the endpoint's error handling. The flaw is a classic CWE-918 SSRF that escalates into cross-namespace Secret disclosure because the leaked responses can expose credentials stored in any namespace. No public exploit code or CISA KEV entry has been identified at time of analysis, but the source-level references confirm the vulnerable code paths, and the CVSS 4.0 score of 8.3 reflects high confidentiality impact on both the vulnerable component and subsequent systems.
WeKnora's URL-based document ingestion endpoint (POST /api/v1/knowledge-bases/:id/knowledge/url) allows authenticated users to reach internal network resources and cloud metadata services by supplying a public URL that redirects to private addresses, bypassing the Go-side SSRF filter applied only to the initial submitted URL. Versions 0.5.2 through 0.6.x are affected; the Python/Playwright web scraper layer followed HTTP redirects without re-invoking SSRF validation, a gap the Go service handler did not share. No public exploit or CISA KEV listing exists at time of analysis, but the redirect-bypass technique is well-documented and accessible to any authenticated user.
Authenticated server-side request forgery in CRMEB v6.0.0 lets a logged-in user coerce the server into issuing arbitrary outbound HTTP requests through the /adminapi/file/online_upload endpoint, enabling internal network reconnaissance and access to resources that are otherwise unreachable from the internet. The flaw is trivially triggered with a crafted POST request (CVSS 8.1, AV:N/AC:L/PR:L/UI:N) and requires only a valid low-privileged session on the admin API. There is no CISA KEV listing and no confirmed public exploit code at time of analysis, though a third-party advisory was published alongside the CVE.
XML External Entity injection in Flowable flowable-engine through 8.0.0 allows authenticated users holding process deployment privileges to exfiltrate arbitrary local files or perform server-side request forgery against internal network endpoints. The vulnerability resides in ProcessDiagramLayoutFactory.parseXml(), which processes user-supplied BPMN XML without disabling external entity resolution, and is present in both the main flowable-engine module and the legacy flowable5-engine (Activiti-derived) module. No public exploit code has been identified at time of analysis, and no confirmed patched release version is available from the referenced data.
Server-side request forgery and root-level code execution in IBM Langflow OSS 1.0.0 through 1.10.0 lets an authenticated user smuggle arbitrary Python through submitted flow components. Because the component validation scanner fails to block socket and urllib imports yet still returns "validated": true, attackers run code as UID=0 to steal AWS credentials via IMDSv1 SSRF, exfiltrate container files, and pivot to internal PostgreSQL and Redis services. Public exploit code exists, though the flaw is not on the CISA KEV list.
An XML external entity (XXE) injection flaw in IBM MQ's reply-message processing lets an authenticated attacker who can place messages on a queue cause the broker to resolve externally defined entities, resulting in arbitrary file disclosure from the MQ server and server-side request forgery against internal networks. The issue spans a wide swath of supported releases - MQ 9.1 LTS through 9.1.0.37, 9.2 LTS through 9.2.0.43, 9.3 LTS through 9.3.0.41 and 9.3 CD through 9.3.5.1, 9.4 LTS through 9.4.0.25 and 9.4 CD through 9.4.5.1, plus MQ 10.0.0.0 Managed File Transfer. IBM rates it CVSS 7.1 (AV:N/AC:L/PR:L/UI:N, high confidentiality, low integrity impact); no public exploit code and no CISA KEV entry were identified at time of analysis.
Server-Side Request Forgery in PraisonAI's multi-agent web tooling allows an authenticated user to exfiltrate internal service responses by supplying a hostname whose DNS A record resolves to a loopback, RFC-1918, link-local, or cloud-metadata address. The SSRF guard in `SpiderTools._validate_url` → `_host_is_blocked` inspects only literal IP encodings and silently falls through for any DNS hostname, meaning a static internal A record is sufficient - no DNS rebinding race is required. Affected are praisonaiagents versions up to 1.6.48 (per GHSA) across the `scrape_page`, `crawl`, `extract_links`, `extract_text`, and `@url` mention-fetch surfaces; the fix ships in praisonaiagents 1.6.58/1.6.59 and PraisonAI 4.6.58. No public exploit identified at time of analysis, though SSVC notes a proof-of-concept exists.
Server-side request forgery in Open Notebook before 1.11.0 allows authenticated users to pivot through the application server to reach cloud instance metadata services, internal network hosts, and localhost-bound services by supplying arbitrary URLs to the POST /api/sources endpoint. The vulnerable parameter is passed directly to the server's HTTP client without any allowlist or blocklist validation, making the application a proxy for internal reconnaissance. No public exploit code has been identified at time of analysis, but the impact is high given the cloud metadata access path (e.g., AWS IMDSv1 credential theft).
SSRF fix bypass in FrontMCP v1.2.1 and its dependency mcp-from-openapi 2.3.0 allows authenticated users of hosted deployments to reach internal network services by supplying crafted OpenAPI specs containing external `$ref` URLs. The previous patch for CVE-2026-39885 introduced a hostname-string denylist that is circumvented via DNS names resolving to loopback (e.g., 127.0.0.1.nip.io), HTTP redirect chains to loopback after an initially allowed host, and IPv4-mapped IPv6 syntax (::ffff:127.0.0.1). A working proof-of-concept with five confirmed bypass vectors is included in the advisory; no CISA KEV listing exists at time of analysis.
Server-Side Request Forgery in Shelf (shelf.nu) asset-tracking platform before v1.20.3 allows authenticated users holding the `asset:import` permission to force the application server to make unrestricted outbound HTTP requests by supplying crafted `imageUrl` values inside a CSV import file. Multiple documented bypass techniques - including image-extension suffixes, redirect chains, and domain substring matching - allow the weak URL validation to be circumvented, after which the server executes an unguarded `fetch()` call. Attackers can reach cloud instance metadata endpoints (e.g., AWS IMDS) to steal IAM credentials, probe internal network services, or trigger memory exhaustion by causing the server to buffer arbitrarily large responses before size checks apply. Vendor-released patch v1.20.3 addresses the issue; no public exploit code identified at time of analysis.
Server-Side Request Forgery in Google Cloud Gemini Enterprise Agent Platform App Builder (all versions prior to the 2026-06-01 deployment date) enables unauthenticated remote attackers to exfiltrate the Compute Engine default service account access token by forcing the application to issue requests to the GCP instance metadata service. The stolen OAuth 2.0 bearer token carries the IAM permissions of the default service account, potentially enabling lateral movement across GCP project resources. Vendor-released patch was deployed on 1 June 2026, but existing app deployments require a manual redeployment to receive the fix - creating remediation lag risk for unmanaged deployments.
Server-Side Request Forgery in IBM DataStage on Cloud Pak for Data 5.4.0.0 allows any authenticated tenant - regardless of project membership or assigned role - to weaponize the shared ds-canvas pod as a network proxy by fully controlling the scheme, host, port, and path of outbound WSDL fetches it performs. The pod's position on the OpenShift overlay network grants reach to co-tenant services, in-cluster CP4D APIs, and link-local IMDS-style addresses, and the fetched body is reflected verbatim to the caller, enabling cross-tenant data exfiltration and internal service reconnaissance. No public exploit or KEV listing has been identified at time of analysis; vendor patch is available.
Server-side request forgery in IBM Langflow OSS 1.0.0 through 1.11.5 allows unauthenticated remote attackers to coerce the application server into fetching arbitrary internal network resources by supplying malicious URLs to the platform's URL-processing functionality. The scope-changed CVSS vector (S:C/C:H) reflects that exploitation exposes systems beyond Langflow itself - including cloud metadata services, internal APIs, and private network hosts accessible from the Langflow host. No public exploit has been identified at time of analysis; a vendor patch is available via IBM's support portal.
Server-Side Request Forgery in IBM Langflow OSS 1.0.0 through 1.11.5 allows unauthenticated remote attackers to coerce the server into issuing arbitrary outbound HTTP requests, exposing internal network services, cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), and other resources inaccessible to the attacker directly. The CVSS vector (AV:N/AC:L/PR:N/UI:N/C:H) confirms this requires no authentication and trivial network access, with high confidentiality impact. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Remote code execution is achievable in IBM DataStage on Cloud Pak for Data 5.4.0.0 through a Server-Side Request Forgery vulnerability that enables an authenticated low-privilege attacker to cause the DataStage server to issue crafted requests to internal resources, ultimately resulting in full host compromise. The CVSS 8.8 score (PR:L) confirms that standard user-level credentials are sufficient to trigger the attack, with no user interaction required and full confidentiality, integrity, and availability impact. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; a vendor-released patch is available via the IBM advisory.
Server-Side Rendering in Angular's @angular/platform-server leaks server-side credentials to attacker-controlled origins via a Unicode whitespace URL validation bypass. When application code validates a user-supplied URL using WHATWG URL parsing (correctly rejecting protocol-relative paths), Angular's internal `resolveUrl` and `parseUrl` utilities subsequently call `String.prototype.trim()`, which strips leading Unicode characters such as U+00A0 (non-breaking space) or U+FEFF (BOM) that WHATWG parsing does not remove - transforming an apparently safe relative path into a protocol-relative URL pointing to the attacker's server. Applications using `relativeUrlsTransformerInterceptorFn` that attach Authorization or other credential headers to outbound HttpClient requests then dispatch those requests - including credentials - to the attacker's origin, resulting in SSRF and credential disclosure. No public exploit has been independently identified at time of analysis, though the patch commits effectively document the bypass technique.
SSRF in AWS Systems Manager Agent's port-forwarding feature allows an authenticated remote user to bypass the link-local address denylist and reach the EC2 Instance Metadata Service (IMDS), enabling theft of the managed instance's temporary IAM role credentials. The bypass exploits insufficient canonicalization of IP addresses before denylist evaluation - alternate representations of 169.254.169.254 (hex, decimal, IPv6-mapped, etc.) pass the check unblocked. With stolen credentials, the attacker can exercise the instance's full IAM role permissions from outside the instance. No public exploit identified at time of analysis, but the release notes confirm the fix explicitly canonicalizes IPs and extends the denylist to include ECS/EKS credential endpoints.
Unauthenticated server-side request forgery in GeoNetwork OpenSource lets any anonymous user force the server to issue arbitrary outbound HTTP GET requests through the SLD tooling endpoint POST /api/tools/ogc/sld. Because the caller-supplied WMS server URL is fetched without validation and the response body is returned and stored when it is XML, the SSRF is non-blind — attackers can read back internal XML resources such as configuration files, bypass authorization boundaries, and map the internal network from an anonymous position. Patched versions 4.4.12 and 4.2.17 are available; there is no public exploit code identified at time of analysis and no confirmed active exploitation (not in CISA KEV).
Server-side request forgery in Open WebUI prior to 0.11.1 allows authenticated users to reach internal cloud infrastructure by exploiting gaps in Python's `is_global` address classification. The web retrieval endpoints POST /api/v1/retrieval/process/web and /process/web/search relied solely on Python's built-in global-address check, which does not reject the Azure platform channel IP (168.63.129.16) or other reserved ranges such as multicast, 6to4 relay, NAT64, IPv6 site-local, and embedded-IPv4 representations. On Azure-hosted deployments this enables exfiltration of platform metadata, certificates, and management tokens accessible via the wire-link channel. No public exploit identified at time of analysis; vendor-released patch exists as version 0.11.1.
Server-Side Request Forgery in Schneider Electric EcoStruxure IT Data Center Expert (formerly StruxureWare Data Center Expert) versions 9.1.2 and prior enables a privileged authenticated attacker to send crafted, unvalidated parameters to a server endpoint, causing the platform to make unauthorized outbound or internal requests. The resulting impact spans unauthorized command execution and disclosure of server-side data - a unusually severe outcome for SSRF, likely achieved by pivoting through the SSRF to reach privileged internal services. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Server-side request forgery in Snipe-IT before 8.7.0 allows an authenticated low-privileged attacker to pivot the application server against internal network resources, cloud metadata endpoints, or arbitrary external targets. The vulnerability stems from TCPDF's writeHTML() processing unsanitized img tag injection through the employee_num field in the asset acceptance PDF generator. Exploitation is deferred until a victim user signs an asset acceptance form, at which point the server makes an outbound HTTP(S) request to the attacker-controlled URL embedded in the rendered PDF. A proof-of-concept exists per SSVC data; no active exploitation has been confirmed in CISA KEV.
Arbitrary file read and SSRF in Snipe-IT before 8.7.0 allow low-privileged users to exfiltrate sensitive server files - including .env credential files - via unsanitized EULA text fields. An attacker with category-edit permissions injects markdown image syntax or raw HTML img tags referencing local file paths or remote URLs; the mail auto-embed library resolves these references server-side during checkout confirmation email generation and returns the resolved content as email attachments. No public exploit has been identified at time of analysis, and a vendor patch is available at 8.7.0.
Server-side request forgery in Lara Dashboard 0.9.2-1.3.1 allows any authenticated content editor to proxy arbitrary HTTP requests through the application server via the markdown fetch API endpoint, with the server returning response bodies verbatim to the caller. The POST /api/admin/builder/markdown/fetch endpoint validated only URL format (not destination host), enabling requests to internal services and cloud metadata endpoints such as AWS IMDSv1 at 169.254.169.254, which can yield IAM role temporary credentials. No public exploit identified at time of analysis; vendor-released patch is available in v1.3.2.
Server-Side Request Forgery (SSRF) in Dell Secure Connect Gateway (SCG) 5.0 allows unauthenticated remote attackers to coerce the appliance or application into issuing arbitrary HTTP/HTTPS requests to internal or external destinations, leading to unauthorized access to internal network services, cloud metadata endpoints, or other back-end resources not intended for external exposure. Both the Appliance and Application deployment modes are affected across all versions prior to the fixed releases. No public exploit code or active exploitation has been identified at time of analysis, but the low-complexity, unauthenticated network vector makes this straightforwardly exploitable against any internet- or intranet-accessible instance.
Server-Side Request Forgery in Dell Secure Connect Gateway (SCG) 5.0 enables unauthenticated remote attackers to cause denial of service against both the Application and Appliance (Virtual Edition) deployment forms. The CVSS vector confirms fully unauthenticated network exploitation with no user interaction, targeting availability exclusively - confidentiality and integrity are unaffected. No public exploit code or active exploitation has been identified; EPSS places this in the 8th percentile, and the CISA SSVC assessment lists exploitation status as none.
Server-side request forgery in Tanium Enforce allows authenticated low-privileged users to cause the Enforce server to issue arbitrary HTTP requests to internal network resources outside the application's normal authorization boundary. The CVSS scope change (S:C) and high confidentiality impact (C:H) reflect that a successful attack can expose internal services, cloud metadata endpoints, or backend infrastructure inaccessible to the attacker directly. Tanium disclosed and addressed this issue in advisory TAN-2026-036; no public exploit code or active exploitation has been identified at time of analysis.
Server-side request forgery in Google Chrome for Mobile (builds prior to 153.0.8010.36) allows a remote attacker who successfully social-engineers a victim into opening a crafted HTML page to induce the browser to issue requests that bypass system access restrictions. Exploitation is not a drive-by: user interaction is mandatory, and the authoritative reassessment scores this as CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N (confidentiality/access-restriction bypass only), so the widely circulated 9.8 vector overstates the real-world impact; Chromium itself rates the issue Low. EPSS is 0.18% (7th percentile) and no public exploit identified at time of analysis, while a vendor-released patch (153.0.8010.36) is already available.
Credential exfiltration in n8n's OpenAI Chat Model node allows an authenticated workflow editor to redirect the model-search dropdown request - including the attached OpenAI API key - to an arbitrary attacker-controlled host by overriding `options.baseURL`. Affected versions span the v1 branch prior to 1.123.76 and the v2 branch prior to 2.37.7 and 2.38.2; the root cause is the omission of `assertOpenAiCredentialAllowsUrl` in `loadModels.ts`, the same domain-restriction guard applied elsewhere in the node. No active exploitation or public exploit code has been identified at time of analysis; vendor-released patches are available across all three branches.
Server-side request forgery in OpenClaw (npm package 'openclaw') versions 2026.4.5 through before 2026.8.1 lets an attacker who controls an approved remote Chrome DevTools Protocol (CDP) hostname, or its DNS answers, use DNS rebinding to steer the Gateway into connecting to SSRF-denied destinations such as loopback, private, link-local, or cloud metadata addresses. The flaw is a check-then-use (TOCTOU) gap: the Gateway validates and pins DNS at configuration time, but the raw WebSocket and Playwright transports independently re-resolve the hostname when the connection is actually made, discarding the pin. Per the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) exploitation is unauthenticated but requires a non-default, operator-configured hostname-based remote CDP endpoint plus a successful rebinding race, so impact is bounded by the internal services reachable from the Gateway host; no public exploit is identified at time of analysis and CISA KEV does not list this issue.
Server-side request forgery in OpenClaw Gateway (npm-distributed, versions 2026.7.1 through 2026.8.0) lets an authenticated, write-scoped caller abuse Synology Chat attachment delivery: the Gateway validates a single DNS lookup for a supplied file URL but then hands the original hostname to the Synology NAS, which resolves it independently and can be steered to a private or policy-denied resource whose contents are returned to the addressed conversation. Reaching that outcome requires remote URL attachment forwarding to be enabled, the Gateway to accept a remotely-influenced hostname, and the attacker to win a DNS rebinding race against the NAS's own resolution, so practical impact hinges on NAS routing, resolver behavior, and whether a useful response exists at the private destination; no public exploit code has been identified at time of analysis. The vendor CVSS 4.0 rating is 7.1 (HIGH), but our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, arguing for a lower real-world priority given the non-default feature-specific pathway, the PR:L authentication requirement, and the narrow affected window that is closed by upgrading to 2026.8.1.
Server-side request forgery in MediaFlow Proxy through 2.4.9 lets remote, unauthenticated attackers force the proxy to fetch arbitrary internal URLs - including loopback services and cloud metadata endpoints such as 169.254.169.254 - and read the full responses back through the d query parameter on the /proxy routes. Two weaknesses combine: the forward route's destination check validated only numeric private/loopback/link-local IP literals, so hostnames like localhost or nip.io-style names that resolve to internal addresses bypassed it, while the /proxy/stream endpoint performed no internal-address check at all, leaving even bare metadata IP literals reachable. No public exploit code has been identified at time of analysis and the flaw is not confirmed as actively exploited (no CISA KEV listing); practical risk depends heavily on deployment, with the highest impact where the instance is internet-reachable and runs in a cloud environment that exposes a metadata service.
A server-side request forgery in the VMware datastore driver of OpenStack glance_store lets an authenticated OpenStack user supply a crafted image location URI pointing at an attacker-controlled server, causing the driver's _retry_request function to attach sensitive vCenter authentication headers to that outbound request and disclose them. The deployment must be configured with the non-default VMware/vCenter datastore backend, and the attacker needs an account with the ability to set or override image locations (typically gated behind the set_location / show_multiple_locations policy); SSVC rates the issue as Exploitation=poc with publicly available exploit code on GitHub (sadandbset/CVE-2026-51772-CVE-2026-51773), Technical Impact=total, but Automatable=no, so it is a targeted attack rather than a mass-exploitation candidate and there is no confirmed active exploitation (CISA KEV) at time of analysis. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 8.1) reflects high confidentiality impact from credential theft; our independent assessment adjusts the integrity impact to Low because the primary outcome is leakage of authentication material rather than direct modification of data.
Server-side request forgery in TREK before 3.3.0 allows an authenticated user (CVSS PR:L) to persist an attacker-controlled llm_base_url through the settings API whenever the LLM_PARSING feature is enabled, and that stored URL is later fetched by the server with no SSRF guard. Reaching the vulnerable path additionally requires write permission on the target trip instance, after which the server can be pointed at internal services or link-local cloud metadata endpoints (for example 169.254.169.254), with upstream error text reflected back in parsing warnings, creating a credible path to infrastructure credential disclosure and, per the vendor's assessment, modification of protected cloud resources. No public exploit code has been identified at time of analysis, and independent assessment rates the impact as high confidentiality but only low integrity (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N), so exploitation is bounded by feature configuration, trip permissions, and network egress controls.
XML External Entity (XXE) injection in http4s-scala-xml's EntityDecoder for scala.xml.Elem (all versions before 0.24.1 and 1.0.0-M39) allows unauthenticated remote attackers who can supply XML message bodies to disclose files readable by the service process, perform server-side request forgery (SSRF) against internal network resources, or trigger denial of service via entity expansion. The decoders obtain a javax.xml.parsers.SAXParserFactory through SAXParserFactory.newInstance without configuring secure-processing features, so JDK default behavior resolves DOCTYPE declarations, external general and parameter entities, and external DTDs. Vendor-released fixes are 0.24.1 and 1.0.0-M39; no public exploit code has been identified at time of analysis, and reachability depends on an application actually using these decoders against untrusted XML.
Server-side request forgery in Termix 2.5.0 allows an authenticated user - including a self-registered low-privilege account where open registration is enabled - to make the Termix backend fetch arbitrary internal URLs through the /homepage/proxy endpoint. Because the handler JSON-parses the fetched body and returns the complete response to the caller, an attacker can reach loopback, RFC1918, link-local and cloud metadata destinations (notably 169.254.169.254) and exfiltrate internal service data and cloud credentials. The vulnerable code path existed only in the narrow 2.5.0-to-2.5.1 window, is fixed in 2.5.1, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in the BentoPDF certificate/timestamp CORS proxy (cloudflare/cors-proxy-worker.js) allows unauthenticated remote attackers to relay requests to internal, reserved, or cloud-metadata destinations when the Worker is hosted on a non-Cloudflare runtime. The flaw is a time-of-check/time-of-use gap: isPrivateOrReservedHost() validates the supplied hostname separately from the DNS resolution performed by fetch(targetUrl), so an attacker who controls a domain's DNS with a very low TTL can pass validation with a public address and have the fetch land on a private one; a certificate-like path satisfies ALLOWED_PATH_PATTERNS, and the browser-oriented Origin header can simply be forged by a direct client, with PROXY_SECRET being only an anti-abuse measure that ships in the public client bundle. Affected versions are 2.8.6 and earlier, fixed in 2.8.7; no public exploit code or confirmed active exploitation was identified at time of analysis, and the assessment rates exploitation as high-complexity because it is gated on a non-default off-Cloudflare deployment that can actually route to internal addresses plus a DNS-rebinding timing race.
Server-side request forgery in Logto prior to 1.43.0 allows an authenticated tenant administrator to point outbound connections at internal, loopback, link-local, or cloud metadata addresses and read the resulting response back through API errors, crossing the deployment's network boundary. The flaw affects webhook delivery (including POST /api/hooks/:id/test), custom OAuth2 connectors that forward the OAuth access token in the Authorization header to an attacker-chosen userInfoEndpoint, OIDC SSO discovery/token/userinfo requests and jwksUri fetching, and SAML IdP metadata retrieval. Rated CVSS 4.0 8.5 (HIGH), driven by the high-privilege PR:H precondition and subsequent-system impacts; no public exploit code or confirmed active exploitation was identified at time of analysis, and the highest-impact outcome (credential theft) depends on whether the deployment exposes a reachable cloud metadata endpoint such as 169.254.169.254. Vendor-released patch: 1.43.0.
Server-side request forgery in IBM DataStage on Cloud Pak for Data 5.4.0.0 allows an authenticated remote attacker to make the server issue requests to internal endpoints and return sensitive information by supplying a manipulated X-Forwarded-Proto header that the application fails to validate. Exploitation requires a valid account on the platform (CVSS PR:L) with network access to the DataStage web interface; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV. The vendor/NVD CVSS 3.1 score of 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) reads as Critical, but the independent assessment scores it C:H/I:N - a confidentiality-only SSRF whose real-world impact depends on which internal services the DataStage host can reach and what those endpoints expose.
Server-side request forgery during OAuth authorization-server metadata discovery in geelen mcp-remote 0.1.32 through 0.1.38 allows a remote attacker to obtain sensitive information from the environment where the client runs. The client trusts an attacker-supplied authorization-server metadata/endpoint URL handled in src/lib/authorization-server-metadata.ts and src/lib/utils.ts without adequate validation, so a victim who connects mcp-remote to an attacker-controlled or attacker-influenced remote MCP server triggers requests to internal targets and discloses the responses. The NVD vector scores it 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) while the independent assessment scores UI:R because the victim must initiate the connection to the malicious server; impact is confidentiality-only, with no integrity or availability effect, and no public exploit identified at time of analysis.
Server-side request forgery in mcp-remote 0.1.32 through 0.1.38 allows an unauthenticated remote attacker who controls or compromises the remote MCP server the victim connects to to make the client fetch attacker-chosen internal or metadata URLs during OAuth discovery. The victim must initiate the connection (UI:R), and the attacker supplies a malicious WWW-Authenticate header whose resource_metadata URL is not validated by the client. No public exploit or KEV activity was identified at time of analysis and EPSS is low at 0.17% (5th percentile); our independent assessment rates the issue CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, requiring user interaction and limiting impact to confidentiality, rather than the reported UI:N and integrity impact.
Server-side request forgery (CWE-918) in IBM Financial Transaction Manager (FTM) for Red Hat OpenShift at affected levels allows an authenticated local attacker to coerce the FTM server into issuing attacker-influenced requests, yielding disclosure of sensitive information and enabling unauthorized actions - rated CVSS 3.1 7.1 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N), high confidentiality and integrity impact with no availability impact. Exploitation requires a deployed affected FTM instance plus valid low-privilege authenticated access reachable locally (the vector is local, not internet-facing, and user interaction is not required); no public exploit code has been identified at time of analysis and EPSS is 0.15% (5th percentile), while CISA SSVC records Exploitation: none and Automatable: no. This is a moderate-priority, not a drop-everything, issue: the niche financial middleware footprint, locally-scoped vector, and mandatory authentication mean an unauthenticated external attacker cannot exploit it directly against a default internet-facing posture. A vendor patch is available.
Server-side request forgery in the GitHub Enterprise Server notebook viewer allows a remote attacker to direct requests to internal services listening on non-standard ports of the same appliance, because the viewer validated a user-supplied URL's scheme and host but not its port. Response bodies are not returned, but response timing acts as an oracle that can be used to extract instance secrets character by character; an extracted secret can then be used in a separate interaction with an internal service to obtain remote code execution on the appliance. All GitHub Enterprise Server versions 3.17 through 3.22 are affected; exploitation requires network access to the instance and is unauthenticated only when private mode is disabled, otherwise any authenticated user suffices, and no public exploit has been identified at time of analysis. Note that the independent assessment rates this as high difficulty (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), since full impact depends on a multi-step timing-oracle extraction succeeding and a usable internal service being reachable for the follow-on RCE.
Privilege escalation in the Adobe Premiere Pro desktop application is achievable through a server-side request forgery flaw (CWE-918) that Adobe's own PSIRT self-reported in advisory APSB26-157, carrying a CVSS 3.1 base score of 7.1 (AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N). Because the attack vector is Local, successful exploitation requires the victim's installed copy of Premiere Pro to process attacker-supplied content - in practice a crafted project or media file - and the changed scope (S:C) indicates the forged request reaches a component outside Premiere Pro's own security authority, yielding integrity and privilege-escalation impact with no confidentiality or availability loss. No public exploit code and no CISA KEV entry are associated with this CVE, so no public exploit is identified at time of analysis; note also that the vendor's UI:N claim conflicts with the ordinary desktop file-open workflow, which our assessment scores as UI:R, and this discrepancy is the environment mismatch flagged in the source description and should be verified against APSB26-157 before external publication.
Server-side request forgery in Adobe Experience Manager (AEM) 6.5 Forms JEE and AEM 6.5 LTS Forms JEE lets an authenticated low-privilege user coerce the Forms server into making HTTP requests to internal-only resources, which can cross a security boundary (CVSS scope change) and yield elevated access. The flaw is rated 9.6 by the vendor and assessed at 9.6/9.6-class severity with the confidentiality impact confirmed as high, while integrity impact is bounded by what the reachable internal endpoints actually allow. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the EPSS signal was not notable in the supplied data.
Server-side request forgery in Adobe Experience Manager Forms JEE lets an attacker who already holds high-privileged, admin-level application access coerce the AEM Forms JEE server into issuing requests to internal-only resources, achieving privilege escalation and a scope change beyond the original AEM security perimeter. Affected deployments are AEM 6.5 Forms JEE and AEM 6.5 LTS Forms JEE, reachable over the network (AV:N) with no end-user interaction (UI:N) but gated behind the PR:H privileged-authentication requirement, so practical risk concentrates on malicious insiders or attackers who have already compromised an administrative account. Based on the supplied intelligence there is no CISA KEV listing and no public exploit code identified at time of analysis; the high EPSS-style urgency implied by the CVSS 8.7 base score reflects the scope change and confidentiality/integrity impact rather than demonstrated exploitation.
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised the configured Atlassian backend return a 3xx redirect pointing at an internal address (for example the 169.254.169.254 cloud metadata service), which the MCP server's HTTP session then follows - potentially returning cloud IAM credentials or other internal service data to the attacker. Only deployments configured through the basic-auth or oauth_pat branches are exposed, because those fetcher sessions fail to attach the _make_ssrf_safe_hook redirect validator that the header-PAT branch sets via attach_ssrf_hook=True; header-PAT deployments are not affected. Publicly available exploit code exists (no CISA KEV listing, so no confirmed active exploitation), the vendor fix ships in 0.22.0, and EPSS remains low at 0.32% (26th percentile) with the assessed vector requiring high attack complexity and a malicious upstream prerequisite.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) versions prior to 0.22.0 allows unauthenticated callers to reach internal or cloud metadata endpoints by exploiting a DNS-rebinding race, because the server validates a hostname's resolved IP and then lets Requests/urllib3 resolve that same hostname again at connection time. The assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N (7.5): no authentication is needed, but the attacker must control authoritative DNS for a low-TTL name that answers publicly during validation and privately during connection, and the server must actually be able to reach a valuable internal target for the attack to pay off. This is a bypass of the earlier CVE-2026-27826 hardening rather than a new class of bug, no public exploit code or confirmed active exploitation was identified at time of analysis, and environments already running 0.22.0 or with no reachable internal/metadata endpoints are not exploitable.
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticated caller to force the MCP server to send requests to an arbitrary destination of the attacker's choosing by supplying the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url headers, which are consumed by _process_authentication_headers without passing through validate_url_for_ssrf. A successful attack redirects the server's Atlassian fetchers at internal services or cloud metadata endpoints, leaking response data back to the caller (scope-changing, high confidentiality impact, no integrity or availability impact per the assessed vector); no public exploit code was identified at time of analysis and EPSS data was not supplied. The defect is an incomplete remediation of the earlier SSRF CVE-2026-27826, and the project shipped a fix in version 0.22.0.
Server-side request forgery in MCP Atlassian (sooperset) versions before 0.22.0 lets unauthenticated callers drive the server into issuing HTTP requests to internal or cloud-metadata addresses by exploiting a DNS-rebinding race in the header-based authentication flow. Only deployments on the header_pat branch, which trust caller-supplied X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers, are exposed; the URL is validated for SSRF once and then re-resolved by the HTTP client at connection time, so a low-TTL attacker-controlled hostname can return a public IP during validation and 127.0.0.1 or 169.254.169.254 during the actual request, with roughly 50 percent success per attempt. Publicly available exploit code exists (a DNS-rebinding proof of concept using rbndr.us), EPSS is low at 0.42 percent (36th percentile), there is no KEV listing indicating confirmed actively exploited (CISA KEV) status, and the vendor-released patch is version 0.22.0.
Server-side request forgery in Adobe Campaign Classic (versions up to and including 7.4.4 build 9401) lets remote unauthenticated attackers induce the ACC server to issue arbitrary requests to other systems, which the vendor rates as a privilege-escalation risk with a changed scope and a maximum CVSS 3.1 base score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). No authentication or user interaction is required per the vendor vector, so the practical limiting factor is whether the ACC endpoint is reachable by the attacker and whether exploitable internal services sit behind it; Adobe does not document a non-default configuration prerequisite, so default deployments in the affected range appear exposed. Exploitation status at time of analysis is that no public exploit has been identified, and EPSS is a modest 0.69% (51st percentile), though the vendor's high impact rating and the absence of preconditions justify prompt patching. An independent recalibration prefers C:H/I:L/A:N over the vendor's triple-high impact, so the 10.0 figure should be read as Adobe's upper-bound claim rather than a confirmed blast radius.
Server-side request forgery in Adobe Campaign Classic lets an authenticated, low-privileged user force the ACC application server to issue requests to internal or otherwise unreachable resources, turning the account into a foothold for reading confidential internal services (CWE-918; CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N). Adobe scores the issue 9.9 Critical, while our assessment keeps the scope change and high confidentiality impact but rates integrity as Low - the dominant effect is unauthorized reach into internal resources rather than direct tampering with protected data - which places effective risk in High territory (≈8.5) rather than Critical. Exploitation requires valid low-privileged ACC credentials and network reachability to the application, needs no user interaction, and no public exploit code or CISA KEV listing was identified at time of analysis.
Server-side request forgery in Adobe Campaign Classic (Classic v7), affecting builds up to and including 7.4.4 build 9401, lets an authenticated low-privileged user coerce the ACC server into making requests to internal systems the user cannot reach directly, with the trust-boundary crossing reflected as a scope change (S:C) that can escalate that user's effective access. No user interaction is required, and Adobe rates the issue 9.9, while our independent assessment retains high confidentiality impact but lowers integrity and availability to Low (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L) and stresses that a valid low-privileged account is a prerequisite, so this is not remote-unauthenticated. No public exploit code and no CISA KEV entry have been identified at time of analysis, EPSS is low at 0.73% (53rd percentile), and SSVC marks the issue non-automatable with total technical impact - making the realistic risk targeted insider or post-foothold abuse rather than opportunistic internet-wide scanning.
Server-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0 allows remote, unauthenticated attackers to make the server issue HTTP requests to internal or otherwise protected network resources. The flaw lives in validate_url_for_ssrf, which parses a URL's authority differently from the Requests connection layer when the server runs the header-based Jira/Confluence URL authentication flow, so a crafted backslash-containing URL can pass validation as an external hostname while the HTTP client actually connects to an internal host. Exploitation is limited to deployments that accept client-supplied Atlassian base URLs, requires the attacker to win the parser-versus-connection-layer discrepancy reliably, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery (CWE-918) in LightRAG before 1.5.5 lets an authenticated caller who can upload a Markdown or textpack document point an external image URL at an IPv6 transition-wrapper literal (NAT64 well-known prefix 64:ff9b::/96 or an IPv4-compatible ::a.b.c.d form) that embeds a loopback, RFC1918, CGNAT, or cloud-metadata IPv4 address, causing the parser's image download to fetch the internal resource and ingest its body. The guard in lightrag/parser/markdown/parser.py evaluated only the literal address with ipaddress.is_global, which classifies these wrappers as globally routable, so the embedded internal target was never checked. Exploitation is conditional (AC:H): the deployment must have compatible NAT64/DNS64 routing for the wrapper to be delivered to the embedded target, which is why the assessed vector is AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). The issue is fixed in v1.5.5.
Server-side request forgery in the WebSSH/WebTelnet listener of Lantronix SLC8000 (before firmware 9.7.0.3), EMG8500/EMG7500 (before firmware 9.7.0.1), and all firmware versions of SLB882 allows unauthenticated remote attackers to make the device open outbound Telnet connections to attacker-chosen hosts by tampering with the rooturl parameter, turning the out-of-band management appliance into a pivot for enumerating or reaching internal network endpoints that are otherwise unreachable from the attacker's position. The flaw sits in the custom shellinaboxd component, which trusts the client-supplied rooturl value to determine its own IP address, and it is remotely exploitable without authentication or user interaction (CVSS:4.0 7.7; independent assessment CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N). Impact is bounded to reconnaissance and lateral communication rather than code execution or data corruption; no public exploit code and no confirmed active exploitation were identified at time of analysis, and the practical risk depends on whether the management interface is exposed to an attacker-controlled network segment. This is a genuine but bounded risk.
Unauthenticated server-side request forgery in the Lantronix SLC8000, EMG8500/EMG7500 and SLB882 console servers lets any remote party that can reach the WebSSH/WebTelnet listener coerce the device into opening an SSH session to an arbitrary, attacker-chosen host or IP. The flaw lives in the custom shellinaboxd daemon, which derives its own address from the client-supplied rooturl parameter, so tampering with that parameter redirects the terminal connection elsewhere, allowing attackers to enumerate or talk to internal endpoints that are otherwise unreachable. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis, though a detailed technical writeup and a VulnCheck advisory describe the mechanism; the assessed CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N, reflecting low confidentiality impact on the device itself and high confidentiality impact on systems behind it.
Unauthenticated server-side request forgery in the WebSSH/WebTelnet web terminal listener of Lantronix SLC8000 console servers (before firmware v9.7.0.3), EMG8500/EMG7500 out-of-band gateways (before firmware v9.7.0.1), and all firmware versions of the SLB882 lets remote attackers make the device open SSH connections of their choosing, including to hosts on internal networks the device can route to but the attacker cannot. The trigger is an overlong username that overflows a fixed-size buffer in a custom shellinaboxd snprintf call, truncating the device-derived IP suffix of the connection target and redirecting it to an attacker-specified endpoint. The independent assessment rates this High (CVSS 4.0 base 7.7, AV:N/AC:L/AT:N/PR:N/UI:N, VC:L/SC:H), remote, unauthenticated and low-complexity, with blind SSRF impact - connection establishment and internal enumeration rather than direct extraction of device data; no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in self-hosted draw.io (jgraph/drawio) prior to 30.3.8 lets an unauthenticated remote attacker point the /embed2.js?fetch= endpoint at internal IPv6 Unique Local Address (ULA) resources and read the reflected response, including AWS instance metadata served on the fd00:ec2::/32 range, which can expose IAM credentials and other sensitive internal data. The flaw is a filter bypass rather than a missing check: the private-address guard compared the JDK's fully expanded IPv6 text form against the compressed prefixes 'fc00::' and 'fd00::', so the entire fc00::/7 ULA space slipped through. Exploitation requires a reachable self-hosted draw.io instance and an internal target genuinely addressable over IPv6 ULA - IPv4 private ranges remain blocked, and neither authentication nor the ENABLE_DRAWIO_PROXY=1 flag nor DNS rebinding is needed on the primary /embed2.js path. No public exploit code was identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV listing); the CVSS 4.0 base score is 7.7 (High), reflecting a network-vector, scope-changing confidentiality impact.
Server-side request forgery and arbitrary local file read in MISP before 2.5.47 allow an authenticated user holding permission to add or modify data to upload content through the MISP export/import file handler that the server treats as a file locator rather than an XML document, causing MISP to read local files off the server or issue outbound requests to internal-only services. Assessed CVSS 3.1 is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N (8.3 in the CNA's CVSS 4.0 vector), reflecting high confidentiality impact, scope change and no integrity or availability impact, with the blast radius on the SSRF branch bounded by what the MISP host can reach on the internal network. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; exploitation requires a valid MISP account with modify/add privileges (PR:L) and no victim interaction.
Server-side request forgery in CuteNews 2.1.2 (core/modules/media.php, the Media Manager 'Upload by URL' handler upload_from_inet) lets an attacker submit a crafted URL that the PHP backend fetches on the attacker's behalf, exposing internal-only services and cloud instance metadata endpoints to server-side retrieval. Our independent assessment scores this as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N rather than the published 9.1, because the Media Manager panel is a post-login feature, so a valid account is the practical prerequisite even though the published vector lists PR:N; realized impact further depends on internal network reachability and on whether the fetched response is returned or stored where the attacker can read it (blind SSRF only allows probing). No public exploit code or KEV-listed active exploitation was identified at time of analysis, and EPSS is very low at 0.15% (5th percentile), so this is a high-CVSS-but-modest-real-risk issue.
XML external entity injection in getID3 1.9.26 and earlier allows an attacker who can get a crafted media file parsed by the library's XML2array helper to read local files, potentially trigger server-side request forgery, and cause denial of service through entity expansion. The flaw only manifests on PHP versions earlier than 8.0, where libxml does not disable external entity loading by default and getID3's error-suppressed libxml_disable_entity_loader() call can fail silently; on PHP 8.0 and later the vulnerable code path does not trigger at all. No authentication or user interaction is required once those preconditions hold - the only requirement is that the application ingests attacker-influenced media metadata - and no public exploit identified at time of analysis, though the vendor has published a fix. Independent assessment rates the dominant impact as high-confidentiality local file disclosure (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L), with integrity impact absent and availability impact limited.
Unauthenticated HTTP requests to the OpenShift console's /api/devfile/ and /api/devfile/samples/ endpoints let remote attackers trigger server-side request forgery from the console pod into internal cluster services and exhaust console memory through repeated large requests lacking a Content-Length header. Red Hat rates this 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L); our assessment agrees on the unauthenticated, network-reachable SSRF crossing a trust boundary but lowers confidentiality to C:L because only partial internal responses are reflected, producing a lower composite score. Clusters that expose the web console to untrusted networks are most at risk; no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV).
Server-side request forgery in Azure AI Foundry allows remote unauthenticated attackers to cause high confidentiality loss by making the service fetch attacker-controlled URLs. Microsoft applies the fix server-side, requiring no customer action, and no public exploit has been identified at time of analysis.
Server-side request forgery in Prebid Server Java before 3.43.0 allows unauthenticated remote attackers to redirect the server's outbound bidder traffic to arbitrary destinations by injecting values into bidder adapter parameters. Multiple adapters - including acuityads, adhese, adtonos, adview, axonix, bidmachine, blis, clydo, contxtful, elementaltv, and eplanning - interpolate user-supplied imp.ext fields (host, path, sellerId, accountId, supplierId, supplyId, partnerId, customerId, adunit) directly into endpoint URL templates without calling HttpUtil to validate the resulting domain or path segment, so a crafted bid request can make the server reach internal network services, cloud metadata endpoints such as 169.254.169.254, or other sensitive endpoints using its own network position. No public exploit identified at time of analysis; the vendor's CVSS score of 10.0 overstates the assessed impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N), and real-world severity depends on which of the affected adapters are actually enabled and on the network adjacency of the server.
Server-side request forgery in Vvveb CMS versions prior to 1.0.8.5 allows an authenticated admin-panel user holding editor/* permission to make the server issue HTTP or HTTPS requests to arbitrary internal addresses through the oEmbedProxy endpoint (GET /admin/index.php?module=editor/editor&action=oEmbedProxy?url=...), returning the fetched response body to the caller. Because the action is reached over GET, no CSRF token is required, so a logged-in editor can be induced to trigger the request cross-site, and the attacker can reach private, loopback, link-local, or reserved destinations - including cloud instance-metadata endpoints such as 169.254.169.254 - potentially disclosing internal service responses and associated credentials. Storefront visitors and anonymous users cannot reach the endpoint (authentication and editor-level privilege are prerequisites), and no public exploit code has been identified at time of analysis; the issue is resolved in 1.0.8.5, which validates resolved IP addresses and pins the outbound connection to the vetted address with redirects disabled.
Server-side request forgery in the self-hosted Glean RSS reader (all versions prior to 0.2.6) allows an authenticated user to make the backend worker issue HTTP requests to attacker-chosen URLs, including loopback, RFC 1918 private-range, link-local and cloud metadata endpoints such as 169.254.169.254. Because the fetched response is written into Entry.content and can be read back through GET /api/entries/{id}, this is a non-blind SSRF with full response disclosure rather than a timing or error oracle. Exploitation requires a valid Glean account able to reach POST /api/feeds/discover (PR:L) and no user interaction, so the limiting factor is authentication plus the server's own network reachability; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
Server-side request forgery in Dell OpenManage Server Administrator versions prior to 11.1.0.3 lets remote, unauthenticated attackers who can induce a user interaction coerce the management agent into issuing requests to attacker-chosen internal or external targets, exposing sensitive internal services such as management APIs and cloud metadata endpoints. The flaw (CWE-918) is rated CVSS 3.1 7.4 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N), with the scope-change and confidentiality-high components reflecting that forged traffic escapes the OMSA trust boundary while integrity and availability are unaffected. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at the time of analysis, and real-world impact depends on the OMSA web interface being network-reachable and the managed host having line-of-sight to valuable internal targets.
Server-side request forgery in HKUDS nanobot before 0.3.0 allows remote attackers to force the WebFetchTool component to request arbitrary URLs, including cloud metadata endpoints, localhost services, and RFC 1918 addresses, potentially exfiltrating IAM credentials and internal service data. The flaw resides in the _validate_url() function, which fails to block internal IP ranges. No public exploit identified at time of analysis; exploitation requires the WebFetchTool to be enabled and the bot to process attacker-supplied messages, with the CVSS vector indicating PR:N (unauthenticated) if the message interface is exposed without authentication.
Unauthenticated attackers can coerce changedetection.io through 0.60.6 into fetching arbitrary internal network addresses by abusing the 'Goto URL' action inside a browser step, because the application's SSRF guard is applied only to the main watch URL and never to the browser-step optional_value parameter. Successful exploitation returns the raw response from otherwise unreachable internal services, giving high-confidentiality read access with no write or code-execution impact (independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, high confidentiality only, scope unchanged, versus the vendor-scale 8.7 CVSS 4.0 score). Publicly available exploit code exists, and exploitation additionally requires that browser steps be reachable and backed by a configured Playwright/Chrome fetcher; the unauthenticated path applies to default deployments that ship with no access password, while password-protected instances require valid credentials first.
Server-side request forgery in Nango through version 0.70.4 lets an authenticated user steer server-side HTTP requests to attacker-chosen destinations by supplying malicious values in connection configuration fields that Nango interpolates into provider token and proxy URL templates. Successful abuse can reach internal-only services or cloud instance metadata endpoints (for example 169.254.169.254) and potentially exfiltrate provider credentials held by the Nango deployment. Authentication with the ability to supply connection configuration is required (CVSS 4.0 vector shows PR:L), no public exploit code was identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) - the practical risk is rated moderate because the primary limiter is the pre-existing authenticated access and the payoff depends heavily on the deployment's cloud/network egress posture.
Server-side request forgery in Coze Studio through version 0.5.1 allows an authenticated user who can register or configure a plugin tool to supply an arbitrary server URL, causing the backend to issue HTTP requests to internal-only destinations on the attacker's behalf. The primary risk is confidentiality rather than code execution: responses from cloud metadata endpoints (for example 169.254.169.254) or other services reachable only from the backend network can be read back through the plugin mechanism, potentially exposing credentials, tokens, and internal service data. The issue is rated 7.1 in the CVSS 4.0 vector published with the CVE, while the independent assessment scores it as a credentialed SSRF (CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with no integrity or availability impact; no public exploit code was identified at time of analysis and no CISA KEV listing applies, so this is a moderate-priority, credentialed SSRF rather than a critical remote-takeover flaw.
Server-side request forgery (SSRF) in Graylog through version 7.1.4 allows an authenticated user who holds lookup table or event notification permissions to coerce the Graylog server into fetching internal services. The flaw occurs because Graylog validates outbound URLs against an allowlist only before the initial request and does not re-validate the destination after an HTTP redirect; an attacker can supply an allowlisted endpoint that redirects to an internal address, and the server returns the internal response. This is a confidentiality-only issue (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) with no public exploit identified at time of analysis.
Server-side request forgery in Wiki.js through 2.5.314 lets an authenticated user who holds page-editing permissions force the server to fetch arbitrary URLs on their behalf, including internal services and cloud instance metadata endpoints, with the fetched response returned to the attacker. The flaw sits in the Image Prefetch renderer, which resolves the src of any img element tagged with the prefetch-candidate class without validating protocol, host, or resolved address; publicly available exploit code exists, and the assessed impact is information disclosure only (high confidentiality, no integrity or availability effect). Exploitation is constrained by the need for an account with editing rights and by the server's network reachability to the intended internal or metadata target, making this a genuine but moderate-priority issue rather than a pre-auth or remote-code-execution class bug.
SQL injection in the management APIs of Cisco Identity Services Engine (ISE) allows an authenticated administrator to read arbitrary content from the backend database and to pivot into server-side request forgery (SSRF) against internal services reachable from the ISE node. The flaw stems from insufficient validation of certain API parameters that are concatenated directly into a backend SQL query, and it affects ISE 3.1.x, 3.2.x, 3.3.x, 3.4.x and 3.5.x releases enumerated by EUVD. Exploitation requires valid administrative credentials (CVSS PR:H, scope-changed S:C, confidentiality High), so this is a genuine but privilege-gated issue best treated as a post-compromise or insider-abuse vector; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Server-side request forgery in the UnifiedLogin service of on-premises Altium Enterprise Server lets an unauthenticated network attacker force the server to issue outbound HTTP requests to arbitrary destinations, including internal-only services. By targeting an internal configuration endpoint that exposes credential material without authentication (relying solely on the request originating locally), the attacker inherits that trusted locality, steals stored credentials, and uses them to obtain an administrative session, resulting in full compromise of the server and its services. Altium 365 cloud deployments are not affected because the vulnerable endpoint is disabled in cloud mode; no public exploit code has been identified at time of analysis, though the assessed severity is maximum (CVSS 10.0 / 3.1 base 10.0).
Server-side request forgery in Quickwit through 0.9.0 allows remote attackers to coerce a Quickwit node into issuing HTTP requests to arbitrary internal addresses by supplying a crafted queue_url when creating an SQS file source. Because Quickwit ships without built-in authentication, any deployment whose management/create-source REST API is network-reachable is effectively unauthenticated against this attack; the only real prerequisite is that the SQS file source feature be usable and that a source definition containing an attacker-chosen queue_url can be POSTed. Exploitation is blind - the attacker learns only whether a connection succeeded, timed out, or errored - so impact is confined to internal network scanning and service fingerprinting from the node's network position, and no public exploit was identified at time of analysis.
Authenticated users of TDuck Survey Form through version 5.3 can hijack forms they do not own and redirect their submissions to arbitrary destinations, because WebhookConfigController enforces neither a form-ownership check nor any validation of the webhook URL. The result is a chained broken-access-control/IDOR plus server-side request forgery issue: a low-privilege account can point a victim's webhook at an external collector to exfiltrate form data, or at internal-only addresses to make the TDuck server issue requests on the attacker's behalf, producing high confidentiality impact with only limited integrity impact. Exploitation needs only a valid authenticated session (remote, no victim interaction beyond normal form submissions, no non-default configuration), and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery with a local file inclusion component in Apache MyFaces - the JSF implementation referred to in the CVE text as 'Apache MyFace Core' - allows an unauthenticated remote attacker to send a single crafted request that makes the application server dereference an attacker-controlled address or file path, yielding disclosure of internal service responses and sensitive local files. The vendor rates this 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H); our independent assessment keeps the unauthenticated, network-reachable, low-complexity profile but models the integrity impact as Low rather than High (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N), since the disclosed mechanism is primarily read/dereference oriented. Exploitation is constrained only by reachability of a vulnerable JSF endpoint on an affected release (2.2.0-beta-2.2.15, 2.3.0-2.3.11, 2.3-next-M1-M8, 3.0.0-3.0.3, 4.0.0-4.0.3, 4.1.0-4.1.3, plus older unsupported versions) and by the presence of interesting internal targets; vendor patches are already released and no public exploit code was identified at time of analysis.
Unauthenticated server-side request forgery in DataGear through 6.0.0 lets any remote attacker who can reach the web interface force the server to issue arbitrary HTTP requests - GET, POST, PUT, PATCH, or DELETE - to internal hosts and cloud metadata services via the /dataSet/preview/Http endpoint, returning the full response body to the caller. The endpoint is reachable without credentials (it is exempted by the SecurityConfigSupport allowlist), so the only prerequisite is network reachability to the DataGear instance, with impact maximized in cloud deployments where the link-local metadata service at 169.254.169.254 is reachable and can yield IAM credential theft. No public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and no vendor-released patch has been identified.
Server-side request forgery in kkFileView 4.2.0 and later lets remote, unauthenticated attackers make the server fetch arbitrary URLs and read the echoed response body via the cross-origin file proxy endpoint /getCorsFile. The flaw is a validation/consumption mismatch: TrustHostFilter checks the first non-empty parameter in a fixed priority order against the trust.host whitelist, while the controller only reads and fetches urlPath, so a request supplying both a whitelisted decoy (url) and the real target (urlPath) passes validation and fetches the unvalidated target. Our independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N - high confidentiality impact with no integrity or availability impact, somewhat lower than the vendor's 9.1 - and no public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis.
Server-side request forgery in the @zereight/mcp-gitlab Model Context Protocol server (npm versions 0.0.1 through 2.1.26) allows a caller who can reach the server's HTTP/SSE transport to redirect every outbound GitLab API call to an attacker-controlled host - taking the victim's Private-Token with it - by setting a crafted X-GitLab-API-URL request header. The server accepts that header only when the non-default environment variable ENABLE_DYNAMIC_API_URL=true is set, and it validates the value with a syntax-only new URL() check, applying no allowlist or hostname restriction before the token is attached to the redirected fetch. Publicly available exploit code exists, the flaw is credibly rated as a high-impact credential-theft issue (assessed CVSS 3.1 base of 9.6 with scope change, C:H/I:H), and a vendor fix is available in version 2.1.27, so exposure is limited to deployments that have enabled the dynamic-API-URL option and exposed the transport beyond localhost.
Unauthenticated server-side request forgery in Fireshare versions prior to 1.6.16 allows any remote attacker to force the server to send an arbitrary HTTP POST to a URL of their choosing. The endpoints POST /api/test-discord-webhook and POST /api/test-webhook are missing the @login_required decorator, so no session cookie, API token, or prior access is needed. Because the attacker controls the destination, the server can be pointed at RFC1918 addresses, loopback services, or cloud instance metadata endpoints (e.g. 169.254.169.254), turning a self-hosted media-sharing instance into a pivot into the hosting network. Vendor patch: version 1.6.16. No public exploit code or active exploitation is indicated in the provided intelligence.
Server-side request forgery in OpenCTI versions prior to 7.260701.0 lets an authenticated account holding the INGESTION capability force the platform to issue outbound HTTP(S) requests to arbitrary destinations, including loopback, link-local, private-range and cloud metadata endpoints, because the synchronizerFetch GraphQL query only validated that the supplied URL used HTTP or HTTPS and never applied the ingestion deny list. Distinguishable connection errors let the attacker map internal services (open HTTP ports, open non-HTTP ports and closed ports), while responses from compatible endpoints can leak internal data. The vendor released a fix in 7.260701.0, and no public exploit code or active exploitation is identified in the available data.
Server-side request forgery in the EdgeConnect SD-WAN Orchestrator API lets any remote user who already holds valid low-privilege credentials redirect server-side fetches to attacker-chosen internal destinations, mapping the internal structure of the Orchestrator host and disclosing sensitive information beyond that user's authorized privilege level. The issue is network-reachable at low attack complexity with no user interaction (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 8.5), and the scope change reflects the pivot out of the API context into the host/network fabric. No public exploit code was identified at time of analysis and no CISA KEV entry is associated with this CVE; note that the description names the Orchestrator while the ENISA EUVD record lists EdgeConnect SD-WAN Gateway builds 9.4.0 through 9.7.0, so the exact affected component should be confirmed against the HPE advisory before scoping exposure.
Server-side request forgery in mcp-searxng before 1.7.1 lets an unauthenticated network client coerce the MCP server into fetching internal-only resources. The web_url_read tool validates only the literal hostname string before handing the URL to undici's fetch, so an attacker-controlled hostname that DNS-resolves to a loopback, private, link-local, or cloud-metadata address passes the lexical check and is connected to by the OS resolver. Successful abuse can read internal HTTP services, leak credentials or service tokens, and enumerate reachable internal hosts; publicly available exploit code exists and EPSS remains low (0.14%, 3rd percentile), so this is a real but conditional risk concentrated in deployments that expose the default HTTP transport without the MCP_HTTP_HARDEN authorization layer.
URL path injection in the Lokka MCP server for Microsoft 365 (versions prior to 2.1.2) allows a crafted path value passed to the Lokka-Microsoft tool to break out of the management.azure.com base URL, causing a valid Azure Resource Manager bearer token to be transmitted to an attacker-controlled host. The flaw is a classic server-side request forgery / token-exfiltration pattern (CWE-918) caused by string concatenation instead of the standard URL API when building ARM request URLs. The vendor fixed it in 2.1.2 by validating Azure paths and composing URLs via the URL constructor; no public exploit code or CISA KEV entry was identified in the provided intelligence, so exploitation is currently assessed as requiring attacker-controlled input (for example indirect prompt injection) into the tool's path argument.
Server-Side Request Forgery protection bypass in the Elixir safeurl library (versions 0.1.0 and later) allows unauthenticated attackers who can influence a URL passed to SafeURL.get/validate_url to reach internal or reserved network destinations that the library is configured to block. The root cause is IPv4-only blocklist matching: a destination rejected as an IPv4 address is accepted when expressed as an IPv6 literal, IPv6 entries in the blocklist never match, and a hostname that resolves to no IPv4 address is accepted regardless of where it actually points; deployments using the library's allowlist (whitelist) option are not affected because unmatched addresses are rejected there. Exploitation requires an application running safeurl in its default blacklist/blocklist mode with attacker-influenced URLs; there is no public exploit identified at time of analysis, CISA KEV does not list this CVE, and EPSS is low at 0.46% (39th percentile), so urgency is driven by the defensive nature of the component rather than observed attack activity. CVSS is rated 9.0 by the CNA, with an independent assessment of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N reflecting high confidentiality impact, low integrity impact, and changed scope.
Server-side request forgery in Crawl4AI before 0.9.3 lets an authenticated user of the crawling service force the server to fetch arbitrary internal URLs through the PDF scraping path. The PDFContentScrapingStrategy helper _get_pdf_path() re-downloads the target with the Python requests library without applying the crawler's egress validation, so an attacker-supplied URL that redirects to an internal address — or that relies on DNS rebinding — is fetched and its contents returned in the crawl result after PDF text extraction. CVSS 4.0 scoring is 8.3 (AV:N/AC:L/PR:L/UI:N, VC:H/SC:H), no CISA KEV listing or public exploit code was identified at time of analysis, and the fix is available in 0.9.3.
Server-side request forgery in Flowise versions before 3.1.4 allows a low-privileged authenticated user to supply arbitrary URLs to the Cheerio, Playwright, and Puppeteer document loader nodes, bypassing the platform's built-in SSRF protections. Because the fetched response body is returned as document text, the flaw is a full-read SSRF rather than a blind one, exposing cloud instance metadata, internal-only services, and private network resources to the attacker. No public exploit code or CISA KEV entry was identified in the supplied intelligence, and no EPSS score was provided, so real-world exploitation is currently unconfirmed; the vendor has released a patch in 3.1.4.
Server-side request forgery in Flowise (an open-source low-code LLM/chatflow orchestration platform) before 3.1.4 lets an authenticated user point the baseURL parameter of a chat-model node at an arbitrary host, causing the Flowise server itself to issue the outbound request. Because stored LLM provider API keys are attached to those requests, an attacker holding the chatflows:create or chatflows:update permission can harvest credentials by redirecting traffic to cloud instance-metadata endpoints (e.g. 169.254.169.254) or internal services reachable from the Flowise host. The issue is fixed in 3.1.4; no CISA KEV entry, EPSS score, or public exploit code was supplied in the source data.
KubeSphere 4.1.3 and earlier ship a git credential verification endpoint that fetches caller-supplied URLs without any allowlist validation, letting an authenticated user point the server at internal services and capture the basic-auth credentials returned in the endpoint's error handling. The flaw is a classic CWE-918 SSRF that escalates into cross-namespace Secret disclosure because the leaked responses can expose credentials stored in any namespace. No public exploit code or CISA KEV entry has been identified at time of analysis, but the source-level references confirm the vulnerable code paths, and the CVSS 4.0 score of 8.3 reflects high confidentiality impact on both the vulnerable component and subsequent systems.
WeKnora's URL-based document ingestion endpoint (POST /api/v1/knowledge-bases/:id/knowledge/url) allows authenticated users to reach internal network resources and cloud metadata services by supplying a public URL that redirects to private addresses, bypassing the Go-side SSRF filter applied only to the initial submitted URL. Versions 0.5.2 through 0.6.x are affected; the Python/Playwright web scraper layer followed HTTP redirects without re-invoking SSRF validation, a gap the Go service handler did not share. No public exploit or CISA KEV listing exists at time of analysis, but the redirect-bypass technique is well-documented and accessible to any authenticated user.
Authenticated server-side request forgery in CRMEB v6.0.0 lets a logged-in user coerce the server into issuing arbitrary outbound HTTP requests through the /adminapi/file/online_upload endpoint, enabling internal network reconnaissance and access to resources that are otherwise unreachable from the internet. The flaw is trivially triggered with a crafted POST request (CVSS 8.1, AV:N/AC:L/PR:L/UI:N) and requires only a valid low-privileged session on the admin API. There is no CISA KEV listing and no confirmed public exploit code at time of analysis, though a third-party advisory was published alongside the CVE.
XML External Entity injection in Flowable flowable-engine through 8.0.0 allows authenticated users holding process deployment privileges to exfiltrate arbitrary local files or perform server-side request forgery against internal network endpoints. The vulnerability resides in ProcessDiagramLayoutFactory.parseXml(), which processes user-supplied BPMN XML without disabling external entity resolution, and is present in both the main flowable-engine module and the legacy flowable5-engine (Activiti-derived) module. No public exploit code has been identified at time of analysis, and no confirmed patched release version is available from the referenced data.
Server-side request forgery and root-level code execution in IBM Langflow OSS 1.0.0 through 1.10.0 lets an authenticated user smuggle arbitrary Python through submitted flow components. Because the component validation scanner fails to block socket and urllib imports yet still returns "validated": true, attackers run code as UID=0 to steal AWS credentials via IMDSv1 SSRF, exfiltrate container files, and pivot to internal PostgreSQL and Redis services. Public exploit code exists, though the flaw is not on the CISA KEV list.
An XML external entity (XXE) injection flaw in IBM MQ's reply-message processing lets an authenticated attacker who can place messages on a queue cause the broker to resolve externally defined entities, resulting in arbitrary file disclosure from the MQ server and server-side request forgery against internal networks. The issue spans a wide swath of supported releases - MQ 9.1 LTS through 9.1.0.37, 9.2 LTS through 9.2.0.43, 9.3 LTS through 9.3.0.41 and 9.3 CD through 9.3.5.1, 9.4 LTS through 9.4.0.25 and 9.4 CD through 9.4.5.1, plus MQ 10.0.0.0 Managed File Transfer. IBM rates it CVSS 7.1 (AV:N/AC:L/PR:L/UI:N, high confidentiality, low integrity impact); no public exploit code and no CISA KEV entry were identified at time of analysis.
Server-Side Request Forgery in PraisonAI's multi-agent web tooling allows an authenticated user to exfiltrate internal service responses by supplying a hostname whose DNS A record resolves to a loopback, RFC-1918, link-local, or cloud-metadata address. The SSRF guard in `SpiderTools._validate_url` → `_host_is_blocked` inspects only literal IP encodings and silently falls through for any DNS hostname, meaning a static internal A record is sufficient - no DNS rebinding race is required. Affected are praisonaiagents versions up to 1.6.48 (per GHSA) across the `scrape_page`, `crawl`, `extract_links`, `extract_text`, and `@url` mention-fetch surfaces; the fix ships in praisonaiagents 1.6.58/1.6.59 and PraisonAI 4.6.58. No public exploit identified at time of analysis, though SSVC notes a proof-of-concept exists.
Server-side request forgery in Open Notebook before 1.11.0 allows authenticated users to pivot through the application server to reach cloud instance metadata services, internal network hosts, and localhost-bound services by supplying arbitrary URLs to the POST /api/sources endpoint. The vulnerable parameter is passed directly to the server's HTTP client without any allowlist or blocklist validation, making the application a proxy for internal reconnaissance. No public exploit code has been identified at time of analysis, but the impact is high given the cloud metadata access path (e.g., AWS IMDSv1 credential theft).
SSRF fix bypass in FrontMCP v1.2.1 and its dependency mcp-from-openapi 2.3.0 allows authenticated users of hosted deployments to reach internal network services by supplying crafted OpenAPI specs containing external `$ref` URLs. The previous patch for CVE-2026-39885 introduced a hostname-string denylist that is circumvented via DNS names resolving to loopback (e.g., 127.0.0.1.nip.io), HTTP redirect chains to loopback after an initially allowed host, and IPv4-mapped IPv6 syntax (::ffff:127.0.0.1). A working proof-of-concept with five confirmed bypass vectors is included in the advisory; no CISA KEV listing exists at time of analysis.
Server-Side Request Forgery in Shelf (shelf.nu) asset-tracking platform before v1.20.3 allows authenticated users holding the `asset:import` permission to force the application server to make unrestricted outbound HTTP requests by supplying crafted `imageUrl` values inside a CSV import file. Multiple documented bypass techniques - including image-extension suffixes, redirect chains, and domain substring matching - allow the weak URL validation to be circumvented, after which the server executes an unguarded `fetch()` call. Attackers can reach cloud instance metadata endpoints (e.g., AWS IMDS) to steal IAM credentials, probe internal network services, or trigger memory exhaustion by causing the server to buffer arbitrarily large responses before size checks apply. Vendor-released patch v1.20.3 addresses the issue; no public exploit code identified at time of analysis.
Server-Side Request Forgery in Google Cloud Gemini Enterprise Agent Platform App Builder (all versions prior to the 2026-06-01 deployment date) enables unauthenticated remote attackers to exfiltrate the Compute Engine default service account access token by forcing the application to issue requests to the GCP instance metadata service. The stolen OAuth 2.0 bearer token carries the IAM permissions of the default service account, potentially enabling lateral movement across GCP project resources. Vendor-released patch was deployed on 1 June 2026, but existing app deployments require a manual redeployment to receive the fix - creating remediation lag risk for unmanaged deployments.
Server-Side Request Forgery in IBM DataStage on Cloud Pak for Data 5.4.0.0 allows any authenticated tenant - regardless of project membership or assigned role - to weaponize the shared ds-canvas pod as a network proxy by fully controlling the scheme, host, port, and path of outbound WSDL fetches it performs. The pod's position on the OpenShift overlay network grants reach to co-tenant services, in-cluster CP4D APIs, and link-local IMDS-style addresses, and the fetched body is reflected verbatim to the caller, enabling cross-tenant data exfiltration and internal service reconnaissance. No public exploit or KEV listing has been identified at time of analysis; vendor patch is available.
Server-side request forgery in IBM Langflow OSS 1.0.0 through 1.11.5 allows unauthenticated remote attackers to coerce the application server into fetching arbitrary internal network resources by supplying malicious URLs to the platform's URL-processing functionality. The scope-changed CVSS vector (S:C/C:H) reflects that exploitation exposes systems beyond Langflow itself - including cloud metadata services, internal APIs, and private network hosts accessible from the Langflow host. No public exploit has been identified at time of analysis; a vendor patch is available via IBM's support portal.
Server-Side Request Forgery in IBM Langflow OSS 1.0.0 through 1.11.5 allows unauthenticated remote attackers to coerce the server into issuing arbitrary outbound HTTP requests, exposing internal network services, cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), and other resources inaccessible to the attacker directly. The CVSS vector (AV:N/AC:L/PR:N/UI:N/C:H) confirms this requires no authentication and trivial network access, with high confidentiality impact. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Remote code execution is achievable in IBM DataStage on Cloud Pak for Data 5.4.0.0 through a Server-Side Request Forgery vulnerability that enables an authenticated low-privilege attacker to cause the DataStage server to issue crafted requests to internal resources, ultimately resulting in full host compromise. The CVSS 8.8 score (PR:L) confirms that standard user-level credentials are sufficient to trigger the attack, with no user interaction required and full confidentiality, integrity, and availability impact. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; a vendor-released patch is available via the IBM advisory.
Server-Side Rendering in Angular's @angular/platform-server leaks server-side credentials to attacker-controlled origins via a Unicode whitespace URL validation bypass. When application code validates a user-supplied URL using WHATWG URL parsing (correctly rejecting protocol-relative paths), Angular's internal `resolveUrl` and `parseUrl` utilities subsequently call `String.prototype.trim()`, which strips leading Unicode characters such as U+00A0 (non-breaking space) or U+FEFF (BOM) that WHATWG parsing does not remove - transforming an apparently safe relative path into a protocol-relative URL pointing to the attacker's server. Applications using `relativeUrlsTransformerInterceptorFn` that attach Authorization or other credential headers to outbound HttpClient requests then dispatch those requests - including credentials - to the attacker's origin, resulting in SSRF and credential disclosure. No public exploit has been independently identified at time of analysis, though the patch commits effectively document the bypass technique.
SSRF in AWS Systems Manager Agent's port-forwarding feature allows an authenticated remote user to bypass the link-local address denylist and reach the EC2 Instance Metadata Service (IMDS), enabling theft of the managed instance's temporary IAM role credentials. The bypass exploits insufficient canonicalization of IP addresses before denylist evaluation - alternate representations of 169.254.169.254 (hex, decimal, IPv6-mapped, etc.) pass the check unblocked. With stolen credentials, the attacker can exercise the instance's full IAM role permissions from outside the instance. No public exploit identified at time of analysis, but the release notes confirm the fix explicitly canonicalizes IPs and extends the denylist to include ECS/EKS credential endpoints.
Unauthenticated server-side request forgery in GeoNetwork OpenSource lets any anonymous user force the server to issue arbitrary outbound HTTP GET requests through the SLD tooling endpoint POST /api/tools/ogc/sld. Because the caller-supplied WMS server URL is fetched without validation and the response body is returned and stored when it is XML, the SSRF is non-blind — attackers can read back internal XML resources such as configuration files, bypass authorization boundaries, and map the internal network from an anonymous position. Patched versions 4.4.12 and 4.2.17 are available; there is no public exploit code identified at time of analysis and no confirmed active exploitation (not in CISA KEV).
Server-side request forgery in Open WebUI prior to 0.11.1 allows authenticated users to reach internal cloud infrastructure by exploiting gaps in Python's `is_global` address classification. The web retrieval endpoints POST /api/v1/retrieval/process/web and /process/web/search relied solely on Python's built-in global-address check, which does not reject the Azure platform channel IP (168.63.129.16) or other reserved ranges such as multicast, 6to4 relay, NAT64, IPv6 site-local, and embedded-IPv4 representations. On Azure-hosted deployments this enables exfiltration of platform metadata, certificates, and management tokens accessible via the wire-link channel. No public exploit identified at time of analysis; vendor-released patch exists as version 0.11.1.
Server-Side Request Forgery in Schneider Electric EcoStruxure IT Data Center Expert (formerly StruxureWare Data Center Expert) versions 9.1.2 and prior enables a privileged authenticated attacker to send crafted, unvalidated parameters to a server endpoint, causing the platform to make unauthorized outbound or internal requests. The resulting impact spans unauthorized command execution and disclosure of server-side data - a unusually severe outcome for SSRF, likely achieved by pivoting through the SSRF to reach privileged internal services. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Server-side request forgery in Snipe-IT before 8.7.0 allows an authenticated low-privileged attacker to pivot the application server against internal network resources, cloud metadata endpoints, or arbitrary external targets. The vulnerability stems from TCPDF's writeHTML() processing unsanitized img tag injection through the employee_num field in the asset acceptance PDF generator. Exploitation is deferred until a victim user signs an asset acceptance form, at which point the server makes an outbound HTTP(S) request to the attacker-controlled URL embedded in the rendered PDF. A proof-of-concept exists per SSVC data; no active exploitation has been confirmed in CISA KEV.
Arbitrary file read and SSRF in Snipe-IT before 8.7.0 allow low-privileged users to exfiltrate sensitive server files - including .env credential files - via unsanitized EULA text fields. An attacker with category-edit permissions injects markdown image syntax or raw HTML img tags referencing local file paths or remote URLs; the mail auto-embed library resolves these references server-side during checkout confirmation email generation and returns the resolved content as email attachments. No public exploit has been identified at time of analysis, and a vendor patch is available at 8.7.0.
Server-side request forgery in Lara Dashboard 0.9.2-1.3.1 allows any authenticated content editor to proxy arbitrary HTTP requests through the application server via the markdown fetch API endpoint, with the server returning response bodies verbatim to the caller. The POST /api/admin/builder/markdown/fetch endpoint validated only URL format (not destination host), enabling requests to internal services and cloud metadata endpoints such as AWS IMDSv1 at 169.254.169.254, which can yield IAM role temporary credentials. No public exploit identified at time of analysis; vendor-released patch is available in v1.3.2.
Server-Side Request Forgery (SSRF) in Dell Secure Connect Gateway (SCG) 5.0 allows unauthenticated remote attackers to coerce the appliance or application into issuing arbitrary HTTP/HTTPS requests to internal or external destinations, leading to unauthorized access to internal network services, cloud metadata endpoints, or other back-end resources not intended for external exposure. Both the Appliance and Application deployment modes are affected across all versions prior to the fixed releases. No public exploit code or active exploitation has been identified at time of analysis, but the low-complexity, unauthenticated network vector makes this straightforwardly exploitable against any internet- or intranet-accessible instance.
Server-Side Request Forgery in Dell Secure Connect Gateway (SCG) 5.0 enables unauthenticated remote attackers to cause denial of service against both the Application and Appliance (Virtual Edition) deployment forms. The CVSS vector confirms fully unauthenticated network exploitation with no user interaction, targeting availability exclusively - confidentiality and integrity are unaffected. No public exploit code or active exploitation has been identified; EPSS places this in the 8th percentile, and the CISA SSVC assessment lists exploitation status as none.
Server-side request forgery in Tanium Enforce allows authenticated low-privileged users to cause the Enforce server to issue arbitrary HTTP requests to internal network resources outside the application's normal authorization boundary. The CVSS scope change (S:C) and high confidentiality impact (C:H) reflect that a successful attack can expose internal services, cloud metadata endpoints, or backend infrastructure inaccessible to the attacker directly. Tanium disclosed and addressed this issue in advisory TAN-2026-036; no public exploit code or active exploitation has been identified at time of analysis.
Server-side request forgery in Google Chrome for Mobile (builds prior to 153.0.8010.36) allows a remote attacker who successfully social-engineers a victim into opening a crafted HTML page to induce the browser to issue requests that bypass system access restrictions. Exploitation is not a drive-by: user interaction is mandatory, and the authoritative reassessment scores this as CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N (confidentiality/access-restriction bypass only), so the widely circulated 9.8 vector overstates the real-world impact; Chromium itself rates the issue Low. EPSS is 0.18% (7th percentile) and no public exploit identified at time of analysis, while a vendor-released patch (153.0.8010.36) is already available.
Credential exfiltration in n8n's OpenAI Chat Model node allows an authenticated workflow editor to redirect the model-search dropdown request - including the attached OpenAI API key - to an arbitrary attacker-controlled host by overriding `options.baseURL`. Affected versions span the v1 branch prior to 1.123.76 and the v2 branch prior to 2.37.7 and 2.38.2; the root cause is the omission of `assertOpenAiCredentialAllowsUrl` in `loadModels.ts`, the same domain-restriction guard applied elsewhere in the node. No active exploitation or public exploit code has been identified at time of analysis; vendor-released patches are available across all three branches.