iTrue: 84 flaws expose implicit trust in 4G and 5G cores

A team from Nanyang Technological University has described 84 previously unknown vulnerabilities across open-source LTE and 5G core implementations. Eighty-three have been confirmed and 81 assigned CVE identifiers. Researchers also validated the most serious result—subscriber session hijacking—against commercial 5G cores.

The shared root cause is not one memory-safety defect. It is an implicit trust error, or iTrue: one core function accepts another component’s message as authoritative without sufficiently checking authorisation, state binding and context.

Research scope

The paper “Understanding Implicit Trust Errors in Core Carrier Networks” is due to appear at USENIX Security 2026. Researchers analysed seven prominent projects:

• LTE: Open5GS and OpenAirInterface;
• 5G: Open5GS, free5GC, OpenAirInterface, SD-Core and eUPF.

They focused on two control protocols:

• GTP-C, which manages LTE tunnel creation, modification and deletion;
• PFCP, which lets the 5G control plane program the user plane.

These projects appear in laboratories, private networks and commercial products. The finding does not mean every public carrier uses an affected configuration or that all 84 flaws are internet-reachable.

How the trust model changed

Traditional carrier cores operated inside tightly controlled environments. Components were physically and logically separated from public networks, so implementations often assumed that a message arriving on an internal interface came from the correct function.

Cloud-native 5G changes that context:

• functions become services and containers;
• orchestrators scale them;
• communication uses shared networks;
• addresses are dynamic;
• multiple vendors integrate;
• workloads run in cloud and edge environments.

If “this interface is internal” remains the only security check, a compromised microservice, segmentation error or exposed port can create a path into other core functions.

What is an implicit trust error?

An iTrue occurs when the receiver checks message syntax but insufficiently verifies:

• whether the sender may change this specific session;
• whether an identifier belongs to that subscriber and tunnel;
• whether the request matches current state;
• whether the message order is possible;
• whether parameters came from an authenticated context;
• whether the message is replayed or belongs to another session.

“Protocol-valid” is not the same as “authorised for this function at this time.”

From denial of service to session hijacking

The paper reports denial-of-service and session-hijacking impact. DoS can tear down sessions, exhaust state or force expensive processing. Session hijacking is more serious because it may redirect traffic or tunnel state across a subscriber boundary.

The authors confirmed one session-hijacking flaw on commercial 5G cores. This does not establish that arbitrary carrier sessions are exposed. Reachability of signalling interfaces, topology, implementation and operator safeguards remain essential preconditions.

iFinder and language models

Researchers built iFinder to model flows between core functions and identify places where trust was not explicitly verified. Language models then generated candidate tests, ran them against controlled implementations and iteratively refined them using observed results.

This is a useful defensive AI pattern:

• the model did not replace confirmation;
• hypotheses ran in a laboratory;
• findings required reproduction;
• maintainers received coordinated reports;
• candidate, confirmed and CVE counts remained separate.

Automation expanded coverage across protocol states that a manual review might not combine.

Who should assess exposure

Priority groups include:

• operators using the named implementations;
• private 4G/5G network vendors;
• universities with reachable core testbeds;
• cloud network-function integrators;
• industrial organisations deploying local 5G;
• providers splitting control and user planes across trust domains.

Finding Open5GS or free5GC is not proof of exposure. Teams need the exact version, configuration, GTP-C/PFCP reachability and maintainer patch mapping.

Actions to take

1. inventory every core function and version;
2. review project advisories and assigned CVEs;
3. map every identity allowed to send GTP-C and PFCP;
4. remove public access and unnecessary cross-domain routes;
5. mutually authenticate network functions;
6. apply role- and direction-specific network policy;
7. validate subscriber, session, state and sequence binding;
8. alert on unusual tunnel creation, modification and deletion;
9. test invalid state transitions in an isolated environment;
10. retain control-plane evidence sufficient to reconstruct a session.

Apply zero-trust thinking inside the core: service identity and operation context should be checked for every request. Our broader zero-trust and microsegmentation guide explains the design model.

Sources versus Breachroad conclusions

The researchers report 84 findings, 83 confirmed flaws, 81 assigned CVEs and validation of one session-hijacking issue in commercial cores. The publication does not document an active campaign exploiting these vulnerabilities against subscribers.

Breachroad’s conclusion is that cloud-native migration removes physical boundaries on which older protocol assumptions relied. Core modernisation must therefore include explicit function authentication, segmentation and state validation—not only containers and automation.

A cloud and infrastructure security assessment can review private-network architecture, communication policy and telemetry. Technical-team cybersecurity training helps translate protocol research into patching and hardening priorities.