Appium Java Client is the Java language binding for writing Appium tests that conform to the W3C WebDriver protocol. From 8.2.1 until 10.1.1, when directConnect(true) is enabled, AppiumCommandExecutor.setDirectConnect() reads the directConnectHost, directConnectPort, and directConnectPath fields from the server's NEW_SESSION response and rebuilds the client's server URL from them, validating only that the protocol is https, with no host allowlist or IP validation; a rogue or compromised server can therefore redirect all subsequent session traffic to an arbitrary destination, enabling full interception of session traffic and a server-side request forgery pivot to internal hosts, including cloud metadata (IMDS) credential theft. This vulnerability is fixed in 10.1.1.
A URL validation weakness in JFrog Artifactory Ansible repository handling could allow a user, under specific repository access conditions, to cause unintended server-side requests.
The issue primarily affects confidentiality and integrity and has been addressed in fixed Artifactory versions.
JFrog Artifactory support for Terraform remote repositories was found to be susceptible to Server-Side Request Forgery (SSRF). An authenticated user - or, if anonymous access is enabled on the repository, an unauthenticated user - could cause Artifactory to issue outbound HTTP requests to arbitrary destinations and receive the response content.
Improper URL validation when handling specific URLs, allows an attacker, under certain conditions, to make unauthorized requests from JFrog Artifactory, potentially exposing internal services and cached response data.
A Server-Side Request Forgery (SSRF) vulnerability exists in Next.js versions 14.1.1 through 15.5.20 and 16.0.0 through 16.2.10. The flaw allows an attacker to cause the server to send outbound requests to malicious hosts by controlling Host-associated headers when Server Actions forward or redirect requests. This affects applications where the incoming host header is not fixed to a trusted value, typically in custom server setups or deployments not behind a host-pinning proxy. Managed hosting and certain Next.js configurations from version 14.2 onward are not affected. The issue has been fixed in versions 15.5.21 and 16.2.11.
A Server-Side Request Forgery (SSRF) and credential exfiltration vulnerability exists in the cloud-healthcare-fhir-fetch-page tool of googleapis/mcp-toolbox.
The tool takes an unvalidated pageURL parameter from the client and issues an HTTP GET request to it using an authenticated client. The underlying transport automatically attaches an Authorization: Bearer header to every outbound request regardless of the destination host. An attacker can supply an arbitrary external URL to the pageURL parameter (either directly via the tool execution payload or implicitly via data-driven pagination tracking loops), leading Toolbox into sending its OAuth/service-account access token to an attacker-controlled listener. Depending on the configuration, this leaks either the end-user's token or the broader service-account access token (ADC), potentially exposing Protected Health Information (PHI) and secondary Google Cloud Platform services.
Plack::App::Prerender versions before 0.3.0 for Perl can proxy to an arbitrary host via unvalidated REQUEST_URI concatenation in call.
When the rewrite base is a plain string, the REQUEST_URI is appended to it, with no check that the path starts with a forward slash ('/').
When the rewrite base does not contain a path (which is the standard given in the SYNOPSIS), an attacker can create a request that changes the hostname. A request target starting with an at-sign ('@') changes the base to a RFC 3986 userinfo component.
For example, a rewrite base of "https://example.com" with the submitted request "GET @192.168.1.2/" will send a request to "https://example.com@192.168.1.2/", with the rendered content returned to the attacker.
This allows an attacker to access internal or restricted hosts that only the webserver has access to.
Papra is a minimalistic document management and archiving platform. Prior to version 26.5.0, Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client. This issue has been patched in version 26.5.0.
### Summary
`Address6`'s special-property checks misclassify IPv4-mapped (`::ffff:0:0/96`) and NAT64 well-known (`64:ff9b::/96`) IPv6 addresses. These checks classify an address by its IPv6 wrapper rather than by the IPv4 address it embeds, so `isLoopback()`, `isLinkLocal()`, `isMulticast()`, and `isUnspecified()` all return `false` for literals such as `::ffff:127.0.0.1` or `::ffff:169.254.169.254` that actually route to loopback, RFC 1918, or link-local (cloud-metadata) destinations. `Address6` also had no `isPrivate()` method, so a mapped RFC 1918 address could not be detected at all.
An application that builds a network trust-boundary decision on these checks (for example, a filter intended to block Server-Side Request Forgery, or SSRF) may therefore treat an internal target as external and allow the request. SSRF is an attack in which a user-supplied address coaxes the server into making a request to an internal destination the user could not otherwise reach, such as a loopback service or a cloud metadata endpoint.
### Details
`Address6.getType()` classifies an address by matching it against a table of known IPv6 special-use prefixes, returning `Global unicast` when nothing matches. That table had no entry for the IPv4-mapped range (`::ffff:0:0/96`), so every mapped address fell through to `Global unicast`; NAT64 addresses matched their own `NAT64 …` labels. The boolean checks `isLoopback`, `isUnspecified`, and `isMulticast` compared `getType()` against a fixed label and so returned `false`, while `isLinkLocal` and `isULA` checked only the native IPv6 ranges.
The library already exposed `isMapped4()` and `to4()`, but did not apply them inside these checks, so a mapped or NAT64 address was never normalized to its embedded IPv4 address before classification. The underlying CIDR matching is correct; the defect is that the special-use table omitted the IPv4-mapped range and the checks performed no embedded-IPv4 normalization.
### Affected versions
`>= 10.1.1, <= 10.2.0`. The `is*` classification API was introduced for `Address4` in 10.1.1 and extended to `Address6` in 10.2.0. Releases before 10.1.1 do not expose this API and are not affected through this vector.
### Impact
The misclassification covers the entire `::ffff:0:0/96` range, in both dotted and hex notation and case-insensitively, plus the `64:ff9b::/96` NAT64 well-known prefix:
| Address | Reported as | Actually points at |
|---|---|---|
| `::ffff:127.0.0.1` / `::ffff:7f00:1` | Global unicast | loopback (`127.0.0.0/8`) |
| `::ffff:10.0.0.1` | Global unicast | RFC 1918 `10/8` |
| `::ffff:172.16.5.5` | Global unicast | RFC 1918 `172.16/12` |
| `::ffff:192.168.1.1` | Global unicast | RFC 1918 `192.168/16` |
| `::ffff:169.254.169.254` / `::ffff:a9fe:a9fe` | Global unicast | link-local / cloud metadata (IMDS) |
| `::ffff:100.64.0.1` | Global unicast | CGNAT `100.64/10` |
| `::ffff:0.0.0.0` / `::ffff:255.255.255.255` | Global unicast | unspecified / broadcast |
| `64:ff9b::7f00:1` / `64:ff9b::a9fe:a9fe` | NAT64 (well-known) | loopback / IMDS via NAT64 |
For IPv4-mapped addresses the host OS routes to the IPv4 stack, so the misclassification is reachable on any dual-stack host. For NAT64, the classification bypass is unconditional but end-to-end reachability additionally requires a NAT64/DNS64 gateway in the deployment network.
### Proof of concept
A guard assembled from these checks lets internal hosts through:
```js
const { Address4, Address6 } = require('ip-address');
// true => block as internal, false => allow outbound
function isBlocked(host) {
try {
const a = new Address4(host);
return a.isPrivate() || a.isLoopback() || a.isLinkLocal() || a.isCGNAT()
|| a.isMulticast() || a.isUnspecified() || a.isBroadcast();
} catch {}
try {
const a = new Address6(host);
return a.isLoopback() || a.isLinkLocal() || a.isULA()
|| a.isMulticast() || a.isUnspecified();
} catch {}
return false;
}
for (const h of ['127.0.0.1', '::1', '10.0.0.1', '8.8.8.8',
'::ffff:127.0.0.1', '::ffff:10.0.0.1',
'::ffff:169.254.169.254', '64:ff9b::7f00:1']) {
console.log(isBlocked(h) ? 'BLOCK ' : 'ALLOW ', h);
}
```
On affected versions this prints (note that every `::ffff:…` and `64:ff9b::…` internal target is allowed):
```
BLOCK 127.0.0.1
BLOCK ::1
BLOCK 10.0.0.1
ALLOW 8.8.8.8
ALLOW ::ffff:127.0.0.1
ALLOW ::ffff:10.0.0.1
ALLOW ::ffff:169.254.169.254
ALLOW 64:ff9b::7f00:1
```
The first three lines (native loopback, native IPv6 loopback, and a literal RFC 1918 address) are blocked as expected; the IPv4-mapped and NAT64 forms of the same internal destinations are allowed through.
### Remediation
Upgrade to the patched release. In the fix, `Address6` normalizes IPv4-mapped and NAT64 well-known addresses to their embedded IPv4 address before classifying, via a new `embeddedIPv4()` helper that `isLoopback`, `isLinkLocal`, `isMulticast`, and `isUnspecified` consult first. `Address6` als
Next.js versions 12.0.0 through 15.5.20 and 16.0.0 through 16.2.10 contain a Server-Side Request Forgery (SSRF) vulnerability. This occurs when rewrites() or redirects() rules build external destination hostnames from request-controlled input, allowing attackers to specify arbitrary hostnames. Rewrites proxy requests to these arbitrary hosts, enabling SSRF, while redirects can lead to open redirect vulnerabilities. The issue is fixed in versions 15.5.21 and 16.2.11.
A VCO feature does not sufficiently validate caller-supplied input, allowing requests to be made on behalf of authenticated tenant accounts to internal services that are not otherwise accessible. This vulnerability requires a minimum role of Enterprise Standard Admin.
This issue was discovered internally by Arista and the company is not aware of any malicious uses of this issue in customer networks.
Kimi Code (@moonshot-ai/kimi-code) before 0.27.0 implements FetchURL SSRF hardening as a static hostname and IP-literal denylist in assertSafeFetchTarget, without resolving DNS or re-validating hosts after HTTP redirects. An attacker who can influence a FetchURL call (for example via prompt injection) can supply a crafted public hostname that resolves to loopback or another internal address, or a public URL that redirects to such a target, and thereby reach internal network services that the denylist was intended to block. FetchURL is included in the default auto-approve tool set, so the call does not require interactive user confirmation in manual mode.
The Printcart Web to Print Product Designer for WooCommerce WordPress plugin before 2.5.3 does not restrict a user-supplied URL before fetching it server-side and does not enforce a valid authorization check, allowing unauthenticated attackers to read arbitrary local files (including configuration files containing database credentials and secret keys) and to make server-side requests to internal resources.