Alexander Scheel

11 exploits Active since Jul 2020
CVE-2026-33757 WRITEUP CRITICAL WRITEUP
OpenBao lacks user confirmation for OIDC direct callback mode
OpenBao is an open source identity-based secrets management system. Prior to version 2.5.2, OpenBao does not prompt for user confirmation when logging in via JWT/OIDC and a role with `callback_mode` set to `direct`. This allows an attacker to start an authentication request and perform "remote phishing" by having the victim visit the URL and automatically log-in to the session of the attacker. Despite being based on the authorization code flow, the `direct` mode calls back directly to the API and allows an attacker to poll for an OpenBao token until it is issued. Version 2.5.2 includes an additional confirmation screen for `direct` type logins that requires manual user interaction in order to finish the authentication. This issue can be worked around either by removing any roles with `callback_mode=direct` or enforcing confirmation for every session on the token issuer side for the Client ID used by OpenBao.
CVSS 9.6
CVE-2020-15720 WRITEUP MEDIUM WRITEUP
Dogtagpki < 10.8.3 - Improper Certificate Validation
In Dogtag PKI through 10.8.3, the pki.client.PKIConnection class did not enable python-requests certificate validation. Since the verify parameter was hard-coded in all request functions, it was not possible to override the setting. As a result, tools making use of this class, such as the pki-server command, may have been vulnerable to Person-in-the-Middle attacks in certain non-localhost use cases. This is fixed in 10.9.0-b1.
CVSS 6.8
CVE-2025-52893 WRITEUP MEDIUM WRITEUP
Openbao < 2.3.0 - Log Information Exposure
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. OpenBao before v2.3.0 may leak sensitive information in logs when processing malformed data. This is separate from the earlier HCSEC-2025-09 / CVE-2025-4166. This issue has been fixed in OpenBao v2.3.0 and later. Like with HCSEC-2025-09, there is no known workaround except to ensure properly formatted requests from all clients.
CVSS 4.5
CVE-2025-52894 WRITEUP HIGH WRITEUP
Openbao < 2.3.0 - Improper Input Validation
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. OpenBao before v2.3.0 allowed an attacker to perform unauthenticated, unaudited cancellation of root rekey and recovery rekey operations, effecting a denial of service. In OpenBao v2.2.0 and later, manually setting the configuration option `disable_unauthed_rekey_endpoints=true` allows an operator to deny these rarely-used endpoints on global listeners. A patch is available at commit fe75468822a22a88318c6079425357a02ae5b77b. In a future OpenBao release communicated on OpenBao's website, the maintainers will set this to `true` for all users and provide an authenticated alternative. As a workaround, if an active proxy or load balancer sits in front of OpenBao, an operator can deny requests to these endpoints from unauthorized IP ranges.
CVSS 7.5
CVE-2025-54998 WRITEUP MEDIUM WRITEUP
Openbao < 2.3.2 - Brute Force
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 0.1.0 through 2.3.1, 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. This is fixed in version 2.3.2. To work around this issue, existing users may apply rate-limiting quotas on the authentication endpoints:, see https://openbao.org/api-docs/system/rate-limit-quotas/.
CVSS 5.3
CVE-2025-55000 WRITEUP MEDIUM WRITEUP
OpenBao <2.3.1 - Info Disclosure
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 0.1.0 through 2.3.1, 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. To work around, ensure that all codes are first normalized before submitting to the OpenBao endpoint. TOTP code verification is a privileged action; only trusted systems should be verifying codes.
CVSS 6.5
CVE-2025-55001 WRITEUP MEDIUM WRITEUP
OpenBao <2.3.1 - Auth Bypass
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, OpenBao allowed the assignment of policies and MFA attribution based upon entity aliases, chosen by the underlying auth method. When the username_as_alias=true parameter in the LDAP auth method was in use, the caller-supplied username was used verbatim without normalization, allowing an attacker to bypass alias-specific MFA requirements. This issue was fixed in version 2.3.2. To work around this, remove all usage of the username_as_alias=true parameter and update any entity aliases accordingly.
CVSS 6.5
CVE-2025-55003 WRITEUP MEDIUM WRITEUP
OpenBao <2.3.1 - Auth Bypass
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, 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. This issue was fixed in version 2.3.2. To work around this, use of rate-limiting quotas can limit an attacker's ability to exploit this: https://openbao.org/api-docs/system/rate-limit-quotas/.
CVSS 5.7
CVE-2025-62513 WRITEUP HIGH WRITEUP
Openbao < 2.4.2 - Log Information Exposure
OpenBao is an open source identity-based secrets management system. In versions 2.2.0 to 2.4.1, OpenBao's audit log experienced a regression wherein raw HTTP bodies used by few endpoints were not correctly redacted (HMAC'd). This impacts those using the ACME functionality of PKI, resulting in short-lived ACME verification challenge codes being leaked in the audit logs. Additionally, this impacts those using the OIDC issuer functionality of the identity subsystem, auth and token response codes along with claims could be leaked in the audit logs. ACME verification codes are not usable after verification or challenge expiry so are of limited long-term use. This issue has been patched in OpenBao 2.4.2.
CVSS 7.5
CVE-2025-62705 WRITEUP MEDIUM WRITEUP
Openbao < 2.4.2 - Log Information Exposure
OpenBao is an open source identity-based secrets management system. Prior to version 2.4.2, OpenBao's audit log did not appropriately redact fields when relevant subsystems sent []byte response parameters rather than strings. This includes, but is not limited to sys/raw with use of encoding=base64, all data would be emitted unredacted to the audit log, and Transit, when performing a signing operation with a derived Ed25519 key, would emit public keys to the audit log. This issue has been patched in OpenBao 2.4.2.
CVSS 4.9
CVE-2025-64761 WRITEUP HIGH WRITEUP
Openbao < 2.4.4 - Incorrect Privilege Assignment
OpenBao is an open source identity-based secrets management system. Prior to version 2.4.4, a privileged operator could use the identity group subsystem to add a root policy to a group identity group, escalating their or another user's permissions in the system. Specifically this is an issue when: an operator in the root namespace has access to identity/groups endpoints and an operator does not have policy access. Otherwise, an operator with policy access could create or modify an existing policy to grant root-equivalent permissions through the sudo capability. This issue has been patched in version 2.4.4.
CVSS 7.2