CVE-2026-13303 in Boundary
Summary
by MITRE • 10/29/2026
HashiCorp Boundary and Boundary Enterprise are vulnerable to a server-side request forgery in the Vault credential store integration that may allow an authenticated user with permission to manage credential stores and credential libraries within a project to cause the Boundary controller to issue outbound requests to a network destination of the requester's choosing and to receive the response. This may expose endpoints reachable only from the controller's host, such as a cloud instance metadata service. This vulnerability, CVE-2026-13303, is fixed in Boundary Enterprise 1.0.2 and 0.21.6.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The identified security flaw, designated as CVE-2026-13303, represents a critical server-side request forgery vulnerability within the HashiCorp Boundary platform, specifically affecting its integration with Vault credential stores in both Boundary and Boundary Enterprise editions. This vulnerability stems from insufficient validation of user-supplied input when configuring or managing credential store resources. An attacker who has obtained authenticated access to the system and possesses specific administrative permissions can exploit this flaw by manipulating the configuration parameters associated with a credential library or store. By crafting malicious requests that specify arbitrary network destinations, the attacker forces the Boundary controller to initiate outbound HTTP connections to addresses of their choosing rather than strictly limiting communication to trusted Vault endpoints.
The technical mechanism behind this exploitation relies on the architectural design where the Boundary controller acts as an intermediary for retrieving credentials from HashiCorp Vault. When a user with management privileges creates or updates a credential library, they define the target Vault address and authentication method. Due to the lack of strict allowlisting or rigorous validation of these destination addresses during the configuration process, the system trusts the input blindly. Consequently, when subsequent operations trigger credential retrieval, the controller executes an outbound request to the attacker-controlled server instead of the intended internal vault instance. This behavior effectively turns the Boundary service into a proxy for SSRF attacks, allowing the requester to leverage the network context and privileges of the Boundary host machine.
The operational impact of this vulnerability is severe due to its potential to facilitate lateral movement and data exfiltration within private networks. Because the requests originate from the Boundary controller's host, they can reach internal services that are not exposed to the public internet but are accessible via the local network interface. A primary target for such exploitation is cloud instance metadata services, which typically reside at well-known IP addresses like 169.254.169.254 on AWS or similar endpoints in other cloud environments. By directing requests toward these metadata service IPs, an attacker can retrieve sensitive infrastructure details, including temporary security credentials, IAM role information, and instance configuration data. This access can lead to the compromise of broader cloud resources if the retrieved credentials are used to escalate privileges within the cloud environment.
From a classification perspective, this vulnerability aligns with CWE-918, which defines Server-Side Request Forgery (SSRF), specifically involving the manipulation of server-side processes to make requests on behalf of an authenticated user. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1557, known as Adversary-in-the-Middle or Lateral Tool Transfer via SSRF, and potentially T1046, Network Service Discovery, if used to probe internal services. The vulnerability highlights the risks associated with trusting administrative inputs in systems that perform network operations on behalf of users, particularly when those operations involve external connectivity from privileged hosts.
Mitigation strategies must focus on both immediate remediation and long-term architectural hardening. HashiCorp has addressed this issue by releasing patched versions of Boundary Enterprise 1.0.2 and version 0.21.6 for the open-source edition. Organizations running affected versions should prioritize upgrading to these fixed releases immediately to eliminate the root cause of the vulnerability. In addition to patching, administrators should implement strict network segmentation policies that restrict outbound traffic from Boundary controller hosts to only known and necessary destinations. Utilizing firewall rules or security groups to block access to cloud metadata service IPs is a critical defensive measure that can mitigate the impact even if an attacker attempts to exploit this flaw before patches are applied. Furthermore, enforcing principle of least privilege by limiting who has permission to manage credential stores and libraries reduces the attack surface available to potential insiders or compromised accounts with elevated permissions.