Die Seite zu öffnen ist der Download

Ein Leser hat einem von uns veröffentlichten Sicherheitshinweis widersprochen, und der Einwand war gut — gut genug, um ihn ausführlich zu beantworten, denn wir vermuten, dass die meisten technisch versierten Menschen nach wie vor dieselbe Überzeugung teilen:

2015 war das eine vernünftige Faustregel. Heute ist sie falsch. Das bloße Laden einer Webseite genügt vollständig, um ein iPhone zu übernehmen — und seit 2026 ist das nichts mehr, was nur staatliche Budgets erreichen.

Die Seite zu öffnen ist der Download

Was ersetzt werden muss, ist das Wort „Download“. Eine Seite zu laden ist bereits Herunterladen und Ausführen. Der Browser holt ein Programm, das ein Fremder geschrieben hat — JavaScript — und führt es aus. Anschließend parst er Bilder, Schriften, Video und Stylesheets desselben Fremden, in Decodern, die in C++ geschrieben sind. Das alles geschieht in einer Sandbox, und diese Sandbox ist das Einzige zwischen jener Seite und Ihrem Gerät.

Die Sandbox ist keine Mauer. Sie ist eine Annahme: dass WebKit und der Kernel heute keinen erreichbaren, ausnutzbaren Fehler enthalten. WebKit umfasst Millionen Zeilen C++, und Apple liefert mehrmals pro Jahr Korrekturen für WebKit-Lücken aus, die als aktiv ausgenutzt gekennzeichnet sind.

„Man muss eine .exe herunterladen, um sich zu infizieren“ ist Windows-Denken. Unter iOS können Sie eine heruntergeladene ausführbare Datei überhaupt nicht starten — und genau deshalb war eine vollständige Kette von Safari bis in den Kernel historisch siebenstellige Beträge wert. Dass Sideloading fehlt, beseitigt die Vordertür nicht. Es macht den Browser zur Vordertür.

Die Vorgeschichte reicht zehn Jahre zurück

Nichts davon ist neu. Drei gut dokumentierte Punkte auf der Kurve:

Was sich 2026 geändert hat, ist nicht die Fähigkeit. Es ist die Verbreitung.

2026: Die Fähigkeit wurde vermietet

Im März veröffentlichte die Google Threat Intelligence Group — gemeinsam mit iVerify und Lookout — eine Analyse eines vollständigen iOS-Exploit-Kits, das unter dem Namen DarkSword geführt wird. Es reichte von iOS 18.4 bis 18.7, verkettete sechs Schwachstellen — drei davon damals Zero-Days — und war mindestens seit November 2025 im Einsatz.

Zwei Details dieses Berichts wiegen schwerer als die Zahl der Schwachstellen.

Das erste ist die Liste der Betreiber. Aktivitäten in der Türkei wurden mit einem türkischen Überwachungsanbieter in Verbindung gebracht; ein weiterer Kunde desselben Anbieters wurde im Januar dabei beobachtet, wie er dieselbe Kette gegen malaysische Nutzer einsetzte; und ein separater, mutmaßlicher Spionagecluster führte Watering-Hole-Angriffe gegen ukrainische Nutzer durch — die Kette wurde auf Seiten platziert, die die Zielpersonen von sich aus besuchen. Eine Exploit-Kette, viele voneinander unabhängige Hände. Das ist eine Lieferantenbeziehung, keine maßgeschneiderte Operation.

Das zweite: Die Forscher fanden Hinweise darauf, dass Entwicklung oder Anpassung der Kette KI-gestützt erfolgt sein könnte. Wie immer man diesen einzelnen Befund gewichtet — die Richtung, in die er zeigt, ist hier entscheidend: Die Einstiegshürde sinkt, und Fähigkeiten, die einer Handvoll Anbieter vorbehalten waren, breiten sich nach außen aus.

Und dann wurde es billig

Am 1. September veröffentlichte Socket eine Untersuchung zur Massenmarkt-Variante genau dieses Trends — und hier geht es überhaupt nicht um Spionage. Es geht um Diebstahl.

