As 5G deployments continue to expand, operators face a difficult reality: moving to newer architectures does not remove old security problems. In many cases, it adds new ones on top. Service based architecture, HTTP/2, JSON, cloud native deployment, and containerized functions bring flexibility and scale, but they also widen the attack surface and introduce new ways to fail.
In this webinar, El Mehdi Regragui shared lessons drawn directly from P1 Security pentest activities across 5G environments. The session focused on the vulnerabilities that appear most often in real assessments, the attack paths they enable, and the practical controls operators and vendors need to treat as essential. The central message was simple: 5G security problems are not hypothetical. Many of the most damaging issues are still basic, and when they combine with weak segmentation and slow patch cycles, they become ideal entry points for APTs and other attackers.
The 5G attack surface is already larger than many teams admit
Before getting into individual weaknesses, it is important to understand the real environment. The 5G core does not exist in isolation. It sits inside a broader telecom infrastructure that includes radio sites, RAN equipment, OAM systems, staff access, internet facing assets, roaming interconnects, fixed broadband domains, IPTV, and other adjacent systems.
That matters because attackers do not need to approach the 5G core directly. They can come from roaming, from internet facing assets, from partner access, from supply chain compromise, or from internal IT paths. In practice, 5G security is part of a much wider telecom security problem.
This is also why the session framed 5G security against a broader telco threat landscape. Recent telecom attacks have shown that threat actors are perfectly willing to enter through ordinary enterprise style paths and then pivot toward much more sensitive telecom functions.
Vulnerability 1: authentication and access control still fail too often
The first major category Mehdi covered was authentication and access control. This remains one of the most common and most damaging weakness classes in 5G environments.
The problems are familiar. Default and weak passwords. Hardcoded credentials or secrets. Password reuse. Private key reuse. Unrestricted root SSH access. None of these sound advanced, but that is exactly the point. Attackers do not need exotic techniques when basic weaknesses still let them move laterally inside critical infrastructure.
One of the most important observations from the session was that these weaknesses often appear in network management systems and operational environments where a small foothold can expand quickly. A compromised machine in the right place can become a bridge toward broader administrative access, especially if root keys are reused or if privilege boundaries are weak.
This is also where accountability becomes a real issue. Who is responsible for removing default credentials after deployment? The vendor or the operator? If that ownership is not clearly assigned and verified, weak credentials remain in production, and production becomes the real attack surface.
The practical lesson is simple. Post deployment hardening cannot be treated as assumed. It has to be verified.
Vulnerability 2: remote code execution remains a devastating compromise path
The second major category was remote code execution. Mehdi described RCE as the ability for an attacker to execute operating system commands on the server running an application, usually leading to full compromise of the application and its data.
In telecom environments, RCE is still more common in operation and management domains, but the adoption of HTTP based service communication in 5G also increases the relevance of signaling side exposure. This matters because 5G has inherited many of the same application layer security risks already seen elsewhere, while still carrying the operational weight of telecom infrastructure.
A particularly useful part of the webinar was the concrete example of insecure SSH authentication extension. In telecom environments, SSH authentication is often extended to external services such as LDAP, Radius, or Keycloak. Done correctly, that is normal. Done badly, it becomes an unauthenticated remote code execution path. The risk appears when developers take shortcuts and call OS commands directly instead of using safer methods.
That is a good example of how 5G security problems often emerge. The functionality itself is legitimate. The implementation is what creates the compromise path.
And when the flaw is unauthenticated, the attacker only needs network reachability.
Vulnerability 3: privilege escalation turns limited access into real control
Once an attacker gains a foothold, privilege escalation becomes the next logical step.
Mehdi divided this into two practical categories. The first is traditional local privilege escalation, where an attacker moves from a standard user to root. The second is privilege escalation inside Kubernetes based deployments, where compromise of one workload can become cluster level or host level access.
The local version is still driven by problems defenders already know well: misconfigured sudo rules, command injection inside proprietary binaries, outdated kernels, and end of life operating systems. Those weaknesses continue to appear even in modern 5G deployments.
The Kubernetes side is where things become more dangerous at scale. If one pod can be used to escalate to the cluster or underlying host, the attacker may not only control the originally compromised network function. They may gain influence over a wider service group, other functions in the same environment, or the platform itself.
This is where 5G complexity starts to amplify security failure. In a clustered, cloud native environment, one escalation path may create much more blast radius than teams initially expect.
Vulnerability 4: SSRF becomes much more dangerous in SBI environments
Server side request forgery was one of the most important technical categories in the webinar because it shows how familiar web vulnerabilities can become far more serious in a 5G context.
SSRF allows an attacker to force a server side application to send requests to unintended locations. In ordinary infrastructure that is already risky. In 5G SBI and indirect communication models, it can become a route into internal services, hidden resources, and control paths that should not be reachable directly.
The session explained two main patterns. One is classic application logic abuse, where business logic sends requests based on attacker controlled input. The other is routing based abuse in service based architecture, especially when functions like SCP or SEPP can be manipulated through headers or indirect communication logic.
This matters because it turns trusted telecom control logic into a relay mechanism. Instead of attacking the internal service directly, the attacker abuses the network’s own service communication model to reach it.
In practice, that means SSRF in a 5G core environment can support internal reconnaissance, access to hidden resources, and in some cases even compromise of the underlying system if the downstream service is weak enough.
Vulnerability 5: SBI denial of service is still too easy
The last major vulnerability class discussed in depth was denial of service in the 5G SBI.
This is not just a brute force traffic flooding problem. In many cases, it is a robustness and input handling problem. SBI interfaces process complex requests with many attributes, structured JSON bodies, and a growing set of custom headers. That creates a large attack surface for crashing services or making them unstable.
The session pointed to several root causes: JSON parsing issues, lack of input validation, unhandled exceptions, regular expression denial of service, and classic unsafe memory handling. The point is that richer APIs create more opportunities for malformed or malicious inputs to trigger failure.
In a telecom context, this matters because these are not just application crashes. A failed network function can affect subscriber service, session handling, mobility, or broader core behavior depending on what component is hit.
The practical lesson is that SBI endpoints need continuous robustness testing, not just feature testing.
Emerging risk 1: roaming plus SSRF could become a serious 5G issue
After covering the current weak spots, the webinar moved into emerging risks. One of the most important was SSRF from a roaming perspective.
The risk here is straightforward. If a malicious or compromised operator can send crafted traffic through a trusted roaming path and exploit indirect communication logic or routing headers, they may be able to pivot toward internal 5G resources that should not be reachable from that perspective.
Even if this is still more of an emerging deployment risk than a mainstream incident pattern today, it is exactly the kind of issue operators should want to validate before broad 5G roaming maturity arrives. Waiting until the model is deployed at scale is the wrong time to discover a weak routing assumption.
Emerging risk 2: HTTP/1.1 support keeps old web risks alive
Another strong warning from the session was about support for HTTP/1.1.
5G is supposed to move communication toward HTTP/2, but in practice many network functions still support HTTP/1.1. That matters because HTTP/1.1 carries older classes of attack that teams should not want to preserve, including request smuggling, hop by hop header abuse, and HTTP pipelining related behavior.
The webinar made the point clearly: if HTTP/1.1 is still supported in production paths, operators and vendors may be reintroducing attack classes that should already have been left behind.
This is one of those issues that looks small from a compatibility perspective and much larger from a security perspective.
Emerging risk 3: supply chain and patch management are still too weak
The final emerging risk area was supply chain security and patch management.
Vendors rely heavily on open source tools and libraries. That is not unusual anymore, but it becomes dangerous when SBOM visibility is weak or incomplete. If neither the vendor nor the operator fully understands what third party components are inside a deployment, then patching becomes slower, less reliable, and less complete.
The session also highlighted another uncomfortable truth: telecom patch cycles remain too slow. Critical vulnerabilities may take far too long to move from discovery to public fix. That delay leaves a wide operational window in which attackers can still use weaknesses that are already effectively known.
This is one of the hardest problems in telecom security. Even when the industry knows what needs to be fixed, operational pressure, dependency chains, and availability concerns often slow real remediation to an unsafe pace.
What operators should actually do now
The conclusion of the webinar was practical rather than theoretical.
Operators need to go back to basics and do them properly. That starts with security hygiene: system hardening, patch management, password management, and MFA where possible. It continues with network segmentation and filtering so that one foothold does not become access to the whole core. And it requires real detection and response capability so attackers can be noticed before they complete the compromise chain.
Mehdi also pointed to deception as a useful supporting measure. Honeytokens and similar controls can help create early warning signals when attackers begin to move through the environment.
The broader logic is simple. Better hygiene and tighter segmentation force attackers to work harder. More effort creates more noise. More noise improves the chance of detection. Better detection improves the chance of ejection before the compromise becomes catastrophic.
That is the defensive chain operators need to strengthen.
Final thoughts
This webinar was valuable because it treated 5G security as it actually exists today, not as a clean future architecture or a marketing promise.
The most important lesson from P1’s pentest work is not that 5G is insecure by design. It is that 5G deployments remain highly exposed when operators and vendors fail on basics such as credential hygiene, hardening, safe implementation, patch discipline, segmentation, and routing control.
New architecture does not save insecure operations. It only gives them a more modern wrapper.
