CVE-2026-76820 in OpenCTI
Summary
by MITRE • 09/15/2026
OpenCTI is an open source platform for managing cyber threat intelligence knowledge and observables. Prior to 7.260701.0, the synchronizerFetch GraphQL query called fetchRemoteStreams after checking only that a remote stream URL used HTTP or HTTPS. The backend did not apply the ingestion deny list or reject private, loopback, and link-local destinations, allowing an authenticated account with the INGESTION capability to make OpenCTI request internal services and cloud metadata endpoints. Returned connection errors could distinguish open HTTP ports, open non-HTTP ports, and closed ports, enabling internal network scanning, while compatible endpoint responses could disclose internal data. This issue is fixed in version 7.260701.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
OpenCTI serves as a critical infrastructure component for organizations seeking to manage cyber threat intelligence knowledge and observables effectively. The platform relies on the ability to ingest external data sources, which involves fetching remote streams via GraphQL queries. Prior to version 7.260701.0, this ingestion mechanism contained a significant security flaw related to URL validation logic. Specifically, the synchronizerFetch GraphQL query performed a check that only verified whether the provided remote stream URL utilized either HTTP or HTTPS protocols. This superficial validation failed to implement robust destination filtering mechanisms necessary for secure external communication within enterprise environments.
The core technical vulnerability lies in the absence of strict access control policies regarding network destinations during the ingestion process. The backend system did not apply an ingestion deny list, nor did it reject requests targeting private IP ranges, loopback addresses, or link-local destinations. Consequently, any authenticated user possessing the INGESTION capability could manipulate this function to direct OpenCTI server-side requests toward internal services that are typically inaccessible from external networks. This includes cloud metadata endpoints such as those found in AWS EC2 instance metadata service or Azure managed identity endpoints, which often contain sensitive configuration data and temporary credentials.
The operational impact of this vulnerability extends beyond simple unauthorized access to specific resources. Because the application returned distinct connection error messages for open HTTP ports, open non-HTTP ports, and closed ports, it inadvertently provided a reliable mechanism for internal network scanning. An attacker could systematically probe various IP addresses and port combinations within the internal network infrastructure by observing these differentiated responses. This capability transforms OpenCTI into an effective proxy or pivot point for reconnaissance activities against protected networks that would otherwise be isolated from direct external access.
Furthermore, if compatible endpoints were reachable, the vulnerability allowed for the disclosure of sensitive internal data. By fetching content from internal services such as databases, administrative interfaces, or cloud metadata stores, attackers could extract valuable intelligence about the organization's architecture and security posture. This scenario aligns with Common Weakness Enumeration CWE-918 regarding Server-Side Request Forgery (SSRF), where a web application fetches a remote resource without validating the user-supplied URL sufficiently to prevent access to unintended internal resources.
From an offensive security perspective, this vulnerability maps directly to MITRE ATT&CK technique T1557, which covers Adversary-in-the-Middle and specifically includes Server-Side Request Forgery as a method for lateral movement or data exfiltration within cloud environments. The ability to scan internal ports also relates to reconnaissance techniques such as T1046 Network Service Discovery, allowing attackers to map out the network topology from an initially compromised account with limited privileges.
To mitigate this risk, organizations running OpenCTI must upgrade immediately to version 7.260701.0 or later, where these validation checks have been strengthened to include comprehensive destination filtering. Administrators should also review their existing user roles and ensure that the INGESTION capability is granted only to trusted accounts with a legitimate need for external data ingestion. Implementing network-level controls such as egress firewalls can provide an additional layer of defense by blocking outbound requests from OpenCTI servers to private IP ranges, thereby limiting the blast radius even if application-layer vulnerabilities are discovered in future versions.