Dreizehn bösartige Composer-Theme-Pakete wurden unter mehreren Namensräumen auf Packagist veröffentlicht. Vietnamesische Film- und Comic-Streaming-Seiten installierten sie per composer require, wodurch die Frontend-Assets dieser Seiten stillschweigend trojanisiert wurden. Jeder Besucher erhielt daraufhin eingeschleustes JavaScript.

Dieses Skript verzweigte:

• Die meisten mobilen Besucher wurden in eine Anzeigenbetrugs- und Glücksspiel-Weiterleitungskette geleitet. Laut, einträglich, unauffällig.
• Besucher auf ungepatchten iPhones erhielten stattdessen eine Exploit-Kette von WebKit bis in den Kernel — und bekamen Spyware installiert.

Die Kette trat über zwei WebKit-Fehler ein und endete mit Lese- und Schreibzugriff auf den Kernel. Beachten Sie, worum es sich dabei handelt: um N-Days, nicht um Zero-Days. Beide waren bereits öffentlich und bereits behoben. Das gesamte Geschäftsmodell ist die Lücke zwischen dem Zeitpunkt, zu dem Apple eine Korrektur ausliefert, und dem Zeitpunkt, zu dem eine bestimmte Person sie installiert. Dieses Kit greift keine iPhones an. Es greift iPhones an, die länger nicht aktualisiert wurden — und auf einem Gerät, das jemand wie ein Haushaltsgerät behandelt, ist das eine enorme Population.

Womit wir bei einem kostenlosen VPS-Angebot wären

Am 31. August wurde eine Domain registriert. Am 1. September verbreitete sie sich bereits.

Der Köder ist gut auf sein Publikum zugeschnitten: ein Cloud-Anbieter kündigt eine geschlossene Beta an, mit kostenlosen VPS-Instanzen — bis zu drei Jahre — für die ersten 5.000 Anmeldungen. Verbreitet wurde er in VPS-, Sysadmin- und Blockchain-Communities per E-Mail-Einladung und, wirkungsvoller, über Empfehlungslinks.

Bei diesem Empfehlungsmechanismus sollte ein Verteidiger innehalten. Er verteilt nicht bloß den Link; er rekrutiert die etablierten Mitglieder der Community selbst als Verteiler, eingehüllt in deren eigene Reputation, weil sie dafür eine längere kostenlose Laufzeit erhalten. Die Nachricht kommt nicht von einem Fremden. Sie kommt von jemandem, dessen Beiträge Sie seit Jahren lesen. Mindestens eine Person, die einen Empfehlungslink geteilt hatte, veröffentlichte später einen Widerruf und warnte andere davor.

Berichtetes Verhalten der Seite:

Eine Werbeantwort betonte Berichten zufolge, der Reservierungslink müsse „unbedingt auf dem Handy geöffnet werden“. Keine echte VPS-Reservierungsseite hat einen Grund, das zu verlangen. Ein Exploit-Kit, das ausschließlich mobil funktioniert, hat jeden Grund dazu.

Was wir bestätigen können und was nicht

Wir wollen beim Beweisstatus präzise sein, denn diese drei Geschichten stehen nicht auf derselben Bestätigungsebene, und es wäre unredlich, sie so darzustellen.

DarkSword und die Packagist-Kampagne sind von Anbietern veröffentlichte Forschung. Namentlich genannte Forscher, benannte CVEs, reproduzierbare technische Details, Veröffentlichung unter organisatorischer Verantwortung. Behandeln Sie sie als gesichert.

Die Kampagne mit dem kostenlosen VPS stammt aus der Community. Dass die Kampagne existiert, ist gut belegt: Die Bewerbung ist über mehrere Threads dokumentiert, das Registrierungsdatum der Domain ist überprüfbar, und ein Teilnehmer hat seinen eigenen Empfehlungsbeitrag öffentlich zurückgezogen. Das genügt bei Weitem, um defensiv zu handeln.

