iFinder: AI Agents Uncover 84 Flaws in 5G Cores

Key Takeaways

• Researchers at Nanyang Technological University built iFinder, a large language model-driven multi-agent system, and used it to discover 84 previously unknown vulnerabilities across seven widely deployed 4G and 5G core network implementations, of which 83 were confirmed by the responsible developers and 81 received CVE identifiers. [1][2]
• The vulnerabilities stem from a common root cause the researchers call implicit trust errors, in which core network functions accept internal signaling messages as inherently trustworthy without validating them — an assumption inherited from an era of physically isolated telecom hardware that no longer holds once those functions run as containerized workloads on shared cloud infrastructure. [2]
• The finding with the clearest real-world impact is a session hijacking flaw in the Packet Forwarding Control Protocol (PFCP): an attacker who can reach a User Plane Function’s internal interface can inject a duplicate, higher-priority Packet Detection Rule and redirect a victim subscriber’s uplink traffic to themselves, a technique validated against two commercial 5G core deployments and assigned CVE-2026-8233. [1][2][3]
• iFinder’s four-agent pipeline — preprocessing, discovery, vetting, and exploitation — achieved 75% precision and generated working proof-of-concept exploits for 86% of ground-truth vulnerabilities in evaluation, more than double the rate of a single-prompt LLM baseline, illustrating both the growing capability and the residual error rate of AI-assisted vulnerability research applied to critical infrastructure. [2]
• As of publication, 58 of the 83 confirmed open-source vulnerabilities had been patched; one commercial vendor, Dotouch, remediated its XproUPF product, while a second commercial carrier remained in the remediation process, underscoring the gap between rapid AI-paced discovery and the slower pace of telecom patch cycles. [1][2]
• Mobile network operators and cloud-native core vendors should treat this research as confirmation that internal 3GPP interfaces such as N4 (PFCP) and S11/S5 (GTP-C) require the same authentication, segmentation, and validation controls long applied to internet-facing services, not the implicit trust historically justified by physical network isolation.

Background

From Physical Isolation to Cloud-Native Trust Assumptions

Fourth- and fifth-generation mobile core networks were designed under an architectural assumption that has eroded over the past decade: that the interfaces connecting core network functions, such as the Serving Gateway, Mobility Management Entity, Session Management Function, and User Plane Function, would only ever be reachable from within a physically secured, operator-controlled facility. Signaling protocols like GTP-C, which carries control-plane messages such as session creation and mobility updates across the 4G and 5G core, and PFCP, which governs how the User Plane Function forwards subscriber traffic under instruction from the Session Management Function, were specified with minimal built-in authentication because the network perimeter itself was assumed to provide that assurance. [2]

That assumption has been overtaken by the industry-wide shift toward cloud-native core deployments, where network functions run as containerized microservices on Kubernetes clusters, often across public or hybrid cloud infrastructure and sometimes spanning multiple tenants or vendors. CSA’s own field research has documented this shift concretely: a 2025 assessment of a Free5GC-based 5G core running on Kubernetes in a public cloud environment found that internal interfaces intended to be trusted by design were reachable in ways the original protocol specifications never anticipated, and recommended mutual authentication and Kubernetes hardening as baseline controls. [4] The NTU research generalizes that finding: implicit trust between core network functions is not a single deployment’s misconfiguration but a systemic property of how these protocols were specified, present across every open-source and commercial implementation the researchers tested. [2]

iFinder: Applying Multi-Agent LLMs to Protocol-Level Flaw Discovery

To find these errors at scale, the NTU team — Ziyu Lin, Ziting Wang, Xinfeng Li, Wei Dong, and XiaoFeng Wang — built iFinder, a system that pairs large language models with structured program analysis rather than relying on either alone. [2] iFinder first distills known vulnerabilities and 3GPP specification text into six recurring detection patterns: missing checks for mandatory fields, insufficiently validated field lengths, unvalidated value ranges, absent state invariants, unchecked identifier references, and missing resource-exhaustion limits. A discovery agent then searches each codebase for operations matching these patterns and traces the execution paths that reach them. Because pattern matching alone tends to produce large numbers of false positives, iFinder adds a vetting agent that cross-checks each candidate against the relevant 3GPP procedure specification to confirm the flagged code path is actually reachable and unguarded in real protocol operation. A final exploitation agent generates a proof-of-concept exploit, runs it against a live testbed, and iterates based on runtime feedback until the exploit either succeeds or is discarded as infeasible. [2]

This architecture reflects a pattern visible across public AI-assisted security research over the past year: LLMs alone tend to generate plausible-sounding but inaccurate vulnerability claims, while pairing them with deterministic verification steps — here, specification cross-checking and live exploit execution — appears to substantially improve precision. The NTU team’s own ablation results bear this out. Removing the specification cross-checking step nearly tripled the false-positive count, from 19 to 62, and cut precision roughly in half. [2] The result is a research tool that behaves less like an autonomous hacker and more like a triage pipeline: broad, LLM-driven hypothesis generation narrowed by targeted formal verification, a pattern likely to recur as similar systems are pointed at other categories of network and embedded protocol code.

