OpenBao CVE-2026-115366

Exploitation requires a token already holding write or delete capability on sys/plugins/catalog/* within a child namespace - the API simply fails to restrict plugin-catalog mutations to the root namespace. The impact is limited to DoS unless the attacker also controls the host's plugin directory: per the vendor advisory, a registration only leads to plugin execution when its command parameter names a real file in the configured plugin_directory AND its sha256sum matches that file's digest on disk, which an ordinary tenant cannot satisfy. Limiting factors confirmed by the vendor: deployments that do not grant tenants write/delete on sys/plugins/catalog/*, or that disable external plugins by not configuring a plugin_directory, are not exploitable; the vendor states updating to v2.6.3 or v2.7.0 is the complete fix.

This is a low-priority vulnerability by every available signal, and the signals are consistent rather than conflicting. The vendor-supplied CVSS 4.0 score is 2.0, with AV:N (network-reachable API), AC:L, but AT:P (an attack requirement must hold), PR:L (the attacker must already hold a sufficiently privileged token in a child namespace), UI:A, and only VA:L impact (limited availability, i.e. DoS) with no confidentiality or integrity impact. The vuln.today decision label is 'monitor', the lowest urgency tier, which aligns with the low CVSS. No EPSS score was supplied and the CVE is not on CISA KEV (KEV=NO), so there is no evidence of active exploitation; treat exploitation probability as unquantified rather than high. No public exploit code or PoC reference was provided in the input - only the GHSA advisory and the VulnCheck advisory, which are analytical write-ups, not exploits. The core limiting factor confirmed by the GHSA advisory is decisive: the flaw lets a privileged child-namespace token reach plugin-catalog APIs that should be root-namespace-only, but turning that into plugin execution additionally requires the attacker-supplied registration's command to be a real file in the host plugin directory and its sha256sum to match that file on disk - so an attacker without control of the host plugin directory is confined to DoS-style abuse (deleting, invalidating, or re-registering existing plugins). This is a real but narrow privilege/authorization boundary issue, not a high-impact one.

In a multi-tenant OpenBao deployment, a tenant holding a token with write/delete capability on sys/plugins/catalog/* inside their own child namespace calls the plugin-catalog API, which fails to enforce root-namespace-only access, and deletes or corrupts existing plugin registrations to disrupt plugin-backed secrets/auth engines for other tenants. Because the attacker cannot place matching files in the host plugin directory, the realistic outcome is denial of service rather than code execution. No public exploit identified at time of analysis.