Total
4032 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-114634 | 2026-10-23 | N/A | 4.3 MEDIUM | ||
| WWBN AVideo before 29.4.0 contains a blind server-side request forgery vulnerability in getHeaderContentTypeFromURL() because get_headers() follows redirects without re-validating targets with isSSRFSafeURL(). Authenticated uploaders can store a videoLink pointing to a redirector, causing internal GET requests when visitors view the video, enabling internal port scanning via the embed-versus-video render oracle. | |||||
| CVE-2026-75885 | 2026-10-23 | N/A | 9.3 CRITICAL | ||
| A flaw was found in the OpenShift console. Unauthenticated access to the `/api/devfile/` and `/api/devfile/samples/` endpoints allows a remote attacker to send crafted devfile payloads. This can lead to Server-Side Request Forgery (SSRF), where the console pod makes requests to internal services and reflects partial responses to the attacker. Additionally, by sending repeated large requests without a specified content length, an attacker can cause unbounded memory growth, leading to a Denial of Service (DoS). | |||||
| CVE-2026-111761 | 2026-10-22 | N/A | 5.8 MEDIUM | ||
| A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final. | |||||
| CVE-2026-75844 | 2026-10-22 | N/A | 7.1 HIGH | ||
| ArcadeDB versions before 26.8.1 contain a server-side request forgery vulnerability in the IMPORT DATABASE command where the security validator resolves and checks hostnames but the subsequent connection re-resolves the raw URL and follows redirects. Authenticated attackers can bypass the validator using DNS rebinding or HTTP redirects to access cloud metadata endpoints, internal services, or read arbitrary local files on default installations. | |||||
| CVE-2026-68927 | 2026-10-22 | N/A | 3.0 LOW | ||
| MobSF is a mobile application security testing tool used. Prior to 4.5.1, get_browsable_activities in mobsf/StaticAnalyzer/views/android/manifest_analysis.py validates only an Android manifest android:host value with valid_host before appending a separately supplied android:port to the URL fetched by _check_url, allowing an authenticated user to upload a crafted APK that makes requests to an attacker-selected nonstandard port at /.well-known/assetlinks.json. With an attacker-controlled hostname and DNS rebinding between validation and the requests.get connection, the request can reach an internal service, although redirects remain disabled and the path is fixed. This issue is fixed in version 4.5.1. | |||||
| CVE-2026-70667 | 2026-10-22 | N/A | 6.3 MEDIUM | ||
| Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_revocation_url in lemur/certificates/verify.py checked the original CRL or OCSP URL but the later request could reach a different destination. The CRL requests.get call followed HTTP redirects without validating each Location target, so a public attacker-controlled URL could redirect to loopback, RFC1918, link-local, or instance-metadata addresses. Validation and connection also performed separate DNS resolutions, creating a time-of-check time-of-use window for DNS rebinding on both CRL and OCSP paths. An operator uploading a certificate through POST /api/1/certificates/upload could therefore induce blind internal requests despite the earlier mitigation. The fix disables redirects and pins validated addresses while preserving the correct Host value. This issue is fixed in version 1.9.3. | |||||
| CVE-2026-50143 | 2026-10-22 | N/A | 8.1 HIGH | ||
| The Apify MCP server enables AI agents to extract data from websites using ready-made scrapers, crawlers, and automation tools available on the Apify Store. Prior to 0.10.11, getActorMCPServerURL in src/mcp/actors.ts concatenates the trusted Actor standby URL with the attacker-controlled webServerMcpPath from an Actor definition without verifying the resulting origin, allowing a malicious Actor publisher to use a userinfo-style authority value to redirect connectMCPClient to a third-party host. The call-actor, fetch-actor-details, and actor-mcp tool-loading paths pass this URL to transports in src/mcp/client.ts that attach the victim Authorization bearer token, exposing the Apify API token and enabling access to Actors, stored data, and billable compute. A victim must invoke or inspect the attacker-controlled Actor. This issue is fixed in version 0.10.11. | |||||
| CVE-2026-12564 | 2026-10-22 | N/A | 9.6 CRITICAL | ||
| A flaw was found in the AAP Controller's HashiCorp Vault credential plugin. The kubernetes_auth() function in awx_plugins/credentials/hashivault.py reads the controller pod's Kubernetes service account token and sends it to an attacker-controlled URL when a HashiCorp Vault Secret Lookup credential with kubernetes_role authentication is tested. An authenticated attacker with credential-creation privileges can exfiltrate the service account token, gaining Kubernetes API access to the control plane namespaces with full pod CRUD and secret read permissions, including database credentials and the Django SECRET_KEY. | |||||
| CVE-2026-75856 | 2026-10-22 | N/A | 8.6 HIGH | ||
| CodeWhale before 0.8.64 contains a server-side request forgery bypass vulnerability in DNS pinning logic that fails to prevent time-of-check-time-of-use attacks. Attackers can manipulate DNS responses to fail initial resolution checks and succeed on secondary requests, allowing requests to internal IP addresses and bypassing SSRF mitigations. | |||||
| CVE-2026-32553 | 2026-10-22 | N/A | 7.2 HIGH | ||
| Unauthenticated Server Side Request Forgery (SSRF) in OttoKit <= 1.1.35 versions. | |||||
| CVE-2026-55162 | 2026-10-22 | N/A | 6.3 MEDIUM | ||
| Lemur manages TLS certificate creation. Prior to 1.9.2, lemur/certificates/verify.py accepted CRL Distribution Point and OCSP responder URLs from uploaded certificate extensions and used them in crl_verify and ocsp_verify without adequate destination validation. An authenticated operator could submit a certificate through POST /api/1/certificates/upload and cause verify_string to reach loopback, RFC1918, link-local, or instance-metadata destinations such as 169.254.169.254. The requests could probe internal services and create side effects from the Lemur host network position. The CRL path also used an unbounded cache, allowing attacker-controlled entries to persist and consume memory. The fix validates destinations, supports explicit trusted-host allowlists, and bounds the CRL cache. This issue is fixed in version 1.9.2. | |||||
| CVE-2026-70666 | 2026-10-22 | N/A | 7.4 HIGH | ||
| Lemur manages TLS certificate creation. Prior to 1.9.3, an authority-role member could update acme_url through PUT /api/1/authorities/ without revalidation and direct setup_acme_client_no_retry to an attacker-controlled ACME server. ACME directory and order responses contain newNonce, newOrder, authorizations, and finalize URLs chosen by that server. The Lemur ClientV2 followed those URLs without requiring their host to match the configured directory host, allowing JWS-signed requests to internal services or cloud metadata endpoints. The issue required an ACME authority and a user authorized for that authority, but did not require global administrator privileges. The fix revalidates updates and introduces _PinnedClientNetwork to enforce a single allowed host for the complete ACME flow. This issue is fixed in version 1.9.3. | |||||
| CVE-2026-75898 | 2026-10-22 | N/A | 8.5 HIGH | ||
| RAGFlow before 0.26.3 contains a server-side request forgery vulnerability in the agent workflow "Invoke" component (agent/component/invoke.py). The component builds an outbound request URL from canvas configuration and runtime template variables and passes it to requests.get, requests.post, or requests.put without calling the shared assert_url_is_safe validator or pinning the resolved address, unlike the crawler, SearXNG, file-upload, and RSS fetch paths. A user who can create or trigger an agent can direct the server to fetch loopback, link-local, and RFC 1918 destinations, including cloud instance metadata endpoints and services co-located on the deployment network, and the response body is returned as the component output. Where an agent is configured to interpolate the chat query into the Invoke URL, the destination is chosen by whoever can send that query. | |||||
| CVE-2026-71303 | 2026-10-22 | N/A | 7.7 HIGH | ||
| Lemur manages TLS certificate creation. Prior to 1.9.3, _validate_acme_url enforced ACME_DIRECTORY_HOST_ALLOWLIST when an authority was created, but PUT /api/1/authorities/ passed options to lemur/authorities/service.py without applying the same check. A user holding an authority role could replace the stored acme_url with an internal service or instance-metadata URL such as 169.254.169.254. The next issuance operation loaded that value and passed it to ClientV2.get_directory, causing an outbound request from the Lemur backend. This bypassed the creation-time mitigation for CVE-2026-55166 and could expose internal services or cloud metadata. The fix revalidates acme_url whenever authority options are updated. This issue is fixed in version 1.9.3. | |||||
| CVE-2026-34884 | 1 Apache | 1 Skywalking Mcp | 2026-10-22 | N/A | 9.8 CRITICAL |
| SSRF via set_skywalking_url Tool and GraphQL expression injection vulnerability in Apache SkyWalking MCP. This issue affects Apache SkyWalking MCP: 0.1.0. Users are recommended to upgrade to version 0.2.0, which fixes this issue. | |||||
| CVE-2026-65985 | 2026-10-22 | N/A | N/A | ||
| FUXA is a web-based Process Visualization (SCADA/HMI/Dashboard) software. In 1.3.2 and earlier, the device-webapi-request Socket.IO handler in server/runtime/index.js permits an authenticated non-admin runtime user to control property.address, causing the FUXA server to issue an outbound HTTP or HTTPS request and return the response body to the requesting socket. The attacker can use the server as a read SSRF oracle against reachable internal services or cloud metadata endpoints, with impact depending on the FUXA host's deployment network. This issue is fixed in version 1.3.3. | |||||
| CVE-2026-63643 | 2026-10-22 | N/A | N/A | ||
| MagicMirror² is an open source modular smart mirror platform. Prior to 2.37.0, the ADD_CALENDAR handler in defaultmodules/calendar/node_helper.js accepts an attacker-controlled URL, authentication data, and selfSignedCert setting through the unauthenticated Socket.IO namespace /calendar. The handler passes these fields to CalendarFetcher, causing a server-side request without SSRF validation and optionally disabling TLS verification. When the response is valid iCal, CALENDAR_EVENTS returns parsed event data to the attacker, allowing internal-service response data to be exfiltrated; other responses still provide a blind request and timing primitive. This issue is fixed in version 2.37.0. | |||||
| CVE-2026-32467 | 2026-10-22 | N/A | 6.0 MEDIUM | ||
| Subscriber Server Side Request Forgery (SSRF) in [Aotuman] Grab WeChat Articles <= 2.0.1 versions. | |||||
| CVE-2026-32473 | 2026-10-22 | N/A | 7.2 HIGH | ||
| Unauthenticated Server Side Request Forgery (SSRF) in PDF Smart Viewer for Elementor <= 1.0.4 versions. | |||||
| CVE-2026-74905 | 2026-10-22 | N/A | 7.1 HIGH | ||
| SiYuan before v3.7.4 contains a server-side request forgery (SSRF) vulnerability in the isPrivateIP function in kernel/util/net.go, used by SSRFSafeDialer to enforce SSRF protection in SafeMode. The function only checks for loopback, link-local unicast, private, and unspecified addresses and does not recognize IPv6 transition addresses (NAT64 64:ff9b::/96, 6to4 2002::/16, Teredo 2001::/32) that embed private IPv4 destinations. When SafeMode is enabled, an authenticated attacker can bypass the SSRF guard via the network forward proxy, WebSocket proxy, or SSE proxy endpoints by supplying a URL whose hostname resolves to such a transition address, reaching internal services and cloud metadata endpoints (e.g., 169.254.169.254). Because the forward proxy returns the full response body, this is a full-read SSRF that can be used to steal instance credentials, reach internal services, and port-scan internal infrastructure. | |||||