Eine aktuelle Veröffentlichung von Forschenden der Nanyang Technological University in Singapur zeigt, wie viele Sicherheitsprobleme in 4G- und 5G-Core-Netzen noch schlummern. In der Studie geht es nicht um exotische Randbedingungen, sondern um Schwachstellen in Signal- und Kontrollschnittstellen, die in weit verbreiteten Open-Source-Implementierungen genutzt werden – sowohl in Forschungstestbeds als auch in kommerziellen Umgebungen.
Im Zentrum stehen sogenannte implicit trust errors: eine fehlerhafte Annahme, dass interne Netzwerkfunktionen eingehende Nachrichten ohne ausreichende Validierung annehmen und weiterverarbeiten. Wenn ein Angreifer diese Schnittstellen über das Internet oder über einen kompromittierten Mobilfunk-Endpunkt erreichen kann, werden aus solchen Vertrauensfehlern schnell reale Angriffsflächen. Neben Denial-of-Service (DoS) nennen die Forschenden insbesondere Session-Hijacking 4G 5G als mögliches Ziel.
Warum Cloud-Deployments das Risiko erhöhen
Historisch wurden Core-Netzfunktionen häufig durch physische Isolation voneinander getrennt. Diese Trennung begrenzte, welche Interfaces überhaupt erreichbar waren. Mit der Umstellung auf cloud-native Deployments verändert sich das Sicherheitsmodell jedoch: Vertrauen wird „fragiler“, und die Angriffsfläche wächst, weil Schnittstellen potenziell weiter nach außen gezogen werden.
Laut der Studie zeigen sich darin Muster von blindem Vertrauen zwischen Komponenten. In Kombination mit konkreten Schwächen in den jeweiligen Protokoll-Schnittstellen kann dies von außen ausgenutzt werden – selbst dann, wenn die eigentliche Erwartung „nur interne Kommunikation“ lautet.
Welche Core-Implementierungen betroffen sind
Die Forschenden betrachten zwei LTE-Implementierungen sowie fünf 5G-Implementierungen. Für LTE werden dabei unter anderem Open5GS und OpenAirInterface analysiert. Im 5G-Bereich fallen gleich mehrere Plattformen in den Fokus: Open5GS, free5GC, OpenAirInterface, SD-Core und eUPF. Die Untersuchung läuft über zwei zentrale Core-Signalling-Protokolle: GTP-C (GPRS Tunnelling Protocol Control Plane) und PFCP (Packet Forwarding Control Protocol).
So entsteht ein Bild, das über eine einzelne Software oder einen einzelnen Use Case hinausgeht. Die Forschenden betonen ausdrücklich, dass die identifizierten Probleme eine gemeinsame Wurzel besitzen: implizites Vertrauen zwischen Core-Funktionen.
Von der Analyse zum Ergebnis: iFinder und mehrstufiges Vorgehen
Um solche Schwachstellen nicht nur aufzuspüren, sondern auch deren Auswirkungen besser einschätzen zu können, entwickeln die Forschenden ein mehrstufiges System namens iFinder. Dieses nutzt einen Large Language Model (LLM)-gestützten, multi-agent Ansatz.
Der Ablauf umfasst laut Studie mehrere Schritte: bekannte Schwächen werden zusammengefasst, in Detektionsmuster eingeordnet und als Grundlage genutzt, um neue implicit trust errors in Core-Implementierungen zu entdecken. Anschließend werden typische Probleme wie Halluzinationen und False Positives mit einer neuartigen „code-specification cross-checking“-Methode aussortiert.
Erst danach werden mit einem LLM-getriebenen Prozess Proof-of-Concept (PoC)-Exploits erzeugt. Diese werden iterativ verfeinert, indem sie gegen die untersuchten Core-Systeme ausgeführt und anhand der Resultate bewertet werden.
Wie die Schwachstellen konkret entstehen
Mehrere der identifizierten Schwächen hängen laut Veröffentlichung mit fehlender Sorgfalt bei der Überprüfung von eingehenden Nachrichten zusammen. Besonders kritisch ist, wenn Komponenten Nachrichten blind entgegennehmen, obwohl sie eigentlich Validierung von Format, Semantik und Ressourcenverfügbarkeit sicherstellen müssten.
Die Forschenden ordnen die Kandidaten außerdem einem konkreten Protokollablauf zu. Entscheidend ist dann die Frage, ob im Code tatsächlich auch jene Validierungs- und Ressourcenchecks existieren, die der Protokollprozess erwarten würde.
84 bisher unbekannte Lücken – und viele bestätigte CVEs
Nachdem iFinder gegen die genannten sieben 4G- und 5G Open-Source-Implementierungen läuft, kommen 84 zuvor unbekannte Schwachstellen heraus. Davon seien bereits 83 bestätigt worden, und 81 erhielten die Zuordnung von CVE-Identifiers.
Ein weiterer wichtiger Befund: Einige 5G-Schwächen sollen von 4G-Gegenstücken „übernommen“ worden sein. Das verdeutlicht, dass Sicherheitsrisiken sich über Generationen hinweg fortpflanzen können – insbesondere, wenn Legacy-Funktionalität nicht ausreichend an moderne Deployment-Modelle angepasst wird.
Session-Hijacking 4G 5G: Voraussetzungen für erfolgreiche Angriffe
Damit DoS- oder Session-Hijacking-Szenarien funktionieren, braucht ein Angreifer mehr als nur eine einzelne Softwarelücke. Laut Studie setzt das erfolgreiche Ausnutzen von implicit trust errors voraus, dass der Angreifer die IP-Adresse der beteiligten Core-Komponenten ermitteln kann. Das kann zum Beispiel über öffentliche Dokumentation, passive Enumeration oder aktives Scanning erfolgen.
Außerdem muss der Angreifer Zugriff auf interne Core-Interfaces haben, wobei misconfigurations in cloud-nativen Umgebungen eine Rolle spielen. Die Studie beschreibt zwei mögliche Angreiferprofile: einen externen Angreifer, der außerhalb des Core-Netzes sitzt, oder ein maliziöses User Equipment (UE), das sich mit dem Mobilfunknetz verbindet. Im zweiten Fall werden speziell präparierte Payloads in den Uplink-Datenstrom eingebracht.
Wie Nachrichten „durch die Grenze geschmuggelt“ werden
Ein Kernelement der beschriebenen Angriffslogik ist das Ausnutzen von Protokoll-Tunneling und einer Art Boundary Bridging. Dabei werden PFCP– oder GTP-C-Nachrichten so in andere Nachrichten verpackt, dass sie ohne strikte Grenzvalidierung durchlässig werden.
Wenn die Boundary-Enforcement nicht ausreichend greift, können diese präparierten Daten am Ende in Core-Komponenten landen, dort geparst werden und die falsche Vertrauensannahme auslösen. Genau damit lassen sich dann je nach Zielrichtung DoS- oder Session-Hijacking 4G 5G-Abläufe nachbilden.
DoS-Beispiel in Open5GS (LTE)
Für ein hypothetisches DoS-Szenario gegen Open5GS in einem LTE-Setup beschreibt die Studie einen Angriff, bei dem der Angreifer GTPv2-C-Nachrichten sendet. Die Wirkung soll beim Parsen von Create Session Request-Nachrichten auftreten, sodass die Steuerkomponente des Serving Gateways (SGW-C) abstürzt.
Session-Hijacking-Szenario über PFCP und UPF
Beim Session-Hijacking schildern die Forschenden einen Ablauf, der auf der User Plane Function (UPF) basiert. Vereinfacht dargestellt sieht das Szenario so aus:
- Der Angreifer sendet eine PFCP Association Setup Request an die UPF.
- Das Opfer-UE triggert durch einen Attach-Prozess die SMF, die eine PFCP Session Establishment Request an die UPF absetzt.
- Der Angreifer schickt dann eine PFCP Session Modification Request und nutzt dabei eine bereits bestehende PDR-ID des Opfers, diesmal mit einer niedrigeren Precedence (höhere Priorität).
- Die Anfrage bindet diese Regel an eine Forwarding Action Rule, die vom Angreifer kontrolliert wird.
- Die UPF nimmt die Duplikate an, sortiert PDRs nach Precedence und platziert die schädliche Regel vor der legitimen.
- Bei der Paketverarbeitung matcht die UPF zuerst die bösartige Regel und etabliert dadurch ein Weiterleitungstunnelziel zwischen UPF und dem Angreifer.
- Dadurch wird der Uplink-Traffic des Opfers nicht ins Internet weitergeleitet, sondern zum Angreifer.
Auf hoher Ebene erlaubt die beschriebene Schwachstelle einem Angreifer, durch eine PFCP Session Modification Request die UPF so zu beeinflussen, dass der Uplink-Traffic des betroffenen UE an den Angreifer weitergeleitet wird.
Mögliche Folgen: mehr als nur „Verbindung weg“
Ein besonders problematischer Punkt ist, dass die weitergeleiteten Daten nicht nur beobachtbar sein könnten, sondern auch in einem vom Angreifer kontrollierten Ziel-Endpunkt landen können. Laut Angaben eines Autors kann der Angreifer dabei entscheiden, ob er die Pakete prüft, verändert, weiterleitet oder verwirft.
Die Studie nennt als mögliche Konsequenzen beispielsweise das Monitoring unverschlüsselter Anwendungsdaten und das Offenlegen von Netzwerkmetadaten wie Ziel-IP-Adresse, Timing oder Datenmenge. Selbst wenn die Payload verschlüsselt ist, kann die Metadatenebene für Angreifer wertvoll bleiben. Darüber hinaus kann es zu Manipulationen kommen, etwa bei ungeschützten DNS-Anfragen.
Es ist außerdem denkbar, dass Angreifer gezielt Pakete verwerfen, sodass die Konnektivität eines bestimmten Teilnehmers gestört wird, ohne das gesamte UPF zu beeinflussen. Genau diese Selektivität erhöht die Angriffsrealistik, weil sie sowohl schwerer zu erkennen als auch weniger offensichtlich als ein Totalausfall ist.
Reaktion in der Praxis: behobene und noch offene Lücken
Die Session-Hijacking-Schwachstelle wurde den Angaben zufolge in zwei realen kommerziellen 5G-Core-Netzen gefunden. Ein Hersteller (Dotouch) habe die Lücke in XproUPF inzwischen adressiert. Dafür wird CVE-2026-8233 genannt (mit einem CVSS-Score von 4.6).
Ein weiterer kommerzieller 5GC-Anbieter (Name nicht genannt) befinde sich noch in der Remediation. Zusätzlich weist die Studie darauf hin, dass CVE-2026-8233 und CVE-2026-36884 denselben zugrunde liegenden Fehler in zwei unabhängig entwickelten Produkten beschreiben. Außerdem gibt es eine weitere produktbezogene Schwachstelle in eUPF (CVE-2025-66776), die ebenfalls zu Session-Hijacking führen kann.
Fazit: Sicherheitslücken sind kein Einzelfall
Die Zahl der gefundenen Probleme unterstreicht nach Ansicht der Forschenden, dass es sich nicht um eine kleine Sammlung isolierter Programmfehler handelt. Vielmehr sei es ein breiteres, fortlaufendes Sicherheitsproblem, das sowohl Hersteller als auch Netzbetreiber kurzfristig adressieren müssen.
Für den Schutz bedeutet das vor allem: Vertrauen zwischen Core-Funktionen darf nicht blind sein. Eingehende Nachrichten müssen konsequent validiert werden, und Grenzmechanismen müssen so ausgelegt werden, dass präparierte PFCP- oder GTP-C-Daten nicht unerkannt an UPF- und Parsing-Pfade gelangen. Wenn Betreiber diese Punkte systematisch angehen, sinkt die Wahrscheinlichkeit, dass aus einer klassischen Trust-Fehlannahme ein realer Angriff wie Session-Hijacking 4G 5G wird.
Quelle: https://thehackernews.com/2026/07/researchers-report-84-flaws-in-4g-and.html
