OpenBao versions prior to 2.4.1 are vulnerable to a denial of service attack via maliciously crafted JSON requests. The vulnerability arises because deserialized JSON objects can consume significantly more memory than their serialized form, allowing attackers to bypass size limits and cause out-of-memory crashes. This occurs early in the request handling process before authentication, enabling unauthenticated attackers to exploit it. Additionally, the audit subsystem may consume excessive CPU when processing requests with many strings. The issue is resolved in OpenBao version 2.4.1.
OpenBao versions 2.3.1 and below have a vulnerability in their Login Multi-Factor Authentication (MFA) system that uses Time-based One Time Passwords (TOTP). The underlying TOTP library normalizes input by allowing whitespace in codes, which can bypass internal MFA rate limiting and permit reuse of existing MFA codes. This issue was fixed in version 2.3.2. As a workaround, rate-limiting quotas can help reduce exploitation risk.
OpenBao versions 2.3.1 and below contain a vulnerability where the LDAP authentication method's username_as_alias=true parameter allows bypassing of alias-specific MFA enforcement. This occurs because the username is used verbatim without normalization, enabling attackers to circumvent MFA policies tied to entity aliases. The issue is fixed in version 2.3.2 by removing this parameter and updating aliases accordingly.
OpenBao versions 0.0.1 through 2.3.1 have a vulnerability in the TOTP secrets engine where valid one-time codes can be reused multiple times due to unexpected normalization behavior in the underlying TOTP library. This flaw allows multiple acceptance of the same TOTP code instead of enforcing a strict single-use policy. The issue is mitigated by normalizing codes before submission. A patch is available that addresses this behavior.
OpenBao versions 0.1.0 through 2.3.1 have a timing side-channel vulnerability in the userpass authentication method that allows user enumeration. This occurs because the response time differs between non-existent users and users with stored credentials, regardless of credential validity. The issue was fixed in version 2.3.2. Users can mitigate the risk by upgrading to 2.3.2 or later, using alternative authentication methods, or applying rate limiting to reduce request frequency.
OpenBao versions 0.1.0 through 2.3.1 contain a vulnerability that allows attackers to bypass the automatic user lockout mechanisms in the Userpass and LDAP authentication systems. This bypass occurs due to inconsistent aliasing between pre-flight and full login request user entity attributions. The issue is resolved in version 2.3.2. As a workaround, rate-limiting quotas can be applied to authentication endpoints.
OpenBao versions 2.3.1 and below contain a critical vulnerability that allows privileged API operators to bypass intended restrictions on system code execution and network connections via the audit subsystem. By manipulating log prefixes, these operators can execute unauthorized code and access the network, violating the security model. This issue is fixed in version 2.3.2. As a workaround, users can block access to sys/audit/* endpoints with explicit deny policies, but root operators cannot be restricted this way.
OpenBao versions 2.3.1 and below contain a vulnerability allowing accounts with access to highly-privileged identity entities in root namespaces to escalate their privileges to the root policy. The root policy, normally restricted to manual generation via unseal or recovery key shares and inaccessible from child namespaces, could be bypassed due to improper policy scope enforcement. This issue is resolved in version 2.3.2. A workaround involves using denied_parameters in policies that access the affected identity endpoints to prevent exploitation.
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.
OpenBao before version 2.3.0 may leak sensitive information in logs when processing malformed data. This vulnerability is distinct from an earlier issue identified as HCSEC-2025-09 / CVE-2025-4166. The issue has been fixed in OpenBao version 2.3.0 and later. There is no known workaround other than ensuring that all client requests are properly formatted.
A vulnerability in Vault allows a privileged operator with write access to the root namespace's identity endpoint to escalate their own or another user's privileges to Vault's root policy. This issue affects Vault versions from 1.7.7 up to but not including 1.18.0. The vulnerability has been fixed in Vault Community Edition 1.18.0 and Vault Enterprise versions 1.15.16, 1.16.11, 1.17.7, and 1.18.0.
Vault Community and Enterprise clusters using the Integrated Storage backend are vulnerable to a denial-of-service (DoS) attack via the Raft cluster join API endpoint. An attacker can send a large volume of join requests, causing excessive memory consumption that may crash the Vault process and underlying system. This vulnerability is identified as CVE-2024-8185 and affects versions from 1.2.0 up to but not including 1.18.1. Fixed versions include Vault Community 1.18.1 and Vault Enterprise 1.18.1, 1.17.8, and 1.16.12.
Vault's SSH secrets engine had a configuration issue where the valid_principals list was not required to contain a value by default. This could allow an authorized user to request an SSH certificate that authenticates as any user on the host if the valid_principals and default_user fields were not set. The vulnerability affects Vault Community Edition and Enterprise versions prior to 1.17.6 and has been fixed in versions 1.17.6 (Community), 1.17.6, 1.16.10, and 1.15.15 (Enterprise).
A vulnerability in the Node.js permission model allows bypass of intended security boundaries via path misvalidation in the process.report.writeReport() function. This affects multiple supported Node.js release lines including versions 22, 24, and 26. Red Hat has released updated hardened image RPMs that address this flaw. The vulnerability can lead to confidentiality impacts or security boundary bypass under affected configurations. The issue is tracked as CVE-2026-48617 and is rated with high severity.
Multiple vulnerabilities affecting Red Hat Hardened Images RPMs for nginx have been addressed in a security update. These include CVE-2026-42533 related to the map directive and regex matching, and CVE-2026-56434 involving a heap buffer over-read in the ngx_http_ssi_module. The vulnerabilities can lead to memory modification or denial of service. A patch is available and users are advised to apply the update to mitigate these issues.
A vulnerability in etcd prior to versions 3.5.33, 3.6.14, and 3.7.1 allows a network attacker to cause unbounded growth of handshake goroutines by opening many TCP connections to the TLS listener and not completing the TLS handshake. This can exhaust memory and cause denial of service, impacting availability of the etcd cluster and dependent systems such as Kubernetes control planes.
A vulnerability in etcd's Watch API allows a user with READ permission on a single exact key to bypass authorization and watch events for all keys lexicographically greater than or equal to that key. This affects versions prior to 3.5.33, 3.6.14, and 3.7.1 when authentication is enabled. The issue arises because the open-ended RangeEnd sentinel is rewritten before the RBAC permission check, causing improper permission validation. This flaw does not affect Range/Get or DeleteRange requests and only impacts clusters with authentication enabled. The vulnerability has been fixed in the specified versions.
JupyterLab versions from 3.3.0 up to but not including 4.5.10, and from 4.6.0 up to but not including 4.6.2, contain a cross-site scripting (XSS) vulnerability via crafted overrides.json settings files. This vulnerability arises because certain settings are not properly validated before being inserted into style content, allowing malicious code execution when a user imports a crafted settings file or when an attacker plants such a file in a shared location. The embedded code executes with the affected user's privileges and can read or modify notebooks, files, and execute code on the notebook server and connected kernels. The issue is fixed in versions 4.5.10 and 4.6.2.
JupyterLab versions prior to 4.5.10 and 4.6.2 contain a cross-site scripting (XSS) vulnerability in the ImageViewer component. The issue arises because the ImageViewer uses URL.createObjectURL for specially crafted SVG images and revokes the blob URL too early. This allows the image to retain an executable same-origin context when opened in the image viewer and then in a new browser tab. This vulnerability can lead to arbitrary code execution on the JupyterLab server. The vulnerability is fixed in versions 4.5.10 and 4.6.2.
JupyterLab versions from 4.5.0 up to but not including 4.5.10, and from 4.6.0 up to but not including 4.6.2, contain a vulnerability in the PyPI extension manager. The blocklist enforcement uses a weaker normalization method than PyPI's canonical package-name normalization, allowing an authenticated user to bypass the blocklist by requesting an equivalent package name variant. This lets the user install prohibited extensions, defeating integrity restrictions and potentially affecting availability without gaining additional read access. The issue is fixed in versions 4.5.10 and 4.6.2.