Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-53935

CVE-2026-53935: Cilium Auth Bypass Vulnerability

CVE-2026-53935 is an authentication bypass flaw in Cilium that allows users to hijack service traffic across namespaces via CiliumLocalRedirectPolicies. This article covers technical details, affected versions, and fixes.

Published:

CVE-2026-53935 Overview

CVE-2026-53935 is an authorization flaw [CWE-863] in Cilium, an open source networking, observability, and security solution for Kubernetes environments. Users with permission to create CiliumLocalRedirectPolicy resources can specify arbitrary ClusterIP values through the addressMatcher field. This allows them to hijack traffic destined for Services in any namespace, bypassing the namespace scoping enforced by serviceMatcher. Deleting an offending policy can also corrupt Cilium's internal service state and stop service translation for the affected Service. The issue affects releases prior to 1.17.16, 1.18.2 through 1.18.9, and 1.19.0 through 1.19.3.

Critical Impact

A tenant with local redirect policy privileges can silently reroute cross-namespace Service traffic and permanently disrupt Service datapath state.

Affected Products

  • Cilium versions prior to 1.17.16
  • Cilium versions 1.18.2 through 1.18.9
  • Cilium versions 1.19.0 through 1.19.3

Discovery Timeline

  • 2026-07-07 - CVE-2026-53935 published to NVD
  • 2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-53935

Vulnerability Analysis

Cilium's CiliumLocalRedirectPolicy (LRP) resource supports two selectors for the redirect frontend: serviceMatcher and addressMatcher. The serviceMatcher selector is namespace-scoped and requires the policy to target a Service in the same namespace as the policy object. The addressMatcher selector, in contrast, accepts a raw IP address and port. Cilium did not verify whether the specified address collided with an existing Kubernetes Service frontend.

An actor with permissions to create an LRP in one namespace can craft redirectFrontend.addressMatcher values that match the ClusterIP of a Service in a different namespace. Traffic destined for that Service is then redirected to backend pods selected by the attacker's policy. This produces a covert traffic hijack that circumvents the namespace boundary that serviceMatcher enforces.

Deleting the malicious LRP compounds the impact. Cilium's service-map bookkeeping removes the frontend entry that the LRP occupied, leaving the legitimate Service without a corresponding service-map entry. Service translation for that ClusterIP stops until the state is manually reconciled.

Root Cause

The root cause is missing authorization and conflict checking on the addressMatcher field [CWE-863]. Cilium accepted arbitrary frontend addresses without verifying ownership by an existing Service or the requester's authority over that address.

Attack Vector

Exploitation requires an authenticated principal with rights to create CiliumLocalRedirectPolicy resources on the cluster. The attack is executed from within the cluster network. No user interaction is required. The resulting traffic redirection crosses namespace boundaries, and Service state corruption persists after policy deletion.

text
// Documentation clarification from the upstream fix
// Source: https://github.com/cilium/cilium/commit/92ca32eda85aa0c7611c28221cc26fa08be17ebc

AddressMatcher is intended for IPs that do not belong to a
Kubernetes Service. If the IP and port/protocol in
`redirectFrontend.addressMatcher` coincide with an existing
`ClusterIP` Service frontend, the policy is not applied to that
address. Cilium refuses to override a frontend owned by another
Service and logs:

    LocalRedirectPolicy matches an address owned by an existing service => refusing to override

To redirect traffic destined for a Service, use `ServiceMatcher` instead.

Detection Methods for CVE-2026-53935

Indicators of Compromise

  • Cilium agent log entries containing LocalRedirectPolicy matches an address owned by an existing service => refusing to override after upgrading to a patched release.
  • CiliumLocalRedirectPolicy objects whose redirectFrontend.addressMatcher.ip equals the ClusterIP of a Service in a different namespace.
  • Services that lose datapath connectivity shortly after an LRP referencing their ClusterIP is deleted.

Detection Strategies

  • Inventory all CiliumLocalRedirectPolicy resources across the cluster and correlate each addressMatcher IP/port with the ClusterIP/port of existing Services.
  • Flag any LRP where the frontend address maps to a Service outside the policy's own namespace.
  • Audit Kubernetes RBAC to identify subjects with create verbs on ciliumlocalredirectpolicies and confirm that each principal is authorized to redirect cluster traffic.

Monitoring Recommendations

  • Ship cilium-agent logs to a central store and alert on warnings related to LRP address conflicts.
  • Monitor Kubernetes audit logs for CiliumLocalRedirectPolicy create, update, and delete events, especially in tenant namespaces.
  • Track Service endpoint health and BPF service-map counters to catch Services that fall out of the datapath after LRP deletions.

How to Mitigate CVE-2026-53935

Immediate Actions Required

  • Upgrade Cilium to 1.17.16, 1.18.10, or 1.19.4 as appropriate for your release branch.
  • Restrict RBAC so that only trusted cluster operators can create or modify CiliumLocalRedirectPolicy objects.
  • Review existing LRPs and remove or rewrite any that use addressMatcher against a Kubernetes Service ClusterIP.

Patch Information

The fix is delivered in Cilium 1.17.16, 1.18.10, and 1.19.4. Patched agents refuse to apply an LRP whose addressMatcher collides with an existing Service frontend and emit a warning log. Details are published in the Cilium Security Advisory GHSA-q6h5-q3q6-f87x and implemented in Cilium Pull Request #45412, Cilium Pull Request #45584, and Cilium Pull Request #45585. On the 1.17 branch, the transient flag --enable-lrp-address-matcher-override=true restores the legacy behavior for backward compatibility; do not enable it unless required.

Workarounds

  • Deny create and update on ciliumlocalredirectpolicies.cilium.io via Kubernetes RBAC to all non-administrative principals until the upgrade is complete.
  • Use an admission controller (for example, OPA Gatekeeper or Kyverno) to reject LRPs whose addressMatcher.ip matches any known Service ClusterIP.
  • Migrate legitimate use cases from addressMatcher to serviceMatcher, which enforces namespace scoping by design.
bash
# Kyverno policy example: block CiliumLocalRedirectPolicy that uses addressMatcher
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-lrp-addressmatcher
spec:
  validationFailureAction: Enforce
  rules:
    - name: deny-addressmatcher
      match:
        any:
          - resources:
              kinds:
                - CiliumLocalRedirectPolicy
      validate:
        message: "addressMatcher is disallowed; use serviceMatcher instead (CVE-2026-53935)."
        pattern:
          spec:
            redirectFrontend:
              X(addressMatcher): "null"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.