CVE-2026-85699: jina-ai reader SSRF Vulnerability

CVE-2026-85699 Overview

CVE-2026-85699 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in the jina-ai/reader service. The application validates the initial URL supplied by the user but fails to re-apply that validation across HTTP redirect hops. An attacker can host a publicly reachable URL that issues a redirect to internal network addresses or cloud metadata endpoints. The reader service follows the redirect and returns the response body to the attacker.

Critical Impact
Unauthenticated attackers can reach internal-only services and cloud instance metadata (for example, AWS IMDS at 169.254.169.254), enabling exposure of credentials, tokens, and internal application data.

Affected Products

jina-ai reader (curl service path, src/services/curl.ts)
jina-ai reader (puppeteer service path, src/services/puppeteer.ts)
Deployments of the reader referenced at commit 1574bfd380d249c86c82db4dace0d9c8fe17e2b1

Discovery Timeline

2026-09-04 - CVE-2026-85699 published to the National Vulnerability Database
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-85699

Vulnerability Analysis

The jina-ai/reader service accepts a user-supplied URL and fetches its contents to return processed page data. Two fetch backends are involved: a curl-based service and a Puppeteer-based headless browser service. Both perform SSRF-relevant validation on the initial URL only.

When the remote server returns an HTTP 3xx redirect, the fetcher follows the Location header without re-executing the URL allow-list or blocklist. An attacker hosts https://attacker.example/redirect, which responds with a redirect to an internal target. The reader completes the request against that internal target and returns the response body in the API response.

This pattern grants unauthenticated read access to any HTTP-reachable resource visible to the reader host. Cloud metadata services, internal admin panels, and localhost-bound debug endpoints are typical targets.

Root Cause

URL validation is implemented as a one-shot check on the entry-point request rather than as a per-hop policy enforced by the HTTP client. Neither curl.ts nor puppeteer.ts re-validates redirect destinations against the intended network policy. This is a classic redirect-based SSRF filter bypass tracked under CWE-918.

Attack Vector

Exploitation requires only network access to the reader endpoint. The attacker submits an ordinary-looking public URL. The controlled origin responds with HTTP 302 Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/ or a similar internal target. The reader follows the redirect and returns the fetched body, delivering internal data to the attacker with no authentication required.

Reference: the VulnCheck SSRF Advisory and GitHub Issue #1252 document the redirect bypass. Source files: curl service and Puppeteer service.

Detection Methods for CVE-2026-85699

Indicators of Compromise

Outbound reader traffic to RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or to loopback ranges.
Reader-originated requests to cloud metadata endpoints such as 169.254.169.254, metadata.google.internal, or fd00:ec2::254.
User-submitted URLs whose DNS or HTTP responses redirect to private, link-local, or metadata hosts.

Detection Strategies

Instrument the fetch backends to log every hop of a redirect chain, including final resolved IP addresses.
Alert on any reader request whose final destination IP falls outside the intended public-only allow-list.
Correlate reader access logs with egress firewall logs to identify requests that terminated on internal ranges.

Monitoring Recommendations

Forward reader application logs and egress proxy logs into a central analytics platform for cross-referencing.
Track baseline volumes of redirect-following requests and alert on statistical spikes.
Monitor cloud audit logs (for example, AWS CloudTrail GetCallerIdentity calls) for use of credentials that should never leave the reader host.

How to Mitigate CVE-2026-85699

Immediate Actions Required

Restrict reader egress at the network layer to a public-only destination set using an egress proxy or firewall policy.
Disable automatic redirect following in the fetch client, or cap maxRedirects to 0 and handle redirects in application code with re-validation.
Remove or scope any cloud instance-role credentials attached to the reader host so metadata exfiltration yields no usable tokens.
Enforce IMDSv2 on AWS deployments so a simple SSRF GET cannot retrieve credentials.

Patch Information

No fixed version identifier is listed in the NVD record at time of publication. Track the upstream project via GitHub Issue #1252 and the jina-ai/reader repository for a patched release. Apply the vendor patch once available and re-validate the redirect-handling logic in both src/services/curl.ts and src/services/puppeteer.ts.

Workarounds

Deploy the reader behind an egress proxy that blocks RFC1918, loopback, link-local, and cloud metadata destinations.
Resolve the submitted hostname to an IP first, validate the IP against a blocklist, and pin the connection to that IP to defeat DNS rebinding.
Wrap the fetch client so that every redirect target is re-validated against the same allow-list applied to the initial URL.

bash

# Example egress restriction using iptables to block SSRF-relevant destinations
iptables -A OUTPUT -m owner --uid-owner reader -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner reader -d 10.0.0.0/8      -j REJECT
iptables -A OUTPUT -m owner --uid-owner reader -d 172.16.0.0/12   -j REJECT
iptables -A OUTPUT -m owner --uid-owner reader -d 192.168.0.0/16  -j REJECT
iptables -A OUTPUT -m owner --uid-owner reader -d 127.0.0.0/8     -j REJECT