CVE-2026-71543: 
Wolfi vulnerability analysis and mitigation

CVE-2026-71543 is an incorrect authorization vulnerability in OpenBao, an open source identity-based secrets management system, where templated ACL, PKI, and SSH policies fail to reject syntax-significant characters in attacker-controlled identity data. Affected versions are all releases prior to 2.6.0. The vulnerability was published on September 21, 2026, with the fix merged into the codebase in July 2026 and released in OpenBao v2.6.0. It carries a CVSS v4.0 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-863 (Incorrect Authorization): OpenBao's templated policy engine substitutes user-controlled identity data into policy expressions without sanitizing syntax-significant characters. In ACL templated policies, the characters *, +, and / can alter path matching semantics; in PKI allowed_uri_sans_template and allowed_domains policies, an asterisk (*) can broaden certificate issuance to unauthorized domains; and in SSH allowed_users and allowed_domains policies, a comma (,) can inject additional unauthorized principals by exploiting comma-delimited parsing. Exploitation requires that (a) the deployment uses templated policies and (b) users can freely modify the identity data referenced by those templates — deployments using the randomly generated identity.entity.id value are not affected. The fix introduces blocked substitution lists per engine and new opt-in flags (allow_globs_in_substitutions, allow_commas_in_substitutions) to explicitly permit such characters only when the data source is trusted (GitHub Advisory, PR #3401).

Successful exploitation can lead to privilege escalation, unauthorized access to secrets paths, and unauthorized TLS or SSH certificate issuance. An attacker who controls their own identity metadata (e.g., username or entity metadata fields) can craft values containing wildcard or delimiter characters to broaden their effective policy scope — for example, gaining read access to all key-value paths instead of only their own, or obtaining a wildcard TLS certificate covering an entire domain. This could enable lateral movement within a secrets management environment and exposure of sensitive credentials or certificates managed by OpenBao (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the publication date. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires an authenticated attacker with high privileges (e.g., the ability to modify their own identity metadata) and a deployment specifically configured to use templated policies with user-controllable data, limiting the practical attack surface (Feedly, GitHub Advisory). The advisory notes this issue was previously disclosed in HashiCorp Vault v2.0.1 without a corresponding CVE.

1. Identify a vulnerable deployment: Confirm the target OpenBao instance is running a version prior to 2.6.0 and uses templated ACL, PKI, or SSH policies that reference user-controllable identity fields (e.g., identity.entity.metadata.<field> or identity.entity.name).
2. Obtain authenticated access: Authenticate to OpenBao with a user account that has permission to modify their own identity entity metadata or whose username/display name is used in a template.
3. Inject a wildcard character: Modify the identity field referenced by the template to include a syntax-significant character. For ACL policies, set the field to a value containing *, +, or / (e.g., set username to *). For PKI policies, set the metadata field to *.example.com. For SSH policies, set the field to legitimate-user,attacker-user.
4. Trigger policy evaluation: Perform an action that causes OpenBao to evaluate the templated policy — for example, request a PKI certificate, attempt to access a secrets path, or request an SSH certificate.
5. Achieve unauthorized access: The injected character causes the policy engine to match a broader set of paths or principals than intended, granting the attacker access to secrets, the ability to issue certificates for unauthorized domains, or SSH access as additional principals (GitHub Advisory, PR #3401).

• Logs: OpenBao audit logs showing policy evaluation for paths or certificate SANs that contain wildcard characters (*, +, /) or comma-separated values originating from identity template substitutions; unexpected successful access to secrets paths outside a user's expected scope.
• PKI: Issued certificates with wildcard common names or URI SANs (e.g., *.example.com) that were not explicitly configured as static allowed values in the PKI role.
• SSH: SSH certificates issued with multiple principals where only one was expected, particularly if the additional principal appears to have been injected via a comma in a template-substituted field.
• Identity Metadata: Identity entity metadata fields containing characters such as *, +, /, or , in fields referenced by templated policies, especially if recently modified by a non-administrative user.

Upgrade OpenBao to version 2.6.0 or later, which blocks syntax-significant characters in template substitutions by default (GitHub Advisory, Release v2.6.0). As a workaround for deployments that cannot immediately upgrade, audit all templated policies to ensure the identity fields they reference cannot be freely modified by end users, and restrict write access to identity entity metadata. Prefer using identity.entity.id (randomly generated by OpenBao) in templates rather than user-modifiable fields. After upgrading, the new opt-in flags allow_globs_in_substitutions and allow_commas_in_substitutions can be set to true only for roles where the substituted data is fully trusted (PR #3401).

The vulnerability was reported and fixed by contributors from Adfinis (phil9909/Philipp Stehle) and reviewed by OpenBao maintainer cipherboy (Alexander Scheel), reflecting active community security engagement. The advisory notes that a similar issue was previously disclosed in HashiCorp Vault v2.0.1 without a CVE assignment, suggesting the OpenBao team proactively addressed the gap in CVE coverage for the open source fork (GitHub Advisory).