Eine harmlose App genügt, um unter Android die aktivierte VPN-Sperre auszuhebeln und die echte IP-Adresse ins offene Netz zu schicken. Der Sicherheitsforscher Armin Šupuk führt den Angriff an einem Pixel 8 Pro mit Android 16 vor: Alle zehn Sekunden verlässt ein Datenpaket den Tunnel, obwohl die Option „Verbindungen ohne VPN blockieren“ aktiv ist. Google stufte den Fund als nicht behebenswert ein.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Die VPN-Sperre gilt als letzte Verteidigungslinie auf dem Smartphone: Kein Byte soll das Gerät ohne verschlüsselten Tunnel verlassen. Diesen Schutz durchbricht ein bisher übersehener Umweg über die Funkchips. Betroffen sind nach Schätzung des Entdeckers die meisten Geräte ab Android 12.
Das Wichtigste in Kürze
- Eine App ohne jede Sonderberechtigung lässt Android sogenannte NAT-T-Keepalive-Pakete direkt über den Funkchip senden.
- Diese Pakete laufen auf UDP-Port 4500 am Tunnel vorbei und geben einem beliebigen Server die echte IP-Adresse preis.
- Die Schutzfunktion „Verbindungen ohne VPN blockieren“ greift dabei nicht.
- Google schloss die Meldung ohne Korrektur, GrapheneOS arbeitet an einer Abriegelung.
Wie kommt der Verkehr an der VPN-Sperre vorbei?
Hardware-Offload ist der Kern des Problems. Android erlaubt Apps, für stromsparende Verbindungen ein NAT-T-Keepalive einzurichten, ein kurzes Signal, das eine Verbindung durch Router und Firewalls offen hält. Den Versand übergibt das System direkt an den WLAN- oder Mobilfunkchip. Ab da entsteht der Datenverkehr unterhalb der Ebene, auf der die VPN-Sperre entscheidet, was den Tunnel nutzt.[1]
Am Tunnel vorbei landet damit jedes dieser Pakete. Šupuk richtete den Keepalive auf einen eigenen Server und protokollierte am Router den Rest: Alle zehn Sekunden traf ein UDP-Paket auf Port 4500 ein, während das VPN und die Blockade liefen. Der Server sah die reale IP und den Takt der Pakete, nicht die getarnte Adresse des Anbieters.[2]
Keine Berechtigung braucht die App dafür. Ein Standort- oder Netzwerkrecht, das misstrauisch machen würde, entfällt. Der Kanal überträgt wenig, genügt aber, um ein Gerät dauerhaft wiederzuerkennen.
Warum ist das kein Einzelfall?
Eine Serie zieht sich durch die jüngere Android-Geschichte. Mullvad dokumentierte zuvor bereits, dass DNS-Anfragen am Tunnel vorbeilaufen und dass jede App über den Verbindungstest von Android Datenverkehr durchsickern lässt. Der neue Keepalive-Trick reiht sich als weiterer Baustein ein.[3]
Gleiches Muster zeigt sich bei der Reaktion. Schon im Frühjahr 2026 legte ein zweiter Forscher unter dem Titel „Tiny UDP Cannon“ ein verwandtes Leck offen, GrapheneOS schloss die Lücke binnen einer Woche. VPN-Leaks gelten dem Konzern als bekanntes Verhalten, nicht als Schwachstelle mit eigenem Update, weshalb gehärtete Systeme wie GrapheneOS einspringen, das zuletzt auf Android 17 sprang.
Eine VPN-Sperre, die der eigene Funkchip aushebelt, ist keine halbe Sicherheit, sondern eine falsche Gewissheit. Firmen, die Mitarbeitergeräte über Always-on-VPN absichern, sollten die echte IP als weiterhin sichtbar behandeln.
— Markus Seyfferth, Chefredakteur Dr. Web
Was bedeutet das für Unternehmen?
DSGVO-relevant wird der Fund, sobald die echte IP-Adresse ein Gerät und mittelbar eine Person identifiziert. Ein Werbe- oder Tracking-SDK in einer beliebigen App könnte den Kanal nutzen, um Nutzer trotz VPN wiederzuerkennen. Für Betreiber mobiler Flotten verschiebt dieser Kanal die Risikolage, weil die Kontrolle beim Betriebssystem liegt, nicht bei der App, ähnlich wie bei der jüngsten Palo-Alto-VPN-Lücke.
Gegensteuern lässt sich trotzdem. Am wirksamsten laufen sensible Dienstgeräte auf einem gehärteten System, das den Kanal dichtmacht. Auf Netzwerkebene hilft ein Mitschnitt des ausgehenden Verkehrs auf Port 4500, um Pakete außerhalb bekannter IPsec-Ziele aufzuspüren. Zur Einordnung dienen der Überblick zu Möglichkeiten und Grenzen von VPNs und die Einsatzszenarien im Unternehmen.
Wie ein NAT-T-Keepalive die aktivierte VPN-Sperre aushebelt
Googles Reaktion
Der Konzern schloss die Meldung ohne Korrektur und wertet VPN-Leaks als bekanntes Verhalten, nicht als Sicherheitslücke. Die Abriegelung übernimmt bislang nur das gehärtete System GrapheneOS.
Fazit für die Praxis: Solange Google die Lücke als Verhalten und nicht als Fehler führt, bleibt die VPN-Sperre auf Standard-Android ein Versprechen mit Sternchen. Behandeln Sie die echte IP mobiler Geräte als sichtbar und verlassen Sie sich nicht allein auf den Schalter im System.
FAQ: Android umgeht die VPN-Sperre
Schützt ein VPN auf Android jetzt überhaupt noch?
Ja, ein VPN verschlüsselt weiterhin den normalen App-Verkehr. Das Leck betrifft nur ein schmales Nebensignal über den Funkchip, das die echte IP-Adresse und den Sendetakt preisgibt, nicht die Inhalte Ihrer Verbindungen.
Woran erkennen Sie, ob Ihr Gerät betroffen ist?
Betroffen sind nach Einschätzung des Entdeckers die meisten Geräte ab Android 12. Ein sicheres Indiz liefert nur ein Mitschnitt am Router: Verlassen UDP-Pakete auf Port 4500 das Gerät, obwohl VPN und Sperre aktiv sind, greift der Umweg.
Können Sie das Leck selbst abschalten?
Im Standard-Android nicht. Google bietet weder einen Schalter noch einen Patch. Nur gehärtete Systeme wie GrapheneOS deaktivieren die missbrauchte Funktion. Auf anderen Geräten helfen nur der Verzicht auf verdächtige Apps und eine Überwachung am Netzwerkrand.
Warum stuft Google das nicht als Sicherheitslücke ein?
Google behandelt VPN-Leaks als bekanntes Verhalten des Systems, nicht als Schwachstelle mit eigenem Sicherheits-Update. Entsprechende Meldungen schließt der Konzern ohne Korrektur, Rückportierungen bleiben aus.
Quellen
[1] Mullvad VPN: „Another way to leak traffic on Android has been discovered“
[2] Armin Šupuk: „NAT-T Keepalive VPN Bypass“
[3] Mullvad VPN: „DNS traffic can leak outside the VPN tunnel on Android“
Mehr Newshunger?
- Kritische PAN-OS-Lücke gibt Angreifern Root-Rechte auf Palo-Alto-Firewalls
- Höchstwertung für Ciscos Firewall-Lücke: CISA warnt vor drei Herstellern
- Qilin-Ransomware nutzt Palo-Alto-VPN-Lücke: Wenn ein Cookie die Firewall öffnet
- Schadsoftware infiziert die Firmware von Android-Autoradios
- Berliner Datenleck: 5,8 Terabyte Behördendaten im Darknet
