Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN987 _____________________________________________________________________ DATE : 08/10/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Vault Enterprise versions prior to 2.1.2, 1.21.12, 1.20.17, 1.19.23, Vault Community Edition versions prior to 2.1.2. ==================================================================== https://discuss.hashicorp.com/t/hcsec-2026-41-vault-vulnerable-to-arbitrary-code-execution-via-plugin-catalog-entries-restored-from-raft-snapshots/77813 https://discuss.hashicorp.com/t/hcsec-2026-42-vault-enterprise-acl-policy-cache-vulnerable-to-cross-namespace-policy-resolution/77814 https://discuss.hashicorp.com/t/hcsec-2026-43-vault-inconsistent-acl-policy-evaluation-may-allow-bypass-of-deny-restrictions/77815 https://discuss.hashicorp.com/t/hcsec-2026-40-vault-pki-acme-default-directory-policy-may-issue-certificates-with-unverified-identities/77812 _____________________________________________________________________ HCSEC-2026-41 - Vault Vulnerable to Arbitrary Code Execution via Plugin Catalog Entries Restored From Raft Snapshots mariajosep.lopez 16h Bulletin ID: HCSEC-2026-41 Affected Products / Versions: Vault Community Edition and Vault Enterprise up to 2.1.1; fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Publication Date: October 7, 2026 Summary Vault and Vault Enterprise did not consistently verify that stored plugin catalog entries reference binaries within the configured plugin directory. When Vault uses Shamir seals and has an external plugin directory configured, a privileged operator able to restore an Integrated Storage (Raft) snapshot may be able to execute arbitrary code on the Vault host. This vulnerability (CVE-2026-105816) is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Background Vault supports external plugins, which are registered in the plugin catalog and executed from the directory configured by plugin_directory. Vault restricts plugin registration so that execution of registered plugin binaries resolves within this directory, limiting executables to the operator-configured plugin directory. Integrated Storage supports saving and restoring snapshots of Vault’s data, including the plugin catalog. Details Vault verified that the executable resolved within the configured plugin directory (directly and after following symbolic links) when a plugin was registered, but not when a stored catalog entry was later used to run a plugin. A plugin catalog entry introduced without going through registration, such as through a restored snapshot, could reference a binary outside the plugin directory. Vault could then execute that binary as the Vault service user when the plugin was used, including during unseal for existing mounts. Exploitation requires a privileged operator able to restore snapshots. This issue only affects clusters using Shamir seals with an external plugin directory configured. Clusters using auto-unseal, or without a configured plugin directory, are not affected. Remediation Customers should evaluate the risk associated with this issue and consider upgrading to Vault Community Edition 2.1.2, or Vault Enterprise 2.1.2, 1.21.12, 1.20.17, or 1.19.23, upgrading every node, including standbys and, for Vault Enterprise, performance and disaster recovery (DR) secondaries. After upgrading, plugin catalog entries that resolve outside the plugin directory, including through symbolic links, are refused and their mounts are skipped at startup; such plugins must be registered again with their binary inside the plugin directory. Acknowledgement This issue was identified by an external party. _____________________________________________________________________ HCSEC-2026-42 - Vault Enterprise ACL Policy Cache Vulnerable to Cross-Namespace Policy Resolution sep.lopez Bulletin ID: HCSEC-2026-42 Affected Products / Versions: Vault Enterprise up to 2.1.1; fixed in Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Publication Date: October 7, 2026 Summary Vault’s ACL policy cache allowed namespace traversal when policy names contained path traversal constructs. This may allow a token assigned specially crafted policy names to use the capabilities of policies defined in other namespaces, including the root namespace. This vulnerability (CVE-2026-105820) is fixed in Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Vault Community Edition does not support namespaces, and is not affected. Background Vault Enterprise namespaces provide isolated environments within a single Vault cluster, each with its own policies, authentication methods, and secrets engines. Policies attached to a token are resolved within the token’s namespace, so a token’s access is limited to the namespaces it is authorized for. Vault caches policies in memory to avoid reading them from storage on every request. See the Namespaces documentation for more information. Details Vault did not prevent policy names from referencing other namespaces via path traversal constructs, and its in-memory policy cache could resolve such a policy belonging to a different namespace. A token assigned such a policy name could then be granted that policy’s capabilities within the policy’s own namespace, allowing the token to act across namespace boundaries. Exploitation requires an authenticated user able to assign arbitrary policy names to a token, for example through token creation or an auth method role. The referenced policy must be present in Vault’s policy cache both when the token is created and when it is used. When the referenced policy is the root policy of another namespace, its capabilities are granted only within the token’s own namespace. Remediation Customers should evaluate the risk associated with this issue and consider upgrading to Vault Enterprise 2.1.2, 1.21.12, 1.20.17, or 1.19.23. Because namespaces are a Vault Enterprise feature, the Vault Community Edition is not affected, but includes these changes as defense-in-depth hardening. After upgrading, policy names containing . or .. path segments are rejected for new policies and assignments, and are ignored for existing tokens and identities, which may reduce their effective permissions; operators should audit and rename any such policies before upgrading. Acknowledgement This issue was identified by an external party. _____________________________________________________________________ HCSEC-2026-43 - Vault Inconsistent ACL Policy Evaluation May Allow Bypass of Deny Restrictions mariajosep.lopez Bulletin ID: HCSEC-2026-43 Affected Products / Versions: Vault Community Edition up to 2.1.1; fixed in Vault Community Edition 2.1.2. Vault Enterprise up to 2.1.1; fixed in Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Publication Date: October 7, 2026 Summary Vault and Vault Enterprise did not consistently evaluate ACL policies against the canonical form of resource and policy names. This may allow an authenticated user with delegated permissions to bypass an explicit deny restriction and access a protected resource or assign a denied policy, potentially leading to privilege escalation. This vulnerability (CVE-2026-89322) is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Background Vault ACL policies grant or deny capabilities on request paths, where a more specific rule takes precedence over a broader wildcard rule, and can use denied_parameters to prevent a principal from setting specific values in a request. Operators commonly combine these controls to delegate management of auth method roles, users, tokens, and identities while protecting specific resources and higher-privilege policies. Many Vault components, including several auth methods, ACL policies, and identity and groups, treat resource and policy names as case-inse nsitive. Details Vault evaluated ACL policies against resource and policy names as supplied in a request, while the receiving component later normalized those names into their canonical form, for example by disregarding letter case or surrounding whitespace. A request that referred to a protected resource or policy using a non-canonical name could therefore avoid a restriction during policy evaluation and still be applied to the protected resource or denied policy. This may allow a delegated user to access or modify a resource protected by a more specific rule, such as obtaining credentials for an explicitly denied auth method role, or to assign an explicitly denied policy to a token, role, user, or identity. In Vault Enterprise, Sentinel policies evaluated against the request path were similarly affected. Exploitation requires an authenticated principal holding broad delegated permissions on an affected endpoint, and a policy that relies either on a more specific rule to deny or limit access alongside a broader allow rule, or on value-specific denied_parameters to restrict assignable policy names. Assigning a denied policy also requires that the policy already exists and that the principal can obtain a token carrying it. Root and internal policies cannot be assigned through this issue, and token creation without sudo remains limited to the caller’s own policies. Deployments that do not combine broad allow rules with more specific restrictions on these resources, do not use non-canonical casing in policy names, and do not use denied_parameters to restrict policy names, are not affected. Remediation Customers should evaluate the risk associated with this issue and consider upgrading to Vault Community Edition 2.1.2, or Vault Enterprise 2.1.2, 1.21.12, 1.20.17, or 1.19.23. After upgrading, ACL policy rules and Vault Enterprise Sentinel policies for affected resources are evaluated against the lowercase resource name, so existing rules that reference mixed-case resource names, including deny rules, will no longer match and should be rewritten in lowercase before upgrading. The Okta, LDAP, and RADIUS auth methods, and Vault Enterprise SCIM clients, are not covered by this fix; operators should avoid combining broad allow rules with more specific deny rules on those resources. Acknowledgement This issue was reported to HashiCorp by Han Sang-Kyung (HAN-BAMBO) and by additional internal and external parties. _____________________________________________________________________ HCSEC-2026-40 - Vault PKI ACME Default Directory Policy May Issue Certificates With Unverified Identities mariajosep.lopez Bulletin ID: HCSEC-2026-40 Affected Products / Versions: Vault Community Edition 1.14.0 up to 2.1.1; fixed in Vault Community Edition 2.1.2. Vault Enterprise 1.14.0 up to 2.1.1; fixed in Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Publication Date: October 7, 2026 Summary Vault’s PKI secrets engine ACME server did not restrict certificate identities that ACME challenges do not validate when issuing certificates under the default directory policy. This may allow an ACME client to obtain a certificate containing unverified identity claims, potentially enabling impersonation toward systems that trust certificates issued by the affected Vault PKI mount. This vulnerability (CVE-2026-105818) is fixed in Vault Community Edition 2.1.2, and Vault Enterprise 2.1.2, 1.21.12, 1.20.17, and 1.19.23. Background Vault’s PKI secrets engine can act as an ACME server, allowing clients to request certificates automatically after proving control of the requested identifiers through ACME challenges. ACME challenges verify control of DNS names and IP addresses. Requests that are not associated with a specific role are governed by the default_directory_policy setting, which defaults to sign-verbatim. See the PKI ACME documentation for more information. Details When the default_directory_policy was set to sign-verbatim (the default, which also applies if the setting is not configured), Vault could include subject alternative name types other than DNS names and IP addresses from the certificate signing request in the issued certificate, even though these identities are never verified by ACME challenges. An ACME client that completes validation for an identifier it controls could therefore obtain a certificate that also asserts other identities. This issue only affects PKI mounts with ACME enabled and using the sign-verbatim default directory policy, either explicitly or by default. Mounts that disable the default directory or set it to a role that constrains these subject alternative name types are not affected. Where external account binding is required, exploitation is limited to clients holding a valid binding. Remediation Customers should evaluate the risk associated with this issue and consider upgrading to Vault Community Edition 2.1.2, or Vault Enterprise 2.1.2, 1.21.12, 1.20.17, or 1.19.23. After upgrading, the sign-verbatim policy rejects certificate requests containing these unverified subject alternative name types. Operators who require the previous behavior can opt in with the new sign-verbatim-unsafe policy, accepting that issued certificates may contain unverified identity claims. Until upgrading, configuring the default directory policy to use a role that restricts these subject alternative name types, or disabling the default directory, mitigates this issue. Acknowledgement This issue was identified by an external party. ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================