Reflected XSS in OpenBao OIDC/JWT authentication error handling

OpenBao is an open source identity-based secrets management system. Prior to version 2.5.2, OpenBao installations that have an OIDC/JWT authentication method enabled and a role with callback_mode=direct configured are vulnerable to XSS via the error_description parameter on the page for a failed authentication. This allows an attacker access to the token used in the Web UI by a victim. The error_description parameter has been replaced with a static error message in v2.5.2. The vulnerability can be mitigated by removing any roles with callback_mode set to direct.

• OpenBao: affected at versions < 2.5.2 in the normalized record; the maintainer advisory expresses the same boundary as <=2.5.1.
• Configuration condition: OIDC/JWT authentication must be enabled and a role must use callback_mode=direct.
• Fixed release: 2.5.2, which replaces error_description with a static error message.
• The available evidence does not establish the status of parallel OpenBao branches or other distribution builds beyond these boundaries.

OpenBao reflects data from the error_description parameter into the HTML page shown after a failed OIDC/JWT authentication without adequate neutralization. Exposure requires the OIDC/JWT authentication method to be enabled and a role configured with callback_mode=direct. The attacker can control the error value through a crafted URL, and the victim must visit that URL in a browser for the attack to complete. When the XSS runs in the Web UI context, the attacker can access the token used by the victim in the Web UI and act within that token's permissions. The upstream fix replaces the displayed error_description with a static error message and adds safer handling for error content in the OIDC/JWT flow. The available evidence does not establish a specific browser payload or a particular endpoint used in a real attack.

The vulnerability is reachable over the network through the Web UI authentication flow and does not require prior attacker privileges. The deployment must have OIDC/JWT authentication enabled and a role using callback_mode=direct. A victim must visit a crafted URL, so exploitation requires user interaction. The supplied evidence does not name a campaign, victim, or specific public exploit; that status should not be treated as proof that exploitation has never occurred.

The flaw allows XSS to execute in the user's browser when the authentication error page reflects data from error_description. The direct outcome described by the vendor is attacker access to the token used in the Web UI. A token with broad permissions could allow reading or changing secrets, revoking tokens, rotating application secrets, and disrupting dependent applications. The vulnerability alone does not establish administrative control over every deployment because the resulting actions depend on the stolen token's permissions. The available evidence does not establish arbitrary code execution on the OpenBao server.

If exploited, the victim's Web UI token may be accessed by an unauthorized party. Depending on the token's permissions, the attacker may read database credentials, API keys, or certificates available to the user, and may modify, overwrite, or destroy secrets or manage tokens on the user's behalf. This can cause loss of confidentiality, unauthorized changes, or disruption to services that depend on those secrets. Actual impact is constrained by the permissions of the exposed token, and the available evidence does not identify a specific breach.

1. Upgrade OpenBao to 2.5.2, which replaces the displayed error_description with a static error message.
2. If an upgrade cannot be completed, review OIDC/JWT configuration and remove or disable every role with callback_mode=direct.
3. Verify that the actual deployed build, including any package or container image, contains the fix before restoring an affected configuration.
4. If the affected authentication flow may have exposed Web UI tokens, take appropriate precautionary action such as revoking related sessions or tokens and rotating secrets accessible to those tokens.

1. Inventory running OpenBao deployments and compare each deployed version with the affected boundary and the fixed release.
2. Inspect authentication configuration to identify enabled OIDC/JWT methods and review every role with callback_mode=direct.
3. Review available server logs around failed OIDC/JWT authentications for unusual error_description or error_uri values, where those fields are recorded. This is a precautionary review, not a confirmed indicator of compromise.
4. Review audit logs for unexpected use of Web UI sessions or tokens belonging to users after failed authentication attempts. The absence of suspicious events does not prove that a token was not exposed.