The transition from 4G LTE to 5G Standalone (SA) represents a paradigm shift in mobile network architecture. Where legacy networks relied on monolithic, proprietary hardware communicating over obscure protocols like SS7 vulnerabilities and Diameter protocol, 5G is built on the Service Based Architecture (SBA) — a cloud-native framework where every core network function is a microservice communicating via RESTful APIs over HTTP/2.
This architectural revolution delivers unprecedented operational flexibility, but it simultaneously imports the entire web application and container security threat landscape into the heart of critical national telecommunications infrastructure. Every OWASP API vulnerability, every Kubernetes misconfiguration, and every container escape technique developed against enterprise cloud environments is now directly applicable to the network that carries emergency calls, enables autonomous vehicles, and supports critical infrastructure slicing.
This research provides a comprehensive analysis of SBA-specific attack vectors, from NRF poisoning to API authorization bypass, and the defensive architectures required to mitigate them. For the broader 5G security context including SUCI, 5G-AKA, and SEPP, see our 5G network security architecture analysis.
In this architecture, Network Functions (NFs) are deployed as cloud-native microservices — typically in Docker containers managed by Kubernetes — communicating via RESTful APIs over HTTP/2. This article dissects the specific attack vectors exposed by the 5G SBA, including NRF poisoning, BOLA exploitation, container escape paths, and protocol translation vulnerabilities at the 4G/5G interworking boundary.
I. 5G SBA Architecture Overview
Before analyzing attack vectors, it's essential to understand the NF landscape. The 5G SBA decomposes the monolithic EPC into discrete, independently scalable Network Functions:
Core Network Functions and Their Attack Surface
| Network Function | Role | API Surface | Risk Level |
|---|---|---|---|
| NRF | Service discovery & authorization | NF registration/discovery | Critical — single point of failure |
| AMF | Access & mobility management | UE registration, handover | High — border-facing NF |
| SMF | Session management | PDU session lifecycle | High — controls data plane |
| UDM | Subscriber data management | Subscription queries | Critical — contains all subscriber data |
| AUSF | Authentication | 5G-AKA/EAP-AKA' | Critical — key derivation |
| UPF | User plane forwarding | N4 (PFCP) | High — data plane access |
| NSSF | Slice selection | NSSAI routing | High — cross-slice routing |
| PCF | Policy control | Policy rules | Medium — QoS/charging |
| NEF | API exposure to external apps | Northbound APIs | High — external attack surface |
| NWDAF | Analytics & ML | Data collection | Medium — lateral movement pivot |
| SCP | Service communication proxy | All inter-NF traffic | Critical — if compromised, all traffic visible |
All inter-NF communication uses HTTP/2 with JSON payloads, routed through the Service Communication Proxy (SCP). The NRF provides OAuth 2.0-based access tokens for NF-to-NF authorization. This is a radical departure from the implicit trust model of SS7 legacy signaling — but introduces its own class of vulnerabilities.
II. The SBA Threat Landscape: Web Attacks Meet Telecom Infrastructure
Because the 5G Core (5GC) uses HTTP/2, REST, and JSON, offensive strategies used against enterprise cloud environments are now directly applicable to telecom networks. But the consequences are orders of magnitude more severe — a compromised API in an e-commerce platform leaks credit card numbers; a compromised API in the 5GC can intercept communications, disable emergency services, or compromise critical URLLC slices.
1. BOLA: The #1 API Vulnerability
<CodeBlock language="http" filename="bola-exploit-attempt.http" code="GET /nudm-sdm/v1/imsi-001010123456789/am-data HTTP/2 Host: udm.5g-core.internal Authorization: Bearer <Compromised_AMF_Token>
Attacker iterates through imsi-XXX to harvest subscriber info
Attack sequence:
1. Compromise AMF via API vulnerability → obtain valid OAuth token
2. Token is scoped to 'nudm-sdm' (subscriber data management)
3. Use token to query ANY subscriber's data (no per-SUPI scoping)
4. Iterate: imsi-001010000000001 → imsi-001010999999999
5. Exfiltrate: subscription profiles, QoS policies, slice assignments"
/>
2. Mass Assignment and Parameter Pollution
Beyond BOLA, 5G NF APIs are vulnerable to Mass Assignment attacks where an attacker includes unexpected parameters in API requests that are blindly processed. For example, a Registration Request to the AMF could include additional JSON fields that are passed through to the UDM, potentially modifying subscriber profile attributes that should be read-only.
<CodeBlock language="http" filename="mass-assignment-attack.http" code="PUT /nudm-sdm/v1/imsi-001010123456789/am-data HTTP/2 Host: udm.5g-core.internal Content-Type: application/json Authorization: Bearer <Compromised_NF_Token>
{ 'subscribedUeAmbr': { 'uplink': '1000 Mbps', // Original subscriber limit: 100 Mbps 'downlink': '1000 Mbps' // Unauthorized upgrade via mass assignment }, 'nssai': { 'sst': 2, // Unauthorized slice access (URLLC) 'sd': 'enterprise_001' } }" />
3. The NRF Poisoning Attack
The Network Repository Function (NRF) acts as the service discovery mechanism for the entire 5GC. It is the DNS of the 5G core — and like DNS poisoning, NRF poisoning can redirect all traffic to attacker-controlled endpoints.
Attack Methodology
- Exploit an authentication weakness in the NRF's registration API (OAuth token with excessive scope, or missing validation of NF profile fields)
- Register a rogue NF instance (e.g., a fake AUSF) with the NRF
- The rogue NF advertises higher priority or lower load than the legitimate AUSF
- The NRF routes authentication requests to the rogue NF
- The rogue NF harvests SUPI, authentication vectors, and KASME keys
- Result: Silent subscriber identity cloning at scale
This effectively bypasses the security architecture controls designed for the 5G Core, because the attack occurs within the trusted SBA fabric.
4. OAuth Token Scope Abuse
The 3GPP specification (TS 33.501) mandates OAuth 2.0 for NF-to-NF authorization. However, the granularity of token scoping is implementation-dependent. Many deployments issue tokens scoped to entire NF service sets rather than specific operations or subscriber contexts:
| Token Scope Level | Security | Implementation Complexity | Prevalence |
|---|---|---|---|
| Per-NF-Type (e.g., "AMF can access UDM") | Weak — any AMF query any subscriber | Low | Common |
| Per-Service (e.g., "AMF can access nudm-sdm") | Moderate — limits to service | Medium | Growing |
| Per-Operation (e.g., "AMF can GET am-data") | Good — limits to read ops | High | Rare |
| Per-Subscriber (e.g., "AMF can GET am-data for SUPI X") | Excellent — zero-trust model | Very High | Experimental |
III. Escaping the Container: Infrastructure Layer Attacks
The SBA assumes isolation, but containerization is not virtualization. All NFs on a Kubernetes node share the underlying host kernel. A container boundary is a userspace isolation mechanism — not a security boundary equivalent to hardware virtualization.
1. Container Breakouts
Zero-day kernel vulnerabilities remain a massive threat. If a border-facing NF (like the AMF, which processes untrusted UE signaling) is compromised via an API vulnerability, the next step is container escape. Once an attacker is on the host node, the logical separation of the 5G core vanishes completely.
Documented container escape vectors relevant to 5G deployments:
- Dirty Pipe (CVE-2022-0847): Kernel-level arbitrary file overwrite
- runc escape (CVE-2024-21626): Container runtime breakout via
/proc/self/fdmanipulation - eBPF privilege escalation: Kernel BPF subsystem vulnerabilities enabling root access
- Privileged container abuse: NFs running with
privileged: truefor DPDK/SR-IOV access (common in UPF deployments, as documented in our slicing security analysis)
2. Network Policy Misconfigurations
Kubernetes relies on Network Policies for micro-segmentation. In rapid deployment cycles, MNOs often deploy clusters with overly permissive allow-all policies — or worse, no Network Policies at all (which defaults to allow-all).
Lateral Movement Path
- Compromise the NWDAF (analytics function) via an insecure ML model ingestion API
- From within the NWDAF pod, scan the cluster network (no egress NetworkPolicy)
- Discover the UDM service endpoint on the same cluster network
- Connect directly to the UDM API — bypassing SCP-level authorization because the traffic originates from a "trusted" internal IP
- Exfiltrate subscriber data using the NWDAF's valid service mesh certificate
<CodeBlock language="yaml" filename="missing-network-policy.yaml" code=" # DANGEROUS: No NetworkPolicy = all pods can reach all pods
Default Kubernetes behavior when no policies are defined
REQUIRED: Deny-all baseline + explicit allow rules
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: 5gc-core spec: podSelector: {} policyTypes:
- Ingress
- Egress
No ingress/egress rules = deny all traffic
Then add per-NF allow rules for legitimate communication paths">
IV. Protocol Translation and Signaling Storms
> The HTTP/2 to Diameter Gateway
Interworking Functions (IWF) translate HTTP/2 SBA calls to Diameter protocol. Attackers use advanced fuzzing to send crafted HTTP/2 headers that, when translated to Diameter AVPs, cause parsing faults, buffer overflows, or HTTP Request Smuggling into the 4G core. This translation boundary is a high-value target because it bridges two fundamentally different trust models.
> Control Plane DDoS
A massive influx of compromised IoT devices (potentially from a compromised MIoT slice) can cause an HTTP/2 signaling storm, exhausting TLS termination capacity and crashing the AMF. Unlike legacy signaling DoS, HTTP/2 multiplexing allows a single TCP connection to carry thousands of concurrent streams, amplifying the attack surface.
V. Defensive Architecture: Zero Trust in the Telco Core
Securing the SBA requires abandoning perimeter defense and enforcing Zero Trust inside the cluster. Every NF must authenticate, authorize, and validate every request — regardless of its origin within the "trusted" core network.
01 Mutual TLS (mTLS) Everywhere
Enforcing mTLS between every microservice via a Service Mesh (Istio or Linkerd) is non-negotiable. This ensures that even if an attacker gains network access, they cannot impersonate NFs without valid certificates. Certificate rotation should be automated and frequent (< 24 hours).
02 API Gateways with Schema Validation
Route all internal API calls through strict, schema-validating API gateways rather than direct pod-to-pod communication. The gateway must validate every JSON payload against the 3GPP OpenAPI specification, rejecting unexpected fields (preventing mass assignment) and enforcing per-SUPI authorization scoping.
03 Strict eBPF Observability
Deploy kernel-level tracing (e.g., Tetragon, Falco) to detect unexpected syscall modifications, container escapes, and unauthorized lateral movement instantly. eBPF provides zero-overhead monitoring that detects attacks that bypass application-layer logging.
04 NRF Hardening
Implement certificate-bound NF identity verification for all NRF registration requests. The NRF must validate that the NF's X.509 certificate matches its claimed NF type, instance ID, and service set. Add rate limiting and anomaly detection for NF profile changes.
Defense Effectiveness Matrix
| Defense | BOLA | NRF Poisoning | Container Escape | Lateral Movement | Signaling Storm |
|---|---|---|---|---|---|
| mTLS (Istio) | N/A | Good (cert validation) | N/A | Excellent | N/A |
| API Gateway (schema) | Excellent | Good | N/A | Good | Partial |
| eBPF Monitoring | N/A | N/A | Excellent | Excellent | Good |
| NetworkPolicy | N/A | N/A | N/A | Excellent | N/A |
| Per-SUPI OAuth Scoping | Excellent | N/A | N/A | N/A | N/A |
| NRF cert-bound identity | N/A | Excellent | N/A | N/A | N/A |
| Rate Limiting (SCP) | Good | Good | N/A | N/A | Excellent |
Recommended Kubernetes Security Configuration
<CodeBlock language="yaml" filename="5gc-security-baseline.yaml" code=" # Pod Security Standards: Restricted baseline for all 5GC NFs apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: 5gc-restricted spec: privileged: false readOnlyRootFilesystem: true runAsUser: rule: MustRunAsNonRoot volumes:
- configMap
- emptyDir
- secret allowedCapabilities: # No capabilities by default
UPF exceptions: NET_ADMIN for packet processing (separate PSP)
Istio PeerAuthentication: Enforce STRICT mTLS cluster-wide
apiVersion: security.istio.io/v1beta1 kind: PeerAuthentication metadata: name: default namespace: 5gc-core spec: mtls: mode: STRICT">
VI. SBA Security Testing Methodology
Assessing 5G SBA security requires expertise spanning web application security, Kubernetes infrastructure, and telecom-specific protocols. TelcoSec recommends a structured telecom pentesting methodology approach:
- API Surface Enumeration: Map all NF API endpoints using the 3GPP OpenAPI specifications (TS 29.xxx series). Identify which endpoints accept subscriber identifiers (SUPI/GPSI) as path parameters — these are BOLA candidates.
- OAuth Token Analysis: Obtain legitimate NF tokens and analyze their scope claims. Test whether tokens from one NF type can access services intended for other NF types.
- NRF Registration Testing: Attempt to register rogue NF instances with various NF types and priorities. Verify that certificate-bound identity validation is enforced.
- Mass Assignment Fuzzing: Send API requests with unexpected JSON fields and verify that they are rejected, not silently processed.
- Container Security Audit: Review Pod Security Policies/Standards, check for privileged containers, verify NetworkPolicy enforcement, and test for container escape paths.
- IWF Fuzzing: Send malformed HTTP/2 requests through the Diameter protocol interworking function and monitor for parsing errors, crashes, or request smuggling.
For building a test environment, see our private LTE/5G lab. Open-source 5G cores (Open5GS, free5GC) provide excellent targets for security research.
VII. Authoritative References
- 01 3GPP TS 33.501Security architecture and procedures for 5G system3GPP TS 33.501 – 5G Security Architecture →
- 02 ENISA 5G Security5G Security Controls MatrixENISA 5G Security Controls →
- 03 OWASP API TOP 10API Security Project - 2023 StandardOWASP API Security Project →
- 04 3GPP TS 29.510NRF Services (Network Repository Function)3GPP TS 29.510 – NRF Services →
- 05 NIST SP 800-204Security Strategies for Microservices-based Application SystemsNIST SP 800-204 Microservices Security →
- 06 3GPP TS 23.501System Architecture for the 5G System (Stage 2)3GPP TS 23.501 – 5G System Architecture →
VIII. Frequently Asked Questions
The Network Repository Function (NRF) is the "central phonebook" of the 5G core. If an attacker can poison it with a rogue Network Function, they can intercept all traffic meant for legitimate services, potentially stealing subscriber authentication keys or modifying call flows. Unlike other attacks that affect individual subscribers, NRF poisoning can compromise the entire core network simultaneously.
Mutual TLS (mTLS) provides strong authentication and encryption between microservices, but it doesn't prevent application-layer attacks. An attacker who compromises a single container can still use its valid certificate to perform authorized (but malicious) API calls — such as BOLA-based subscriber enumeration. mTLS is necessary but not sufficient.
eBPF (Extended Berkeley Packet Filter) allows security tools to monitor syscalls and network traffic at the kernel level with minimal overhead. It is essential for detecting container escapes and unauthorized lateral movement within the highly dynamic 5G core environment. Tools like Tetragon and Falco leverage eBPF for real-time security enforcement.
The SS7 vulnerabilities and Diameter protocol protocols provided no authentication at all — any node could send any message to any destination. The 5G SBA adds OAuth 2.0, mTLS, and NRF-based authorization, which is a massive improvement. However, the cloud-native architecture introduces entirely new attack classes (container escapes, BOLA, mass assignment) that didn't exist in the legacy monolithic world.
Network slicing provides logical separation, but slices share the SBA infrastructure (AMF, NRF, SCP). A BOLA attack or NRF poisoning in the shared control plane affects all slices. True protection requires per-slice NRF instances and slice-specific OAuth scoping — which most current deployments don't implement.
Open5GS and free5GC provide complete 5G core implementations for lab testing. For API security testing, standard tools (Burp Suite, OWASP ZAP) work against the HTTP/2 APIs. Kubernetes security can be assessed with kube-bench, kube-hunter, and Trivy. TelcoSec's TelcoSec protocol analysis tools provide telecom-specific testing frameworks.
Conclusion & Next Steps
The 5G SBA offers unprecedented flexibility but exposes MNOs to the full volatility of the cloud-native threat landscape. Telecom engineers can no longer isolate themselves from web application and container security — the same OWASP Top 10 vulnerabilities that plague enterprise APIs now threaten the network infrastructure that supports critical IoT slices.
The defense roadmap for operators deploying 5G SA cores:
- Immediate: Enforce mTLS and deny-all NetworkPolicy across all 5GC namespaces
- Short-term: Deploy eBPF-based runtime security monitoring (Tetragon/Falco)
- Medium-term: Implement per-operation OAuth scoping and NRF certificate-bound identity
- Long-term: Transition to per-SUPI authorization and automated telecom pentesting methodology
Protecting the 5G core requires deep expertise in Kubernetes hardening, REST API security, and zero-trust mesh architectures. Explore our TelcoSec research library for related 5G intelligence, or review the 3GPP specification navigator for detailed protocol references.
