NASA earthdata-search granules Endpoint handler.js OpenSearchGranuleSearchLambda server-side request forgery

A flaw has been found in NASA earthdata-search 1.0.0. Affected by this issue is the function OpenSearchGranuleSearchLambda of the file serverless/src/openSearchGranuleSearch/handler.js of the component granules Endpoint. Executing a manipulation of the argument openSearchOsdd can lead to server-side request forgery. The attack can be launched remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Server-Side Request Forgery (SSRF) in GitLab AI Gateway

GitLab has remediated a vulnerability in the GitLab AI Gateway component affecting all versions of the AI Gateway from 18.10 to 19.0.12, 19.1 to 19.1.7, and 19.2 to 19.2.2 that could have allowed an authenticated user with Duo Agent Platform access to redirect outbound model requests to an externally-controlled endpoint via a crafted inline flow configuration that overrides the HTTP Host header, resulting in disclosure of Google Cloud Vertex cloud service credentials and private signing keys.

n8n before 2.32.1 SSRF Protection Bypass via MCP Client

n8n versions before 2.32.1 contain a server-side request forgery protection bypass vulnerability in the MCP Client node that allows authenticated users to bypass SSRF protections. Attackers can craft workflows that send requests to internal or blocked hosts without routing through SSRF protection, exposing internal services and reading responses back through the workflow.

n8n before 1.123.69 SSRF Protection Bypass via OAuth2

n8n before 1.123.69, 2.33.4, and 2.34.1 contains an SSRF protection bypass in the OAuth2 credential authorization-code-to-access-token exchange. While OAuth2 discovery and dynamic-client-registration requests use n8n's SSRF-protected HTTP client, the token exchange uses a separate client with no SSRF guard. A user with credential-creation permissions can set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a fixed-shape token-exchange POST to that target and reflect its response body back to the attacker (limited to what the target returns to this specific request).

n8n before 2.34.1 SSRF Protection Bypass via SearXNG Tool

n8n before 2.34.1 and 2.33.x before 2.33.4 contains an SSRF protection bypass in the SearXNG Agent tool. The tool sent requests to the user-supplied API URL using a raw HTTP client that did not route through n8n's centralized SSRF protection. On instances with N8N_SSRF_PROTECTION_ENABLED=true, an authenticated user with permission to create SearXNG credentials and configure a personal agent could set the API URL to an internal host, causing the n8n server to connect to that host and return the response content through the Agent chat output.

Apache Shiro: Server-side POST request may be steered to an alternate host

When Apache Shiro is used with the Jakarta EE integration module, a low-privileged user can craft an HTTP request that causes the server to initiate a connection to an attacker-controlled URL and transmit attacker-controlled data. This vulnerability affects Apache Shiro versions 2.x through 3.0.0 only in deployments that use the Jakarta EE integration module. Mitigation: Upgrade to version 3.0.1 or later, which fixes the issue. + Alternatively, you can set the `org.apache.shiro.form-resubmit-host` (String) and `org.apache.shiro.form-resubmit-port` (Integer) system properties to restrict the host and port that Shiro will connect to when resubmitting a form.

Server-side request forgery (SSRF) in the /har/test endpoint in QD 20220208 through 20250803. Fetcher.build_request() in libs/fetcher.py constructs an httpclient.HTTPRequest from user-supplied JSON without validating URL scheme, host, or IP range. The /har/test handler does not require authentication, enabling unauthenticated remote attackers to force the QD server to send arbitrary HTTP requests to internal network resources and cloud metadata endpoints. validate_cert is set to False, disabling TLS verification.

In Spring for Apache Kafka, SSRF via DNS resolution triggered by untrusted java.net types in header mapper default trusted packages

JsonKafkaHeaderMapper and DefaultKafkaHeaderMapper include java.net in their default trusted packages list. When these mappers are used — which is the default configuration for all @KafkaListener consumers — an external Kafka producer can inject a java.net.InetAddress type via the spring_json_header_types message header. Spring for Apache Kafka 4.1.0 Spring for Apache Kafka 4.0.0 - 4.0.6 Spring for Apache Kafka 3.0.0 - 3.3.16 Spring for Apache Kafka 2.9.0 - 2.9.14 Spring for Apache Kafka 2.8.12 and earlier

hyperledger-firefly Webhook Subscription webhooks.go ValidateOptions server-side request forgery

A vulnerability was found in hyperledger-firefly firefly up to 1.4.0. The impacted element is the function ValidateOptions of the file internal/events/webhooks/webhooks.go of the component Webhook Subscription. Performing a manipulation of the argument url results in server-side request forgery. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The vendor was contacted early about this disclosure but did not respond in any way.

Wallos: Authenticated SSRF via per-user SMTP notification host (low-privilege user)

Wallos is an open-source, self-hostable personal subscription tracker. From version 2.0.0 to before version 5.0.0, any authenticated Wallos user (no admin rights required) can make the server open arbitrary outbound SMTP connections to internal/link-local addresses, by setting the SMTP host of their personal email notifications to an internal IP. The per-user notification settings endpoint (endpoints/notifications/saveemailnotifications.php) performs no SSRF validation, and the notification cron (endpoints/cronjobs/sendnotifications.php) feeds that user-controlled host straight into PHPMailer ($mail->Host = $email['smtpAddress']). When the user's subscription notification fires, the server connects to the chosen host:port. This issue has been patched in version 5.0.0.

