# The Cellular Core Was Never Built to Be Trusted From the Outside. Now It Is.


When carriers moved their 4G and 5G core networks into the cloud, they brought along an assumption that no longer holds: that the components talking to each other could be trusted by default, because they all lived behind the same wall.


That wall is gone. The assumption stayed.


Researchers from Nanyang Technological University published findings this week that expose 84 previously unknown vulnerabilities across seven open-source LTE and 5G core implementations — bugs that can trigger denial-of-service attacks and, more critically, allow an attacker to seize control of a user's active network session. Eighty-three of the 84 have been confirmed. Eighty-one now have CVE identifiers. The root cause is the same across all of them.


## One Problem, Eighty-Four Faces


The researchers call the vulnerability class "implicit trust errors," or iTrues. The name is precise. These aren't memory corruption bugs or cryptographic failures. They're logic errors — places where core network components receive messages from internal peers and simply act on them, skipping the checks that would verify whether the message is well-formed, semantically valid, or even coming from a legitimate source.


That sounds benign until you consider what the session hijacking attack actually looks like. In PFCP (Packet Forwarding Control Protocol), which governs how traffic gets routed through 5G user-plane functions, duplicate PDR IDs in a Session Modification Request can trick a UPF into reassigning an active session to an attacker. No credential theft. No malware. Just a malformed packet that the network silently accepts, because it was designed to trust whoever sent it.


The affected implementations span two LTE and five 5G stacks: Open5GS, OpenAirInterface, free5GC, SD-Core, and eUPF — covering both GTP-C and PFCP signaling protocols. These aren't obscure research toys. Open5GS and OpenAirInterface underpin university testbeds and commercial deployments. SD-Core is part of the Aether project, which targets private enterprise 5G networks. The blast radius here is real.


## How the Cloud Cracked Open the Core


Traditional carrier networks treated physical isolation as a security control. Core network functions communicated over dedicated links in controlled facilities. Even if the software trusted its neighbors without verification, the neighbors were hard to reach. The attack surface existed but was physically constrained.


Cloud-native deployment changed the equation. Virtualized network functions run on shared infrastructure, often across multi-tenant environments. The interfaces between core components — GTP-C for control plane signaling, PFCP between control and user plane functions — can now be reachable from outside the trust zone if network segmentation isn't perfect. And in complex cloud environments, segmentation is rarely perfect.


The researchers put it plainly: the transition to cloud-native deployments has made the historic trust model "fragile." That's diplomatic. What it means in practice is that an adversary who can reach the IP address of a core network component — through misconfiguration, a compromised adjacent system, or a deliberately exposed research testbed — can exploit these flaws without needing carrier-level access.


## A Vulnerability Discovery Engine Built From Language Models


The methodological story here is worth separate attention. The NTU team didn't find 84 bugs by reading specs and fuzzing manually. They built iFinder: an LLM-assisted multi-agent system that summarizes known vulnerabilities, categorizes them into detection patterns, and uses those patterns to hunt for new iTrues in actual codebases.


The pipeline handles the hallucination problem — a genuine obstacle when using LLMs for security analysis — through code-specification cross-checking. Before a candidate vulnerability gets flagged, the system maps it to the protocol procedure it implements and verifies whether the required validation actually exists in the codebase. False positives get filtered out structurally, not by hand.


iFinder then generates proof-of-concept exploits and refines them iteratively by running them against live CN implementations and analyzing the results. The researchers essentially built a continuous feedback loop between vulnerability hypothesis and empirical confirmation.


This is the future of large-scale protocol security research, and it cuts both ways. Defenders can use tooling like this to audit their own stacks before deployment. Adversaries — nation-states with research capacity, primarily — can build the same pipelines.


## The Inheritance Problem


One detail in the paper deserves more attention than it will likely get: some 5G vulnerabilities were directly inherited from their 4G counterparts. The researchers explicitly flag this as an example of how security risks can "jump generations."


This isn't a surprise if you understand how 5G was built. Significant portions of the 5G core were designed to interwork with LTE, and open-source implementations frequently reused code from LTE predecessors. If a validation gap existed in the LTE PFCP implementation, porting it to a 5G stack without an explicit security review brought the bug along for free.


The implication is that you cannot assess a 5G deployment's security posture without auditing what it inherited from 4G. Operators running mixed-generation networks — which is most of them — are carrying technical debt from an era when physical isolation did the job that software should be doing now.


---


## HackWire Analysis


The 84-flaw count is the number that will dominate headlines. It shouldn't be.


What this research actually exposes is a structural failure mode in how the telecommunications industry handled its cloud-native transition. The implicit trust model worked when "internal" meant physically internal. The moment carrier networks started running as virtualized functions on shared infrastructure, that assumption became a liability — and nobody systematically audited whether the software had been updated to reflect the new reality.


This is the same failure pattern we've seen in OT/ICS security for fifteen years. Air-gapped systems moved to networked environments; the security assumptions moved with them on paper, not in the code. The result was Stuxnet, and then a decade of industrial control system vulnerabilities that keep reappearing because the root cause — blind internal trust — was never actually fixed.


Telecom is now running that playbook, just with 5G stacks instead of PLCs.


For private network operators — enterprises running 5G on SD-Core or similar platforms for industrial IoT, manufacturing, or campus connectivity — the exposure calculus is immediate. These networks tend to have tighter physical perimeters than public carrier networks, but the software stacks are the same. If an attacker gets inside the perimeter (phishing, supply chain, insider), the path from "on the network" to "hijacking sessions" is now documented and CVE-numbered.


Defenders running any of the seven affected implementations should treat this as a patch-and-audit event, not a monitoring task. Wait for PoC code to circulate — and it will — and you're playing defense against a published exploit.


The researchers have disclosed to affected projects. Patch timelines weren't published. That gap is where risk lives right now.


— HackWire Editorial


---


## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)