NGINX Gateway Fabric
CVE-2026-96615: NGINX Gateway Fabric leaks TLS private keys across namespaces
A namespaced attacker with a Kubernetes service account can impersonate the NGINX Agent gRPC connection and read TLS private keys of Gateways in other namespaces. Fixed in 2.8.0; F5's record doesn't mention exploitation.
Published Updated
Affected and fixed versions
| Product / branch | Fixed in |
|---|---|
| NGINX Gateway Fabric 2.0.0 to 2.7.x | 2.8.0 or later |
Always confirm against the vendor advisory, which lists every fixed hotfix.
What it is
NGINX Gateway Fabric’s control plane talks to NGINX Agent over an authenticated gRPC connection. F5 says an attacker who has a service account in one namespace can impersonate that connection (CWE-290, identity spoofing) and read the TLS private keys of Gateway deployments in other namespaces.
It’s a confidentiality bug only: F5 rates it CVSS 3.1 6.5 (medium) and CVSS 4.0 7.1 (high), with no integrity or availability impact. F5 describes it as a control plane issue with no data plane exposure. The risk is that stolen keys let an attacker impersonate your services or decrypt captured traffic.
Am I affected?
You’re affected if both are true:
- You run NGINX Gateway Fabric 2.0.0 up to, but not including, 2.8.0.
- It is configured with Gateway CRDs and an authenticated gRPC connection to NGINX Agent.
The attacker also needs a service account with access in the cluster, so multi-tenant clusters, where teams share a cluster but not namespaces, are the main concern.
F5 doesn’t evaluate software past End of Technical Support. Check the version you run against the F5 advisory.
What to do
- Upgrade to NGINX Gateway Fabric 2.8.0 or later. This is the fixed version implied by F5’s CVE record (affected range “up to but not including 2.8.0”).
- F5’s record lists no workaround. Until you upgrade, limit who can obtain service accounts in namespaces on the cluster.
- If untrusted or semi-trusted users had service-account access while you ran an affected version, treat the TLS private keys of your Gateways as possibly exposed: reissue the certificates and rotate the keys.
Detection
Neither F5’s record nor any source I found describes log entries or indicators for this issue, and no exploitation has been reported. Review Kubernetes audit logs for unexpected use of service accounts in namespaces that can reach the NGINX Gateway Fabric control plane, and review access to the Secrets that hold Gateway TLS keys. These are general hunting ideas, not vendor guidance.
Indicators of compromise
Checked the F5 CVE record. No indicators have been published and the record doesn't mention exploitation. Not independently searched beyond that.
No indicators of compromise have been published for this CVE yet. We'll add them here if the vendor or a researcher releases any. Until then, use the behaviour in Detection.
Sources
Page changelog
- Full analysis published.
KEV status, EPSS score and vendor data refreshed automatically, last on 15 Oct 2026.