Die tiefergehenden technischen Aussagen — die konkrete Kette, die genaue Staffelung — stammen aus einer anonymen Analyse ohne veröffentlichte CVE-Kennungen oder Sample-Hashes, erstellt binnen eines Tages. Das ist machbar, wenn die Autorenschaft ein bekanntes Kit wiedererkannt hat; hätte sie über Nacht eine neuartige Kette reverse-engineert, wäre das bemerkenswert. Die oben genannte Socket-Forschung ist das, was den Bericht glaubwürdig macht, nicht umgekehrt: dasselbe Versionsband, dieselbe Liste gestohlener Daten, dasselbe Krypto-Motiv, dieselbe Architektur aus Fingerprinting und anschließendem Nachladen. Ein gemietetes N-Day-Kit, gerichtet auf Menschen, die seit einem Jahr nicht aktualisiert haben, sieht genau so aus.

Unsere Position: glaubwürdig genug, um sich davor zu schützen, nicht bestätigt genug, um es als Tatsache zu zitieren. Sollte sich das ändern, aktualisieren wir diesen Beitrag an Ort und Stelle, wie bei früheren Hinweisen auch.

„Zero-Click“ ist das falsche Wort, und die Wahrheit ist kaum besser

Der Community-Bericht ist als Zero-Click-Angriff betitelt. Das ist es nicht, und die Unterscheidung lohnt sich, denn sie ändert, was Sie schützt.

Zero-Click bedeutet: überhaupt keine Nutzeraktion — eine Nachricht trifft ein, und das Gerät ist kompromittiert, bevor irgendetwas geöffnet wurde. Hier müssen Sie einen Link öffnen. In der üblichen Systematik ist das ein One-Click-, Watering-Hole- oder Drive-by-Angriff.

Die Unterscheidung ist aus praktischen Gründen wichtig: Gegen eine One-Click-Kette schützt Sie umsichtiger Umgang mit Links tatsächlich. Gegen eine echte Zero-Click-Kette tut er das nicht — dort helfen nur Patch-Stand und der Sperrmodus.

Nehmen Sie daraus aber nicht zu viel Trost. „Ein Klick“ heißt hier: einen Link öffnen, den Ihnen jemand geschickt hat, dem Sie vertrauen. Es gibt keine zweite Abfrage, keine Download-Leiste, keinen Installationsdialog, kein Berechtigungsfenster. Das Öffnen ist die gesamte Nutzerinteraktion. Das Wort ist falsch; der praktische Unterschied für das Opfer beträgt einen Tipp.

Ist Android davor sicher?

Vor dieser Kette: ja. Vor dieser Klasse von Angriffen: nein.

Diese Kette besteht aus Fehlern in WebKit und JavaScriptCore, einem IOKit-Kerneltreiber von iOS und build-spezifischen Offsets für bestimmte iPhone-Modelle. Nichts davon existiert unter Android. Beide Kampagnen bestätigen das im Verhalten: Im Packagist-Fall prüfte das eingeschleuste Skript die Plattform und schickte Android-Besucher zum Anzeigenbetrugs-Banner; im Fall des kostenlosen VPS erhalten Android- und Desktop-Besucher nur das Phishing-Formular.

Diese Klasse ist eine andere Sache. Chrome, V8 und Android WebView sind dieselbe Art Artefakt wie WebKit: riesige C++-Engines, die feindliche Eingaben parsen. Google hat fünf im Jahr 2026 aktiv ausgenutzte Chrome-Zero-Days geschlossen; einer davon erlaubte einem entfernten Angreifer, allein über eine präparierte HTML-Seite Code innerhalb der Browser-Sandbox auszuführen. Das ist derselbe erste Schritt, den die iOS-Ketten gehen.

Die fünf sind CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 und CVE-2026-11645. Der letzte ist ein Lese- und Schreibzugriff außerhalb der Grenzen in V8.

Auch Drive-by-Ketten für Android sind dokumentiert, darunter eine, die einen Chrome-Zero-Day, eine nur unter Android wirksame Umgehung der Chrome-GPU-Sandbox und eine Rechteausweitung im Mali-GPU-Treiber kombinierte und per SMS-Link ausgeliefert wurde.

Wo Android sich tatsächlich unterscheidet

