CVE-2025-15566

Published Feb 6, 2026

Last updated 3 months ago

CVSS high 8.8
Kubernetes
ingress-nginx
Container Security

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-15566 is a vulnerability found in the Kubernetes ingress-nginx controller. It stems from improper input validation (CWE-20) concerning the `nginx.ingress.kubernetes.io/auth-proxy-set-headers` Ingress annotation. This annotation, intended for setting authentication proxying headers, can be manipulated due to insufficient validation. Exploiting this flaw allows an attacker to inject arbitrary configuration directives into the nginx configuration managed by the ingress controller. Given that the ingress-nginx controller typically operates with elevated privileges and often has cluster-wide access to Kubernetes Secrets, successful exploitation could lead to arbitrary code execution within the controller's context and the unauthorized disclosure of sensitive Secrets.

Description
A security issue was discovered in ingress-nginx where the `nginx.ingress.kubernetes.io/auth-proxy-set-headers` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)
Source
jordan@liggitt.net
NVD status
Deferred

Risk scores

CVSS 3.1

Type
Secondary
Base score
8.8
Impact score
5.9
Exploitability score
2.8
Vector string
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity
HIGH

Weaknesses

jordan@liggitt.net
CWE-20

Social media

Hype score
Not currently trending

  1. CVE-2025-15566 (CVSS:8.8, HIGH) is Awaiting Analysis. A security issue was discovered in ingress-nginx where the `https://t.co/ck5lZ1DrME` Ingress ..https://t.co/uKT90IxpUB #cybersecurityawareness #cybersecurity #CVE #infosec #hacker #nvd #mitre

    @cracbot

    11 Feb 2026

    9 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. no this cve, CVE-2025-15566 is not from the set earlier this week - this is just the non-stop security nightmare that is kubernetes https://t.co/jIcxg8dr0D

    @nanovms

    6 Feb 2026

    186 Impressions

    2 Retweets

    3 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. CVE-2025-15566 #devopsish #kubernetes #cve https://t.co/mIyVR7HGKV

    @ChrisShort

    6 Feb 2026

    119 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. CVE-2025-15566: ingress-nginx auth-proxy-set-headers nginx configuration injection - https://t.co/fmNcoelbFa

    @kubernetesio

    6 Feb 2026

    5080 Impressions

    7 Retweets

    33 Likes

    17 Bookmarks

    3 Replies

    0 Quotes

  5. CVE-2025-15566: ingress-nginx auth-proxy-set-headers nginx configuration injection - https://t.co/w1VtoO3WAv

    @K8sContributors

    6 Feb 2026

    727 Impressions

    1 Retweet

    11 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  6. CVE-2025-15566 Kubernetes Ingress-Nginx Arbitrary Code Execution via Header Injection Annotation https://t.co/13fssoOBrk

    @VulmonFeeds

    6 Feb 2026

    84 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. CVE-2025-15566 A security issue was discovered in ingress-nginx where the `https://t.co/5vaSyCfUF2` Ingress annotation can be used to inject configuration… https://t.co/iXN8vewOdK

    @CVEnew

    6 Feb 2026

    206 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Related CVEs

  1. CVE-2025-14269
  2. SimpleHelp Authentication Bypass Vulnerability•CVE-2026-48558
  3. In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors.•CVE-2026-46300
  4. In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.•CVE-2026-43503
  5. 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

References

Sources include official advisories and independent security research.