Latest News

### Impact OpenBao allows assignment of policies and MFA attribution based upon entity aliases, chosen by the underlying auth method. When using the `username_as_alias=true` parameter in the LDAP auth method, the caller-supplied username is used verbatim without normalization, allowing an attacker to bypass alias-specific MFA requirements. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds LDAP methods are only vulnerable if using `username_as_alias=true`. Remove all usage of this parameter and update any entity aliases accordingly. ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-20-vault-ldap-mfa-enforcement-bypass-when-using-username-as-alias/76092 - https://nvd.nist.gov/vuln/detail/CVE-2025-6013

### Impact OpenBao's Login Multi-Factor Authentication (MFA) system allows enforcing MFA using Time-based One Time Password (TOTP). Due to normalization applied by the underlying TOTP library, codes were accepted which could contain whitespace; this whitespace could bypass internal rate limiting of the MFA method and allow reuse of existing MFA codes. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Use of rate-limiting quotas can limit an attacker's ability to exploit this: https://openbao.org/api-docs/system/rate-limit-quotas/ ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-19-vault-login-mfa-bypass-of-rate-limiting-and-totp-token-reuse/76038 - https://nvd.nist.gov/vuln/detail/CVE-2025-6015

### Impact OpenBao's TOTP secrets engine could accept valid codes multiple times rather than strictly-once. This was caused by unexpected normalization in the underlying TOTP library. ### Patches OpenBao v2.3.2 will patch this issue. In patching, codes which were not normalized (strictly N numeric digits) will now be rejected. This is a potentially breaking change. ### Workarounds TOTP code verification is a privileged action; only trusted systems should be verifying codes. Ensure that all codes are first normalized before submitting to the OpenBao endpoint. ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-17-vault-totp-secrets-engine-code-reuse/76036 - https://nvd.nist.gov/vuln/detail/CVE-2025-6014

### Impact When using OpenBao's `userpass` auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Users may use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/ ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-15-timing-side-channel-in-vault-s-userpass-auth-method/76034 - https://nvd.nist.gov/vuln/detail/CVE-2025-6011 Barring further information, this is also assumed to cover and remediate the following additional vulnerability: - https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enumeration-in-userpass-auth-method/76095 - https://nvd...

### Impact Attackers could bypass the automatic user lockout mechanisms in the OpenBao Userpass or LDAP auth systems. This was caused by different aliasing between pre-flight and full login request user entity alias attributions. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Existing users may apply rate-limiting quotas on the authentication endpoints: https://openbao.org/api-docs/system/rate-limit-quotas/ ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-16-vault-userpass-and-ldap-user-lockout-bypass/76035 - https://nvd.nist.gov/vuln/detail/CVE-2025-6004

### Impact Under certain threat models, OpenBao operators with privileged API access may not be system administrators and thus normally lack the ability to update binaries or execute code on the system. Additionally, privileged API operators should be unable to perform TCP connections to arbitrary hosts in the environment OpenBao is executing within. The API-driven audit subsystem granted privileged API operators the ability to do both with an attacker-controlled log prefix. Access to these endpoints should be restricted. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Users may deny all access to the `sys/audit/*` interface (with `create` and `update`) permission via policies with explicit deny grants. This would not restrict `root` level operators, however, for whom there are no workarounds. This interface allowed arbitrary filesystem and network (write) access as the user the OpenBao server was running as; in conjunction with allowing custom plugins or other...

### Impact Accounts with access to the highly-privileged identity entity system in the root namespace may increase their scope directly to the `root` policy. While the identity system always allowed adding arbitrary policies, which in turn could contain capability grants on arbitrary paths, the `root` policy is restricted to manual generation using unseal or recovery key shares. The global `root` policy is not accessible from child namespaces. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Use of `denied_parameters` in any policy which has access to the affected identity endpoints (on [identity entities](https://openbao.org/api-docs/secret/identity/entity/)) may be sufficient to prohibit this type of attack. ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-13-vault-root-namespace-operator-may-elevate-token-privileges/76032 - https://nvd.nist.gov/vuln/deta...

### Summary An authentication bypass vulnerability allows any unauthenticated attacker to impersonate any ActivityPub actor by sending forged activities signed with their own keys. Activities are processed before verifying the signing key belongs to the claimed actor, enabling complete actor impersonation across all Fedify instances ### Details The vulnerability exists in handleInboxInternal function in fedify/federation/handler.ts. The critical flaw is in the order of operations: 1. Line 1712: routeActivity() is called first, which processes the activity (either immediately or by adding to queue) 2. Line 1730: Authentication check (doesActorOwnKey) happens AFTER processing ```ts // fedify/federation/handler.ts:1712-1750 const routeResult = await routeActivity({ // ← Activity processed here context: ctx, json, activity, recipient, inboxListeners, inboxContextFactory, inboxErrorHandler, kv, kvPrefixes, queue, span, tracerProvi...

Security is everyone's responsibility, but as a CISO, it starts with you.

The tranche of information includes data on recent campaigns, attack tools, compromised credentials, and command files used by a threat actor believed to be acting on behalf of China or North Korea.