Drei reale Unterschiede — und sie weisen nicht alle in dieselbe Richtung.

Was tatsächlich schützt

Für die beiden dokumentierten iOS-Kampagnen ist der Patch-Stand entscheidend — und in den Versionsnummern steckt eine Falle:

Über das Patchen hinaus der strukturelle Rat: Bewahren Sie Wallet-Seed-Material nicht auf dem Gerät auf, mit dem Sie Links öffnen. Die finalen Payloads beider Kampagnen zielten auf den Schlüsselbund und auf Wallet-Apps. Eine Hardware-Wallet oder ein dediziertes Gerät macht aus einem Totalverlust ein Ärgernis.

Und behandeln Sie „Öffnen Sie das auf Ihrem Telefon“ als Anomalie. Einer legitimen Anmeldeseite ist es gleich, welches Gerät Sie verwenden. Einem rein mobilen Exploit-Kit ist es das sehr wohl nicht.

Falls Sie sie geöffnet haben

Gehen Sie von einer Kompromittierung aus, statt auf das Gegenteil zu hoffen — in dieser Reihenfolge:

• Zuerst die Gelder bewegen. Waren auf dem Gerät Wallet-Apps installiert, betrachten Sie die Seed-Phrasen als offengelegt. Übertragen Sie die Werte in eine Wallet, deren Schlüssel anderswo erzeugt wurden. Ändern Sie nicht einfach einen Gerätecode — der Seed ist das Konto.
• Dann aktualisieren, dann neu starten. Installieren Sie die aktuelle iOS-Version. Viele dieser Implantate überstehen einen Neustart nicht; Aktualisieren und Neustarten schließt die Lücke und räumt zugleich eine nicht persistente Stufe ab.
• Erneuern Sie, was im Schlüsselbund lag. Gespeicherte Passwörter, WLAN-Zugangsdaten, Sitzungs-Cookies. Melden Sie sich überall von allen Sitzungen ab und ändern Sie die Passwörter anschließend von einem anderen Gerät aus.
• Prüfen Sie Ihre Konten auf Hinzufügungen, nicht nur auf Anmeldungen. Neue 2FA-Methoden, neue Wiederherstellungsadressen, neue API-Schlüssel, neue autorisierte Geräte. Entwendete Cookies werden genutzt, um sich einen dauerhaften Rückweg einzurichten.

Kettenstufen, wie berichtet

Rekonstruiert aus Sockets veröffentlichter Analyse der Packagist-Kampagne. Die Stufengrenzen sind für die Triage entscheidend: jede hinterlässt andere Spuren, und nur die letzte ist persistent.

Zwei Dinge sollte ein Verteidiger aus dieser Form mitnehmen. Erstens: nur Stufe 1 berührt jeden Besucher — eine Seite, die den Injektor ausliefert, ist für ihr gesamtes Publikum gefährlich, obwohl fast niemand Stufe 4 erreicht. Zweitens ist die Einstiegsbedingung in beiden Fällen ein behobener Fehler, also ist Exposition eine Funktion des Update-Verzugs, nicht des Nutzerverhaltens.

Expositionsmatrix

Triage für ein mutmaßlich betroffenes Gerät

Diese Reihenfolge weicht bewusst von der Leserempfehlung ab. Der Blog rät der Besitzerin oder dem Besitzer, sofort zu aktualisieren und neu zu starten — richtig, wenn es darum geht, die Blutung zu stoppen. Geht es darum festzustellen, ob ein Gerät kompromittiert wurde, zerstört ein Neustart die Beweise: mehrere dieser Stufen sind nicht persistent und existieren nur im flüchtigen Zustand.

