Kong Ingress Controller for Kubernetes (KIC): Cross-namespace TLS Secret Exfiltration in Gateways with GatewayClass missing `konghq.com/gatewayclass-unmanaged: 'true'` annotation
Kong Ingress Controller for Kubernetes (KIC): Cross-namespace TLS Secret Exfiltration in Gateways with GatewayClass missing `konghq.com/gatewayclass-unmanaged: 'true'` annotation
Prioriteit & onderbouwing
Prioriteit: Laag
Monitoren
Laag (39/100): monitoren. Zwaarst wegend: technische ernst en betrouwbaarheid van het signaal.
midden
- Technische ernst (severity): Genormaliseerde ernst 'medium'; geen CVSS-score beschikbaar.
laag
- Geen exploit bekend: Er is geen exploit of actief misbruik bekend.
midden
- Gemeentelijke relevantie: Relevantiescore 35/100 uit de relevantie-engine (module 5).
midden
- Technische ernst: Threat Score 42/100 x gewicht 25%.
- Exploitatie: Exploit Score 10/100 x gewicht 25%.
- Gemeentelijke relevantie: Relevantiescore 35/100 x gewicht 22%.
- Betrouwbaarheid van het signaal: Confidence 'likely' x gewicht 12%.
- Blootstellingskans: Geschatte blootstelling 30% x gewicht 10%.
- Betrouwbaarheid van de bron: Bronbetrouwbaarheid 88% x gewicht 6%.
De priority_score is de Action Urgency Score: een gewogen combinatie van de technische ernst, de exploitatie en de gemeentelijke relevantie.
Toelichting
## Summary A vulnerability in the Kong Ingress Controller (KIC) allows for the unauthorized exfiltration of TLS certificates and private keys across Kubernetes namespace boundaries. In "managed" mode (where the `GatewayClass` lacks an unmanaged annotation), the Gateway TLS translator skips critical status checks. This bypass allows the translator to fetch Secrets from any namespace KIC watches, even when a `ReferenceGrant` explicitly denies access or is missing. An actor with RBAC permissions to create or modify Gateways in a low-privileged namespace can reference a Secret in a high-privileged namespace, causing KIC to "leak" that Secret's sensitive private key material into the Kong dataplane configuration. ## Am I affected? You are affected if all of these hold: 1. You are using Kong Ingress Controller with the **Gateway API**. 2. Your `GatewayClass` is operating in **managed mode** (default behavior, no unmanaged annotation). 3. KIC is configured to **watch multiple namespaces** (multi-tenant environment). 4. Users have RBAC permissions to `create` or `update` `gateways.gateway.networking.k8s.io` in their own namespaces. You are not affected if any of this: - You only use KIC for `Ingress` resources (not Gateway API). - Your `GatewayClass` uses the `konghq.com/gateway-unmanaged` annotation. - KIC is restricted via RBAC or configuration to only watch a single namespace. - You have strictly limited Gateway creation/modification permissions to trusted cluster administrators only. ## Mitigation 1. **Add unmanaged gateway annotation**: add the `konghq.com/gateway-unmanaged` annotation to your `GatewayClass` ### Additional best practicies 1. **Restrict Gateway RBAC**: Limit the ability to create or modify Gateway resources to high-trust administrative users until a patch is applied. 2. **Namespace Isolation**: If possible, limit the namespaces KIC is permitted to watch using the `WATCH_NAMESPACE` environment variable or specific RBAC RoleBindings. ## Fix The fix mandates `ReferenceGrant` validation for all cross-namespace certificate references. By requiring a `Programmed: True` listener status, the translator now strictly authorizes external Secret access while maintaining default access for same-namespace certificates, effectively closing the exfiltration vector. Fixed in [#7920](https://github.com/Kong/kubernetes-ingress-controller/pull/7920), with backports to supported release branches in [#7921](https://github.com/Kong/kubernetes-ingress-controller/pull/7921) and [#7922](https://github.com/Kong/kubernetes-ingress-controller/pull/7922). Upgrade to one of the following patched versions (or later): - **3.4.14** - **3.5.7** ## CVSS `CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:P` = **5.6 Medium**
Onderbouwing van de classificatie
Categorie 'supplier_incident' overgenomen van de bron; geen specifieker incidenttype gedetecteerd. Severity 'medium' bepaald op basis van: bronlabel 'medium'. Confidence 'likely': gerenommeerd securityonderzoek (GitHub Security Advisories). Geen bekende leveranciers of producten herkend.
Kwetsbaarheden
- CVSS
- —
- EPSS
- —
- KEV
- Nee
Gemeentelijke relevantie
Deze dreiging scoort 35/100 voor de gemeentelijke relevantie. Meegewogen: getroffen internetgerichte technologie en een leveranciers- of ketenrisico. Geraakte processen: Leveranciersketen.
Bestuurlijke duiding
Deze dreiging is relevant voor de gemeente. Omdat het een leverancier betreft, is de gemeente afhankelijk van diens herstel en is regie op de keten nodig. De impact is beheersbaar mits de geadviseerde maatregelen tijdig worden opgevolgd. Laat de CISO de voortgang bewaken en escaleer richting directie zodra nieuwe signalen daartoe aanleiding geven.
Geraakte processen
Geraakte technologie
Betrokken rollen
CISO · ISO · Leveranciersmanager
Operationele acties
- Inventariseer welke koppelingen en gegevensstromen met de leverancier lopen.
- Schakel waar nodig de koppeling met de leverancier tijdelijk uit.
- Vraag bewijs van herstel op voordat de dienstverlening wordt hervat.
Concrete stappen voor ICT-beheer en het securityteam.
Aanbevolen acties
- Breng in kaart welke leveranciers en koppelingen zijn geraakt.
- Vraag de leverancier om een statusupdate en een herstelplan.
- Beoordeel de impact op de eigen dienstverlening.
Dit zijn algemene handelingsperspectieven. Stem de opvolging af op de eigen omgeving en het ISMS van uw gemeente.
Kenmerken
- Ernst
- Midden
- Categorie
- Leveranciersincident
- Zekerheid
- Waarschijnlijk
- Status
- Verrijkt
- CVE's
- Geen
- Prioriteitsscore
- 39 / 100 · Laag
- Bron
- GitHub Security Advisories
- Gepubliceerd
- 19 mei 2026