Security Analysis

Scope and Distribution of Findings

iFinder was run against seven implementations spanning three programming languages and both 4G and 5G core architectures: Open5GS and OpenAirInterface (OAI) in their LTE (4G) configurations, and Open5GS, free5GC, OAI, SD-Core, and eUPF in their 5G configurations. Across these targets it surfaced 84 previously undocumented vulnerabilities, with the heaviest concentration — 30 findings, all confirmed and assigned CVEs — in the Open5GS LTE implementation, followed by 14 in free5GC and 11 in OAI’s 5G codebase. [2] By protocol, PFCP accounted for 47 of the 84 findings, concentrated in User Plane Function code, while GTP-C accounted for the remaining 37, concentrated in Serving Gateway code. The single largest category of flaw, accounting for 31 of the 84 findings, involved code that dereferenced a mandatory protocol field without first checking that the field was present in the received message — a class of defect that is conceptually simple but, given how many independent implementations exhibited it, points to a specification-level gap rather than isolated coding mistakes. Resource-exhaustion flaws, in which a network function allocates memory or state in response to a message without any bound on attacker-controlled repetition, and malformed-field flaws, in which length or boundary checks are missing or incomplete, each accounted for a further 14 findings. [2]

The following table summarizes the vulnerability categories iFinder’s detection patterns were built to find, each grounded in a documented gap in how core network functions validate internal signaling messages.

The Session Hijacking Flaw in Detail

The finding with the clearest real-world impact is a session hijacking vulnerability rooted in how the User Plane Function processes PFCP Session Modification Requests, and it illustrates the implicit trust problem concretely. When a subscriber’s device attaches to the network, the Session Management Function establishes a PFCP session with the User Plane Function and assigns a Packet Detection Rule (PDR) that tells the User Plane Function how to route that subscriber’s traffic. The vulnerable implementations did not enforce that PDR identifiers be unique within a session; an attacker positioned to send PFCP messages to the User Plane Function’s N4 interface could send a Session Modification Request that reused the victim’s PDR identifier while assigning it a lower precedence value, which the protocol treats as higher matching priority. The User Plane Function would then match the attacker’s forwarding rule first, redirecting the victim’s uplink traffic to the attacker rather than the intended destination. [1][2]

iFinder’s exploitation agent validated this attack chain in a controlled testbed, and the NTU team subsequently confirmed it against two real, unnamed commercial 5G core deployments, assigning it CVE-2026-8233 [3], alongside a related denial-of-service finding tracked as CVE-2026-8232. [1] The 4.6 CVSS figure reported for CVE-2026-8233 is a v3.1 score from third-party analysis; NVD has not yet published its own scoring for this CVE, and a separate CVSS v4.0 assessment from another aggregator scores it lower, so the figure should be read as scoring-methodology-dependent rather than a single settled value. Dotouch, the vendor of one of the affected UPF products (XproUPF), patched the access-control gap; the second commercial vendor remained in remediation as of the report’s publication. Whatever the precise score, the underlying precondition is what matters operationally: successful exploitation requires network-level access to an internal core interface, knowledge of the target component’s address, and the ability to send arbitrary PFCP messages, a precondition that is materially easier to satisfy in cloud-native deployments where internal interfaces may be reachable across shared infrastructure, misconfigured network segments, or compromised adjacent workloads than it ever was in a physically isolated telecom facility. [2]

Evaluation Rigor and Acknowledged Limitations

The NTU team evaluated iFinder against a ground-truth set of 22 previously documented vulnerabilities to measure detection accuracy independent of the 84 novel findings, reporting 75.0% precision, 68.2% recall, and an F1 score of 71.4%, compared with 31.8% F1 for a baseline that used a single LLM prompt without the specification cross-checking or iterative exploitation stages. [2] The exploitation agent’s feedback-driven refinement process produced working proofs-of-concept for 86.4% of ground-truth vulnerabilities, compared with 36.4% for a non-iterative baseline — a substantial gain that the authors attribute to the agent’s ability to revise its exploit based on runtime errors rather than generating a single static attempt. Running the full pipeline against one implementation took an average of roughly 710 seconds and consumed approximately 9.8 million tokens, split across the discovery, vetting, and exploitation agents. [2]

The authors are candid about where the system falls short, which matters for organizations considering whether AI-assisted analysis of their own network function code would be exhaustive. Four ground-truth vulnerabilities involving corner-case validation logic were missed because they did not match any of the six generalized detection patterns; three additional cases involved execution paths spanning multiple modules that the discovery agent could not reliably reconstruct. The authors also note that the LLM components can make incorrect feasibility judgments when a vulnerability’s exploitability depends on subtle, implementation-specific state transitions that are not explicit in the specification text. [2] These limitations are consistent with a pattern visible across other public AI-assisted vulnerability research: current systems substantially accelerate discovery of known classes of flaw but are not a substitute for human security review, particularly for vulnerability classes that require reasoning about system-wide invariants rather than localized code patterns.

