GHSA-fm8w-2m5w-9j7r is a medium-severity (CVSS 5.4) CWE-863 vulnerability in github.com/cilium/cilium. O3 Security confirms whether GHSA-fm8w-2m5w-9j7r is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Cilium may unexpectedly allow ingress traffic from the local namespace when a Kubernetes NetworkPolicy is configured with an ipBlock match
Real-World Exposure
github.com/cilium/ciliumReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Standard Kubernetes NetworkPolicy specifications using CIDR-based ipBlock rules without pod or namespace selectors erroneously generate a wildcard namespace allow rule under specific cluster configurations.
When Cilium deployment is configured with a specific custom clusterName (rather than the default "any" value), the parser incorrectly instantiates a pod selector on selectorless peer definitions. This leads to Cilium appending an unintended wildcard namespace label selector to the policy's allowed Layer 3 rules, which allows traffic from other workloads in the same namespace as the subject of the policy.
Example policy affected by this issue:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-server
namespace: default
spec:
podSelector:
matchLabels:
app: test-server
policyTypes:
- Ingress
ingress:
- from:
- ipBlock:
cidr: 192.0.2.3
In affected versions, this policy erroneously allows the test-server Pod in the default namespace to receive any traffic from other workloads running in the default namespace.
Patches
This issue has been patched in:
- Cilium v1.19.5
Releases below v1.19.0 are not affected.
This issue affects:
- Cilium v1.19 between v1.19.0 and v1.19.4 inclusive
Workarounds
Developers can create the equivalent policy using CiliumNetworkPolicy fromCIDR expressions. CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy are not affected by this issue.
Acknowledgements
Special thanks to @TheBeeZee for reporting this issue and preparing the fix, and to @fristonio and @odinuge for their assistance in reviewing the solution.
For more information
If a vulnerability affecting Cilium appears to have been found, the Cilium security team strongly encourages reporting it to the security mailing list at [email protected]. This is a private mailing list for the Cilium security team, and the report will be treated as top priority.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/cilium/cilium | ≥ 1.19.0&&< 1.19.5 | 1.19.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/cilium/cilium. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/cilium/cilium to 1.19.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fm8w-2m5w-9j7r is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-fm8w-2m5w-9j7r is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-fm8w-2m5w-9j7r. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-fm8w-2m5w-9j7r in your dependencies?
O3 detects GHSA-fm8w-2m5w-9j7r across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.