{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/openbao/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["openbao/openbao (Go)"],"_cs_severities":["high"],"_cs_tags":["vulnerability","acl-bypass","secrets-management"],"_cs_type":"advisory","_cs_vendors":["GitHub","OpenBao"],"content_html":"\u003cp\u003eOpenBao, a secrets management solution, utilizes namespaces for multi-tenant isolation. A vulnerability exists in versions 2.5.3 and earlier where a user in one namespace can revoke or renew leases belonging to another namespace. This is achieved by exploiting the legacy, undocumented \u003ccode\u003esys/revoke\u003c/code\u003e and \u003ccode\u003esys/renew\u003c/code\u003e endpoints. An attacker with knowledge of a valid lease ID from a different namespace can leverage these endpoints to disrupt service or potentially gain unauthorized access to secrets. This vulnerability, identified as CVE-2026-45808, allows bypassing of intended ACL restrictions. The issue is resolved in OpenBao v2.5.4.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains access to a valid lease ID from a target namespace, either through unintentional leakage or through malicious insider activity.\u003c/li\u003e\n\u003cli\u003eAttacker crafts an HTTP request targeting the legacy \u003ccode\u003esys/revoke\u003c/code\u003e endpoint, including the stolen lease ID in the request body.\u003c/li\u003e\n\u003cli\u003eThe OpenBao server processes the request to the \u003ccode\u003esys/revoke\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eDue to the legacy nature of the endpoint, ACL checks are bypassed.\u003c/li\u003e\n\u003cli\u003eThe targeted lease is revoked, rendering any associated credentials invalid.\u003c/li\u003e\n\u003cli\u003eIf the attacker targets the \u003ccode\u003esys/renew\u003c/code\u003e endpoint, the lease will be renewed with settings controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe affected application or service relying on the revoked lease experiences a denial of service or disruption.\u003c/li\u003e\n\u003cli\u003eDepending on the targeted secrets, an attacker might gain unauthorized access to the target application or service if they were able to successfully renew the lease.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-45808 can lead to denial of service for applications relying on OpenBao-managed secrets. In multi-tenant environments, this can impact services in other namespaces, even without proper authorization. While there is no direct information disclosure, unauthorized lease revocation and renewal can interrupt legitimate operations. The severity is high because it impacts availability of critical services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade OpenBao to version 2.5.4 or later to patch CVE-2026-45808.\u003c/li\u003e\n\u003cli\u003eMonitor OpenBao logs for requests to the \u003ccode\u003e/sys/revoke\u003c/code\u003e endpoint, which may indicate unauthorized lease revocation attempts (see Sigma rule below).\u003c/li\u003e\n\u003cli\u003eImplement strict lease ID handling procedures within your organization to prevent unintended leakage.\u003c/li\u003e\n\u003cli\u003eConsider disabling or restricting access to the \u003ccode\u003esys/revoke\u003c/code\u003e and \u003ccode\u003esys/renew\u003c/code\u003e endpoints through appropriate ACL policies as a temporary mitigation measure until the upgrade is complete.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-28T17:38:26Z","date_published":"2026-05-28T17:38:26Z","id":"https://feed.craftedsignal.io/briefs/2026-05-openbao-lease-revoke/","summary":"OpenBao versions up to 2.5.3 allow cross-namespace lease revocation by exploiting legacy sys/revoke endpoints, potentially leading to unauthorized credential access and denial of service.","title":"OpenBao Cross-Namespace Lease Revocation via Legacy sys/revoke Path","url":"https://feed.craftedsignal.io/briefs/2026-05-openbao-lease-revoke/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["OpenBao"],"_cs_severities":["critical"],"_cs_tags":["openbao","xss","reflected-xss","web-application"],"_cs_type":"advisory","_cs_vendors":["OpenBao"],"content_html":"\u003cp\u003eOpenBao, a secrets management tool, is susceptible to a reflected XSS vulnerability (CVE-2026-33758) affecting installations using OIDC/JWT authentication methods. The vulnerability specifically impacts roles configured with \u003ccode\u003ecallback_mode=direct\u003c/code\u003e. An attacker can exploit this flaw by injecting malicious JavaScript code via the \u003ccode\u003eerror_description\u003c/code\u003e parameter in the authentication error page. Successful exploitation grants the attacker access to the victim's Web UI token, potentially leading to unauthorized access to sensitive secrets. The vulnerability was introduced prior to version 2.5.2 and has been patched in version 2.5.2 by replacing the dynamic \u003ccode\u003eerror_description\u003c/code\u003e with a static error message. Defenders should either upgrade or implement the described workaround immediately.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an OpenBao instance with OIDC/JWT authentication enabled and at least one role configured with \u003ccode\u003ecallback_mode=direct\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious URL containing a JavaScript payload within the \u003ccode\u003eerror_description\u003c/code\u003e parameter. Example: \u003ccode\u003e/ui/login?error_description=\u0026lt;script\u0026gt;alert('XSS')\u0026lt;/script\u0026gt;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker tricks a victim (e.g., an administrator logged into the OpenBao Web UI) into clicking the malicious link, perhaps via phishing or other social engineering methods.\u003c/li\u003e\n\u003cli\u003eThe victim's browser sends a request to the OpenBao server with the malicious \u003ccode\u003eerror_description\u003c/code\u003e parameter.\u003c/li\u003e\n\u003cli\u003eThe OpenBao server reflects the attacker's JavaScript payload back to the victim's browser within the HTML of the authentication error page.\u003c/li\u003e\n\u003cli\u003eThe victim's browser executes the attacker-controlled JavaScript code due to the reflected XSS vulnerability.\u003c/li\u003e\n\u003cli\u003eThe malicious JavaScript code steals the victim's authentication token used for accessing the OpenBao Web UI.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen token to authenticate to the OpenBao Web UI and gain unauthorized access to secrets.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this XSS vulnerability allows attackers to steal authentication tokens from legitimate OpenBao users. With a stolen token, an attacker can gain complete access to the OpenBao Web UI, allowing them to read, modify, or delete secrets, policies, and other sensitive configurations. This could lead to a complete compromise of the secrets management system, potentially affecting all applications and services that rely on OpenBao for their credentials. The severity is considered critical due to the ease of exploitation and high potential impact on confidentiality and integrity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade OpenBao to version 2.5.2 or later to apply the patch that replaces the vulnerable \u003ccode\u003eerror_description\u003c/code\u003e parameter (reference: Patches section).\u003c/li\u003e\n\u003cli\u003eAs a workaround, remove any roles configured with \u003ccode\u003ecallback_mode=direct\u003c/code\u003e (reference: Workarounds section).\u003c/li\u003e\n\u003cli\u003eImplement a web application firewall (WAF) rule to detect and block requests containing suspicious JavaScript code in the \u003ccode\u003eerror_description\u003c/code\u003e parameter (example rule below).\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for requests with \u003ccode\u003eerror_description\u003c/code\u003e containing \u003ccode\u003e\u0026lt;script\u0026gt;\u003c/code\u003e or other HTML tags commonly used in XSS attacks (reference: example rule below, logsource: webserver).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-29T12:00:00Z","date_published":"2024-01-29T12:00:00Z","id":"https://feed.craftedsignal.io/briefs/2024-01-openbao-xss/","summary":"OpenBao installations with OIDC/JWT authentication enabled and roles with `callback_mode=direct` are vulnerable to reflected XSS via the `error_description` parameter, allowing attackers to steal Web UI tokens; patched in v2.5.2.","title":"OpenBao Reflected XSS Vulnerability in OIDC Authentication Error Message","url":"https://feed.craftedsignal.io/briefs/2024-01-openbao-xss/"}],"language":"en","title":"CraftedSignal Threat Feed - OpenBao","version":"https://jsonfeed.org/version/1.1"}