CVE-2026-129485 in Kroki
Summary
by MITRE • 11/15/2026
Kroki before 0.36.0 contains a server-side request forgery vulnerability in the BlockDiag family of engines that allows unauthenticated attackers to make server requests via node icon and background attributes. Attackers can send crafted diagrams to POST /blockdiag/svg or sibling endpoints to query internal services or cloud metadata and read local image files from the server.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability identified in Kroki versions prior to 0.36.0 represents a critical Server-Side Request Forgery (SSRF) flaw within the BlockDiag family of diagramming engines. This security defect allows unauthenticated attackers to manipulate how the server processes requests for generating diagrams, specifically by exploiting the handling of node icon and background attributes. When an attacker submits a crafted diagram definition via POST requests to endpoints such as /blockdiag/svg or related sibling interfaces, they can inject malicious values into these specific attribute fields. The underlying engine fails to adequately sanitize or validate these inputs before attempting to fetch resources referenced within them, thereby allowing the server itself to initiate network connections based on user-controlled data rather than legitimate application logic.
From a technical perspective, this flaw stems from insufficient input validation and lack of URL scheme restrictions when resolving external resources for diagram rendering components. By specifying arbitrary URLs in the node icon or background attributes, an attacker forces the Kroki service to act as a proxy, fetching content from destinations chosen by the user. This capability is particularly dangerous because it bypasses standard client-side security controls like Cross-Origin Resource Sharing (CORS) policies that typically restrict web browsers from making cross-domain requests. Since the request originates from the server infrastructure itself, firewalls and network segmentation rules designed to protect internal services may not apply or may be misconfigured for outbound traffic initiated by application processes.
The operational impact of this vulnerability is severe, enabling a range of malicious activities against both on-premises and cloud-based deployments. Attackers can leverage this SSRF vector to probe the local network topology, discovering internal services that are otherwise inaccessible from the public internet. Furthermore, in cloud environments, attackers frequently use such vulnerabilities to access instance metadata endpoints, which often contain sensitive credentials, API keys, and configuration details necessary for further compromise of the underlying infrastructure. Additionally, because the vulnerability allows reading local image files, an attacker can potentially exfiltrate sensitive data stored on the server's filesystem if they know or can guess file paths that are accessible by the user account running the Kroki process.
This incident aligns with CWE-918, which defines Server-Side Request Forgery as a weakness where a web application fetches a remote resource without validating the user-supplied URL. It also maps to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer variants that utilize SSRF for network reconnaissance and credential theft. The lack of authentication requirement exacerbates the risk, as any external actor with access to the diagramming interface can exploit this flaw without needing valid credentials.
To mitigate this vulnerability, organizations running Kroki must immediately upgrade to version 0.36.0 or later, where these input validation checks have been implemented. In environments where upgrading is not immediately feasible, network-level mitigations should be employed. This includes configuring outbound firewall rules to restrict the server's ability to make HTTP requests to internal IP ranges and cloud metadata service endpoints such as 169.254.169.254 for AWS or similar addresses for other providers. Additionally, implementing a web application firewall with specific rules to detect and block SSRF patterns in POST body parameters can provide an additional layer of defense until the software patch is applied.