Boundary SSRF Turns A Project Role Into Controller-Network Access

HashiCorp has disclosed CVE-2026-13303, a high-severity server-side request forgery flaw in the Vault credential-store integration for Boundary and Boundary Enterprise. An authenticated principal who can manage credential stores and credential libraries inside a project can direct a Boundary controller to an unintended network destination, influence a response that sends the controller onward, and receive the result. The fixed releases are Boundary Enterprise 1.0.2 and 0.21.6.

This is not an anonymous attack on every Boundary endpoint. It requires a deliberately privileged project role and an affected 0.21.3 through 1.0.1 deployment. The impact is still serious because the request originates from the controller's network position rather than the user's. Operators should patch, identify every principal with the required management grants, preserve credential-store changes and controller events, review outbound connections to internal and metadata endpoints, and rotate exposed credentials only where evidence or reachability justifies it.

HashiCorp published bulletin HCSEC-2026-54 on October 29. It covers Boundary and Boundary Enterprise from 0.21.3 through 1.0.1 and identifies Boundary Enterprise 1.0.2 and 0.21.6 as fixed. The associated GitHub Advisory Database record rates CVE-2026-13303 at 8.7 under CVSS 3.1, with a network attack vector, high privileges, no user interaction, and changed scope.

The vulnerable component is the integration between Boundary and Vault credential stores. Boundary normally keeps end users away from the secret backend. A project configures a Vault address and token, credential libraries reference Vault paths, and the controller makes the outbound requests needed to issue credentials for sessions. That design lets Boundary broker access without handing a durable Vault token to every user.

The flaw was insufficient restriction of the destination used by those controller requests. HashiCorp says a principal able to create or update a Vault credential store and credential library could direct the controller to an unintended internal address, influence the response so the controller followed the request to another destination, and receive the result. The fix restricts which destinations the controller will contact. The bulletin does not report active exploitation, a public proof of concept, or anonymous reachability.

Boundary's project model limits where a credential store belongs and which principals can manage it. That authorization boundary still relies on a trusted controller to perform network work. The request does not leave from the administrator's workstation or a tenant workload. It leaves from a component that may share a management subnet with Vault, databases, orchestration services, cloud control endpoints, and other infrastructure hidden from ordinary project users.

That difference is the security consequence of SSRF. A user may lack direct routes, firewall permission, or credentials for an internal endpoint, yet still be able to supply configuration that makes a trusted service fetch it. If the response comes back through the application, network isolation has been converted into an indirect read path. HashiCorp specifically cites cloud instance metadata as an example, not as a confirmed result in every environment.

The prerequisite is narrow but meaningful. The attacker needs a Boundary account with management authority over credential stores and credential libraries in a project. That may describe a project administrator, automation identity, delegated platform team, or a compromised account. It does not describe a normal user who can only start an approved session. Inventorying who can exercise the exact grants is therefore more useful than treating all Boundary users as equally exposed.

Move affected deployments to a fixed branch. HashiCorp names 0.21.6 and Boundary Enterprise 1.0.2 in the bulletin. Operators already on a newer supported line should confirm with HashiCorp's current release guidance that the fix is included rather than inferring safety from a version that merely sorts higher. Record the version running on every controller and worker before and after the change.

Boundary's upgrade guide requires operators to review the target release and every intermediate release for database migrations. Schema-changing upgrades require all controllers to stop, a restorable PostgreSQL backup, an offline migration, and coordinated controller restart. Patch releases cannot be assumed to omit schema changes. Workers should then be upgraded to the controller version to preserve protocol compatibility.

After maintenance, verify more than the package file. Confirm every controller reports the intended build, reconnects to PostgreSQL, emits events, and can complete authentication and approved credential-brokered sessions. Test representative Vault stores and libraries without introducing new addresses or broadening token policy. Keep the pre-upgrade backup until normal operation and event delivery are demonstrated, but do not roll an incident-affected database backward without an evidence and data-integrity decision.

If patching cannot happen immediately, remove unnecessary credential-store and credential-library management grants from project roles. Freeze nonessential changes to Vault-backed stores and libraries, require review for the remaining changes, and disable or isolate unused integrations. These measures reduce who can reach the vulnerable configuration path, but HashiCorp does not present them as complete substitutes for the fixed release.

Constrain controller egress according to what the deployment actually needs. A controller that only needs PostgreSQL, approved Vault addresses, Boundary workers, identity dependencies, and update or telemetry services should not have unrestricted access to every internal subnet. Cloud metadata protections and host firewalls can add another layer, but their exact controls vary by provider. Apply them as defense in depth, not as proof that the vulnerable Boundary path is harmless.

Vault tokens should remain unique per credential store and limited to the paths required by that project's libraries, matching HashiCorp's documented model. Separate the shared Boundary controller policy from store-specific policy. Least privilege cannot stop the controller from making an unintended request, but it can reduce what a stolen or misused Vault token can do and make credential rotation more targeted after an investigation.

Start with authorization. Export the roles and grants that allowed principals to create or update credential stores and credential libraries in each project. Map those grants to human users, groups, service accounts, authentication methods, and token history. Look for recent privilege changes, dormant identities becoming active, automation running outside its normal window, and accounts whose upstream identity provider shows suspicious authentication.

Then review the configuration timeline. Preserve creation and update events for Vault credential stores and libraries, including addresses, TLS settings, namespaces, worker filters, referenced paths, and the actor and request time. Compare current objects with infrastructure-as-code or a trusted baseline. Unexpected internal IP addresses, loopback names, link-local destinations, unfamiliar hostnames, redirects, or short-lived objects deserve explanation even if the configuration was later restored.

Correlate Boundary events with DNS, proxy, firewall, flow, endpoint, Vault, and cloud metadata telemetry. Boundary's default events configuration leaves audit events disabled unless an operator enables them, so confirm what was actually retained before promising a complete history. Search for controller-originated requests to destinations outside the approved Vault set and for any follow-on use of credentials or cloud identities. A missing application event does not erase independent network or provider evidence.

A suspicious request does not automatically mean every secret in the environment was exposed. Build scope from the destination, response content, controller network path, cloud metadata configuration, and credentials available to the controller at that time. If the path only reached an inert endpoint and no response returned, record that evidence. If metadata, Vault data, internal APIs, or service credentials may have been returned, follow each identity into the systems that accepted it.

Rotate proven or plausibly exposed credentials at their issuer, revoke active tokens and leases where appropriate, and review their use before and after revocation. For cloud identities, inspect new keys, role assumptions, policy changes, instances, snapshots, storage access, and persistence. For Vault material, review audit logs, token accessors, leases, secret paths, and downstream systems. Rotation limits future use; it does not explain prior activity.

HashiCorp's public bulletin leaves several questions open: it does not identify observed attacks, exact indicators, the redirect mechanics, or which metadata services and internal protocols were tested. Keep those unknowns visible. The durable design lesson is narrower and well supported: a project-scoped configuration field becomes a cross-scope capability when a central controller resolves it from a trusted network. Destination validation, egress policy, minimal role grants, and retained audit evidence must work together.