CVE-2025-14269

Container Security

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-14269 refers to a security vulnerability discovered in Headlamp, a web UI for Kubernetes. Specifically, the vulnerability affects the in-cluster version of Headlamp where unauthenticated users could potentially reuse cached credentials to access Helm functionality via the Headlamp UI. Kubernetes clusters are only affected if Headlamp is installed in-cluster with the configuration setting `config.enableHelm` set to true, and an authorized user has previously accessed the Helm functionality. The vulnerability is related to how Headlamp handles credentials when interfacing with Helm, the package manager for Kubernetes. If a legitimate administrator accesses Helm features within Headlamp, their credentials might be cached insecurely. An attacker with network access to the dashboard could then use those cached credentials to perform Helm operations without logging in.

Description
-

Social media

Hype score
Not currently trending

  1. CVE-2025-14269: Kubernetes: Credential caching in Headlamp with Helm enabled https://t.co/U8eo4NY7VJ Unauthenticated users may access Helm. Clusters are only affected if Headlamp is installed, configured with config.enableHelm: true, and an authorized user has previously accessed

    @oss_security

    26 Dec 2025

    1501 Impressions

    3 Retweets

    8 Likes

    3 Bookmarks

    0 Replies

    0 Quotes

  2. [Security Advisory] CVE-2025-14269: Credential caching in Headlamp with Helm enabled #devopsish https://t.co/AaUjOXp2na

    @ChrisShort

    23 Dec 2025

    63 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. Kubernetes向けWeb UI「Headlamp」に認証情報キャッシュの脆弱性(CVE-2025-14269) https://t.co/tnHuLO6SgG #セキュリティ対策Lab #セキュリティ #Security

    @securityLab_jp

    22 Dec 2025

    70 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. CVE-2025-14269 PoC #exploit https://t.co/qy4ViyDjoC https://t.co/TM44dPxQOJ

    @TheExploitLab

    22 Dec 2025

    142 Impressions

    0 Retweets

    0 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  5. Dissecting the KUBERNETES CVE-2025-14269 Credential Hijack Read the full report on - https://t.co/VsKbRd2uiy https://t.co/aeWCdX8xiE

    @cyberbivash

    21 Dec 2025

    3 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. CVE-2025-14269: Credential caching in Headlamp with Helm enabled - https://t.co/k5HxzzAdTE

    @kubernetesio

    18 Dec 2025

    5038 Impressions

    1 Retweet

    15 Likes

    7 Bookmarks

    1 Reply

    0 Quotes

Related CVEs

  1. 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
  2. Linux Kernel Incorrect Resource Transfer Between Spheres Vulnerability•CVE-2026-31431
  3. Docker Model Runner (DMR) is software used to manage, run, and deploy AI models using Docker. Prior to version 1.1.25, Docker Model Runner contains an SSRF vulnerability in its OCI registry token exchange flow. When pulling a model, Model Runner follows the realm URL from the registry's WWW-Authenticate header without validating the scheme, hostname, or IP range. A malicious OCI registry can set the realm to an internal URL (e.g., http://127.0.0.1:3000/), causing Model Runner running on the host to make arbitrary GET requests to internal services and reflect the full response body back to the caller. Additionally, the token exchange mechanism can relay data from internal services back to the attacker-controlled registry via the Authorization: Bearer header. This issue has been patched in version 1.1.25. For Docker Desktop users, enabling Enhanced Container Isolation (ECI) blocks container access to Model Runner, preventing exploitation. However, if the Docker Model Runner is exposed to localhost over TCP in specific configurations, the vulnerability is still exploitable.•CVE-2026-33990
  4. Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows attackers to bypass authorization plugins (AuthZ). This issue has been patched in version 29.3.1.•CVE-2026-34040
  5. In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a ("netfilter: nft_set_rbtree: don't gc elements on insert").•CVE-2026-23351

References

Sources include official advisories and independent security research.