oasdiff actions resolve external $refs by default, enabling SSRF and disclosure of structured files on pull-request runs

oasdiff-action is a GitHub Action that detects breaking changes in OpenAPI specs and post a review on every pull request. Before version 0.0.51, the oasdiff actions resolved external $refs in the OpenAPI spec by default (allow-external-refs: true). When an action runs on a pull request whose spec is attacker-controlled — most importantly fork pull requests on public repositories — a $ref in that spec is fetched/read on the runner with no interaction required, enabling SSRF and disclosure of structured files on the runner. This issue has been patched in version 0.0.51.

Weblate: DNS rebinding in VCS operations allows server-side request forgery

Weblate is a web-based continuous localization platform used to manage software translations. In versions prior to 2026.8, a user permitted to manage component repository URLs can perform server-side request forgery against internal services through DNS rebinding during VCS operations. Weblate validates the hostname's first DNS resolution, but the external VCS clients that later connect perform a separate DNS lookup, so an attacker-controlled hostname that initially resolves to a public address can be re-pointed to an internal or private address before the connection is made. By triggering a clone, fetch, push, or similar remote operation, the attacker can cause Weblate to reach internal VCS-compatible services and potentially expose private repository contents. Installations that permit untrusted repository hostnames while using VCS_RESTRICT_PRIVATE=True are affected. This issue is fixed in version 2026.8.

HCL Connections is vulnerable to server-side request forgery (SSRF)

HCL Connections is vulnerable to server-side request forgery (SSRF) when an internal server is compromised possibly allowing an attacker to send unauthorized requests in certain scenarios leading to information disclosure or security bypass.

Apify Actors MCP Server before 0.9.12 Server-Side Request Forgery via get-html-skeleton

The get-html-skeleton tool fetched a URL the caller supplied after checking only its syntax. The handler in src/tools/common/get_html_skeleton.ts validated the url argument with isValidHttpUrl from src/utils/generic.ts, which confirmed the string began with an http or https scheme and parsed as a URL and inspected neither the host name nor the address it resolves to. Loopback, link-local and private ranges therefore passed, including the address cloud providers use to serve instance metadata. The unchecked URL was handed to the web-browser actor and the fetched document was returned in the tool response, so any caller of the MCP server could make it request an endpoint reachable only from the host and read the result, including instance credentials. Version 0.9.12 removes the tool.

CC: Tweaked: Incomplete fix for GHSA-5jh9-2h63-pw4q: RFC 8215 NAT64 prefix (64:ff9b:1::/96) bypasses SSRF protection

CC: Tweaked is a mod for Minecraft which adds programmable computers, turtles, and more to the game. Prior to 1.120.0, the SSRF protection in projects/core/src/main/java/dan200/computercraft/core/apis/http/options/AddressPredicate.java blocks the RFC 6052 64:ff9b::/96 NAT64 prefix but omits the RFC 8215 64:ff9b:1::/48 local-use prefix. On a dual-stack server using RFC 8215 NAT64, an unauthenticated user who can execute Lua code can use http.request or http.websocket with an address under 64:ff9b:1::/48 to reach loopback, RFC 1918, cloud metadata, or internal API endpoints because PrivatePattern.matches() does not classify the mapped IPv6 address as private. This issue is fixed in version 1.120.0.

A server-ide request forgery (SSRF) vulnerability in webhook in Synology Chat Server before 2.4.5-22148 allows remote authenticated users to obtain non-sensitive information.

Wallos: SSRF via Unvalidated User-Level SMTP Host in Email Notification Settings

Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 5.0.0, Wallos lets any authenticated user store an arbitrary SMTP host — including private and cloud-metadata IP addresses — in their personal email notification settings, with no server-side SSRF validation. When the scheduled notification cron job runs, it passes the stored host directly to PHPMailer, causing the Wallos server to open an outbound TCP connection to whatever address the attacker specified. This gives a low-privileged attacker a reliable mechanism to probe internal network services from the server's perspective. This issue has been patched in version 5.0.0.

Wallos: SSRF via Test Email Notification - unvalidated SMTP host/port

Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 4.9.6, POST /endpoints/notifications/testemailnotifications.php accepts smtpaddress and smtpport from POST body with zero SSRF validation. PHPMailer connects to attacker-supplied host:port. Every other notification endpoint uses ssrf_helper.php but email was missed. Any authenticated user can probe internal network, cloud metadata. This issue has been patched in version 4.9.6.

jina-ai reader Server-Side Request Forgery via disabled private-address guard

jina-ai reader disables its private-address guard outside Google Cloud deployments, allowing unauthenticated attackers to perform server-side request forgery. Attackers can supply publicly resolvable hostnames mapping to private addresses to retrieve cloud metadata and internal service content.

SSRF via Tenable Proxy Endpoint in Heimdall 2.11.6-2.13.x

In MITRE SAF Heimdall 2.11.6 through 2.13.x before 2.14.0, an SSRF issue allows remote attackers to access internal network resources via the Tenable proxy endpoint. This occurs in apps/backend/src/tenable/tenable.controller.ts.