Understanding Implicit Trust Errors in Core Carrier Networks through Multi-Agent Flaw Discovery and Analysis

Image generated by AI

TLDR

• What: iFinder is an LLM-driven multi-agent framework that uses a multi-agent pipeline (Discovery, Vetting, and Exploitation) to automatically detect "implicit trust errors" (iTrue)—logic bugs stemming from the "walled garden" assumption—in stateful cellular core network protocols.
• Who's at risk: Open-source and commercial 4G/5G core networks (such as Open5GS, free5GC, OAI, SD-Core, and major carrier networks) running cloud-native deployments with exposed internal control-plane interfaces.
• Key number: 84 previously unknown vulnerabilities discovered across 7 core network stacks (with 83 confirmed and 81 CVEs assigned), including a session-hijacking vulnerability (CVE-2026-8233) verified on live commercial 5G networks.

As telecommunication operators aggressively migrate 4G and 5G cellular core networks (CNs) from isolated, physical hardware to shared, cloud-native deployments, the foundational "walled garden" security model is collapsing. Historically, internal interfaces like the Packet Forwarding Control Protocol (PFCP) and GPRS Tunnelling Protocol Control Plane (GTP-C) operated under an implicit trust assumption, lacking strong encryption or mutual authentication. However, recent studies have demonstrated that attackers can reach these internal interfaces via cloud misconfigurations or by abusing GTP-U tunnels to inject arbitrary traffic.

This paper introduces iFinder, an LLM-driven multi-agent framework designed to systematically discover, vet, and exploit implicit trust errors (iTrues)—vulnerabilities where core network functions blindly trust incoming messages from internal peers. By executing automated, cross-layer analysis on seven prominent open-source 5G/LTE core implementations, the researchers uncovered 84 previously unknown vulnerabilities, highlighting the urgent need to transition from network-level isolation to zero-trust application security.

Threat Model

Background / Problem Setup

Testing stateful carrier networks is uniquely challenging. Traditional security-testing tools struggle to navigate complex state transitions across multi-step procedures (e.g., session establishment, modification, and deletion).

The table below contrasts the methodology of this paper with other standard network security evaluation frameworks:

Methodology: The iFinder Multi-Agent Pipeline

To reliably detect logical flaws without generating a flood of false positives, iFinder coordinates distinct LLM-driven agents running via the Claude Agent SDK, using Claude Opus 4.5 as the underlying model.

       [3GPP Specs]         [GitHub Known Flaws]
            │                        │
            ▼                        ▼
    ┌──────────────┐         ┌──────────────┐
    │ Extract Spec │         │ Summarize    │
    │ & Schemas    │         │ iTrue Patts  │
    └──────┬───────┘         └──────┬───────┘
           │                        │
           └───────────┬────────────┘
                       │
                       ▼
             ┌───────────────────┐
             │  Discovery Agent  │ ◄─── scans code via backward analysis
             └─────────┬─────────┘
                       │ (iTrue Candidates)
                       ▼
             ┌───────────────────┐
             │   Vetting Agent   │ ◄─── cross-checks with 3GPP context
             └─────────┬─────────┘
                       │ (Feasible Candidates)
                       ▼
             ┌───────────────────┐
             │ Exploitation Agt. │ ◄─── iterative test-and-refine loop
             └─────────┬─────────┘
                       │
                       ▼
              [Verified Exploit]

Step 1: Preprocessing & Pattern Extraction

The pipeline first distills 22 known historical core network vulnerabilities from GitHub repositories (Open5GS and free5GC) into six protocol-agnostic "iTrue patterns." These patterns are formulated as triples:

For example, the Absent Field Pattern represents cases where a mandatory Information Element (IE) is directly dereferenced without a prior presence check, leading to a null pointer dereference, which can cause a DoS.

Step 2: Discovery Agent (DA)

Rather than scanning a massive codebase from top to bottom (which triggers severe LLM context-window limits and hallucinations), the DA performs LLM-based backward analysis:

1. It locates dangerous operations matching the pattern (e.g., locating memory copies using an IE length field).
2. It uses CLI tools (Grep, Glob, Read) to recursively trace caller chains backwards to find the entry-point protocol message handler.
3. It checks whether the required syntactic, semantic, or resource checks are missing along this execution path.

Step 3: Vetting Agent (VA) - Reducing False Positives

A major source of false positives in code-only analysis is that required checks are often executed earlier in the protocol procedure (e.g., during connection setup) rather than in the local code snippet under review.

To address this, the VA performs code-specification cross-checking:

• It maps the flagged code handler back to the corresponding 3GPP specification procedure (e.g., Modify Bearer).
• It retrieves preceding "anchor" messages (e.g., CreateSessionRequest and CreateSessionResponse).
• It locates the code handlers for those preceding messages and audits them for the validation checks. If the validation is found earlier in the session state machine, the candidate is safely discarded.

Step 4: Exploitation Agent (EA) - Exploit Generation

To confirm a vulnerability is genuinely exploitable, the EA utilizes a feedback-aware refinement loop:

1. It generates an initial PoC exploit using the message schemas extracted during preprocessing.
2. It executes the PoC against a containerized testbed (e.g., running Open5GS).
3. If the attack fails (e.g., the target discards the message due to an incorrect Session Endpoint Identifier (SEID)), the EA parses the execution logs, extracts the required state parameters, updates the exploit, and retries (up to 5 iterations).

Key Results

Detection & Ablation Performance

The effectiveness of the pipeline was validated on a ground-truth dataset of 22 historically known vulnerabilities.

Table 1: Detection Performance & Component Ablation (from Section 5)