• Entscheiden Sie zuerst: Wiederherstellung oder Nachweis. Beides zugleich geht meist nicht. Stehen Gelder auf dem Spiel, wählen Sie die Wiederherstellung und nehmen den Beweisverlust in Kauf.
• Für den Nachweis: vor dem Neustart sichern. Eine vor dem Neustart erstellte sysdiagnose bewahrt weit mehr als eine danach. Wiederholte Abstürze des WebContent- oder GPU-Prozesses um den Besuchszeitpunkt sind die Spur, die am ehesten überdauert.
• Wallet-Material gilt als offengelegt, nicht als gefährdet. Stufe 5 zielt direkt darauf. Ein Schlüsseltausch ist nicht optional und lässt sich durch Patchen nicht nachholen.
• Prüfen Sie auf Hinzufügungen, nicht auf Zugriffe. Entwendete Cookies dienen dazu, einen dauerhaften zweiten Weg einzurichten — neue MFA-Faktoren, Wiederherstellungsadressen, API-Schlüssel, autorisierte Geräte. Eine saubere Anmeldehistorie beweist nichts.
• Prüfen Sie das Netz, nicht nur das Telefon. WLAN-Passwörter waren im Zugriff. Ein kompromittiertes Gerät bedeutet offengelegte Zugangsdaten für jedes Netz, das es gespeichert hatte.

Bewertung, und was sie ändern würde

Wir benennen die Konfidenz ausdrücklich, denn diese drei sind nicht gleich gut belegt, und ein Hinweis, der das verwischt, ist weniger wert als einer, der es nicht tut.

Was die niedrige Bewertung anheben würde: ein veröffentlichter Sample-Hash, eine zweite unabhängige Analyse oder eine Anbieterbestätigung, die dieselben CVEs benennt. Was sie senken würde: wenn der Köder sich als gewöhnliche Zugangsdaten-Phishing-Seite ohne versionsabhängige Payload erweist — das ist die Nullhypothese, und nichts, was wir selbst gesehen haben, schließt sie aus.

Für die Gratis-VPS-Kampagne liegt uns kein Sample vor. Alles, was in diesem Hinweis darüber steht, ist aus zweiter Hand. Wir sagen das ausdrücklich, statt das stehende Angebot dieser Seite, Payloads zu teilen, etwas anderes suggerieren zu lassen.

Zeitleiste

Selbst überprüfen

Wenn Sie das Weichenverhalten selbst prüfen wollen, statt es jemandem zu glauben, tun Sie es von einer Maschine aus, die nicht das Ziel ist: Holen Sie das Skript der Seite unter Linux mit einem iPhone-User-Agent und dem Community-Forum als Referer und vergleichen Sie es mit dem, was ein Desktop-User-Agent erhält. Payload-Auslieferung nach User-Agent ist in solchen Kits Standard, und ein Desktop-User-Agent bekommt sehr wahrscheinlich sauberes JavaScript.

Tun Sie das nicht von einem Telefon aus und nicht von einem Gerät, auf dem Wallet-Material liegt. Cloaking schneidet in beide Richtungen: Dass ein Scanner eine aktive Phishing-Seite als sauber meldet, ist das erwartete Ergebnis — kein beruhigendes.

Indikatoren

event.polarnode[.]vip          Köder-Host, registriert am 2026-08-31
CVE-2025-31277                 WebKit, behoben in iOS 18.6
CVE-2025-43529                 WebKit, behoben in iOS 18.7.3 / 26.2
AppleM2ScalerCSCDriver         IOKit-User-Client, über den der Kernel erreicht wurde
Packagist-Namensräume:         vsmov, vsphim, haiau009, chilltvcms, ophimcms

Warum in diesem Artikel keine Links stehen

Jede feindliche Adresse, die wir veröffentlichen, ist entschärft geschrieben, und keine davon ist ein funktionierender Link. Ein Phishing-Hostname als lebender Anker gerendert macht aus einem Artikel eine Weiterleitung, leiht der Kampagne einen Teil unserer Reputation und fordert eine Suchmaschine auf, beides miteinander zu verknüpfen. Unsere Veröffentlichungspipeline erzwingt das: Ein Host, der irgendwo in einem Beitrag entschärft auftaucht, darf an keiner anderen Stelle desselben Beitrags einen lebenden Link tragen.

Die hier angeführte Anbieterforschung ist über ihren Namen leicht zu finden. Uns ist lieber, Sie gelangen über eine Suche dorthin, die Sie selbst durchgeführt haben, als über einen Link, den wir gesetzt haben.