CVE-2026-90769: SSRF — HIGH

CISO Take

Open Notebook fails to validate the URL supplied to its source-ingestion endpoint, letting any authenticated user force the application server to make arbitrary outbound HTTP requests — including to cloud metadata endpoints (AWS/GCP/Azure IMDS), internal-only APIs, and localhost-bound services that should never be reachable from outside. There's no EPSS score yet since this is a fresh disclosure, it isn't in CISA KEV, and no public exploit or Nuclei template exists today, so this isn't an active mass-exploitation event — but the attack requires only low privileges, no user interaction, and low complexity (CVSS 7.7, AV:N/AC:L/PR:L), meaning any low-trust account (including a free-tier or shared-workspace user) can pivot straight to your cloud IAM credentials. The scope-changed (S:C) rating in the vector reflects exactly this: impact extends beyond the vulnerable component into whatever internal network the app server sits on. Patch to Open Notebook 1.11.0 immediately; if you can't patch right away, block outbound requests from the app server to link-local/metadata ranges (169.254.169.254, RFC1918 space) at the network or egress-proxy layer and require IMDSv2 with hop-limit 1 on any AWS-hosted instance. Detection: alert on POST /api/sources payloads containing non-http(s) schemes, internal IPs, or metadata-service hostnames, and audit `sources` table entries for URLs pointing at 169.254.169.254 or private ranges.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk despite the absence of a KEV listing or known exploit: the vulnerability is trivially exploitable (CWE-918 classic SSRF, AC:L, PR:L, UI:N) and the scope-changed CVSS component confirms the blast radius extends past the application into the hosting environment's internal network and cloud control plane. Any authenticated user — even a low-privilege one — can weaponize this immediately with a single crafted request; no AI/ML-specific expertise is required. The lack of public PoC/Nuclei coverage today should not be read as low urgency given how mechanical SSRF discovery and exploitation is once the vulnerable parameter is known (it's now public via the GitHub advisory and commit diff).

How does the attack unfold?

Initial Access

An authenticated low-privilege user submits a crafted internal/metadata URL as a new 'source' via POST /api/sources.

AML.T0049

Server-Side Request Forgery

The application server fetches the attacker-controlled URL directly, without validating that it targets internal or metadata addresses.

AML.T0075

Impact

The fetched response (cloud credentials, internal service data, or localhost-bound secrets) is stored/returned to the attacker as the ingested source content, enabling further compromise of the hosting environment.

Initial Access

An authenticated low-privilege user submits a crafted internal/metadata URL as a new 'source' via POST /api/sources.

AML.T0049

Server-Side Request Forgery

The application server fetches the attacker-controlled URL directly, without validating that it targets internal or metadata addresses.

AML.T0075

Impact

The fetched response (cloud credentials, internal service data, or localhost-bound secrets) is stored/returned to the attacker as the ingested source content, enabling further compromise of the hosting environment.

How severe is it?

CVSS 3.1

7.7 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I None

A None

What should I do?

1 step

Upgrade to Open Notebook 1.11.0 or later, which fixes the missing URL validation per the linked GitHub commit. Until patched: place an egress allowlist/proxy in front of the app server that blocks requests to RFC1918/link-local ranges and the cloud metadata IP (169.254.169.254), enforce IMDSv2 with a hop limit of 1 on AWS to neutralize metadata-credential theft even if SSRF succeeds, and run the app server with the least-privilege IAM role possible so a successful SSRF yields minimal value. Detection: log and alert on outbound requests from the source-fetch worker to internal IP ranges or non-standard schemes (file://, gopher://, etc.), and review existing sources records for suspicious internal/metadata URLs already ingested.

How is it classified?

Data Leakage Privacy Violation RAG Framework AML.T0049 - Exploit Public-Facing Application AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.3 - AI system security controls

NIST AI RMF

MANAGE-2.3 - Third-party AI system risk response

OWASP LLM Top 10

LLM08 - Vector and Embedding Weaknesses / Insecure Data Ingestion

Frequently Asked Questions

What is CVE-2026-90769?

Open Notebook fails to validate the URL supplied to its source-ingestion endpoint, letting any authenticated user force the application server to make arbitrary outbound HTTP requests — including to cloud metadata endpoints (AWS/GCP/Azure IMDS), internal-only APIs, and localhost-bound services that should never be reachable from outside. There's no EPSS score yet since this is a fresh disclosure, it isn't in CISA KEV, and no public exploit or Nuclei template exists today, so this isn't an active mass-exploitation event — but the attack requires only low privileges, no user interaction, and low complexity (CVSS 7.7, AV:N/AC:L/PR:L), meaning any low-trust account (including a free-tier or shared-workspace user) can pivot straight to your cloud IAM credentials. The scope-changed (S:C) rating in the vector reflects exactly this: impact extends beyond the vulnerable component into whatever internal network the app server sits on. Patch to Open Notebook 1.11.0 immediately; if you can't patch right away, block outbound requests from the app server to link-local/metadata ranges (169.254.169.254, RFC1918 space) at the network or egress-proxy layer and require IMDSv2 with hop-limit 1 on any AWS-hosted instance. Detection: alert on POST /api/sources payloads containing non-http(s) schemes, internal IPs, or metadata-service hostnames, and audit `sources` table entries for URLs pointing at 169.254.169.254 or private ranges.

Is CVE-2026-90769 actively exploited?

No confirmed active exploitation of CVE-2026-90769 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-90769?

Upgrade to Open Notebook 1.11.0 or later, which fixes the missing URL validation per the linked GitHub commit. Until patched: place an egress allowlist/proxy in front of the app server that blocks requests to RFC1918/link-local ranges and the cloud metadata IP (169.254.169.254), enforce IMDSv2 with a hop limit of 1 on AWS to neutralize metadata-credential theft even if SSRF succeeds, and run the app server with the least-privilege IAM role possible so a successful SSRF yields minimal value. Detection: log and alert on outbound requests from the source-fetch worker to internal IP ranges or non-standard schemes (file://, gopher://, etc.), and review existing `sources` records for suspicious internal/metadata URLs already ingested.

What systems are affected by CVE-2026-90769?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, document/source ingestion pipelines, self-hosted AI knowledge tools.

What is the CVSS score for CVE-2026-90769?

CVE-2026-90769 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.26%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesdocument/source ingestion pipelinesself-hosted AI knowledge tools

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

ISO 42001: A.6.2.3

NIST AI RMF: MANAGE-2.3

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

Open Notebook before 1.11.0 fails to validate the URL parameter in POST /api/sources endpoint, allowing authenticated users to perform server-side requests to internal services. Attackers can supply arbitrary URLs to read cloud metadata, internal network services, and localhost-bound services through the application server's direct HTTP requests.

Exploitation Scenario

An attacker who has obtained (or self-registered, if signup is open) a low-privileged account on a shared Open Notebook instance submits a new 'source' with a URL of `http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>` instead of a legitimate article link. The server-side ingestion worker fetches this URL directly and stores/returns the response as the source's extracted content, handing the attacker the instance's temporary IAM credentials inside the notebook UI. Using those credentials, the attacker pivots into the cloud account to access S3 buckets, other internal APIs, or the database backing the application — turning a content-ingestion feature into a full cloud-environment compromise.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF)

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Source: MITRE CWE corpus.