SSRF
Monthly
Server-side request forgery in Redash 10.0.0 through 26.9.0 allows an authenticated user holding execute_query permission on a JSON data source to redirect the query runner's HTTP request to an arbitrary external origin. The flaw stems from the use of urljoin in redash/query_runner/json_ds.py, which lets an absolute query URL replace the configured base_url instead of remaining bound to it; when the data source is configured with HTTP Basic Auth, those stored credentials are also forwarded to the attacker-selected origin, creating a credential-exfiltration path. Private and internal address access remains constrained while REDASH_ENFORCE_PRIVATE_IP_BLOCK is enabled, which limits but does not eliminate the impact; there is no confirmation of active exploitation (CISA KEV) and no public exploit code identified at time of analysis, and the assessed risk is a genuine but moderate-severity SSRF rather than an emergency.
Server-side request forgery in Portkey AI Gateway 1.14.0 through 1.15.2 lets unauthenticated remote attackers make the gateway issue requests to loopback and Docker host services and return the responses to the caller. The flaw exists because the isValidCustomHost check trusts localhost-style hostnames whenever the TRUSTED_CUSTOM_HOSTS environment variable is unset, which is the default configuration; an attacker only needs to send a /v1 request carrying a crafted x-portkey-custom-host header (for example via the ollama provider). Publicly available exploit code exists for this issue and it is not listed in CISA KEV, so exploitation activity is not confirmed; the assessed impact is limited to confidentiality and integrity of services reachable from the gateway host, with no availability or code-execution impact.
When OpenID sign-in is enabled, Gitea processes unauthenticated assertion parameters and sends an HTTP POST request to the caller-supplied OpenID provider endpoint during verification. An attacker controls the destination and much of the form body, allowing interaction with internal HTTP services reachable from the Gitea server. The response is not returned to the attacker, so the issue is blind SSRF; its impact depends on the services and network addresses the server can reach.
Server-side request forgery in Gitea lets an unauthenticated remote attacker cause the server to contact loopback or private-network HTTP services by supplying a crafted OpenID URL when OpenID sign-in is enabled. Affected deployments are vulnerable Gitea releases such as 1.25.4 (CPE wildcard all versions) that have deliberately enabled ENABLE_OPENID_SIGNIN and lack destination restrictions; the vendor patch changes that setting to default false and adds a built-in blocklist for localhost, loopback, private ranges, and IPv6 link-local addresses. Publicly available exploit code exists and the issue is automatable, but no CISA KEV active-exploitation confirmation is present, and the assessed CVSS is 5.3 with only low confidentiality impact.
Server-side request forgery in the yudao-module-ai image service of ruoyi-vue-pro (through 2026.09) lets an authenticated user make the application server issue HTTP requests to arbitrary destinations by supplying the referImageUrl parameter to the Midjourney 'imagine' endpoint, which is handed to Hutool's HttpUtil.downloadBytes() without SSRF filtering. Exploitation requires a valid low-privileged application account with access to that AI image feature (CVSS 4.0 base 5.3, PR:L), so there is no unauthenticated attack path; the practical payoff is internal reconnaissance and information disclosure - probing loopback, RFC1918, and cloud metadata endpoints such as 169.254.169.254 - rather than code execution. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, making this a moderate-priority finding whose real-world severity rises sharply on cloud-hosted deployments that expose IMDSv1 or internal-only administrative services.
Server-side request forgery in ONLYOFFICE DocumentServer before 10.0.0 lets unauthenticated remote attackers coerce the server into fetching arbitrary internal, loopback, and cloud-metadata URLs through the /downloadfile/:docid endpoint and proxy the responses back to the requester. The flaw is reachable in the default configuration because JWT verification is disabled out of the box and a crafted request body setting the isInJwtToken flag causes the fetch to be processed as a DIRECT request, skipping the private-address request-filtering-agent; instances that have explicitly enabled JWT verification are not exploitable through this path. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, but the highest-value impact is on cloud-hosted deployments where reachable metadata services can expose IAM credentials, making this a genuine but moderate-priority issue (CVSS 6.3) rather than a critical emergency.
Contributor-level WordPress users can abuse the FV Flowplayer Video Player plugin's server-side URL fetch routine to probe internal network resources, because the plugin fails to properly validate a user-supplied URL and its existing host-based restriction does not cover every case. Only sites running versions 7.5.44.7212 through 7.5.55.7212 that grant untrusted users Contributor access or above are realistically exposed, and the payoff is a semi-blind oracle: the attacker learns whether an internal host or service responds and its HTTP status code, but never sees the response body, making this a reconnaissance primitive rather than a data-theft vector. Exploitation is authenticated and requires the plugin's URL-based media fetch feature, EPSS is a negligible 0.16 percent (5th percentile), SSVC records no observed exploitation and no automatable path, and while publicly available exploit code exists there is no evidence of active exploitation in the wild; the vendor has shipped a patch in 7.5.55.7212, and this remains a genuinely low-priority issue.
Server-side request forgery in the Azure Arc Connected Machine Agent (versions 1.0.0 up to but not including 1.68) lets an already-authenticated, low-privilege actor induce the agent to fetch attacker-influenced URLs, reaching internal or cloud-metadata endpoints and returning data that can be used to elevate privileges over the network. The issue is confidentiality-only per the assessed vector (C:H/I:N/A:N) and requires network reach plus an existing low-privilege foothold - an unauthenticated attacker cannot exploit it - and no user interaction is needed. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, and vendor patching to agent 1.68 or later removes the exposure.
Server-side request forgery in Microsoft SharePoint Server Subscription Edition lets an authenticated remote attacker with low privileges coerce the SharePoint server into making requests to destinations of the attacker's choosing, exposing information held on network-accessible resources that the server can reach (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). Because the vector specifies PR:L, a valid low-privileged session on the affected build (16.0.0 before 16.0.20326.20190) is required and unauthenticated exploitation is not indicated; no user interaction is needed. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, so this is a medium-priority, confidentiality-only issue whose urgency is driven by how widely low-privileged accounts are granted and whether the farm is internet-exposed.
Server-side request forgery in Finsys Dockhand before 1.0.45 lets an authenticated low-privilege user redirect outbound requests to internal services by smuggling private, loopback, or cloud-metadata IPv4 addresses inside NAT64, 6to4, or Teredo IPv6 transition literals. The flaw lives in the ipCategory() function of src/lib/server/url-safety.ts, which does not classify IPv6 transition ranges as private, so any of the notification, backup, template, registry, git, or secret-provider URL fields can be abused as an SSRF vector. Rated 5.3 (CVSS 4.0; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N), this is a genuine but moderate-priority issue rather than a critical one: exploitation requires an authenticated account, network reachability from Dockhand to the target service, and - for the highest-impact credential-theft scenario - a cloud deployment exposing the 169.254.169.254 metadata endpoint. No public exploit code has been identified at time of analysis, and the vendor has released a fix in 1.0.45.
SSRF protection bypass in the Lancet Go library's netutil.IsInternalIP allows applications that use this helper as their allow/deny filter to fetch internal services and cloud metadata endpoints via IPv6 and transition address forms the function misclassifies as external. Affected releases are Lancet 1.3.1 through 1.4.6 and 2.1.2 through 2.3.9; the function must be consumed by a server-side fetch path that accepts attacker-controlled hostnames, which is why the issue is assessed as moderate priority rather than emergency (CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N, CVSS 4.0 base 6.3). Publicly available exploit code exists (SSVC Exploitation: poc) and an unauthenticated, remote attacker providing hostnames that resolve to fd00::/8, fe80::/10, 100.64.0.0/10, or NAT64/6to4/Teredo encodings of internal IPv4 can reach otherwise unreachable targets; exploitation is not reliably automatable at scale (SSVC Automatable: no) and no confirmed active exploitation (CISA KEV) has been reported.
Server-side request forgery in Shaarli through 0.16.9 lets a logged-in user force the server to issue blind GET requests to loopback, RFC 1918, or link-local cloud-metadata addresses by creating a bookmark whose URL is fetched for thumbnail generation. The practical barrier is authentication (the supplied CVSS 4.0 vector is PR:H; the independent assessment scores it PR:L under CVSS 3.1), and that barrier disappears when the open_shaarli configuration setting is enabled, at which point any unauthenticated visitor can trigger the fetch. Scoring is moderate (base 5.1, confidentiality-only, no integrity or availability impact) and the effect is blind - no response is returned to the attacker - but real-world risk rises sharply on cloud-hosted instances that can reach internal metadata endpoints; no public exploit code and no CISA KEV entry were identified at time of analysis.
Server-side request forgery in Kavita 0.9.0 through 0.9.1.4 allows an authenticated user with permission to use the CBL import feature to submit a URL to POST /api/Cbl/upload-cbl-file and, by winning a DNS-rebinding race or following an HTTPS redirect, bypass the SSRF blocklist so the server probes internal ports or services blindly. Exploitation requires authentication and a time-of-check/time-of-use precondition, is limited to low confidentiality impact, and no public exploit identified at time of analysis; KEV and EPSS data were not provided. This is a confirmed CWE-918 SSRF but a low-severity, low-priority issue per the independent assessment.
Razorpay IFSC Ruby gem through version 2.0.62 is affected by a server-side request forgery (SSRF) vulnerability. Unauthenticated remote attackers can supply a crafted IFSC code to IFSC.find or IFSC#get - such as a network-path reference (//evil.host) or an absolute URI - that Ruby's URI.join resolves as a new host, redirecting API requests to internal or attacker-chosen hosts and returning parsed response fields. Exploitation requires the consuming application to pass untrusted input directly to these methods; impact is limited to low confidentiality (CVSS 4.0 base 6.9) with no write or availability effect, and no public exploit has been identified at time of analysis.
Server-side request forgery in Microsoft SharePoint Server Subscription Edition (builds below 16.0.20326.20190) lets an authenticated attacker who can reach the server from an adjacent network segment make the SharePoint front end issue requests on their behalf, exposing internal services and data (CVSS 5.7, AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, confidentiality-only impact). Low-privilege credentials and adjacency are both mandatory preconditions, so unauthenticated internet-based attackers are excluded, and no user interaction or race conditions are involved. A vendor patch is available, no public exploit code has been identified at time of analysis, and no confirmed active exploitation (CISA KEV) has been reported, making this a patch-management priority rather than an emergency.
Missing authorization in Jorani's Contracts::import() handler lets any authenticated user, including a low-privilege one, submit a contract id plus an arbitrary URL over POST to import days off into any contract, overwriting its non-working-day calendar and driving server-side requests into internal networks. The flaw is present in default installations of Jorani before 1.0.4, where the import action lacks the isAllowed('adddayoff_contract') permission check that v1.0.4 introduces, so no non-default configuration is required. Exploitation requires a valid Jorani session and is network-reachable with no user interaction (CVSS 4.0 base 5.3 Medium; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N with limited confidentiality and integrity impact); no public exploit code identified at time of analysis.
Server-side request forgery in Conductor OSS through 3.33.0-rc10 lets remote attackers influence the kafka_request.bootStrapServers argument handled by KafkaPublishTask.start in the Kafka contrib module, causing the Conductor server to connect to an attacker-chosen Kafka bootstrap endpoint. The issue is CWE-918; VulDB rates it CVSS 4.0 5.5, while our independent assessment uses CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:N/C:L/I:L/A:L and characterizes the practical impact as low, with publicly available exploit code existing but CISA KEV active exploitation not indicated in the provided data. Although the CVSS vector is PR:N, practical exploitation requires that the Kafka contrib module is deployed, that a usable KafkaPublishTask exists, and that the attacker can create or execute a workflow/task controlling the bootstrap-servers argument, so deployments that enforce authentication/authorization on workflow submission or are not internet-exposed are substantially less exposed.
Server-Side Request Forgery (SSRF) protection bypass exists in the UrlImageConverter component of Apache Fesod (Incubating) fesod-sheet 2.0.2-incubating, where an attacker who controls DNS responses for an attacker-supplied image URL can use DNS rebinding to slip past hostname IP validation and force the outbound fetch to reach a restricted internal address. The vulnerability is unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N) and is rated moderate because it requires the application to actively accept untrusted remote image URLs for spreadsheet writing and the attacker to win the time-of-check/time-of-use window between validation and connection; impact is limited to low confidentiality with scope change and no integrity or availability effect. There is no public exploit identified at time of analysis, and the vendor-released fix is Apache Fesod (Incubating) 2.1.0-incubating, which disables remote URL image fetching by default and requires an explicit exact-host allowlist when enabled. This issue is distinct from CVE-2026-49328, which covers the earlier SSRF in releases before 2.0.2-incubating.
Server-side request forgery in conductor-oss Conductor through 3.33.0-rc10 allows unauthenticated remote attackers to induce the Agentspan Agent Runtime to make crafted requests to arbitrary URLs via AgentController.java (CWE-918). The assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) limits impact to confidentiality only, and the CVSS 4.0 vector's E:P metric indicates publicly available exploit code exists; no CISA KEV listing or confirmed active exploitation was provided. Realistic risk is moderate and hinges on whether the Conductor instance is internet-facing and what internal services or cloud metadata endpoints are reachable from the server.
Server-side request forgery in Conductor OSS through 3.32.5 allows unauthenticated remote attackers to force the server to fetch attacker-controlled URLs through the A2A Agent Card Fetching endpoint when the AI/a2a feature is enabled and reachable. The vulnerable path is A2AService.getAgentCard, where the agentUrl argument can be manipulated to reach internal services; publicly available exploit code exists, but no confirmed active exploitation (CISA KEV) is indicated. The independent assessment rates this as moderate with low confidentiality, integrity, and availability impact, and exploitation is realistic only where the A2A agent-card functionality is exposed.
Server-side request forgery (CWE-918) in the MCP Service of conductor-oss Conductor 3.22.0 lets an authenticated low-privilege user who can invoke the listTools operation supply a crafted mcpServer argument and cause the Conductor server to issue requests to attacker-chosen destinations. The impact is scored low (CVSS 4.0 base 2.1; independent assessment CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) because authentication is required, the vulnerable path is only reachable when the MCP integration is enabled and exposed, and there is no scope change to downstream systems. Publicly available exploit code exists for this issue, but there is no confirmation of active exploitation, and no EPSS or CISA KEV data was provided.
Server-side request forgery in conductor-oss Conductor 3.31.2 allows an authenticated low-privileged user to force the server to issue outbound HTTP requests to attacker-chosen destinations by supplying a crafted specUrl when defining an API tool, since ListApiToolsTask.start processes that argument without validating or restricting the target address. Successful abuse can expose internal-only services, loopback interfaces, and cloud instance metadata reachable from the Conductor host, with the assessed CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:N/C:L/I:L/A:N) reflecting limited confidentiality and integrity impact and no availability effect. Publicly available exploit code exists and the flaw is disclosed via VulDB; there is no indication of confirmed active exploitation (not in CISA KEV), and exploitation requires a valid low-privileged account that can create or modify API tool definitions plus a network position where internal targets are actually reachable.
Server-side request forgery in Fit2Cloud MeterSphere up to 3.6.9-lts allows an authenticated low-privilege user to make the server issue outbound HTTP requests to an attacker-chosen URL by manipulating the swaggerUrl argument handled by Swagger3ParserApiDefinition.testUrlTimeout in the Swagger3 API-definition import component. Publicly available exploit code exists and the vendor was contacted but did not respond, so no fix is confirmed; the flaw is network-reachable (AV:N) and needs no user interaction, but it requires valid credentials plus access to the API-import feature, which keeps it a moderate priority rather than an urgent one. Real-world impact depends on what the MeterSphere host can reach internally - internal services, admin interfaces, or cloud metadata endpoints - and the assessed impact is limited to low confidentiality exposure (C:L, I:N, A:N).
Server-side request forgery in GitLab CE/EE (all versions from 10.3 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2) allows an authenticated user with repository import rights to reach internal network resources by winning a time-of-check to time-of-use race condition in the URL validation performed during import operations. The base score is low (CVSS 3.1 3.5, AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N): the attacker must repeatedly race the validation and fetch windows, so the flaw does not trigger reliably and yields only limited confidentiality impact with no integrity or availability effect. There is no public exploit identified at time of analysis and no confirmed active exploitation; the primary risk is limited internal-network reconnaissance or access to internal services from a GitLab instance that can route to them.
Server-side request forgery in EricLBuehler mistral.rs 0.9.3 and earlier allows remote unauthenticated attackers to bypass the private-IP guard used by the server's media-source fetcher, causing the server to request internal addresses such as loopback, link-local, or cloud metadata endpoints. The flaw lives in the is_global_ip/reject_private_ip logic in mistralrs-server-core/src/media_source.rs, which failed to decode IPv6 transition-address forms (IPv4-mapped, IPv4-compatible, 6to4, and NAT64) that embed an internal IPv4 address, so those addresses were judged global and fetched. Publicly available exploit code exists, and the issue is rated CVSS 4.0 6.9 (our independent assessment is a lower-severity SSRF with low confidentiality impact and no integrity or availability impact); no confirmed active exploitation (CISA KEV) was identified at time of analysis. Exploitation is only meaningful where remote media-URL fetching is enabled and reachable internal services exist.
Server-side request forgery in Frappe ERPNext (before 15.112.0 and 16.x before 16.23.0) allows an authenticated user holding a common operational role to point a writable configuration field at an arbitrary destination, causing the ERPNext server to issue outbound requests to hosts that are only reachable from inside the deployment's network. The issue is rated CVSS 5.3 and requires a valid session with permissions to edit the affected field (PR:L), so it is not exploitable by fully unauthenticated attackers; real-world impact depends entirely on what internal services - such as cloud metadata endpoints, internal APIs, or databases - are reachable from the application server. No public exploit code has been identified and the flaw is not confirmed as actively exploited (no CISA KEV listing); per our assessment this is a moderate, not urgent, priority that is fully resolved by upgrading to a fixed release.
Server-side request forgery and local file inclusion in Frappe Framework 15.x before 15.107.3 and 16.x before 16.17.0 allow an authenticated user who can render user-controllable content to PDF to make the server fetch internal resources or embed local server files into the resulting PDF. The root cause is Frappe's dependency on a vulnerable version of the pdfkit library (CVE-2025-26240), which resolves external URLs and file references during server-side PDF rendering. The assessed vector is network-accessible but requires a valid Frappe account with access to a PDF-generating feature (print formats, templates, or report-to-PDF flows), and impact is limited to confidentiality; it is a medium-severity, low-priority issue for most deployments, and no public exploit was identified at time of analysis.
Server-side request forgery in SPIP before 4.4.18 lets an authenticated user with access to remote-fetching features (such as syndicated site feeds or remote document imports) force the CMS to retrieve internal or link-local resources, including cloud metadata endpoints like 169.254.169.254. The root cause is that recuperer_url() in ecrire/inc/distant.php follows up to 10 HTTP redirects without re-invoking valider_url_distante(), so a benign external URL that passes validation can redirect to a target that would otherwise be blocked. Exploitation requires valid credentials (CVSS:4.0 PR:L) and attacker-controlled or attacker-influenced external hosting; impact is confidentiality-only and read-oriented, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in Red Hat Quay allows an authenticated repository administrator to bypass the hostname blacklist enforced by the webhook notification feature, causing the Quay application to issue HTTP requests to attacker-chosen internal destinations such as cloud metadata endpoints or in-cluster services. Successful exploitation can disclose sensitive information returned by those internal services, though the CVSS 3.1 score of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) reflects a moderate impact: the attacker must already hold a privileged in-application role, must use the webhook functionality, and the yield is bounded by which internal endpoints the Quay pod can actually reach. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw is tracked by Red Hat under CVE-2026-85471 with all Quay 3 and Mirror Registry offerings listed as affected via wildcarded CPEs.
Blind server-side request forgery in Crawl4AI before 0.9.4 lets unauthenticated remote attackers bypass Docker egress controls via the RobotsParser.can_fetch robots.txt fetch path, using HTTP redirects or DNS rebinding to reach loopback, internal, and cloud-metadata addresses for service discovery. Rated CVSS 4.0 6.9 (Medium), exploitation requires the check_robots_txt behavior to be in effect when the service processes an attacker-influenced target URL, which makes the Docker service being reachable by untrusted callers a precondition. The SSRF is blind, so responses are not returned to the attacker, keeping confidentiality impact low; no public exploit code or confirmed active exploitation was identified at time of analysis.
Authenticated users on LogicalDOC Community Edition through 9.3 can abuse the default-enabled XMLConverter to make the server fetch attacker-chosen URLs and apply attacker-controlled XSLT during document conversion, because xml-stylesheet href values are resolved without scheme or host allowlisting. The vulnerable converter accepts http, ftp, file, and jar URLs, so a low-privileged user who can upload an XML document can reach internal services, read local files, or influence the resulting converted output. The issue is rated medium severity (CVSS 4.0 base 5.3; independently assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N), authentication is mandatory and no unauthenticated path exists, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery (SSRF) in Ollama versions up to 0.34.1 allows unauthenticated remote attackers to make the server issue HTTP requests to arbitrary internal hosts via cross-host redirects during model pulls. A malicious or compromised registry can redirect manifest or blob requests to internal addresses, potentially exposing limited sensitive information. Publicly available exploit code exists, and the issue is fixed in version 0.34.2 by enforcing a same-host-only redirect policy by default.
Server-side request forgery in houtini-ai voice-analyser-mcp through version 2.1.1 allows a low-privilege authenticated user to make the server issue arbitrary outbound HTTP requests by supplying a crafted sitemap_url to the collect_corpus tool. Because the crawler's fetch function in src/utils/crawler.ts forwards the user-controlled URL without adequate validation, an attacker who can reach and invoke that feature can pivot requests toward internal services, localhost ports, or cloud metadata endpoints, though the assessed impact is bounded to low confidentiality, integrity, and availability effects with no subsequent-system scope. Publicly available exploit code exists and the vendor was contacted but did not respond, and no vendor-released patch has been identified at time of analysis; this is a genuine but low-priority SSRF rather than an unauthenticated or high-severity flaw.
Server-side request forgery in houtini-ai seo-crawler-mcp through version 2.1.5 allows an authenticated caller of the MCP tool interface to coerce the Crawler component into issuing requests to arbitrary destinations through the run_seo_audit function in src/core/CrawlOrchestrator.ts. The vendor was contacted about the flaw but did not respond, so there is no upstream fix at time of analysis, and publicly available exploit code exists (disclosed via the Net-defense/public_exp reference), though there is no evidence of confirmed active exploitation (not in CISA KEV). The independent assessment rates this low priority: exploitation requires low-level privileges on the MCP server (PR:L per both the vendor CVSS 4.0 vector and the assessed CVSS 3.1 vector), needs no user interaction, and yields only low read-level impact, with real risk concentrated where the MCP server has network reach to sensitive internal endpoints such as cloud metadata or internal APIs and lacks URL/egress filtering.
Server-side request forgery in Appwrite 2.3.0 and earlier allows remote attackers to make the Browser Screenshot Service (exposed through the Avatars screenshot endpoint and its 'url' parameter) fetch arbitrary attacker-chosen URLs, reaching internal services or cloud metadata endpoints; because the headless browser resolves the hostname itself, the pre-patch hostname validation can be bypassed via DNS rebinding. Per the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N), exploitation is unauthenticated over the network with confidentiality-only impact (score 6.9), and the independent assessment rates this a genuine but moderate-priority issue bounded to information disclosure through the rendered screenshot. No public exploit was identified at time of analysis, and exploitation requires the screenshot endpoint to be deployed and reachable; the vendor-released fix is Appwrite 2.4.0 (patch commit 393255e7302ae5503331d45802e2eee01c6a47fe, PR 13995).
Server-side request forgery in Company Research Agent through 2.2.0 allows unauthenticated remote attackers to make the server issue outbound HTTP requests by injecting unescaped ReportLab paragraph markup - specifically inline img elements - into the report_content parameter handled by the /generate-pdf endpoint, with the fetched image responses embedded in the returned PDF to give an attacker a content-leakage and internal-reachability oracle. Impact is confined to confidentiality (only responses renderable as images leak content), with no integrity or availability effect, and no public exploit code has been identified at time of analysis, although a public technical writeup describes the injection technique. The issue is tracked as CWE-918 and rated CVSS 4.0 base 6.9 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L), consistent with an independent assessment of a genuine-but-moderate SSRF.
Shepherd (shepherd-ai) through 0.3.1 contains a DNS-rebinding bypass of the citation-checker's public_url SSRF guard, letting an attacker who controls authoritative DNS for a reference URL planted in a checked document redirect the outbound fetch to internal HTTP(S) services and capture the responses inside evidence files. Exploitation requires the shepherd_citation_checker extra to be in use and a victim to actually run a citation check on the attacker-influenced document, then win a time-of-check/time-of-use race in which the guard validates a public IP but the connection re-resolves the hostname to an internal address; no public exploit identified at time of analysis. Impact is read-only information disclosure (low confidentiality, no integrity or availability effect), consistent with the low CVSS 4.0 base score of 2.3 and the assessed CVSS 3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N, and the attacker does not need credentials but does need user interaction and DNS control.
Authenticated server-side request forgery (CWE-918) in Miniflux 2.3.0 through 2.3.3 lets any logged-in user who can create or edit a feed set that feed's proxy_url to a loopback or internal host, defeating the FETCHER_ALLOW_PRIVATE_NETWORKS safeguard so the server itself probes internal ports and sends proxy-style requests to internal services. Impact is confined to low confidentiality disclosure - internal port probing and response/metadata leakage - with no integrity, availability, code-execution or denial-of-service component, and the prerequisite of a valid account means unauthenticated outsiders cannot trigger it; both the supplied CVSS v4.0 score (5.3) and the independent CVSS v3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, also 5.3) agree on a moderate rating. Exploitation status is modest: no CISA KEV entry and no public exploit identified at time of analysis, although a public technical writeup of the bypass and the exact upstream source locations of the flawed logic are linked in the references; reported by VulnCheck, which published a matching advisory, and no EPSS data was supplied with this record.
Blind server-side request forgery (SSRF) in LLMGateway through 1.20.0 allows authenticated API key holders to force webhook POST requests to arbitrary internal targets via the video-generation callback_url parameter, which bypasses the assertSafeWebhookTarget check. Attackers can reach loopback, private RFC1918, or cloud metadata endpoints (169.254.169.254) from the worker's network, potentially exposing internal services or cloud credentials, though the blind nature limits data exfiltration to side effects of the POST request. No public exploit code has been identified at time of analysis, and exploitation requires a valid API key and use of the video feature.
Server-side request forgery in Casdoor's CAS proxy-validation handler (CasP3ProxyValidate in controllers/cas.go) lets a low-privilege authenticated user who already holds a valid CAS service ticket supply a crafted pgtUrl callback value and make the Casdoor server issue outbound HTTP requests to an arbitrary destination of the attacker's choosing. Only deployments that expose the CAS protocol endpoints and use CAS proxy authentication in versions up to 3.164.0 and 4.10.0 are affected, and because the pre-patch code fetches the attacker-supplied URL with http.DefaultClient.Do without destination validation, redirect restrictions, or a timeout, the practical impact is a blind or limited SSRF (some confidentiality exposure, no integrity or availability impact) rather than full compromise of internal services. Publicly available exploit code exists, but there is no confirmed active exploitation (no CISA KEV listing), and the assessed severity is genuinely low, so this is a low-priority hardening item for CAS-enabled Casdoor instances rather than an emergency patch; upgrading to 4.11.0 resolves it.
Server-side request forgery (SSRF) in elvix-sdk versions up to 0.10.1 allows remote attackers with low-privileged authenticated access to the MCP Request Handler to manipulate the 'path' argument in src/mcp/index.ts, causing the server to make arbitrary outbound requests. Publicly available exploit code exists, though no confirmed active exploitation has been observed. The vendor was contacted but did not respond, and no patch is available, leaving mitigation to compensating controls.
Server-side request forgery in Studio-Saelix Sencho up to 0.94.1 allows an authenticated user who can configure git sources to make the backend issue outbound HTTP/HTTPS connections to attacker-chosen internal addresses by manipulating the repo_url argument handled by outboundTarget.ts in the git-sources Browse API endpoint. Exploitation requires a valid session with git-source administration rights (CVSS 3.1 PR:L), and impact is limited to low confidentiality - internal request issuance and response exposure - with no integrity or availability effect; publicly available exploit code exists, though no confirmed in-the-wild activity has been reported. The vendor disputes the CVE characterization, arguing repository access to private LAN, VPC, VPN, CGNAT and IPv6 ULA ranges is an intentional administrative feature rather than a privilege-boundary bypass, while nonetheless shipping defense-in-depth hardening.
Server-side request forgery in Studio-Saelix Sencho up to 0.97.1 allows an authenticated user with node-management permission to supply a crafted URL to the Add Remote Node API endpoint, where the isValidRemoteUrl function in backend/src/utils/validation.ts fails to block server-side requests. Publicly available exploit code exists, and the CVSS 4.0 base score is 2.0; the independent assessment also rates this as a low-priority issue. Per the vendor, the issue demonstrates server-side request capability but not arbitrary internal response exfiltration, so confidentiality, integrity, and availability impact are limited.
Server-side request forgery in the Jawn webhook sender of Helicone (affected through v2025.08.21-1) allows authenticated organization users to create webhooks whose public hostnames resolve - or are DNS-rebound - to loopback or internal addresses, causing the Jawn backend to issue blind POST requests to internal HTTPS services. Rated 5.3 (CVSS 4.0 AV:N/AC:L/AT:N/PR:L/UI:N with only VI:L and no confidentiality, availability, or subsequent-system impact), the vulnerability yields integrity-side effects on reachable internal endpoints rather than data readback. Exploitation requires a valid account within a Helicone organization (PR:L) plus control of a hostname that can resolve or rebind to private space; there is no public exploit identified at time of analysis and CISA KEV does not list this CVE.
Server-side request forgery in Mealie 3.26.0 through 3.28.0 allows an authenticated OpenID Connect user to redirect the server's avatar-fetch routine to arbitrary ports on the configured identity provider's address, because the allowlist check validates only the provider hostname and ignores the port. The fetch fires as a server-side GET on each login, so the practical impact is limited to blind interaction and reconnaissance against services co-located on the already-trusted IdP host; the response body is not returned to the attacker. Exploitation requires Mealie to be configured for OIDC authentication (non-default for many deployments) and a valid account on the trusted IdP whose 'picture' claim the user controls, which is why this scores low (CVSS 4.0 base 2.3, independent assessment CVSS 3.1 4.x-equivalent severity). No public exploit code and no confirmed active exploitation were identified at time of analysis, and no vendor-released patch version is present in the available data.
Server-side request forgery in zotero-mcp 0.10.0 through 0.14.1 lets an unauthenticated attacker who successfully lands a prompt injection steer the connected LLM agent into calling the zotero_add_by_url tool with an attacker-chosen URL, which _fetch_embedded_metadata then fetches without any destination validation. Because redirects are followed, the resulting requests can reach loopback, RFC1918 private, or link-local addresses such as 169.254.169.254, leaking citation meta-tags and error details from internal services that are reachable from the MCP server's network position. Impact is confined to low confidentiality and integrity with no availability effect: exploitation requires the chained prompt injection to succeed (AT:P/UI:R) and an internal service to actually be reachable, and no public exploit identified at time of analysis.
Server-side request forgery in PDFMathTranslate (pdf2zh) through 1.9.11 lets unauthenticated remote attackers force the server to fetch arbitrary URLs supplied through the Gradio web GUI's Link (translate-from-URL) input, reaching internal services and cloud metadata endpoints with the fetched content returned inside the generated PDF. The flaw exists because the translate_file handler forwards user-controlled URLs to download_with_limit without validating the URL scheme or destination address, and the CVSS vector confirms no privileges (PR:N) and no user interaction (UI:N) are needed. Exploitation is gated primarily by exposure: the Gradio interface must be network-reachable and able to route to internal or link-local addresses, and impact is confined to information disclosure (VC:L, no integrity or availability effect) - there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis.
Server-side request forgery in Kortix Suna 0.10.7 through 0.13.51 allows an authenticated user holding the project.connector.write permission to bypass the isPrivateIp egress guard by encoding connector base_url, OpenAPI, Postman, or MCP endpoints as IPv6 6to4 (2002::/16) or Teredo (2001:0::/32) addresses whose embedded IPv4 points at an internal host or the 169.254.169.254 cloud metadata endpoint. Exploitation reaches internal-only services and metadata and returns the fetched responses to the attacker, but impact is capped at low confidentiality and integrity with no availability loss and no scope escape beyond the connector fetch path. Publicly available exploit code exists (a technical writeup linked from the CVE record), and the issue is fully remediated in v0.13.52; there is no confirmed active exploitation (CISA KEV) for this CVE.
An authenticated low-privilege user of openPDC can abuse the Modbus connection feature to make outbound connections to arbitrary internal destination addresses and ports, because the destination input is caller-controlled and not validated against any allow-list. The result is a server-side request forgery (CWE-918) condition that leaks reachability information - an attacker can distinguish which internal hosts and ports respond and, through repeated probes, gradually map the internal network - but no data theft, code execution, integrity, or availability impact is possible. The vulnerability is rated 5.3 under both the vendor's CVSS 4.0 vector and the independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting that valid credentials are mandatory and the only confirmed impact is limited confidentiality disclosure; there is no public exploit identified at time of analysis and no confirmed active exploitation.
Server-side request forgery in Dell Secure Connect Gateway (SCG) Policy Manager affects versions prior to 5.34.00.16, letting an attacker who already holds high-privilege access to the management interface coerce the appliance into issuing requests to attacker-chosen destinations. Because the CVSS vector carries PR:H, this is not reachable by anonymous or low-privileged users, and the impact is limited to information disclosure (C:H) with no integrity or availability effect; scope is changed (S:C), so the server can be pivoted toward internal or backend resources outside its own security boundary. No public exploit code or confirmed active exploitation was identified at time of analysis, and the underlying high-privilege prerequisite keeps this a moderate-severity, low-urgency issue rather than a top remediation priority.
Server-side request forgery in the Kirki WordPress plugin before 6.3.2 allows authenticated users holding editor-level privileges or above to supply a URL that the WordPress server then fetches without validating the target host, letting them probe internal-only services and infer from the responses which of those hosts are live. The issue is rated CVSS 4.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N), so impact is confined to information disclosure with no write, code execution, or denial-of-service capability, and exploitation requires a trusted privileged account rather than anonymous access. Publicly available exploit code exists and WPScan is credited as the reporting source, but there is no CISA KEV confirmation of active exploitation; combined with the high privilege prerequisite, the signals converge on a modest, non-urgent priority appropriate for routine patching alongside other plugin updates.
Server-side request forgery in Indico (all versions prior to 3.3.13) allows an authenticated event organizer to make the server fetch a prohibited local or internal URL by embedding a backslash in a crafted URL, and then read the target's response through affected Indico features. The vulnerability is a CWE-918 SSRF stemming from an incomplete fix for CVE-2026-25738; the trigger (demonstrated as 'http://127.0.0.1\@1.1.1.1') defeats Indico's local-target filter, which now rejects any URL containing a backslash. Exploitation requires the trusted event-organizer role (CVSS 3.1 PR:H, score 6.8, scope changed), there is no confirmed active exploitation (not in CISA KEV), and no public exploit code was identified at time of analysis.
Server-side request forgery in FFmpeg's RTSP handling (ff_rtsp_connect() in libavformat/rtsp.c) lets a malicious RTSP server answer with an RTSP 3xx redirect whose Location header points to an internal host and port under a different scheme, which the library then follows without validating the target - defeating the -protocol_whitelist control. Affected builds are FFmpeg before 7.1.4 and the 8.0.x line before 8.0.2; exploitation is unauthenticated per the CVSS 4.0 vector (PR:N) but requires a victim application or user to process the attacker-controlled rtsp:// source, and impact is bounded to probing/reaching internal services rather than data exfiltration or code execution. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis; vendor patches are available in 7.1.4 and 8.0.2.
Server-side request forgery in Pydantic AI's URL-fetching guards lets an application that has explicitly opted a URL into local-network access reach IPv6 cloud metadata endpoints such as fd00:ec2::254 and read short-lived cloud IAM credentials, because appending an RFC 4007 zone identifier (for example fd00:ec2::254%251) makes the address unequal to its blocklist entry while the kernel silently ignores the zone for a non-link-local destination and routes the request anyway. Affected releases are pydantic-ai and pydantic-ai-slim at 1.56.0 up to but not including 1.107.6, and 2.0.0b1 up to but not including 2.44.0; exploitation additionally requires that the URL be attacker-influenced or model-chosen, that one of the two opt-ins be enabled (FileUrl with force_download='allow-local', or web_fetch_tool(allow_local_urls=True) - both off by default), and an IPv6-enabled environment with a reachable metadata service. Vendor-released patches are available in versions 1.107.6 and 2.44.0 (upstream fix tracked via pull requests 8401 and 8402); no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
A domain-denylist bypass in Pydantic AI's local web-fetch tooling (web_fetch_tool and the WebFetch local fallback) lets an attacker-influenced model reach a host the operator explicitly placed in blocked_domains by supplying a DNS-equivalent spelling - an IDNA/fullwidth form, a non-ASCII label separator, a case variation, or a trailing root label - that does not string-match the configured entry but resolves to the same host. Affected are pydantic-ai and pydantic-ai-slim versions 1.77.0 through 1.107.5 and 2.0.0b1 through 2.44.0; the flaw is a denylist bypass only, so configurations that use allowed_domains fail closed and are unaffected, and the private-IP and cloud-metadata SSRF protections remain effective, meaning internal or metadata endpoints are not reachable through this bug. Rated CVSS 3.1 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) as a low-severity, high-complexity information-fetch issue, with no public exploit identified at time of analysis and vendor patches available in 1.107.6 and 2.44.0.
Server-side request forgery in IBM DataPower Gateway (10.5.0.0 through 10.5.0.22, 10.6.0.0 through 10.6.0.10, 10.6.1 through 10.6.6, and 11.0.0.0 through 11.0.0.2) lets an authenticated user who satisfies high-complexity preconditions make the appliance send requests to destinations of the attacker's choosing, enabling internal network enumeration and reconnaissance that can support follow-on attacks. Rated CVSS 4.9 (AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N), this is a moderate-severity, low-priority issue rather than an emergency: exploitation requires a valid authenticated session plus the ability to reach a request-handling function that accepts an attacker-influenced destination, and there is no public exploit identified at time of analysis, with real-world impact bounded by whatever sensitive internal hosts the gateway itself can reach. IBM has published an advisory covering these builds, and other versions are not in scope.
Server-side request forgery in LinuxServer Heimdall through 2.8.3 lets an unauthenticated attacker coerce the server into issuing HTTP requests to arbitrary internal hosts and ports, including the cloud metadata address 169.254.169.254, by inducing a victim with network reachability to the instance to load attacker-controlled content that triggers the CSRF-reachable POST /test_config or GET /get_stats endpoints (CVSS 3.1 base score 3.4, vector AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N). Publicly available exploit code exists, but there is no indication of confirmed active exploitation, and the author scopes the CSRF exposure to only 'some realistic installations' where those endpoints are reachable. The realistic impact is a status/port oracle plus partial response data - not full response exfiltration - and the cloud-metadata path additionally requires Heimdall to run on an instance exposing an unauthenticated metadata service.
Splunk MCP Server versions below 1.2.1 transmit the Splunk platform authentication token of the user who executes a custom API tool to whatever URL that tool is configured to call, so an attacker who can author a custom tool pointing at a server they control can capture the victim's token and then act as that user. Exploitation is authenticated and requires user interaction: the attacker needs privileges to create or configure a custom API tool, and a separate victim holding a role with the mcp_tool_execute capability must actively run that tool (CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:L/A:L). Real-world risk is moderate - it does not affect default deployments that make no use of custom API tools, and no public exploit has been identified at time of analysis. A vendor patch is available in Splunk MCP Server 1.2.1.
Server-side request forgery in Splunk Enterprise (below 10.4.3, 10.2.7, and 10.0.10) lets an authenticated user who holds a role with the read_o11y_content capability redirect an outbound request made by the Splunk App for Splunk Observability Cloud to an attacker-controlled host, thereby disclosing the configured Observability Cloud API token. The flaw exists because the app does not fully validate the destination of outbound requests; the request is triggered through the REST API, requires no user interaction, and is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), indicating a high-confidentiality but no integrity or availability impact. Exploitation is gated by a non-default capability, by the presence of the Observability Cloud app, and by an environment where an API token is configured; Splunk Enterprise 9.4.x is explicitly unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and a vendor patch is available.
Server-side request forgery in Gophish 0.11.0 through 0.12.1 allows authenticated, low-privileged users to force the server to fetch arbitrary internal URLs through the POST /api/import/site endpoint, because the default dialer deny list does not block loopback or RFC1918 private destinations. Attackers can read the responses of reachable internal services and enumerate internal hosts and ports from differential error messages, but the impact is confined to information disclosure with no write, code-execution, or availability effect, and authentication is mandatory (CVSS:4.0 PR:L / assessed CVSS:3.1 PR:L). Publicly available exploit code exists - documented in an Ostorlab review of Gophish 0.12.1 and tracked by VulnCheck - while the reported CVSS 4.0 score is a moderate 5.3 and no CISA KEV entry is present in the supplied intelligence, so this is confirmed as a moderate-severity issue rather than an emergency.
Server-side request forgery in LMCache through 0.5.5 allows unauthenticated remote attackers to bypass the frontend monitoring service's proxy allowlist by registering arbitrary host entries through POST /api/proxies, then relaying requests to internal systems via /proxy or /proxy2 and reading the responses back. Successful abuse also permits tampering with catalogued nodes and stopping the heartbeat mechanism, but the impact is bounded to limited information disclosure, limited integrity impact, and availability disruption rather than full host takeover. Exploitation is unauthenticated (PR:N, CWE-306) and requires only network reachability to the frontend monitoring service, so real-world risk depends heavily on whether that service is exposed beyond trusted internal ML-serving infrastructure; no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in the PowerPress Podcasting plugin by Blubrry (versions 11.13.12 through before 11.17.11) lets authenticated WordPress users with contributor-level access or higher supply a media URL that the plugin fetches server-side, following HTTP redirects to attacker-chosen destinations, and thereby probe or reach internal services. The flaw is a redirect-destination validation failure classified as CWE-918 with CVSS 4.1 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N per the assessed vector), so impact is limited to confidentiality-oriented access to internal endpoints with no direct write or code-execution path indicated. Publicly available exploit code exists for this issue, but there is no confirmed active exploitation (CISA KEV) and no evidence of a zero-day; the vendor has released a patch, and this is a moderate, not urgent, priority.
Server-side request forgery in the agent import functionality of Amazon Bedrock AgentCore Starter Toolkit versions before 0.3.14 allows an authenticated actor within the same AWS account to make the environment of a user importing a Bedrock Agent issue arbitrary outbound requests and read arbitrary local files. The attacker must supply crafted external reference values in the OpenAPI content associated with a Bedrock Agent action group, and exploitation requires the victim to actively import that agent; this narrow interaction requirement and the same-account authentication prerequisite limit the practical exposure, consistent with the vendor's Medium (CVSS 4.0 5.7) rating and our assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:R with high confidentiality impact only. No public exploit code has been identified at time of analysis, and no known active exploitation has been reported.
Server-side request forgery in Gitea's repository migration feature lets an authenticated user who is permitted to start migrations force the Gitea server to connect to reserved or link-local addresses, including the cloud metadata endpoint 169.254.169.254. The flaw only manifests in a non-default configuration where the administrator has set [migrations] ALLOWED_DOMAINS to a wildcard such as `*` or a hostname wildcard, which bypasses the intended ALLOW_LOCALNETWORKS = false protection because the local-network block list omitted reserved/link-local ranges and hostname allow-list matching was accepted irrespective of the resolved IP. Impact is bounded to reachability and read-style access from the server (no code execution or data modification), authentication is required per the CVSS vector (PR:L), and no public exploit has been identified at time of analysis, so this is a low-to-moderate priority issue whose real-world severity rises mainly where a reachable instance metadata service exists on the Gitea host.
Server-side request forgery (SSRF) in Arista CloudVision Portal allows an authenticated user with high privileges to manipulate the OIDC bearer token configuration and direct requests to arbitrary destinations. Affected versions include 2023.3.0 before 2025.3.0, 2025.3.0 through 2025.3.3, 2026.1.0 through 2026.1.2, and 2026.2.0. Exploitation requires pre-existing elevated access, limiting impact to subsequent-system confidentiality; no public exploit identified at time of analysis.
Server-side request forgery (SSRF) in Arista CloudVision Portal arises from insufficient validation of OIDC SSO provider configuration, allowing a user holding the specific high-privilege right to view and modify that configuration to direct CVP-originated requests to arbitrary destinations. The practical impact is limited rather than systemic: the CVSS 4.0 base of 5.1 and our independent CVSS 3.1 assessment (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) both reflect that the attacker must already be a highly privileged CVP administrator with network reach to the management interface, and that the consequence is a low-confidentiality information-disclosure primitive rather than code execution or service disruption. There is no public exploit identified at time of analysis and no confirmed active exploitation (SSVC: Exploitation=none, Automatable=no); a vendor patch is available via Arista security advisory 0186, and the main residual risk is abuse or takeover of an already-privileged administrative account.
URL injection and server-side request forgery (SSRF) in i18next-http-backend prior to 4.0.2 allows attacker-controlled language or namespace values to redirect translation resource requests away from the intended origin, but only when the application configures a custom loadPath or addPath template that begins directly with the {{lng}} or {{ns}} placeholder. Because the placeholder must occupy the URL's structural beginning for a colon to form an absolute URL (or, in browsers, a double-slash namespace to form a protocol-relative URL), the default '/locales/{{lng}}/{{ns}}.json' template and any template with a leading path or origin prefix are unaffected; this uncommon configuration and the need to control the language/namespace input drive the High attack complexity rating. Impact is limited to low confidentiality loss (blind SSRF/URL injection with no integrity or availability effect), and all signals indicate a low-priority issue - no public exploit code and no confirmed active exploitation were identified at time of analysis. The issue is fixed in version 4.0.2.
Authenticated device registration in Microsoft UFO versions prior to 3.0.9 can be abused to make the server open WebSocket connections to internal hosts, because pinned-address enforcement is applied only to the initial destination while the underlying websockets client still follows HTTP redirects. An attacker with valid credentials who can supply a device server_url that passes Galaxy's URL validation can then have that endpoint return a 301/302/303/307/308 redirect to an internal address, causing a cross-origin TCP connection and WebSocket upgrade handshake to be sent before peer-IP validation runs. The impact is limited to the internal connection and handshake request - no arbitrary HTTP methods, response-body disclosure, completed AIP session, or cloud metadata access - and this is a medium-severity (CVSS 6.4) SSRF whose real-world priority is modest rather than urgent; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Server-side request forgery (SSRF) in Django's GeoDjango spatial lookups allows remote unauthenticated attackers to make the Django process issue outbound network requests when an application passes attacker-controlled `bytes` raster values directly into a lookup against a `RasterField`. Affected versions are Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18; older unsupported series (5.1.x, 5.0.x, 4.2.x) were not evaluated and may also be affected. The flaw is an incomplete fix for CVE-2026-15307, and exploitation requires a deployment that uses GeoDjango raster fields and forwards raw untrusted bytes into spatial lookups - not a default Django configuration. There is no public exploit identified at time of analysis and the issue is not in CISA KEV; Django rates it 'moderate' severity (CVSS 5.3), with impact limited to attacker-directed outbound requests rather than data compromise or code execution.
Request forgery in MongoDB Controllers for Kubernetes allows an authenticated user who can modify an OpsManager custom resource to cause unintended administrative changes in Enterprise Ops Manager when backup reconciliation is enabled. The flaw involves insufficient escaping of Ops Manager backup store identifiers when the controller builds admin API request paths. It is a low-severity issue with no public exploit identified at time of analysis, and the vendor fixed it in MongoDB Controllers for Kubernetes 1.13.0.
Server-side request forgery in O2OA up to and including 10.0.1-ce lets an authenticated, low-privileged user force the application server to issue outbound HTTP requests to attacker-chosen destinations by supplying a crafted fileUrl argument to the ActionUploadExcelWithUrl handler in the General Module. Publicly available exploit code exists and the flaw is remotely reachable, but impact is limited to low confidentiality exposure (CVSS 3.1 base of 2.1, PR:L, C:L with no integrity or availability effect), so this is a low-priority issue despite the SSRF classification. The vendor was notified through a GitHub issue report and has not responded, so no patched release is identified at time of analysis.
DYMO ID 1.5.1.71 and earlier automatically parse job files with DTD processing enabled, allowing a crafted file placed on a browsed network share to trigger XML external entity (XXE) processing. This can lead to SSRF, NTLMv2 credential capture, local file disclosure, or process crash, though the independent assessment notes impact is bounded and does not include arbitrary code execution. No public exploit code has been identified at time of analysis, and the vendor released a fix in version 1.6.0.
Server-side request forgery in Penpot before 2.18.0 allows an authenticated user who controls a media-import URL, or an administrator who controls a webhook URL, to reach internal and cloud-metadata endpoints by supplying IPv6 transition addresses (NAT64 64:ff9b::/96, 6to4 2002::/16, or Teredo 2001:0000::/32) that embed a blocked IPv4 destination such as 169.254.169.254, 127.0.0.1, link-local, or RFC1918 addresses. The bypass works because the backend blocklist app.util.ssrf/blocked-address? applies its extra CIDR checks only to IPv4 values and relies on Java InetAddress predicates that do not classify transition-mechanism addresses; exploitation further requires the request to traverse a NAT64 gateway or the attacker to control a DNS AAAA record the Penpot server resolves, with cloud environments that already run DNS64/NAT64 directly exploitable, while non-NAT64 deployments depend on the harder attacker-controlled AAAA path. Media import can disclose response bodies, whereas webhook delivery exposes only response status as a network-probing side channel, and there is no public exploit identified at time of analysis. Penpot 2.18.0 is the vendor-released fix (commit 326d83e780ae120b45ccd6f3d7bd24922b54461c).
Server-side request forgery in the Ghost CMS webhooks feature (versions 1.18.0 through releases prior to 6.27.0) allows an authenticated staff user who can create or edit webhooks to point a webhook target_url at internal hosts and force the Ghost server to issue requests to them. The CVSS vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, score 2.7) confirms this is a network-reachable but privileged-account-required issue whose impact is limited to low confidentiality loss - blind or semi-blind probing rather than response retrieval or code execution - and there is no public exploit identified at time of analysis. Ghost 6.27.0 fixes the issue by routing webhook delivery through a request library that blocks internal IPs unless the operator explicitly opts in via a new configuration flag.
Server-side request forgery (SSRF) in Ghost CMS versions 6.0.9 through 6.64.x lets an unauthenticated remote attacker induce the server to issue limited HTTP requests to hosts on its internal network. The flaw is blind - no response body is ever returned to the attacker - so the practical value is confined to request-triggered side effects and liveness/timing inference rather than data exfiltration, and exploitation depends on the target deployment actually having reachable internal hosts (e.g. NAT64/DNS64 setups or flat internal networks). The vendor fixed the issue in Ghost 6.65.0; no public exploit code has been identified at time of analysis and the flaw is not listed in CISA KEV, consistent with the assessed CVSS 3.1 score of 4.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N).
Server-side request forgery (SSRF) in Event Gallery for Joomla before 6.6.0 allows an attacker to make the server send the Google Photos OAuth access token to an arbitrary address or probe internal network resources. The vulnerability resides in the back-end upload page's Google Photos picker, which fetches image thumbnails using a user-supplied address without validation and without a form token, enabling exploitation via CSRF against a logged-in administrator or directly by a back-end user with 'Manage' permission. No public exploit code has been identified, and the risk is assessed as moderate and targeted.
Server-side request forgery in LibreOffice on Linux can expose local files and internal or remote URLs when a document links to a crafted HLS media playlist and the victim opens it and permits link updates. LibreOffice relies on the GStreamer media backend on Linux to play linked audio and video; a malicious playlist's listed resources were fetched while the document loaded and their contents could be written into the document, yielding confidentiality impact (VC:H, SC:H) with no integrity or availability impact in the assessed CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N). The issue is moderate severity and interaction-dependent rather than an urgent priority; no public exploit code and no confirmed active exploitation (no CISA KEV listing) were identified at time of analysis, and exploitation is constrained to Linux installations using the GStreamer backend.
LibreOffice Calc on affected versions automatically fetched external CSV data links embedded in a spreadsheet while the document loaded, so an attacker-crafted Calc file could read a local file into a sheet or force a request to a host of the document author's choosing (SSRF, CWE-918). Exploitation is local and interaction-gated - the attacker must deliver the malicious document and the victim must open it - and the flaw affects confidentiality only, with no impact on integrity or availability. No public exploit code and no confirmed active exploitation were identified at time of analysis; the vendor addressed it by placing external data links under the same link-update control that governs other spreadsheet links.
Server-side request forgery in feelec-yishu feelcrm-os 1.0.0 allows unauthenticated remote attackers to make the application's server issue attacker-controlled HTTP requests through the getCurlData endpoint in App/Feelcrm/Index/Controller/GoogleController.class.php, by manipulating the 'url' argument. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms this is remotely reachable, low-complexity and requires no authentication or user interaction, while impact is uniformly LOW (VC:L/VI:L/VA:L) with no scope change, making it a limited-impact SSRF rather than a full internal pivot or credential-theft primitive. Publicly available exploit code exists and the issue was reported to the project, which has not yet responded with a fix; no confirmed active exploitation (CISA KEV) has been observed.
Server-side request forgery (SSRF) in Shaarli up to 0.16.3 allows an attacker who can reach the admin-only MetadataController endpoint to make the server fetch arbitrary HTTP(S) URLs, including those resolving to private, loopback, link-local, or reserved addresses. Exploitation requires either an authenticated administrator session (PR:H) or tricking a logged-in admin into triggering the request, which was feasible before the fix because the endpoint did not validate a CSRF token; the pre-patch code also only checked that the URL scheme contained the substring 'http' and performed no IP validation. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis; a vendor patch is available in version 0.16.4.
Server-side request forgery (CWE-918) in ChatGPTNextWeb NextChat up to and including 2.16.1 lets an unauthenticated, remote attacker who can reach the /api/proxy endpoint (the Proxy Fallback Handler) redirect the server's outbound HTTP requests to arbitrary hosts by supplying a crafted x-base-url header. Because the hostname is concatenated into the server-side fetch target without any validation against private, loopback, link-local, or cloud-metadata ranges, a successful attack can reach internal-only services or instance-metadata endpoints, with impact bounded by what the host's network position can actually reach. Publicly available exploit code exists (referenced GitHub issue #6813), but there is no confirmation of active exploitation; the fix is an unmerged pull request (#6884) that awaits acceptance, so no released patched version is independently confirmed and the risk should be treated as a genuine but medium-tier issue rather than an emergency.
Blind server-side request forgery in the X.509 client-certificate authenticator of Keycloak (and the downstream Red Hat Build of Keycloak and Red Hat Single Sign-On 7) lets an unauthenticated remote attacker induce the server to make outbound requests to URLs specified in a crafted client certificate, before that certificate has been fully validated. The flaw is reachable only when X.509 client-certificate authentication is enabled and certificate revocation checking via CRL Distribution Points or OCSP is configured - a non-default setup, which is why the assessed vector carries AC:H despite PR:N/UI:N. Impact is limited to low confidentiality (the SSRF is blind and no response content is returned to the attacker), and no public exploit has been identified at time of analysis.
Zitadel deployments before 4.16.2 expose a server-side request forgery (SSRF) path in the organization custom-domain HTTP verification flow, where the challenge fetch uses Go's default http.Get rather than Zitadel's SSRF-protected HTTP client. An authenticated principal holding privileges to create or manage an organization and register a custom domain can point DNS/HTTP for that domain at loopback, RFC1918/internal, or link-local cloud metadata addresses (e.g., 169.254.169.254), causing the Zitadel server to issue requests to those targets and enabling port scanning and internal network mapping. Impact is limited to server-side reconnaissance - there is no data modification, and confidentiality exposure depends on what internal or metadata services are actually reachable from the instance - and no public exploit code has been identified at time of analysis; EPSS and KEV signals are absent, and the scored severity is low (CVSS v4.0 base 2.3; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N).
Unauthenticated remote attackers can exploit a server-side request forgery (SSRF) in SciPhi-AI R2R 3.6.6 and earlier by supplying a crafted generation_config.api_base value to the Retrieval Completion API endpoint, causing the server to make requests to arbitrary internal or attacker-controlled URLs. Publicly available exploit code exists (a GitHub Gist), and the vendor did not respond to disclosure, so no patched version is confirmed at time of analysis. The independent assessment rates this as medium severity (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L; VulDB CVSS 4.0 score 6.9), with impact bounded by what internal targets the R2R server can reach.
Server-side request forgery in Open Identity Platform OpenAM before 16.1.3 allows an authenticated attacker holding the privilege to register or modify OAuth 2.0 / OpenID Connect clients to make the OpenAM server fetch arbitrary internal resources through an unvalidated client jwks_uri. The vulnerable dereference occurs on the OIDC client-authentication and ID-token validation paths, so the resulting fetches are made by OpenAM itself and can be aimed at internal hosts, cloud metadata endpoints or local files, or abused to consume request threads for a low-impact denial of service. Exploitation requires PR:L per the assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L (CVSS 4.0 base 5.3); no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
Server-side request forgery (SSRF) in Zilliz Attu before 3.0.0 allows remote attackers to proxy requests to private IP addresses via the Playground feature. This is a moderate-severity, not high-priority, issue: exploitation requires network access to an Attu instance's Playground feature, which proxies user-supplied requests without validating the destination; the CVSS vector indicates unauthenticated access (PR:N) with no user interaction, but real-world authentication enforcement is not confirmed. No public exploit identified at time of analysis.
Server-side request forgery in UTMStack before 11.2.16 lets any authenticated user (even a low-privilege one) coerce the web-pdf microservice into fetching an arbitrary URL by supplying an unvalidated url parameter to GET /api/generate-pdf-report, with the fetched response rendered back into the returned PDF. A successful attack exposes internal-only resources the container can reach - backend APIs, the OpenSearch cluster, or a cloud instance-metadata endpoint (169.254.169.254) - making credential theft the highest-impact outcome on cloud-hosted deployments; there is no code execution, no data modification, and exploitation requires a valid UTMStack session (CVSS vector PR:L, so authentication is required). No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (not in CISA KEV); the CVE carries a CVSS 4.0 score of 6.3, while our independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) rates it High, with real-world impact gated by the server's network reachability to the targeted internal resource and, for the metadata path, by the instance running in a cloud environment.
Server-side request forgery (SSRF) in UTMStack before 11.2.16 is a genuine but moderate-severity issue rather than a top-tier emergency: an authenticated user who can reach the POST/PUT /api/identity-providers endpoint can supply a crafted metadata URL that IdentityProviderService.validateMetadataUrl() accepts without validating target host, IP, or scheme, causing the server to issue attacker-directed requests to internal or cloud metadata hosts. The practical consequence is internal network reconnaissance and port scanning, plus exposure of cloud instance-metadata services such as 169.254.169.254 when UTMStack is deployed in a cloud environment; impact is otherwise confined to confidentiality (scope-changed C:L/I:N/A:N) and is gated by the requirement for a valid UTMStack account (PR:L). No public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the vendor has released version 11.2.16 as the fixed version.
Authenticated server-side request forgery (SSRF) in ThemeREX Addons versions up to 2.46.0 allows any logged-in WordPress user with low privileges to force the server to make arbitrary HTTP requests, potentially reaching internal services or cloud metadata endpoints. The CVSS 6.4 rating reflects limited confidentiality and integrity impact, and exploitation requires the plugin to be active and an attacker to hold a valid low-privilege account. No public exploit identified at time of analysis.
Server-side request forgery and cross-site scripting in YesWiki before 4.6.7 allow an authenticated page editor to abuse the Bazar 'valeur' action to make the server fetch arbitrary URLs, including loopback and internal addresses, and to inject unescaped remote HTML that executes script in a victim's browser. Exploitation requires an editor-level account (CVSS PR:L) and, for the XSS half, a separate victim viewing the poisoned page, so anonymous remote exploitation is not possible; no public exploit identified at time of analysis. Risk is medium severity per the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, and a vendor-released fix is available in 4.6.7.
Server-side request forgery in Redash 10.0.0 through 26.9.0 allows an authenticated user holding execute_query permission on a JSON data source to redirect the query runner's HTTP request to an arbitrary external origin. The flaw stems from the use of urljoin in redash/query_runner/json_ds.py, which lets an absolute query URL replace the configured base_url instead of remaining bound to it; when the data source is configured with HTTP Basic Auth, those stored credentials are also forwarded to the attacker-selected origin, creating a credential-exfiltration path. Private and internal address access remains constrained while REDASH_ENFORCE_PRIVATE_IP_BLOCK is enabled, which limits but does not eliminate the impact; there is no confirmation of active exploitation (CISA KEV) and no public exploit code identified at time of analysis, and the assessed risk is a genuine but moderate-severity SSRF rather than an emergency.
Server-side request forgery in Portkey AI Gateway 1.14.0 through 1.15.2 lets unauthenticated remote attackers make the gateway issue requests to loopback and Docker host services and return the responses to the caller. The flaw exists because the isValidCustomHost check trusts localhost-style hostnames whenever the TRUSTED_CUSTOM_HOSTS environment variable is unset, which is the default configuration; an attacker only needs to send a /v1 request carrying a crafted x-portkey-custom-host header (for example via the ollama provider). Publicly available exploit code exists for this issue and it is not listed in CISA KEV, so exploitation activity is not confirmed; the assessed impact is limited to confidentiality and integrity of services reachable from the gateway host, with no availability or code-execution impact.
When OpenID sign-in is enabled, Gitea processes unauthenticated assertion parameters and sends an HTTP POST request to the caller-supplied OpenID provider endpoint during verification. An attacker controls the destination and much of the form body, allowing interaction with internal HTTP services reachable from the Gitea server. The response is not returned to the attacker, so the issue is blind SSRF; its impact depends on the services and network addresses the server can reach.
Server-side request forgery in Gitea lets an unauthenticated remote attacker cause the server to contact loopback or private-network HTTP services by supplying a crafted OpenID URL when OpenID sign-in is enabled. Affected deployments are vulnerable Gitea releases such as 1.25.4 (CPE wildcard all versions) that have deliberately enabled ENABLE_OPENID_SIGNIN and lack destination restrictions; the vendor patch changes that setting to default false and adds a built-in blocklist for localhost, loopback, private ranges, and IPv6 link-local addresses. Publicly available exploit code exists and the issue is automatable, but no CISA KEV active-exploitation confirmation is present, and the assessed CVSS is 5.3 with only low confidentiality impact.
Server-side request forgery in the yudao-module-ai image service of ruoyi-vue-pro (through 2026.09) lets an authenticated user make the application server issue HTTP requests to arbitrary destinations by supplying the referImageUrl parameter to the Midjourney 'imagine' endpoint, which is handed to Hutool's HttpUtil.downloadBytes() without SSRF filtering. Exploitation requires a valid low-privileged application account with access to that AI image feature (CVSS 4.0 base 5.3, PR:L), so there is no unauthenticated attack path; the practical payoff is internal reconnaissance and information disclosure - probing loopback, RFC1918, and cloud metadata endpoints such as 169.254.169.254 - rather than code execution. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV, making this a moderate-priority finding whose real-world severity rises sharply on cloud-hosted deployments that expose IMDSv1 or internal-only administrative services.
Server-side request forgery in ONLYOFFICE DocumentServer before 10.0.0 lets unauthenticated remote attackers coerce the server into fetching arbitrary internal, loopback, and cloud-metadata URLs through the /downloadfile/:docid endpoint and proxy the responses back to the requester. The flaw is reachable in the default configuration because JWT verification is disabled out of the box and a crafted request body setting the isInJwtToken flag causes the fetch to be processed as a DIRECT request, skipping the private-address request-filtering-agent; instances that have explicitly enabled JWT verification are not exploitable through this path. No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV, but the highest-value impact is on cloud-hosted deployments where reachable metadata services can expose IAM credentials, making this a genuine but moderate-priority issue (CVSS 6.3) rather than a critical emergency.
Contributor-level WordPress users can abuse the FV Flowplayer Video Player plugin's server-side URL fetch routine to probe internal network resources, because the plugin fails to properly validate a user-supplied URL and its existing host-based restriction does not cover every case. Only sites running versions 7.5.44.7212 through 7.5.55.7212 that grant untrusted users Contributor access or above are realistically exposed, and the payoff is a semi-blind oracle: the attacker learns whether an internal host or service responds and its HTTP status code, but never sees the response body, making this a reconnaissance primitive rather than a data-theft vector. Exploitation is authenticated and requires the plugin's URL-based media fetch feature, EPSS is a negligible 0.16 percent (5th percentile), SSVC records no observed exploitation and no automatable path, and while publicly available exploit code exists there is no evidence of active exploitation in the wild; the vendor has shipped a patch in 7.5.55.7212, and this remains a genuinely low-priority issue.
Server-side request forgery in the Azure Arc Connected Machine Agent (versions 1.0.0 up to but not including 1.68) lets an already-authenticated, low-privilege actor induce the agent to fetch attacker-influenced URLs, reaching internal or cloud-metadata endpoints and returning data that can be used to elevate privileges over the network. The issue is confidentiality-only per the assessed vector (C:H/I:N/A:N) and requires network reach plus an existing low-privilege foothold - an unauthenticated attacker cannot exploit it - and no user interaction is needed. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, and vendor patching to agent 1.68 or later removes the exposure.
Server-side request forgery in Microsoft SharePoint Server Subscription Edition lets an authenticated remote attacker with low privileges coerce the SharePoint server into making requests to destinations of the attacker's choosing, exposing information held on network-accessible resources that the server can reach (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). Because the vector specifies PR:L, a valid low-privileged session on the affected build (16.0.0 before 16.0.20326.20190) is required and unauthenticated exploitation is not indicated; no user interaction is needed. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis, so this is a medium-priority, confidentiality-only issue whose urgency is driven by how widely low-privileged accounts are granted and whether the farm is internet-exposed.
Server-side request forgery in Finsys Dockhand before 1.0.45 lets an authenticated low-privilege user redirect outbound requests to internal services by smuggling private, loopback, or cloud-metadata IPv4 addresses inside NAT64, 6to4, or Teredo IPv6 transition literals. The flaw lives in the ipCategory() function of src/lib/server/url-safety.ts, which does not classify IPv6 transition ranges as private, so any of the notification, backup, template, registry, git, or secret-provider URL fields can be abused as an SSRF vector. Rated 5.3 (CVSS 4.0; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N), this is a genuine but moderate-priority issue rather than a critical one: exploitation requires an authenticated account, network reachability from Dockhand to the target service, and - for the highest-impact credential-theft scenario - a cloud deployment exposing the 169.254.169.254 metadata endpoint. No public exploit code has been identified at time of analysis, and the vendor has released a fix in 1.0.45.
SSRF protection bypass in the Lancet Go library's netutil.IsInternalIP allows applications that use this helper as their allow/deny filter to fetch internal services and cloud metadata endpoints via IPv6 and transition address forms the function misclassifies as external. Affected releases are Lancet 1.3.1 through 1.4.6 and 2.1.2 through 2.3.9; the function must be consumed by a server-side fetch path that accepts attacker-controlled hostnames, which is why the issue is assessed as moderate priority rather than emergency (CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N, CVSS 4.0 base 6.3). Publicly available exploit code exists (SSVC Exploitation: poc) and an unauthenticated, remote attacker providing hostnames that resolve to fd00::/8, fe80::/10, 100.64.0.0/10, or NAT64/6to4/Teredo encodings of internal IPv4 can reach otherwise unreachable targets; exploitation is not reliably automatable at scale (SSVC Automatable: no) and no confirmed active exploitation (CISA KEV) has been reported.
Server-side request forgery in Shaarli through 0.16.9 lets a logged-in user force the server to issue blind GET requests to loopback, RFC 1918, or link-local cloud-metadata addresses by creating a bookmark whose URL is fetched for thumbnail generation. The practical barrier is authentication (the supplied CVSS 4.0 vector is PR:H; the independent assessment scores it PR:L under CVSS 3.1), and that barrier disappears when the open_shaarli configuration setting is enabled, at which point any unauthenticated visitor can trigger the fetch. Scoring is moderate (base 5.1, confidentiality-only, no integrity or availability impact) and the effect is blind - no response is returned to the attacker - but real-world risk rises sharply on cloud-hosted instances that can reach internal metadata endpoints; no public exploit code and no CISA KEV entry were identified at time of analysis.
Server-side request forgery in Kavita 0.9.0 through 0.9.1.4 allows an authenticated user with permission to use the CBL import feature to submit a URL to POST /api/Cbl/upload-cbl-file and, by winning a DNS-rebinding race or following an HTTPS redirect, bypass the SSRF blocklist so the server probes internal ports or services blindly. Exploitation requires authentication and a time-of-check/time-of-use precondition, is limited to low confidentiality impact, and no public exploit identified at time of analysis; KEV and EPSS data were not provided. This is a confirmed CWE-918 SSRF but a low-severity, low-priority issue per the independent assessment.
Razorpay IFSC Ruby gem through version 2.0.62 is affected by a server-side request forgery (SSRF) vulnerability. Unauthenticated remote attackers can supply a crafted IFSC code to IFSC.find or IFSC#get - such as a network-path reference (//evil.host) or an absolute URI - that Ruby's URI.join resolves as a new host, redirecting API requests to internal or attacker-chosen hosts and returning parsed response fields. Exploitation requires the consuming application to pass untrusted input directly to these methods; impact is limited to low confidentiality (CVSS 4.0 base 6.9) with no write or availability effect, and no public exploit has been identified at time of analysis.
Server-side request forgery in Microsoft SharePoint Server Subscription Edition (builds below 16.0.20326.20190) lets an authenticated attacker who can reach the server from an adjacent network segment make the SharePoint front end issue requests on their behalf, exposing internal services and data (CVSS 5.7, AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, confidentiality-only impact). Low-privilege credentials and adjacency are both mandatory preconditions, so unauthenticated internet-based attackers are excluded, and no user interaction or race conditions are involved. A vendor patch is available, no public exploit code has been identified at time of analysis, and no confirmed active exploitation (CISA KEV) has been reported, making this a patch-management priority rather than an emergency.
Missing authorization in Jorani's Contracts::import() handler lets any authenticated user, including a low-privilege one, submit a contract id plus an arbitrary URL over POST to import days off into any contract, overwriting its non-working-day calendar and driving server-side requests into internal networks. The flaw is present in default installations of Jorani before 1.0.4, where the import action lacks the isAllowed('adddayoff_contract') permission check that v1.0.4 introduces, so no non-default configuration is required. Exploitation requires a valid Jorani session and is network-reachable with no user interaction (CVSS 4.0 base 5.3 Medium; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N with limited confidentiality and integrity impact); no public exploit code identified at time of analysis.
Server-side request forgery in Conductor OSS through 3.33.0-rc10 lets remote attackers influence the kafka_request.bootStrapServers argument handled by KafkaPublishTask.start in the Kafka contrib module, causing the Conductor server to connect to an attacker-chosen Kafka bootstrap endpoint. The issue is CWE-918; VulDB rates it CVSS 4.0 5.5, while our independent assessment uses CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:N/C:L/I:L/A:L and characterizes the practical impact as low, with publicly available exploit code existing but CISA KEV active exploitation not indicated in the provided data. Although the CVSS vector is PR:N, practical exploitation requires that the Kafka contrib module is deployed, that a usable KafkaPublishTask exists, and that the attacker can create or execute a workflow/task controlling the bootstrap-servers argument, so deployments that enforce authentication/authorization on workflow submission or are not internet-exposed are substantially less exposed.
Server-Side Request Forgery (SSRF) protection bypass exists in the UrlImageConverter component of Apache Fesod (Incubating) fesod-sheet 2.0.2-incubating, where an attacker who controls DNS responses for an attacker-supplied image URL can use DNS rebinding to slip past hostname IP validation and force the outbound fetch to reach a restricted internal address. The vulnerability is unauthenticated per the assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N) and is rated moderate because it requires the application to actively accept untrusted remote image URLs for spreadsheet writing and the attacker to win the time-of-check/time-of-use window between validation and connection; impact is limited to low confidentiality with scope change and no integrity or availability effect. There is no public exploit identified at time of analysis, and the vendor-released fix is Apache Fesod (Incubating) 2.1.0-incubating, which disables remote URL image fetching by default and requires an explicit exact-host allowlist when enabled. This issue is distinct from CVE-2026-49328, which covers the earlier SSRF in releases before 2.0.2-incubating.
Server-side request forgery in conductor-oss Conductor through 3.33.0-rc10 allows unauthenticated remote attackers to induce the Agentspan Agent Runtime to make crafted requests to arbitrary URLs via AgentController.java (CWE-918). The assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) limits impact to confidentiality only, and the CVSS 4.0 vector's E:P metric indicates publicly available exploit code exists; no CISA KEV listing or confirmed active exploitation was provided. Realistic risk is moderate and hinges on whether the Conductor instance is internet-facing and what internal services or cloud metadata endpoints are reachable from the server.
Server-side request forgery in Conductor OSS through 3.32.5 allows unauthenticated remote attackers to force the server to fetch attacker-controlled URLs through the A2A Agent Card Fetching endpoint when the AI/a2a feature is enabled and reachable. The vulnerable path is A2AService.getAgentCard, where the agentUrl argument can be manipulated to reach internal services; publicly available exploit code exists, but no confirmed active exploitation (CISA KEV) is indicated. The independent assessment rates this as moderate with low confidentiality, integrity, and availability impact, and exploitation is realistic only where the A2A agent-card functionality is exposed.
Server-side request forgery (CWE-918) in the MCP Service of conductor-oss Conductor 3.22.0 lets an authenticated low-privilege user who can invoke the listTools operation supply a crafted mcpServer argument and cause the Conductor server to issue requests to attacker-chosen destinations. The impact is scored low (CVSS 4.0 base 2.1; independent assessment CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) because authentication is required, the vulnerable path is only reachable when the MCP integration is enabled and exposed, and there is no scope change to downstream systems. Publicly available exploit code exists for this issue, but there is no confirmation of active exploitation, and no EPSS or CISA KEV data was provided.
Server-side request forgery in conductor-oss Conductor 3.31.2 allows an authenticated low-privileged user to force the server to issue outbound HTTP requests to attacker-chosen destinations by supplying a crafted specUrl when defining an API tool, since ListApiToolsTask.start processes that argument without validating or restricting the target address. Successful abuse can expose internal-only services, loopback interfaces, and cloud instance metadata reachable from the Conductor host, with the assessed CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:N/C:L/I:L/A:N) reflecting limited confidentiality and integrity impact and no availability effect. Publicly available exploit code exists and the flaw is disclosed via VulDB; there is no indication of confirmed active exploitation (not in CISA KEV), and exploitation requires a valid low-privileged account that can create or modify API tool definitions plus a network position where internal targets are actually reachable.
Server-side request forgery in Fit2Cloud MeterSphere up to 3.6.9-lts allows an authenticated low-privilege user to make the server issue outbound HTTP requests to an attacker-chosen URL by manipulating the swaggerUrl argument handled by Swagger3ParserApiDefinition.testUrlTimeout in the Swagger3 API-definition import component. Publicly available exploit code exists and the vendor was contacted but did not respond, so no fix is confirmed; the flaw is network-reachable (AV:N) and needs no user interaction, but it requires valid credentials plus access to the API-import feature, which keeps it a moderate priority rather than an urgent one. Real-world impact depends on what the MeterSphere host can reach internally - internal services, admin interfaces, or cloud metadata endpoints - and the assessed impact is limited to low confidentiality exposure (C:L, I:N, A:N).
Server-side request forgery in GitLab CE/EE (all versions from 10.3 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2) allows an authenticated user with repository import rights to reach internal network resources by winning a time-of-check to time-of-use race condition in the URL validation performed during import operations. The base score is low (CVSS 3.1 3.5, AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N): the attacker must repeatedly race the validation and fetch windows, so the flaw does not trigger reliably and yields only limited confidentiality impact with no integrity or availability effect. There is no public exploit identified at time of analysis and no confirmed active exploitation; the primary risk is limited internal-network reconnaissance or access to internal services from a GitLab instance that can route to them.
Server-side request forgery in EricLBuehler mistral.rs 0.9.3 and earlier allows remote unauthenticated attackers to bypass the private-IP guard used by the server's media-source fetcher, causing the server to request internal addresses such as loopback, link-local, or cloud metadata endpoints. The flaw lives in the is_global_ip/reject_private_ip logic in mistralrs-server-core/src/media_source.rs, which failed to decode IPv6 transition-address forms (IPv4-mapped, IPv4-compatible, 6to4, and NAT64) that embed an internal IPv4 address, so those addresses were judged global and fetched. Publicly available exploit code exists, and the issue is rated CVSS 4.0 6.9 (our independent assessment is a lower-severity SSRF with low confidentiality impact and no integrity or availability impact); no confirmed active exploitation (CISA KEV) was identified at time of analysis. Exploitation is only meaningful where remote media-URL fetching is enabled and reachable internal services exist.
Server-side request forgery in Frappe ERPNext (before 15.112.0 and 16.x before 16.23.0) allows an authenticated user holding a common operational role to point a writable configuration field at an arbitrary destination, causing the ERPNext server to issue outbound requests to hosts that are only reachable from inside the deployment's network. The issue is rated CVSS 5.3 and requires a valid session with permissions to edit the affected field (PR:L), so it is not exploitable by fully unauthenticated attackers; real-world impact depends entirely on what internal services - such as cloud metadata endpoints, internal APIs, or databases - are reachable from the application server. No public exploit code has been identified and the flaw is not confirmed as actively exploited (no CISA KEV listing); per our assessment this is a moderate, not urgent, priority that is fully resolved by upgrading to a fixed release.
Server-side request forgery and local file inclusion in Frappe Framework 15.x before 15.107.3 and 16.x before 16.17.0 allow an authenticated user who can render user-controllable content to PDF to make the server fetch internal resources or embed local server files into the resulting PDF. The root cause is Frappe's dependency on a vulnerable version of the pdfkit library (CVE-2025-26240), which resolves external URLs and file references during server-side PDF rendering. The assessed vector is network-accessible but requires a valid Frappe account with access to a PDF-generating feature (print formats, templates, or report-to-PDF flows), and impact is limited to confidentiality; it is a medium-severity, low-priority issue for most deployments, and no public exploit was identified at time of analysis.
Server-side request forgery in SPIP before 4.4.18 lets an authenticated user with access to remote-fetching features (such as syndicated site feeds or remote document imports) force the CMS to retrieve internal or link-local resources, including cloud metadata endpoints like 169.254.169.254. The root cause is that recuperer_url() in ecrire/inc/distant.php follows up to 10 HTTP redirects without re-invoking valider_url_distante(), so a benign external URL that passes validation can redirect to a target that would otherwise be blocked. Exploitation requires valid credentials (CVSS:4.0 PR:L) and attacker-controlled or attacker-influenced external hosting; impact is confidentiality-only and read-oriented, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in Red Hat Quay allows an authenticated repository administrator to bypass the hostname blacklist enforced by the webhook notification feature, causing the Quay application to issue HTTP requests to attacker-chosen internal destinations such as cloud metadata endpoints or in-cluster services. Successful exploitation can disclose sensitive information returned by those internal services, though the CVSS 3.1 score of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) reflects a moderate impact: the attacker must already hold a privileged in-application role, must use the webhook functionality, and the yield is bounded by which internal endpoints the Quay pod can actually reach. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw is tracked by Red Hat under CVE-2026-85471 with all Quay 3 and Mirror Registry offerings listed as affected via wildcarded CPEs.
Blind server-side request forgery in Crawl4AI before 0.9.4 lets unauthenticated remote attackers bypass Docker egress controls via the RobotsParser.can_fetch robots.txt fetch path, using HTTP redirects or DNS rebinding to reach loopback, internal, and cloud-metadata addresses for service discovery. Rated CVSS 4.0 6.9 (Medium), exploitation requires the check_robots_txt behavior to be in effect when the service processes an attacker-influenced target URL, which makes the Docker service being reachable by untrusted callers a precondition. The SSRF is blind, so responses are not returned to the attacker, keeping confidentiality impact low; no public exploit code or confirmed active exploitation was identified at time of analysis.
Authenticated users on LogicalDOC Community Edition through 9.3 can abuse the default-enabled XMLConverter to make the server fetch attacker-chosen URLs and apply attacker-controlled XSLT during document conversion, because xml-stylesheet href values are resolved without scheme or host allowlisting. The vulnerable converter accepts http, ftp, file, and jar URLs, so a low-privileged user who can upload an XML document can reach internal services, read local files, or influence the resulting converted output. The issue is rated medium severity (CVSS 4.0 base 5.3; independently assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N), authentication is mandatory and no unauthenticated path exists, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery (SSRF) in Ollama versions up to 0.34.1 allows unauthenticated remote attackers to make the server issue HTTP requests to arbitrary internal hosts via cross-host redirects during model pulls. A malicious or compromised registry can redirect manifest or blob requests to internal addresses, potentially exposing limited sensitive information. Publicly available exploit code exists, and the issue is fixed in version 0.34.2 by enforcing a same-host-only redirect policy by default.
Server-side request forgery in houtini-ai voice-analyser-mcp through version 2.1.1 allows a low-privilege authenticated user to make the server issue arbitrary outbound HTTP requests by supplying a crafted sitemap_url to the collect_corpus tool. Because the crawler's fetch function in src/utils/crawler.ts forwards the user-controlled URL without adequate validation, an attacker who can reach and invoke that feature can pivot requests toward internal services, localhost ports, or cloud metadata endpoints, though the assessed impact is bounded to low confidentiality, integrity, and availability effects with no subsequent-system scope. Publicly available exploit code exists and the vendor was contacted but did not respond, and no vendor-released patch has been identified at time of analysis; this is a genuine but low-priority SSRF rather than an unauthenticated or high-severity flaw.
Server-side request forgery in houtini-ai seo-crawler-mcp through version 2.1.5 allows an authenticated caller of the MCP tool interface to coerce the Crawler component into issuing requests to arbitrary destinations through the run_seo_audit function in src/core/CrawlOrchestrator.ts. The vendor was contacted about the flaw but did not respond, so there is no upstream fix at time of analysis, and publicly available exploit code exists (disclosed via the Net-defense/public_exp reference), though there is no evidence of confirmed active exploitation (not in CISA KEV). The independent assessment rates this low priority: exploitation requires low-level privileges on the MCP server (PR:L per both the vendor CVSS 4.0 vector and the assessed CVSS 3.1 vector), needs no user interaction, and yields only low read-level impact, with real risk concentrated where the MCP server has network reach to sensitive internal endpoints such as cloud metadata or internal APIs and lacks URL/egress filtering.
Server-side request forgery in Appwrite 2.3.0 and earlier allows remote attackers to make the Browser Screenshot Service (exposed through the Avatars screenshot endpoint and its 'url' parameter) fetch arbitrary attacker-chosen URLs, reaching internal services or cloud metadata endpoints; because the headless browser resolves the hostname itself, the pre-patch hostname validation can be bypassed via DNS rebinding. Per the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N), exploitation is unauthenticated over the network with confidentiality-only impact (score 6.9), and the independent assessment rates this a genuine but moderate-priority issue bounded to information disclosure through the rendered screenshot. No public exploit was identified at time of analysis, and exploitation requires the screenshot endpoint to be deployed and reachable; the vendor-released fix is Appwrite 2.4.0 (patch commit 393255e7302ae5503331d45802e2eee01c6a47fe, PR 13995).
Server-side request forgery in Company Research Agent through 2.2.0 allows unauthenticated remote attackers to make the server issue outbound HTTP requests by injecting unescaped ReportLab paragraph markup - specifically inline img elements - into the report_content parameter handled by the /generate-pdf endpoint, with the fetched image responses embedded in the returned PDF to give an attacker a content-leakage and internal-reachability oracle. Impact is confined to confidentiality (only responses renderable as images leak content), with no integrity or availability effect, and no public exploit code has been identified at time of analysis, although a public technical writeup describes the injection technique. The issue is tracked as CWE-918 and rated CVSS 4.0 base 6.9 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L), consistent with an independent assessment of a genuine-but-moderate SSRF.
Shepherd (shepherd-ai) through 0.3.1 contains a DNS-rebinding bypass of the citation-checker's public_url SSRF guard, letting an attacker who controls authoritative DNS for a reference URL planted in a checked document redirect the outbound fetch to internal HTTP(S) services and capture the responses inside evidence files. Exploitation requires the shepherd_citation_checker extra to be in use and a victim to actually run a citation check on the attacker-influenced document, then win a time-of-check/time-of-use race in which the guard validates a public IP but the connection re-resolves the hostname to an internal address; no public exploit identified at time of analysis. Impact is read-only information disclosure (low confidentiality, no integrity or availability effect), consistent with the low CVSS 4.0 base score of 2.3 and the assessed CVSS 3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N, and the attacker does not need credentials but does need user interaction and DNS control.
Authenticated server-side request forgery (CWE-918) in Miniflux 2.3.0 through 2.3.3 lets any logged-in user who can create or edit a feed set that feed's proxy_url to a loopback or internal host, defeating the FETCHER_ALLOW_PRIVATE_NETWORKS safeguard so the server itself probes internal ports and sends proxy-style requests to internal services. Impact is confined to low confidentiality disclosure - internal port probing and response/metadata leakage - with no integrity, availability, code-execution or denial-of-service component, and the prerequisite of a valid account means unauthenticated outsiders cannot trigger it; both the supplied CVSS v4.0 score (5.3) and the independent CVSS v3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, also 5.3) agree on a moderate rating. Exploitation status is modest: no CISA KEV entry and no public exploit identified at time of analysis, although a public technical writeup of the bypass and the exact upstream source locations of the flawed logic are linked in the references; reported by VulnCheck, which published a matching advisory, and no EPSS data was supplied with this record.
Blind server-side request forgery (SSRF) in LLMGateway through 1.20.0 allows authenticated API key holders to force webhook POST requests to arbitrary internal targets via the video-generation callback_url parameter, which bypasses the assertSafeWebhookTarget check. Attackers can reach loopback, private RFC1918, or cloud metadata endpoints (169.254.169.254) from the worker's network, potentially exposing internal services or cloud credentials, though the blind nature limits data exfiltration to side effects of the POST request. No public exploit code has been identified at time of analysis, and exploitation requires a valid API key and use of the video feature.
Server-side request forgery in Casdoor's CAS proxy-validation handler (CasP3ProxyValidate in controllers/cas.go) lets a low-privilege authenticated user who already holds a valid CAS service ticket supply a crafted pgtUrl callback value and make the Casdoor server issue outbound HTTP requests to an arbitrary destination of the attacker's choosing. Only deployments that expose the CAS protocol endpoints and use CAS proxy authentication in versions up to 3.164.0 and 4.10.0 are affected, and because the pre-patch code fetches the attacker-supplied URL with http.DefaultClient.Do without destination validation, redirect restrictions, or a timeout, the practical impact is a blind or limited SSRF (some confidentiality exposure, no integrity or availability impact) rather than full compromise of internal services. Publicly available exploit code exists, but there is no confirmed active exploitation (no CISA KEV listing), and the assessed severity is genuinely low, so this is a low-priority hardening item for CAS-enabled Casdoor instances rather than an emergency patch; upgrading to 4.11.0 resolves it.
Server-side request forgery (SSRF) in elvix-sdk versions up to 0.10.1 allows remote attackers with low-privileged authenticated access to the MCP Request Handler to manipulate the 'path' argument in src/mcp/index.ts, causing the server to make arbitrary outbound requests. Publicly available exploit code exists, though no confirmed active exploitation has been observed. The vendor was contacted but did not respond, and no patch is available, leaving mitigation to compensating controls.
Server-side request forgery in Studio-Saelix Sencho up to 0.94.1 allows an authenticated user who can configure git sources to make the backend issue outbound HTTP/HTTPS connections to attacker-chosen internal addresses by manipulating the repo_url argument handled by outboundTarget.ts in the git-sources Browse API endpoint. Exploitation requires a valid session with git-source administration rights (CVSS 3.1 PR:L), and impact is limited to low confidentiality - internal request issuance and response exposure - with no integrity or availability effect; publicly available exploit code exists, though no confirmed in-the-wild activity has been reported. The vendor disputes the CVE characterization, arguing repository access to private LAN, VPC, VPN, CGNAT and IPv6 ULA ranges is an intentional administrative feature rather than a privilege-boundary bypass, while nonetheless shipping defense-in-depth hardening.
Server-side request forgery in Studio-Saelix Sencho up to 0.97.1 allows an authenticated user with node-management permission to supply a crafted URL to the Add Remote Node API endpoint, where the isValidRemoteUrl function in backend/src/utils/validation.ts fails to block server-side requests. Publicly available exploit code exists, and the CVSS 4.0 base score is 2.0; the independent assessment also rates this as a low-priority issue. Per the vendor, the issue demonstrates server-side request capability but not arbitrary internal response exfiltration, so confidentiality, integrity, and availability impact are limited.
Server-side request forgery in the Jawn webhook sender of Helicone (affected through v2025.08.21-1) allows authenticated organization users to create webhooks whose public hostnames resolve - or are DNS-rebound - to loopback or internal addresses, causing the Jawn backend to issue blind POST requests to internal HTTPS services. Rated 5.3 (CVSS 4.0 AV:N/AC:L/AT:N/PR:L/UI:N with only VI:L and no confidentiality, availability, or subsequent-system impact), the vulnerability yields integrity-side effects on reachable internal endpoints rather than data readback. Exploitation requires a valid account within a Helicone organization (PR:L) plus control of a hostname that can resolve or rebind to private space; there is no public exploit identified at time of analysis and CISA KEV does not list this CVE.
Server-side request forgery in Mealie 3.26.0 through 3.28.0 allows an authenticated OpenID Connect user to redirect the server's avatar-fetch routine to arbitrary ports on the configured identity provider's address, because the allowlist check validates only the provider hostname and ignores the port. The fetch fires as a server-side GET on each login, so the practical impact is limited to blind interaction and reconnaissance against services co-located on the already-trusted IdP host; the response body is not returned to the attacker. Exploitation requires Mealie to be configured for OIDC authentication (non-default for many deployments) and a valid account on the trusted IdP whose 'picture' claim the user controls, which is why this scores low (CVSS 4.0 base 2.3, independent assessment CVSS 3.1 4.x-equivalent severity). No public exploit code and no confirmed active exploitation were identified at time of analysis, and no vendor-released patch version is present in the available data.
Server-side request forgery in zotero-mcp 0.10.0 through 0.14.1 lets an unauthenticated attacker who successfully lands a prompt injection steer the connected LLM agent into calling the zotero_add_by_url tool with an attacker-chosen URL, which _fetch_embedded_metadata then fetches without any destination validation. Because redirects are followed, the resulting requests can reach loopback, RFC1918 private, or link-local addresses such as 169.254.169.254, leaking citation meta-tags and error details from internal services that are reachable from the MCP server's network position. Impact is confined to low confidentiality and integrity with no availability effect: exploitation requires the chained prompt injection to succeed (AT:P/UI:R) and an internal service to actually be reachable, and no public exploit identified at time of analysis.
Server-side request forgery in PDFMathTranslate (pdf2zh) through 1.9.11 lets unauthenticated remote attackers force the server to fetch arbitrary URLs supplied through the Gradio web GUI's Link (translate-from-URL) input, reaching internal services and cloud metadata endpoints with the fetched content returned inside the generated PDF. The flaw exists because the translate_file handler forwards user-controlled URLs to download_with_limit without validating the URL scheme or destination address, and the CVSS vector confirms no privileges (PR:N) and no user interaction (UI:N) are needed. Exploitation is gated primarily by exposure: the Gradio interface must be network-reachable and able to route to internal or link-local addresses, and impact is confined to information disclosure (VC:L, no integrity or availability effect) - there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis.
Server-side request forgery in Kortix Suna 0.10.7 through 0.13.51 allows an authenticated user holding the project.connector.write permission to bypass the isPrivateIp egress guard by encoding connector base_url, OpenAPI, Postman, or MCP endpoints as IPv6 6to4 (2002::/16) or Teredo (2001:0::/32) addresses whose embedded IPv4 points at an internal host or the 169.254.169.254 cloud metadata endpoint. Exploitation reaches internal-only services and metadata and returns the fetched responses to the attacker, but impact is capped at low confidentiality and integrity with no availability loss and no scope escape beyond the connector fetch path. Publicly available exploit code exists (a technical writeup linked from the CVE record), and the issue is fully remediated in v0.13.52; there is no confirmed active exploitation (CISA KEV) for this CVE.
An authenticated low-privilege user of openPDC can abuse the Modbus connection feature to make outbound connections to arbitrary internal destination addresses and ports, because the destination input is caller-controlled and not validated against any allow-list. The result is a server-side request forgery (CWE-918) condition that leaks reachability information - an attacker can distinguish which internal hosts and ports respond and, through repeated probes, gradually map the internal network - but no data theft, code execution, integrity, or availability impact is possible. The vulnerability is rated 5.3 under both the vendor's CVSS 4.0 vector and the independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), reflecting that valid credentials are mandatory and the only confirmed impact is limited confidentiality disclosure; there is no public exploit identified at time of analysis and no confirmed active exploitation.
Server-side request forgery in Dell Secure Connect Gateway (SCG) Policy Manager affects versions prior to 5.34.00.16, letting an attacker who already holds high-privilege access to the management interface coerce the appliance into issuing requests to attacker-chosen destinations. Because the CVSS vector carries PR:H, this is not reachable by anonymous or low-privileged users, and the impact is limited to information disclosure (C:H) with no integrity or availability effect; scope is changed (S:C), so the server can be pivoted toward internal or backend resources outside its own security boundary. No public exploit code or confirmed active exploitation was identified at time of analysis, and the underlying high-privilege prerequisite keeps this a moderate-severity, low-urgency issue rather than a top remediation priority.
Server-side request forgery in the Kirki WordPress plugin before 6.3.2 allows authenticated users holding editor-level privileges or above to supply a URL that the WordPress server then fetches without validating the target host, letting them probe internal-only services and infer from the responses which of those hosts are live. The issue is rated CVSS 4.1 (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N), so impact is confined to information disclosure with no write, code execution, or denial-of-service capability, and exploitation requires a trusted privileged account rather than anonymous access. Publicly available exploit code exists and WPScan is credited as the reporting source, but there is no CISA KEV confirmation of active exploitation; combined with the high privilege prerequisite, the signals converge on a modest, non-urgent priority appropriate for routine patching alongside other plugin updates.
Server-side request forgery in Indico (all versions prior to 3.3.13) allows an authenticated event organizer to make the server fetch a prohibited local or internal URL by embedding a backslash in a crafted URL, and then read the target's response through affected Indico features. The vulnerability is a CWE-918 SSRF stemming from an incomplete fix for CVE-2026-25738; the trigger (demonstrated as 'http://127.0.0.1\@1.1.1.1') defeats Indico's local-target filter, which now rejects any URL containing a backslash. Exploitation requires the trusted event-organizer role (CVSS 3.1 PR:H, score 6.8, scope changed), there is no confirmed active exploitation (not in CISA KEV), and no public exploit code was identified at time of analysis.
Server-side request forgery in FFmpeg's RTSP handling (ff_rtsp_connect() in libavformat/rtsp.c) lets a malicious RTSP server answer with an RTSP 3xx redirect whose Location header points to an internal host and port under a different scheme, which the library then follows without validating the target - defeating the -protocol_whitelist control. Affected builds are FFmpeg before 7.1.4 and the 8.0.x line before 8.0.2; exploitation is unauthenticated per the CVSS 4.0 vector (PR:N) but requires a victim application or user to process the attacker-controlled rtsp:// source, and impact is bounded to probing/reaching internal services rather than data exfiltration or code execution. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis; vendor patches are available in 7.1.4 and 8.0.2.
Server-side request forgery in Pydantic AI's URL-fetching guards lets an application that has explicitly opted a URL into local-network access reach IPv6 cloud metadata endpoints such as fd00:ec2::254 and read short-lived cloud IAM credentials, because appending an RFC 4007 zone identifier (for example fd00:ec2::254%251) makes the address unequal to its blocklist entry while the kernel silently ignores the zone for a non-link-local destination and routes the request anyway. Affected releases are pydantic-ai and pydantic-ai-slim at 1.56.0 up to but not including 1.107.6, and 2.0.0b1 up to but not including 2.44.0; exploitation additionally requires that the URL be attacker-influenced or model-chosen, that one of the two opt-ins be enabled (FileUrl with force_download='allow-local', or web_fetch_tool(allow_local_urls=True) - both off by default), and an IPv6-enabled environment with a reachable metadata service. Vendor-released patches are available in versions 1.107.6 and 2.44.0 (upstream fix tracked via pull requests 8401 and 8402); no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
A domain-denylist bypass in Pydantic AI's local web-fetch tooling (web_fetch_tool and the WebFetch local fallback) lets an attacker-influenced model reach a host the operator explicitly placed in blocked_domains by supplying a DNS-equivalent spelling - an IDNA/fullwidth form, a non-ASCII label separator, a case variation, or a trailing root label - that does not string-match the configured entry but resolves to the same host. Affected are pydantic-ai and pydantic-ai-slim versions 1.77.0 through 1.107.5 and 2.0.0b1 through 2.44.0; the flaw is a denylist bypass only, so configurations that use allowed_domains fail closed and are unaffected, and the private-IP and cloud-metadata SSRF protections remain effective, meaning internal or metadata endpoints are not reachable through this bug. Rated CVSS 3.1 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) as a low-severity, high-complexity information-fetch issue, with no public exploit identified at time of analysis and vendor patches available in 1.107.6 and 2.44.0.
Server-side request forgery in IBM DataPower Gateway (10.5.0.0 through 10.5.0.22, 10.6.0.0 through 10.6.0.10, 10.6.1 through 10.6.6, and 11.0.0.0 through 11.0.0.2) lets an authenticated user who satisfies high-complexity preconditions make the appliance send requests to destinations of the attacker's choosing, enabling internal network enumeration and reconnaissance that can support follow-on attacks. Rated CVSS 4.9 (AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N), this is a moderate-severity, low-priority issue rather than an emergency: exploitation requires a valid authenticated session plus the ability to reach a request-handling function that accepts an attacker-influenced destination, and there is no public exploit identified at time of analysis, with real-world impact bounded by whatever sensitive internal hosts the gateway itself can reach. IBM has published an advisory covering these builds, and other versions are not in scope.
Server-side request forgery in LinuxServer Heimdall through 2.8.3 lets an unauthenticated attacker coerce the server into issuing HTTP requests to arbitrary internal hosts and ports, including the cloud metadata address 169.254.169.254, by inducing a victim with network reachability to the instance to load attacker-controlled content that triggers the CSRF-reachable POST /test_config or GET /get_stats endpoints (CVSS 3.1 base score 3.4, vector AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N). Publicly available exploit code exists, but there is no indication of confirmed active exploitation, and the author scopes the CSRF exposure to only 'some realistic installations' where those endpoints are reachable. The realistic impact is a status/port oracle plus partial response data - not full response exfiltration - and the cloud-metadata path additionally requires Heimdall to run on an instance exposing an unauthenticated metadata service.
Splunk MCP Server versions below 1.2.1 transmit the Splunk platform authentication token of the user who executes a custom API tool to whatever URL that tool is configured to call, so an attacker who can author a custom tool pointing at a server they control can capture the victim's token and then act as that user. Exploitation is authenticated and requires user interaction: the attacker needs privileges to create or configure a custom API tool, and a separate victim holding a role with the mcp_tool_execute capability must actively run that tool (CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:L/A:L). Real-world risk is moderate - it does not affect default deployments that make no use of custom API tools, and no public exploit has been identified at time of analysis. A vendor patch is available in Splunk MCP Server 1.2.1.
Server-side request forgery in Splunk Enterprise (below 10.4.3, 10.2.7, and 10.0.10) lets an authenticated user who holds a role with the read_o11y_content capability redirect an outbound request made by the Splunk App for Splunk Observability Cloud to an attacker-controlled host, thereby disclosing the configured Observability Cloud API token. The flaw exists because the app does not fully validate the destination of outbound requests; the request is triggered through the REST API, requires no user interaction, and is rated CVSS 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N), indicating a high-confidentiality but no integrity or availability impact. Exploitation is gated by a non-default capability, by the presence of the Observability Cloud app, and by an environment where an API token is configured; Splunk Enterprise 9.4.x is explicitly unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and a vendor patch is available.
Server-side request forgery in Gophish 0.11.0 through 0.12.1 allows authenticated, low-privileged users to force the server to fetch arbitrary internal URLs through the POST /api/import/site endpoint, because the default dialer deny list does not block loopback or RFC1918 private destinations. Attackers can read the responses of reachable internal services and enumerate internal hosts and ports from differential error messages, but the impact is confined to information disclosure with no write, code-execution, or availability effect, and authentication is mandatory (CVSS:4.0 PR:L / assessed CVSS:3.1 PR:L). Publicly available exploit code exists - documented in an Ostorlab review of Gophish 0.12.1 and tracked by VulnCheck - while the reported CVSS 4.0 score is a moderate 5.3 and no CISA KEV entry is present in the supplied intelligence, so this is confirmed as a moderate-severity issue rather than an emergency.
Server-side request forgery in LMCache through 0.5.5 allows unauthenticated remote attackers to bypass the frontend monitoring service's proxy allowlist by registering arbitrary host entries through POST /api/proxies, then relaying requests to internal systems via /proxy or /proxy2 and reading the responses back. Successful abuse also permits tampering with catalogued nodes and stopping the heartbeat mechanism, but the impact is bounded to limited information disclosure, limited integrity impact, and availability disruption rather than full host takeover. Exploitation is unauthenticated (PR:N, CWE-306) and requires only network reachability to the frontend monitoring service, so real-world risk depends heavily on whether that service is exposed beyond trusted internal ML-serving infrastructure; no public exploit code or confirmed active exploitation was identified at time of analysis.
Server-side request forgery in the PowerPress Podcasting plugin by Blubrry (versions 11.13.12 through before 11.17.11) lets authenticated WordPress users with contributor-level access or higher supply a media URL that the plugin fetches server-side, following HTTP redirects to attacker-chosen destinations, and thereby probe or reach internal services. The flaw is a redirect-destination validation failure classified as CWE-918 with CVSS 4.1 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N per the assessed vector), so impact is limited to confidentiality-oriented access to internal endpoints with no direct write or code-execution path indicated. Publicly available exploit code exists for this issue, but there is no confirmed active exploitation (CISA KEV) and no evidence of a zero-day; the vendor has released a patch, and this is a moderate, not urgent, priority.
Server-side request forgery in the agent import functionality of Amazon Bedrock AgentCore Starter Toolkit versions before 0.3.14 allows an authenticated actor within the same AWS account to make the environment of a user importing a Bedrock Agent issue arbitrary outbound requests and read arbitrary local files. The attacker must supply crafted external reference values in the OpenAPI content associated with a Bedrock Agent action group, and exploitation requires the victim to actively import that agent; this narrow interaction requirement and the same-account authentication prerequisite limit the practical exposure, consistent with the vendor's Medium (CVSS 4.0 5.7) rating and our assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:R with high confidentiality impact only. No public exploit code has been identified at time of analysis, and no known active exploitation has been reported.
Server-side request forgery in Gitea's repository migration feature lets an authenticated user who is permitted to start migrations force the Gitea server to connect to reserved or link-local addresses, including the cloud metadata endpoint 169.254.169.254. The flaw only manifests in a non-default configuration where the administrator has set [migrations] ALLOWED_DOMAINS to a wildcard such as `*` or a hostname wildcard, which bypasses the intended ALLOW_LOCALNETWORKS = false protection because the local-network block list omitted reserved/link-local ranges and hostname allow-list matching was accepted irrespective of the resolved IP. Impact is bounded to reachability and read-style access from the server (no code execution or data modification), authentication is required per the CVSS vector (PR:L), and no public exploit has been identified at time of analysis, so this is a low-to-moderate priority issue whose real-world severity rises mainly where a reachable instance metadata service exists on the Gitea host.
Server-side request forgery (SSRF) in Arista CloudVision Portal allows an authenticated user with high privileges to manipulate the OIDC bearer token configuration and direct requests to arbitrary destinations. Affected versions include 2023.3.0 before 2025.3.0, 2025.3.0 through 2025.3.3, 2026.1.0 through 2026.1.2, and 2026.2.0. Exploitation requires pre-existing elevated access, limiting impact to subsequent-system confidentiality; no public exploit identified at time of analysis.
Server-side request forgery (SSRF) in Arista CloudVision Portal arises from insufficient validation of OIDC SSO provider configuration, allowing a user holding the specific high-privilege right to view and modify that configuration to direct CVP-originated requests to arbitrary destinations. The practical impact is limited rather than systemic: the CVSS 4.0 base of 5.1 and our independent CVSS 3.1 assessment (AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N) both reflect that the attacker must already be a highly privileged CVP administrator with network reach to the management interface, and that the consequence is a low-confidentiality information-disclosure primitive rather than code execution or service disruption. There is no public exploit identified at time of analysis and no confirmed active exploitation (SSVC: Exploitation=none, Automatable=no); a vendor patch is available via Arista security advisory 0186, and the main residual risk is abuse or takeover of an already-privileged administrative account.
URL injection and server-side request forgery (SSRF) in i18next-http-backend prior to 4.0.2 allows attacker-controlled language or namespace values to redirect translation resource requests away from the intended origin, but only when the application configures a custom loadPath or addPath template that begins directly with the {{lng}} or {{ns}} placeholder. Because the placeholder must occupy the URL's structural beginning for a colon to form an absolute URL (or, in browsers, a double-slash namespace to form a protocol-relative URL), the default '/locales/{{lng}}/{{ns}}.json' template and any template with a leading path or origin prefix are unaffected; this uncommon configuration and the need to control the language/namespace input drive the High attack complexity rating. Impact is limited to low confidentiality loss (blind SSRF/URL injection with no integrity or availability effect), and all signals indicate a low-priority issue - no public exploit code and no confirmed active exploitation were identified at time of analysis. The issue is fixed in version 4.0.2.
Authenticated device registration in Microsoft UFO versions prior to 3.0.9 can be abused to make the server open WebSocket connections to internal hosts, because pinned-address enforcement is applied only to the initial destination while the underlying websockets client still follows HTTP redirects. An attacker with valid credentials who can supply a device server_url that passes Galaxy's URL validation can then have that endpoint return a 301/302/303/307/308 redirect to an internal address, causing a cross-origin TCP connection and WebSocket upgrade handshake to be sent before peer-IP validation runs. The impact is limited to the internal connection and handshake request - no arbitrary HTTP methods, response-body disclosure, completed AIP session, or cloud metadata access - and this is a medium-severity (CVSS 6.4) SSRF whose real-world priority is modest rather than urgent; no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV).
Server-side request forgery (SSRF) in Django's GeoDjango spatial lookups allows remote unauthenticated attackers to make the Django process issue outbound network requests when an application passes attacker-controlled `bytes` raster values directly into a lookup against a `RasterField`. Affected versions are Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18; older unsupported series (5.1.x, 5.0.x, 4.2.x) were not evaluated and may also be affected. The flaw is an incomplete fix for CVE-2026-15307, and exploitation requires a deployment that uses GeoDjango raster fields and forwards raw untrusted bytes into spatial lookups - not a default Django configuration. There is no public exploit identified at time of analysis and the issue is not in CISA KEV; Django rates it 'moderate' severity (CVSS 5.3), with impact limited to attacker-directed outbound requests rather than data compromise or code execution.
Request forgery in MongoDB Controllers for Kubernetes allows an authenticated user who can modify an OpsManager custom resource to cause unintended administrative changes in Enterprise Ops Manager when backup reconciliation is enabled. The flaw involves insufficient escaping of Ops Manager backup store identifiers when the controller builds admin API request paths. It is a low-severity issue with no public exploit identified at time of analysis, and the vendor fixed it in MongoDB Controllers for Kubernetes 1.13.0.
Server-side request forgery in O2OA up to and including 10.0.1-ce lets an authenticated, low-privileged user force the application server to issue outbound HTTP requests to attacker-chosen destinations by supplying a crafted fileUrl argument to the ActionUploadExcelWithUrl handler in the General Module. Publicly available exploit code exists and the flaw is remotely reachable, but impact is limited to low confidentiality exposure (CVSS 3.1 base of 2.1, PR:L, C:L with no integrity or availability effect), so this is a low-priority issue despite the SSRF classification. The vendor was notified through a GitHub issue report and has not responded, so no patched release is identified at time of analysis.
DYMO ID 1.5.1.71 and earlier automatically parse job files with DTD processing enabled, allowing a crafted file placed on a browsed network share to trigger XML external entity (XXE) processing. This can lead to SSRF, NTLMv2 credential capture, local file disclosure, or process crash, though the independent assessment notes impact is bounded and does not include arbitrary code execution. No public exploit code has been identified at time of analysis, and the vendor released a fix in version 1.6.0.
Server-side request forgery in Penpot before 2.18.0 allows an authenticated user who controls a media-import URL, or an administrator who controls a webhook URL, to reach internal and cloud-metadata endpoints by supplying IPv6 transition addresses (NAT64 64:ff9b::/96, 6to4 2002::/16, or Teredo 2001:0000::/32) that embed a blocked IPv4 destination such as 169.254.169.254, 127.0.0.1, link-local, or RFC1918 addresses. The bypass works because the backend blocklist app.util.ssrf/blocked-address? applies its extra CIDR checks only to IPv4 values and relies on Java InetAddress predicates that do not classify transition-mechanism addresses; exploitation further requires the request to traverse a NAT64 gateway or the attacker to control a DNS AAAA record the Penpot server resolves, with cloud environments that already run DNS64/NAT64 directly exploitable, while non-NAT64 deployments depend on the harder attacker-controlled AAAA path. Media import can disclose response bodies, whereas webhook delivery exposes only response status as a network-probing side channel, and there is no public exploit identified at time of analysis. Penpot 2.18.0 is the vendor-released fix (commit 326d83e780ae120b45ccd6f3d7bd24922b54461c).
Server-side request forgery in the Ghost CMS webhooks feature (versions 1.18.0 through releases prior to 6.27.0) allows an authenticated staff user who can create or edit webhooks to point a webhook target_url at internal hosts and force the Ghost server to issue requests to them. The CVSS vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N, score 2.7) confirms this is a network-reachable but privileged-account-required issue whose impact is limited to low confidentiality loss - blind or semi-blind probing rather than response retrieval or code execution - and there is no public exploit identified at time of analysis. Ghost 6.27.0 fixes the issue by routing webhook delivery through a request library that blocks internal IPs unless the operator explicitly opts in via a new configuration flag.
Server-side request forgery (SSRF) in Ghost CMS versions 6.0.9 through 6.64.x lets an unauthenticated remote attacker induce the server to issue limited HTTP requests to hosts on its internal network. The flaw is blind - no response body is ever returned to the attacker - so the practical value is confined to request-triggered side effects and liveness/timing inference rather than data exfiltration, and exploitation depends on the target deployment actually having reachable internal hosts (e.g. NAT64/DNS64 setups or flat internal networks). The vendor fixed the issue in Ghost 6.65.0; no public exploit code has been identified at time of analysis and the flaw is not listed in CISA KEV, consistent with the assessed CVSS 3.1 score of 4.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N).
Server-side request forgery (SSRF) in Event Gallery for Joomla before 6.6.0 allows an attacker to make the server send the Google Photos OAuth access token to an arbitrary address or probe internal network resources. The vulnerability resides in the back-end upload page's Google Photos picker, which fetches image thumbnails using a user-supplied address without validation and without a form token, enabling exploitation via CSRF against a logged-in administrator or directly by a back-end user with 'Manage' permission. No public exploit code has been identified, and the risk is assessed as moderate and targeted.
Server-side request forgery in LibreOffice on Linux can expose local files and internal or remote URLs when a document links to a crafted HLS media playlist and the victim opens it and permits link updates. LibreOffice relies on the GStreamer media backend on Linux to play linked audio and video; a malicious playlist's listed resources were fetched while the document loaded and their contents could be written into the document, yielding confidentiality impact (VC:H, SC:H) with no integrity or availability impact in the assessed CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N). The issue is moderate severity and interaction-dependent rather than an urgent priority; no public exploit code and no confirmed active exploitation (no CISA KEV listing) were identified at time of analysis, and exploitation is constrained to Linux installations using the GStreamer backend.
LibreOffice Calc on affected versions automatically fetched external CSV data links embedded in a spreadsheet while the document loaded, so an attacker-crafted Calc file could read a local file into a sheet or force a request to a host of the document author's choosing (SSRF, CWE-918). Exploitation is local and interaction-gated - the attacker must deliver the malicious document and the victim must open it - and the flaw affects confidentiality only, with no impact on integrity or availability. No public exploit code and no confirmed active exploitation were identified at time of analysis; the vendor addressed it by placing external data links under the same link-update control that governs other spreadsheet links.
Server-side request forgery in feelec-yishu feelcrm-os 1.0.0 allows unauthenticated remote attackers to make the application's server issue attacker-controlled HTTP requests through the getCurlData endpoint in App/Feelcrm/Index/Controller/GoogleController.class.php, by manipulating the 'url' argument. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms this is remotely reachable, low-complexity and requires no authentication or user interaction, while impact is uniformly LOW (VC:L/VI:L/VA:L) with no scope change, making it a limited-impact SSRF rather than a full internal pivot or credential-theft primitive. Publicly available exploit code exists and the issue was reported to the project, which has not yet responded with a fix; no confirmed active exploitation (CISA KEV) has been observed.
Server-side request forgery (SSRF) in Shaarli up to 0.16.3 allows an attacker who can reach the admin-only MetadataController endpoint to make the server fetch arbitrary HTTP(S) URLs, including those resolving to private, loopback, link-local, or reserved addresses. Exploitation requires either an authenticated administrator session (PR:H) or tricking a logged-in admin into triggering the request, which was feasible before the fix because the endpoint did not validate a CSRF token; the pre-patch code also only checked that the URL scheme contained the substring 'http' and performed no IP validation. There is no confirmed active exploitation (not listed in CISA KEV) and no public exploit code identified at time of analysis; a vendor patch is available in version 0.16.4.
Server-side request forgery (CWE-918) in ChatGPTNextWeb NextChat up to and including 2.16.1 lets an unauthenticated, remote attacker who can reach the /api/proxy endpoint (the Proxy Fallback Handler) redirect the server's outbound HTTP requests to arbitrary hosts by supplying a crafted x-base-url header. Because the hostname is concatenated into the server-side fetch target without any validation against private, loopback, link-local, or cloud-metadata ranges, a successful attack can reach internal-only services or instance-metadata endpoints, with impact bounded by what the host's network position can actually reach. Publicly available exploit code exists (referenced GitHub issue #6813), but there is no confirmation of active exploitation; the fix is an unmerged pull request (#6884) that awaits acceptance, so no released patched version is independently confirmed and the risk should be treated as a genuine but medium-tier issue rather than an emergency.
Blind server-side request forgery in the X.509 client-certificate authenticator of Keycloak (and the downstream Red Hat Build of Keycloak and Red Hat Single Sign-On 7) lets an unauthenticated remote attacker induce the server to make outbound requests to URLs specified in a crafted client certificate, before that certificate has been fully validated. The flaw is reachable only when X.509 client-certificate authentication is enabled and certificate revocation checking via CRL Distribution Points or OCSP is configured - a non-default setup, which is why the assessed vector carries AC:H despite PR:N/UI:N. Impact is limited to low confidentiality (the SSRF is blind and no response content is returned to the attacker), and no public exploit has been identified at time of analysis.
Zitadel deployments before 4.16.2 expose a server-side request forgery (SSRF) path in the organization custom-domain HTTP verification flow, where the challenge fetch uses Go's default http.Get rather than Zitadel's SSRF-protected HTTP client. An authenticated principal holding privileges to create or manage an organization and register a custom domain can point DNS/HTTP for that domain at loopback, RFC1918/internal, or link-local cloud metadata addresses (e.g., 169.254.169.254), causing the Zitadel server to issue requests to those targets and enabling port scanning and internal network mapping. Impact is limited to server-side reconnaissance - there is no data modification, and confidentiality exposure depends on what internal or metadata services are actually reachable from the instance - and no public exploit code has been identified at time of analysis; EPSS and KEV signals are absent, and the scored severity is low (CVSS v4.0 base 2.3; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N).
Unauthenticated remote attackers can exploit a server-side request forgery (SSRF) in SciPhi-AI R2R 3.6.6 and earlier by supplying a crafted generation_config.api_base value to the Retrieval Completion API endpoint, causing the server to make requests to arbitrary internal or attacker-controlled URLs. Publicly available exploit code exists (a GitHub Gist), and the vendor did not respond to disclosure, so no patched version is confirmed at time of analysis. The independent assessment rates this as medium severity (CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L; VulDB CVSS 4.0 score 6.9), with impact bounded by what internal targets the R2R server can reach.
Server-side request forgery in Open Identity Platform OpenAM before 16.1.3 allows an authenticated attacker holding the privilege to register or modify OAuth 2.0 / OpenID Connect clients to make the OpenAM server fetch arbitrary internal resources through an unvalidated client jwks_uri. The vulnerable dereference occurs on the OIDC client-authentication and ID-token validation paths, so the resulting fetches are made by OpenAM itself and can be aimed at internal hosts, cloud metadata endpoints or local files, or abused to consume request threads for a low-impact denial of service. Exploitation requires PR:L per the assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L (CVSS 4.0 base 5.3); no public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
Server-side request forgery (SSRF) in Zilliz Attu before 3.0.0 allows remote attackers to proxy requests to private IP addresses via the Playground feature. This is a moderate-severity, not high-priority, issue: exploitation requires network access to an Attu instance's Playground feature, which proxies user-supplied requests without validating the destination; the CVSS vector indicates unauthenticated access (PR:N) with no user interaction, but real-world authentication enforcement is not confirmed. No public exploit identified at time of analysis.
Server-side request forgery in UTMStack before 11.2.16 lets any authenticated user (even a low-privilege one) coerce the web-pdf microservice into fetching an arbitrary URL by supplying an unvalidated url parameter to GET /api/generate-pdf-report, with the fetched response rendered back into the returned PDF. A successful attack exposes internal-only resources the container can reach - backend APIs, the OpenSearch cluster, or a cloud instance-metadata endpoint (169.254.169.254) - making credential theft the highest-impact outcome on cloud-hosted deployments; there is no code execution, no data modification, and exploitation requires a valid UTMStack session (CVSS vector PR:L, so authentication is required). No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (not in CISA KEV); the CVE carries a CVSS 4.0 score of 6.3, while our independent CVSS 3.1 assessment (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) rates it High, with real-world impact gated by the server's network reachability to the targeted internal resource and, for the metadata path, by the instance running in a cloud environment.
Server-side request forgery (SSRF) in UTMStack before 11.2.16 is a genuine but moderate-severity issue rather than a top-tier emergency: an authenticated user who can reach the POST/PUT /api/identity-providers endpoint can supply a crafted metadata URL that IdentityProviderService.validateMetadataUrl() accepts without validating target host, IP, or scheme, causing the server to issue attacker-directed requests to internal or cloud metadata hosts. The practical consequence is internal network reconnaissance and port scanning, plus exposure of cloud instance-metadata services such as 169.254.169.254 when UTMStack is deployed in a cloud environment; impact is otherwise confined to confidentiality (scope-changed C:L/I:N/A:N) and is gated by the requirement for a valid UTMStack account (PR:L). No public exploit code has been identified at time of analysis, there is no CISA KEV listing, and the vendor has released version 11.2.16 as the fixed version.
Authenticated server-side request forgery (SSRF) in ThemeREX Addons versions up to 2.46.0 allows any logged-in WordPress user with low privileges to force the server to make arbitrary HTTP requests, potentially reaching internal services or cloud metadata endpoints. The CVSS 6.4 rating reflects limited confidentiality and integrity impact, and exploitation requires the plugin to be active and an attacker to hold a valid low-privilege account. No public exploit identified at time of analysis.
Server-side request forgery and cross-site scripting in YesWiki before 4.6.7 allow an authenticated page editor to abuse the Bazar 'valeur' action to make the server fetch arbitrary URLs, including loopback and internal addresses, and to inject unescaped remote HTML that executes script in a victim's browser. Exploitation requires an editor-level account (CVSS PR:L) and, for the XSS half, a separate victim viewing the poisoned page, so anonymous remote exploitation is not possible; no public exploit identified at time of analysis. Risk is medium severity per the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, and a vendor-released fix is available in 4.6.7.