Security Researchers Discover "Widespread" Trust Issues in 4G and 5G Core Networks

What Happened?

Imagine a big office building where every employee has a keycard. The building’s security system trusts anyone with a keycard—it never double-checks who is holding it or why they’re opening a door. If a bad guy steals a keycard, they can walk right in and access everything.

That’s essentially what researchers from Nanyang Technological University (Singapore) found in the "brains" of 4G and 5G mobile networks. Their study, titled "Understanding Implicit Trust Errors in Core Carrier Networks through Multi-Agent Flaw Discovery and Analysis," reveals a whole class of security vulnerabilities caused by blind trust between network components.

Key Takeaway: The problem isn’t one specific bug—it’s a design philosophy that assumes "everyone inside the network is trustworthy." That assumption breaks down when networks move to the cloud.

The Core Problem: "Implicit Trust Errors" (iTrue)

How Mobile Networks Used to Work

• Physical isolation: Core network equipment lived in locked rooms, connected by dedicated cables.
• Trust zone: Because only authorized people could physically touch the wires, engineers assumed any message arriving on those wires was legitimate.
• No double-checking: Components didn’t verify message formats, meanings, or resource limits—they just acted on them.

What Changed?

• Cloud-native deployments: Network functions now run as software in the cloud (like AWS, Azure, or private data centers).
• Expanded attack surface: Internal interfaces that were once hidden are now reachable over the internet if misconfigured.
• Fragile trust model: The old "trust everyone inside" approach falls apart when "inside" includes the public internet.

Important: The researchers call this class of flaws iTrue (Implicit Trust Errors). It’s not a single bug—it’s a recurring pattern across multiple implementations and protocols.

Which Systems Are Affected?

The study tested 7 open-source core network implementations used in both research labs and commercial deployments:

Protocols examined:

• GTP-C (GPRS Tunnelling Protocol Control Plane) — 4G signaling
• PFCP (Packet Forwarding Control Protocol) — 5G user-plane signaling

How Did They Find These Flaws? Meet iFinder

The researchers built an AI-powered detective system called iFinder (Implicit Trust Finder). Think of it as a team of specialized AI agents working together:

The iFinder Workflow (Step by Step)

1. Summarize known flaws — Read existing vulnerability reports and extract patterns.
2. Categorize into detection patterns — Group flaws by type (e.g., "missing format validation," "no resource check").
3. Hunt for new iTrues — Scan target codebases for the same patterns.
4. Weed out false alarms — Use a novel code-specification cross-checking technique:
   → Map each candidate flaw to the protocol procedure it implements
   → Check if the code actually enforces the required validations
5. Generate & refine exploits — An LLM writes proof-of-concept (PoC) attacks, runs them against real implementations, and iteratively improves them based on results.

What Did They Find?

Generational Inheritance: Some 5G flaws were inherited from 4G codebases—showing how legacy trust assumptions carry over into "modern" systems.

Real Attack Scenarios (ELI5 Versions)

Attack 1: Denial-of-Service (DoS) on Open5GS LTE

Analogy: Sending a malformed letter that crashes the mailroom sorting machine.

1. Attacker sends a crafted GTPv2-C Create Session Request to the SGW-C (Serving Gateway Control Plane).
2. The SGW-C tries to parse it → crashes because it blindly trusts the message format.
3. Result: Legitimate users can’t establish sessions → network outage.

Attack 2: Session Hijacking (The "Traffic Thief")

Analogy: A con artist convinces the post office to redirect your mail to their address by slipping a fake "change of address" form into the system.

Step-by-step (PFCP Session Hijacking in 5G UPF):

1. Attacker sends PFCP Association Setup Request to the UPF (User Plane Function) — "Hi, I’m a trusted control node."
2. Victim UE attaches → SMF (Session Management Function) sends legitimate PFCP Session Establishment Request to UPF.
3. Attacker sends PFCP Session Modification Request that:
   • Reuses the victim’s PDR ID (Packet Detection Rule — like a "mailbox number")
   • Sets lower Precedence value (= higher priority)
   • Binds it to a malicious FAR (Forwarding Action Rule — "send mail to my address")
4. UPF accepts the duplicate PDR, sorts by precedence → malicious rule wins.
5. During packet processing, UPF matches the malicious PDR first.
6. Victim’s uplink traffic gets forwarded to the attacker instead of the internet.

Impact: The attacker can intercept, inspect, or modify the victim’s data — all without touching the victim’s phone.

Real-World Confirmation: It’s Not Just Theory

Researcher Quote: "The continually increasing number of vulnerabilities demonstrates that this is not a small collection of isolated implementation bugs, but a broader and ongoing security problem that requires urgent attention from vendors and network operators." — Ziyu Lin, study author

How Could an Attacker Reach These Interfaces?

The study outlines two realistic threat models:

Defense Insight: Strict network boundary enforcement (inspecting/decapsulating GTP-U at the edge) can block the UE-based attack path.

Summary

• Root cause: Implicit trust between core network functions — components blindly act on messages from "internal" peers.
• Trigger: Cloud-native deployments exposed previously hidden interfaces.
• Scope: 84 new vulns across 7 implementations (4G & 5G), 81 CVEs assigned.
• Impact: DoS (crash core components) and Session Hijacking (steer user traffic to attacker).
• Detection: Novel LLM-powered multi-agent system (iFinder) that cross-checks code against specs.
• Real-world: Confirmed in commercial 5G cores — one patched, one still fixing.
• Urgency: This is a systemic, generational problem — not a few one-off bugs.

Bottom Line: Vendors and operators must stop assuming internal interfaces are safe and start validating every message, every time — just like zero-trust security in IT networks.

FAQ

1. Does this affect my phone or my data directly?

Not directly. These flaws live in the network core (the carrier’s infrastructure), not on your device. But if exploited, an attacker could intercept your traffic (websites you visit, unencrypted data) or disconnect you from the network.

2. Are all 4G/5G networks vulnerable?

The study tested 7 open-source implementations widely used in research and commercial deployments. Many carriers build on these codebases. Commercial proprietary cores may have similar issues — the researchers found the same flaw class in two real 5G carriers.

3. Can I protect myself as a user?

Not directly — this requires carrier-side fixes (patches, config hardening, boundary enforcement). However, using end-to-end encryption (HTTPS, TLS, VPN) limits what an attacker can see even if they hijack your session.

4. What is a "PDR" and "FAR" in simple terms?

• PDR (Packet Detection Rule): "If you see a packet matching this description, apply that rule." Like a mail filter: "If sender = Bank, forward to Secure Folder."
• FAR (Forwarding Action Rule): "Send the packet here." Like a forwarding address.
• The attack tricks the UPF into using the attacker’s forwarding address by winning a priority contest.

5. Why does moving to the cloud make this worse?

In the old days, core network boxes were in a locked room, connected by physical cables. Nobody from the internet could talk to them directly. In the cloud, those same interfaces run on virtual networks — if a firewall rule is wrong or a port is open, anyone on the internet can send messages to them. The code never expected that.