Live Exposure Defense: From CVE to Confirmed Exposure in 12 Hours – See more

New CVE Detected

CVE-2026-82638 – SSRF via Disabled Private-Address Guard – jina-ai Reader (self-hosted, up to commit

Be the first to know when new zero-days emerge:

Summary

CVE-2026-82638 is a Server-Side Request Forgery (SSRF) vulnerability in jina-ai’s Reader (the open-source engine behind r.jina.ai, which converts URLs into LLM-friendly content). Self-hosted deployments disable the built-in private-address guard, allowing unauthenticated remote attackers to force the service to fetch internal or cloud-metadata resources by supplying publicly resolvable hostnames that resolve to private IP addresses. The flaw is rated HIGH severity (CVSS 8.7).

Technical details

  • Root cause: In src/services/misc.ts, the privateIpNotAcceptable guard is only enabled when both NODE_ENV contains "prod" and the GCLOUD_PROJECT environment variable is set. Self-hosted/Docker deployments typically lack GCLOUD_PROJECT, so the guard never activates.
  • Trigger condition: When the guard is disabled, DNS resolution of attacker-supplied hostnames is not checked against private/link-local/unique-local IP ranges before the service fetches the target.
  • Attack vector: An unauthenticated attacker submits a URL using a publicly resolvable hostname (e.g., via wildcard DNS services like nip.io) that resolves to a private IP, such as a cloud metadata endpoint or internal service address.
  • Impact: Successful exploitation can expose cloud instance metadata (including IAM credentials on AWS/GCP/Azure), and allows reconnaissance or content exfiltration from internal services such as databases, Kubernetes API servers, and admin interfaces reachable from the Reader host. No integrity or availability impact is reported; the primary impact is confidentiality.

Affected software

  • jina-ai Reader (GitHub: jina-ai/reader), self-hosted deployments, from commit 45d1682db02f0c50b680ad350855da4e38ab2122 through commit 1574bfd380d249c86c82db4dace0d9c8fe17e2b1.
  • Deployments running outside Google Cloud (i.e., without GCLOUD_PROJECT set) are affected; the guard is only active in production Google Cloud deployments.

Severity

  • CVSS v3.1: 7.5 (HIGH) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
  • CVSS v4.0: 8.7 (HIGH) — CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
  • CWE-918: Server-Side Request Forgery (SSRF)

Mitigation and recommended actions

  • Immediate: No official patched release has been published as of this writing. A fix (rejecting hostnames that resolve to non-public IPs) has been proposed in an open, unmerged pull request against the jina-ai/reader repository. Track this pull request and upgrade as soon as a fixed release is available.
  • Workarounds/network mitigations:
    • Do not rely on NODE_ENV/GCLOUD_PROJECT to enable SSRF protection in self-hosted deployments; explicitly enforce private-IP/DNS-resolution filtering at the application or proxy layer regardless of environment.
    • Restrict egress network access from the Reader service/container so it cannot reach cloud metadata endpoints (e.g., block 169.254.169.254) or internal RFC1918/link-local/unique-local address ranges.
    • Run the Reader service with minimal or no cloud IAM privileges attached, to limit the blast radius if metadata is exposed.
    • Place the service behind an authenticating proxy if it is not intended to be publicly reachable.

References

Are you exposed?

Get a free report of your organization’s exposure to this CVE and threat

How IONIX’s External Exposure Management Platform Detects and Validates
Zero-Days to Shrink MTTR

1

Map your entire attack surface (continously)

IONIX uses multi-factor discovery methods, including DNS analysis, certificate mapping, metadata inspection, and more, to automatically map every internet-facing asset across your environment. This includes cloud instances, third-party platforms, shadow IT, and even forgotten infrastructure that traditional tools miss.

2

Monitor for new CVEs

Dozens of threat intel feeds using agentic technology are continuously analyzed to detect the appearance of proof-of-concept code, exploit kits, and indicators of active targeting. IONIX goes further by applying AI to proactively evaluate whether emerging vulnerabilities are likely to be exploited, even before PoCs go public.

3

Identify Potential External Exposures

Not all CVEs matter. IONIX filters vulnerabilities by asking attacker-centric questions: Can it be reached from the internet? Does it require authentication? Is it being exploited in the wild? This dramatically reduces noise and focuses teams on threats that can actually be weaponized.

4

Create Safe, Scalable Exploit Validations

IONIX transforms real-world PoCs into safe, non-intrusive test payloads that can be run in production environments without disruption. These simulations are precisely targeted to the systems that are vulnerable, ensuring rapid validation without unnecessary load.

5

Execute Exploit Validations

By combining context about software stack, versioning, exposure status, and reachability, IONIX ensures that only the right payloads are executed against the right assets, maximizing efficiency and minimizing risk.

6

Drive Fast and Actionable Remediation

Results are routed through integrations with ticketing, SOAR, and SIEM tools. Issues are written in plain language, bundled into remediation clusters, and prioritized based on asset criticality, exploitability, and blast radius. This shortens mean time to remediation (MTTR) and empowers teams to act with confidence.

Are you exposed?

Get a free report of your organization’s exposure to this CVE and threat

Subscribe to Threat Center RSS

Copy/paste the link below into your preferred RSS reader or follow these instructions to subscribe to Slack alerts.

Get Real-Time CVE Alerts to Your Email

Be the first to know when new zero-days emerge