Researchers at Nanyang Technological University turned a set of AI agents loose on the software that runs 4G and 5G phone networks, and the agents came back with 84 security flaws nobody had reported before.
Developers have confirmed 83 of them, and 81 now carry CVE numbers. The most serious one lets an attacker take over a subscriber’s data session, so the network delivers that subscriber’s traffic to the attacker instead of to the internet.
The hijack works because of a bad assumption. Inside a phone network, one component decides where a subscriber’s data should go and tells another component to move it. Those instructions travel over internal links that were designed back when the whole core sat in a locked room, so the receiving side tends to accept whatever arrives without much checking. An attacker who can reach one of those links sends an instruction that reuses the ID of a forwarding rule already assigned to a real subscriber, flagged as higher priority than the original. Nothing verifies that the ID is unique. The network sorts by priority, picks the attacker’s rule, and starts delivering the victim’s outbound traffic to the attacker.
The attack ran end to end in a lab against OpenAirInterface’s 5G core, which is open source. It was then validated on two commercial 5G core networks, including a reproduction inside a partner vendor’s lab under default settings. One vendor has fixed the problem and CVE-2026-8233 was assigned. The other, a major 5G carrier, is still working on it.
What makes this more than a lab curiosity is where phone networks now live. Operators have been moving their cores into cloud environments, and a misconfiguration there can expose an internal interface to the open internet. The researchers also tested a second route in: an ordinary phone with a valid SIM, hiding network control messages inside the data tunnel that carries its own uplink traffic. That trick worked against five of the seven open-source cores they examined.
The tool that found all this, called iFinder, runs three AI agents in a row. The first reads through the code looking for places where data from an incoming message gets used without being checked. The second consults the 3GPP standards documents to figure out whether the missing check happens earlier in the conversation, which is the most common reason a suspicious-looking line of code turns out to be fine. The third writes a working exploit, runs it against a test network, reads the error logs, and rewrites the exploit until it either works or gives up. The pipeline is useful rather than magic: on a set of 22 previously known bugs, it caught 15, and roughly a quarter of everything it reports is wrong.
The reports have landed unevenly. Of the 83 confirmed flaws, 58 have been patched. Three of the seven projects have shipped nothing at all, which leaves 23 confirmed problems that have CVE numbers and no code change behind them.
“The split mainly reflects maintainer responsiveness and development capacity. OAI has not responded to our reports, while eUPF acknowledged them but indicated that fixes depend on available development resources. Open5GS, SD-Core, and free5GC engaged actively and addressed the reported issues,” Ziyu Lin, a co-author of the study, told Help Net Security.
A batch of machine-generated reports arriving at once could easily have gone badly with maintainers, and the packaging mattered. “Additionally, every finding was manually reviewed, reproduced, and accompanied by a working PoC before being reported. This helped maintainers treat the batch as a set of verified security reports rather than unfiltered machine-generated results,” Lin said.
The commercial cores got a lighter touch. iFinder needs source code to work, which rules out a shipped product, so the two commercial networks were tested by replaying exploits built against the open-source versions. Three of those exploits worked: the session hijack on both cores, plus two denial-of-service bugs on one of them, one of which has its own CVE. “Direct analysis would require access to the source code, build environment, and a suitable testbed,” Lin said.
That leaves an open question for anyone running a commercial core. Did the vendors inherit these gaps from shared open-source ancestry, or did three findings just happen to land? “Many commercial 5GCs may incorporate or customize open-source stacks, and both free5GC and OAI have downstream commercial derivatives, so validation gaps in the upstream code can propagate into products that carry the same design assumptions,” Lin said. “Three confirmed cases are a small sample, and we have not audited the commercial cores directly, so we would call this supporting evidence rather than a conclusion. Direct analysis of additional commercial cores would be needed to establish how far the inheritance extends.”
Download: The ultimate guide to network operations management