Do Son 
TL;DR
The free5GC project has published two security advisories with full technical details and proof-of-concept material. The worst of these free5GC vulnerabilities, CVE-2026-115926, scores 9.1 on CVSS v3.1. It leaves a key 5G core service open to anyone on the network. As of October 28, neither flaw has a patched release.
free5GC’s Binding Support Function (BSF) has no authentication at all. Separately, the project ships its root CA private key inside the public source code. Both advisories include working PoC material, so operators should apply workarounds now.
- Vulnerabilities: 2 flaws (CVE-2026-115926, CVE-2026-115925)
- Highest severity: 9.1 (Critical · CVSSv3)
- Status: No confirmed exploitation yet
- Action: See vendor advisories
| CVE | CVSS (CVSSv3) | Status |
|---|---|---|
| CVE-2026-115926 | 9.1 | Not exploited |
| CVE-2026-115925 | 8.7 | Not exploited |
Why It Matters
free5GC is an open-source 5G core network. Labs, researchers and private 5G projects use it to run core functions such as the AMF, SMF and PCF. As a result, a flaw in one function can ripple across the whole 5G core.
The BSF advisory states that the bug enables “control-plane redirection attacks against the entire 5G core.” Meanwhile, the second advisory warns that the exposed key “enables complete compromise of TLS/mTLS communications across all 5G core services.”
How the Attack Works
CVE-2026-115926: BSF without authentication
The BSF tracks which policy function (PCF) serves each subscriber. According to the advisory, the BSF exposes its management API “with zero authentication middleware.” By contrast, every other free5GC function checks OAuth2 tokens.
Consequently, anyone who can reach the BSF port can read, create, change or delete subscriber bindings. An attacker can point a subscriber’s binding to a rogue PCF. The SMF then sends policy requests to that rogue server. That hands the attacker control over QoS, charging and traffic gating. Fake bindings also persist in the database across restarts.
The reporter published scripts and a Docker lab that reproduce each step. In addition, the advisory notes that the BSF “appears to have shipped before completing the auth integration.”
CVE-2026-115925: Root CA private key in the repo
The second of the free5GC vulnerabilities scores 8.7. The project commits an “unencrypted Root Certificate Authority (CA) private key” to its repository. That key signs the certificates for every network function. Therefore, anyone with the key could forge a trusted certificate and impersonate a core service. The attack still needs a man-in-the-middle position, which raises its complexity.
Affected Versions
- CVE-2026-115926: the free5gc/bsf component up to commit 1754bde, shipped with free5GC v4.2.3
- CVE-2026-115925: free5GC v1.0.0 through v4.2.3 and later
Notably, a check of the free5GC GitHub repositories on October 28 found the root key still present. The BSF router also still registers its routes without an auth check. This includes the code behind the v4.3.0 release.
Patch and Mitigation
Neither advisory lists a fixed version. Until fixes ship, generate a new root CA key and re-sign every network function certificate. Never use the bundled key in a real deployment.
For the BSF, block access to its service port from anything except trusted core functions. Alternatively, disable the optional BSF if you do not need it. So far, no attacks in the wild have been reported for these free5GC vulnerabilities.
Support Our Threat Intelligence
Find our vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