Critical Analysis of Results

While iFinder significantly outperforms the baseline—boosting Precision from 28.205% to 75.000% and doubling the F1 score—it is not without limitations:

• False Negatives (7 cases): These were caused by two issues: pattern coverage gaps (4 cases where validation logic did not fit the generalized templates) and incomplete context construction (3 cases where caller chains spanned long, asynchronous, cross-module pathways).
• False Positives (12 cases): These occurred because the EA's validation mechanism relies on observing a target crash. In some instances, the generated PoC triggered an unrelated bug earlier in the execution path, creating the illusion that the target vulnerability was validated.

Zero-Day Discoveries

iFinder was executed against seven production open-source core network implementations, uncovering 84 new vulnerabilities:

Table 2: New Vulnerability Discoveries (from Section 6)

Core Vulnerability Case Studies

1. Denial of Service (DoS) in Open5GS SGW-C (Section 6.2)

• The Bug: The Serving Gateway Control Plane (SGW-C) failed to validate the syntactic formatting and encoding of the Bearer Quality of Service (QoS) Information Element when parsing a GTPv2-C Create Session Request.
• The Exploit: An attacker sends a malformed Create Session Request containing an invalid fixed-length QoS field.
• The Impact: The SGW-C crashes immediately on an assertion failure, triggering the SGW-U to release the SGW-U-eNB GTP-U tunnels, causing a DoS.

┌──────────┐            GTPv2-C: Create Session Request             ┌──────────┐
│ Attacker │ ─────────────────────────────────────────────────────> │  SGW-C   │
└──────────┘            [Malformed Bearer QoS IE]                   └────┬─────┘
                                                                         │
                                                                   Assertion Fail
                                                                         │
                                                                         ▼
                                                                     *CRASH*
                                                                         │
                                                                         ▼
                                                             SGW-U Tunnels Released

2. Session Hijacking in OAI 5G UPF (Section 6.2)

• The Bug: The User Plane Function (UPF) failed to enforce uniqueness constraints on Packet Detection Rule (PDR) IDs when processing PFCP Session Modification Requests.
• The Exploit: An attacker injects a duplicate PDR ID associated with a victim's active session, but assigns it a lower Precedence value (meaning a higher priority).
• The Impact: Because the UPF matches rules sequentially by priority, it processes the attacker's duplicate PDR first. This redirects the victim's uplink traffic to an IP address controlled by the attacker.

┌──────────┐           PFCP Session Modification Request            ┌──────────┐
│ Attacker │ ─────────────────────────────────────────────────────> │   UPF    │
└──────────┘          [Duplicate PDR ID = 1, Precedence = 10]       └────┬─────┘
                                                                         │
                                                             Overrules Legitimate PDR
                                                             [PDR ID = 1, Precedence = 100]
                                                                         │
                                                                         ▼
                                                             Uplink Traffic Hijacked
                                                                 to Attacker

What Practitioners Should Do

If you design, deploy, or maintain cellular core networks, you should take the following steps to mitigate these risks:

1. Terminate the "Walled Garden" Trust Model

Deploy mutual authentication on all internal network-function interfaces. Never assume physical or network-layer separation is sufficient to protect internal APIs.

2. Enforce Boundary Filtering & GTP-U Inspections

Configure edge routers and firewalls to block all external IP packets targeting internal core interfaces. To counter GTP-U tunneling exploits, implement boundary checks to prevent encapsulated GTP-C or PFCP payloads from crossing the user-plane boundary (referencing MITRE FiGHT technique FGT1599.505: Network Boundary Bridging).

3. Implement Strict Syntactic & Semantic Schemas

Core components must explicitly validate all incoming message structures. Implement rigorous syntactic and semantic validation at protocol boundaries, maintain uniqueness invariants for session and rule identifiers, and check boundary bounds before invoking memory operations. Never dereference optional or conditional fields without verifying their presence.

4. Transition to Bounded Resource Allocation

Ensure that your network functions handle resource allocation failures gracefully. Adopt bounded resource allocation with graceful rejection rather than process-ending assertions or crash-inducing panics.

The Takeaway

As cellular core networks move to the cloud, security must shift from network-level isolation to zero-trust application design. The discovery of 84 vulnerabilities across multiple independent implementations demonstrates that "implicit trust" is a systemic industry weakness rather than a collection of isolated bugs. Security teams must assume that internal interfaces are reachable and proactively harden their components against malformed, out-of-order control traffic.

Den's Take

I’m usually highly skeptical of papers claiming LLM-driven vulnerability discovery; most produce a mountain of false positives or target trivial synthetic bugs. But iFinder’s results are impossible to ignore: 84 zero-days found across 7 core network stacks, with 81 CVEs assigned, including a validated critical session-hijacking vulnerability (CVE-2026-8233).

By focusing on "implicit trust errors" (iTrues) in 4G/5G core networks migrating to cloud-native environments, the authors targeted a massive, real-world architectural blind spot. As telecommunication operators move to shared cloud infrastructure, exposing control-plane interfaces like PFCP and GTP-C, the old "walled garden" trust model collapses. iFinder's three-agent pipeline (Discovery, Vetting, and Exploitation) successfully bridges the gap between identifying static logic flaws and generating validated exploits. This multi-agent approach to automated offensive security directly demonstrates that LLM agents can be incredibly potent when constrained by stateful protocol specifications.

My only reservation is efficiency: consuming an average of 9.8M tokens per target codebase is a massive footprint. However, given that these exploits actually worked on live commercial 5G setups, the return on investment for proactive defense is a complete no-brainer.