CVE-2026-90769 in Open Notebook
Summary
by MITRE • 09/13/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in Open Notebook versions prior to 1.11.0 represents a critical Server-Side Request Forgery (SSRF) flaw within its API infrastructure. Specifically, the POST /api/sources endpoint fails to adequately validate or sanitize the URL parameter provided by authenticated users during source configuration. This lack of input validation allows an attacker who has obtained valid credentials for the application to inject arbitrary Uniform Resource Locators into HTTP requests initiated by the server itself. Because Open Notebook operates as a web-based knowledge management tool, it frequently makes outbound network connections to fetch content from configured sources; however, in this instance, the mechanism designed to retrieve external data is weaponized against internal infrastructure due to insufficient boundary checks on the destination address.
From a technical perspective, the core issue lies in the application's handling of user-supplied input within an administrative or configuration context that triggers backend network activity. When a user submits a source URL via the API, the server processes this value without verifying whether it points to a trusted external domain or if it attempts to access local resources. This oversight enables the attacker to direct the server’s HTTP client toward internal endpoints that are typically inaccessible from outside the application's perimeter. By manipulating the request destination, an authenticated user can force the Open Notebook server to act as a proxy, sending requests to localhost addresses, private IP ranges associated with cloud metadata services, or other sensitive internal microservices running on the same network segment.
The operational impact of this vulnerability is severe, primarily because it facilitates unauthorized access to sensitive data and internal service enumeration through an authenticated vector. Attackers can exploit this flaw to read cloud provider instance metadata, such as AWS EC2 metadata (169.254.169.254) or Azure managed identity endpoints, which often contain temporary security credentials for other services running on the same host. Furthermore, by targeting localhost-bound services, an attacker may interact with internal APIs, databases, or monitoring tools that are not exposed to the public internet but remain reachable from within the application server's network context. This capability effectively bypasses traditional perimeter defenses like firewalls and web application firewalls, as the traffic originates from a trusted internal host—the Open Notebook server itself—making detection by external security controls difficult without deep packet inspection or specific egress filtering rules.
To mitigate this risk, organizations running versions of Open Notebook earlier than 1.11.0 should prioritize immediate upgrading to the patched version where input validation and URL allow-listing mechanisms have been implemented. In scenarios where an upgrade is not immediately feasible, network-level controls such as strict egress firewall policies can be deployed to restrict outbound connections from the application server's IP address to only known external domains required for functionality. Additionally, implementing a reverse proxy with robust SSRF protection rules or configuring the underlying HTTP client library to disable redirects and enforce domain whitelisting can significantly reduce the attack surface. Monitoring network logs for unusual outbound traffic patterns originating from the Open Notebook service is also recommended to detect potential exploitation attempts in real-time.
This vulnerability aligns with Common Weakness Enumeration (CWE) ID 918, which defines Server-Side Request Forgery as a weakness where a web server receives a URL or similar request and makes it to retrieve content without validating the user's intent. It also maps directly to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle (AitM) or Lateral Tool Transfer variants that leverage SSRF for credential theft and internal network reconnaissance. The exploitation path demonstrates how authenticated users can pivot from application-level access to infrastructure-level compromise by abusing the trust relationship between the web application and its backend services.