CVE-2025-6000

Published Aug 1, 2025

Last updated a year ago

CVSS critical 9.1
hsm

Overview

Description
A privileged Vault operator within the root namespace with write permission to {{sys/audit}} may obtain code execution on the underlying host if a plugin directory is set in Vault’s configuration. Fixed in Vault Community Edition 1.20.1 and Vault Enterprise 1.20.1, 1.19.7, 1.18.12, and 1.16.23.
Source
security@hashicorp.com
NVD status
Analyzed
Products
vault

Risk scores

CVSS 3.1

Type
Secondary
Base score
9.1
Impact score
6
Exploitability score
2.3
Vector string
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Severity
CRITICAL

Weaknesses

security@hashicorp.com
CWE-94

Social media

Hype score
Not currently trending

  1. #VulnerabilityReport #CVE20256000 Critical HashiCorp Vault Flaw (CVE-2025-6000) Allows Code Execution for Privileged Users https://t.co/NpB2IJXuY9

    @Komodosec

    8 Sept 2025

    44 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. Warning: A Critical RCE vulnerability in #HashiCorp Vault enables attackers to execute arbitrary code, bypass auth, escalate privileges & impersonate users. #CVE-2025-6000 CVSS(3.1): 9.1 Read the advisory: https://t.co/UjtEKYG1SA and #patch #patch #patch

    @CCBalert

    11 Aug 2025

    42 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. A critical vulnerability has been disclosed in HashiCorp Vault, tracked as CVE-2025-6000 (CVSS score 9.1), which allows a privileged attacker with write access to the sys/audit endpoint to remotely execute arbitrary code on the host system. This vulnerability affects Vault http

    @zakpatrik

    4 Aug 2025

    90 Impressions

    0 Retweets

    0 Likes

    1 Bookmark

    1 Reply

    0 Quotes

  4. HashiCorpは、Vaultにおける重大な脆弱性（CVE-2025-6000、CVSS 9.1）を修正した。 Vaultの監査ログ機能（sys/audit）を悪用することで、特権を持つオペレータがホスト上で任意コードを実行できる恐れがある。

    @yousukezan

    4 Aug 2025

    889 Impressions

    0 Retweets

    3 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  5. 🚨 CRITICAL: CVE-2025-6000 exposes HashiCorp Vault (0.8.0+) to code injection if a plugin dir is set. Privileged operators can gain host access. Patch to 1.20.1+ ASAP! 🔒 https://t.co/LtHmxaImat #OffSeq #HashiCo... https://t.co/aLxx5yvx3Y

    @offseq

    2 Aug 2025

    32 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. CVE-2025-6000 kan leda till fjärrkodexekvering i HashiCorp Vault genom osäker pluginsökväg. Uppgradera snarast för att skydda er miljö. #säkerhet #cybersäkerhet #CVE

    @Sakerhetsblogg

    1 Aug 2025

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. [CVE-2025-6000: CRITICAL] Critical security vulnerability in Vault fixed in versions 1.20.1 & 1.19.7, 1.18.12, and 1.16.23. Attackers could gain code execution, affecting cyber security.#cve,CVE-2025-6000,#cybersecurity https://t.co/icXcrAB4kJ https://t.co/WiBEwH5rqL

    @CveFindCom

    1 Aug 2025

    51 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. CVE-2025-6000 A privileged Vault operator within the root namespace with write permission to {{sys/audit}} may obtain code execution on the underlying host if a plugin directory is s… https://t.co/W8cEQOV36l

    @CVEnew

    1 Aug 2025

    228 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

Configurations

Related CVEs

  1. Temporal Server decided whether a Workflow completion callback was internal by reading a caller-supplied HTTP header. An authenticated caller holding only write permission in a single namespace could attach a completion callback whose URL host matched the configured callback address allowlist, whose URL path was any Temporal HTTP API route, and whose header map contained a non-empty header named source. When the History service delivered that callback, the non-empty source header caused it to re-target the request at the local frontend client and rewrite only the scheme and host, preserving the caller's path, query, and request body. Where an internal frontend is deployed with its HTTP API enabled, that client resolves to the internal frontend, which authorizes every request as a system administrator without requiring authentication information. The result is that the server performs an attacker-chosen state-changing HTTP POST against its own administrative API on the caller's behalf, in namespaces where the caller has no permission. The caller never needs network access to the internal frontend, because the History service makes the request. Confirmed effects include terminating Workflows in other namespaces, registering namespaces, modifying another namespace's configuration, and deleting another namespace and its Workflows. The affected routing logic is present in both the HSM and CHASM callback delivery implementations. This description and the CVSS score in this record describe releases 1.30.0 and later, where any non-empty source header is sufficient. Releases 1.25.0 through 1.29.7 are affected by a narrower form of the same defect in which the header must exactly match a configured cluster ID, a UUID that a namespace-scoped caller cannot read through the API. The consequence once that match occurs is the same, but the attack is materially harder and scores lower. To determine whether a deployment is affected, check two settings together: the static Server configuration for a non-zero services.internal-frontend.rpc.httpPort, and the effective per-namespace dynamic configuration value of component.callbacks.allowedAddresses. A deployment is exposed only when an internal frontend is deployed with a non-zero HTTP port, at least one allowlist rule admits a host, and authorization is enabled. The allowlist is empty by default, which denies all external callback URLs, and the stock static topology does not include an internal frontend. Note that a failed attach returns the error 'invalid url: url does not match any configured callback address', which proves only that one tested URL did not match and does not prove the effective allowlist is empty. To look for callbacks already attached, use DescribeWorkflowExecution, which returns callback information for a Workflow's registered completion callbacks. Operators should be aware of a gap when searching for evidence of delivery: the frontend HTTP API server records the request method and URL at debug level only, so at default log levels a delivered request is not written to the internal frontend's logs, and the absence of such log entries is not evidence that the issue was not exploited.•CVE-2026-87858
  2. A command injection vulnerability in Palo Alto Networks PAN-OS® software enables an authenticated administrator to bypass system restrictions and run arbitrary commands as a root user. To be able to exploit this issue, the user must have access to the PAN-OS CLI and the device must be configured with a Luna Hardware Security Module (HSM). The security risk posed by this issue is significantly minimized when CLI access is restricted to a limited group of administrators. Panorama, Cloud NGFW, and Prisma® Access are not impacted by this vulnerability.•CVE-2026-0309
  3. In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.•CVE-2026-43500
  4. In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: avoid in-place decrypt on shared skb frags MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data().•CVE-2026-43284
  5. Linux Kernel Incorrect Resource Transfer Between Spheres Vulnerability•CVE-2026-31431

References

Sources include official advisories and independent security research.