Recommendations

Immediate Actions

Mobile network operators and private 5G deployment owners running any of the seven affected implementations — Open5GS, free5GC, OpenAirInterface, SD-Core, or eUPF, in either their LTE or 5G configurations — should confirm they are running patched versions and prioritize the User Plane Function and Serving Gateway components specifically, since those concentrated the majority of confirmed findings. [2] Organizations operating commercial core network products from vendors named or implicated in this research, including any deployment of Dotouch’s XproUPF, should confirm patch status directly with the vendor and verify the fix addresses CVE-2026-8233 rather than assuming a general product update covers it.

Short-Term Mitigations

Operators should audit which network functions and management systems can reach internal core interfaces — specifically the N4 interface between the Session Management Function and User Plane Function, and the S11/S5 interfaces carrying GTP-C signaling — and restrict that reachability to the minimum set of components that require it, consistent with network segmentation guidance CSA has published specifically for cellular environments. [4][5] Where the underlying network functions do not yet enforce PDR identifier uniqueness or equivalent session-state invariants at the protocol level, deploying an intrusion detection capability tuned to flag duplicate or conflicting PFCP Packet Detection Rules within an active session provides a compensating control while vendor patches are validated and rolled out.

Strategic Considerations

The underlying lesson of this research extends beyond the specific 84 vulnerabilities: implicit trust between core network functions is a structural property of protocols designed for a physically isolated deployment model, and that model no longer describes how the majority of new 5G cores are built. Organizations planning cloud-native or hybrid-cloud core deployments should treat internal 3GPP interfaces as untrusted by default, requiring mutual authentication and message validation equivalent to what they would demand of any internet-facing API, rather than inheriting historical assumptions about the security of “internal” telecom signaling. Separately, this research is a data point in a broader trend of LLM-driven multi-agent systems being applied to large-scale vulnerability discovery in complex, safety-critical codebases; organizations that operate or procure network function software should expect the pace of externally discovered flaws in these systems to increase as similar tooling is applied by both researchers and, potentially, adversaries, and should build patch validation and deployment processes capable of keeping pace.

CSA Resource Alignment

This research is a direct, empirical confirmation of the risk model described in CSA’s Enabling Zero Trust for Cellular Networks: Guidance for Securing Mobile Services, which argues that 5G’s shift to distributed, cloud-native architectures has outpaced the perimeter-based trust assumptions baked into legacy telecom protocol design. [5] The implicit trust vulnerabilities (what the researchers term “iTrues”) that iFinder discovered are a concrete instance of exactly the gap that guidance identifies: internal core interfaces treated as inherently trustworthy despite no longer being physically isolated.

CSA’s Zero Trust Lessons from a Real-World 5G Cloud Core Security Assessment is even more directly on point, since that assessment examined a free5GC-based core running on Kubernetes — one of the same open-source implementations iFinder tested — and independently arrived at the recommendation to enforce mutual authentication on critical internal APIs. [4] Operators evaluating remediation priorities for the vulnerabilities described in this note should treat that assessment’s Kubernetes-hardening and API-authentication recommendations as directly applicable compensating controls.

The AI Controls Matrix (AICM) v1.1’s Threat and Vulnerability Management domain provides the governance structure operators should use to track remediation of the specific CVEs this research generated, while its Application and Interface Security domain applies to the underlying input-validation failures — absent field checks, unvalidated identifiers, missing state invariants — that iFinder’s detection patterns systematically surfaced across seven independent codebases. [6] Because iFinder is itself an autonomous multi-agent system capable of generating and executing exploit code against production-adjacent infrastructure, organizations standing up similar internal tooling, or evaluating vendor claims about AI-assisted security testing, should assess that tooling’s own trust boundaries and permissions against CSA’s MAESTRO agentic AI threat modeling framework before granting it access to sensitive network testbeds. [7]

References

[1] The Hacker News Staff. “Researchers Report 84 Flaws in 4G and 5G Cores, Including a Session Hijacking Flaw.” The Hacker News, July 2026.

[2] Lin, Ziyu, Ziting Wang, Xinfeng Li, Wei Dong, and XiaoFeng Wang. “Understanding Implicit Trust Errors in Core Carrier Networks through Multi-Agent Flaw Discovery and Analysis.” arXiv:2607.10315, Nanyang Technological University, July 2026.

[3] NVD. “CVE-2026-8233 Detail.” National Vulnerability Database, 2026.

[4] Cloud Security Alliance. “Zero Trust Lessons from a Real-World 5G Cloud Core Security Assessment.” Cloud Security Alliance, July 2025.

[5] Cloud Security Alliance. “Enabling Zero Trust for Cellular Networks: Guidance for Securing Mobile Services.” Cloud Security Alliance, 2025.

[6] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.

[7] Cloud Security Alliance. “Agentic AI Threat Modeling Framework: MAESTRO.” Cloud Security Alliance, February 2025.