Mit Apple iOS 26 ist das physische Jailbreaking endgültig Geschichte. Erfahren Sie, warum Corellium der einzige Weg ist, iOS-Interna und Schwachstellen mobiler Apps vollständig zu analysieren und zu verifizieren sowie mobile Sicherheitsrecherchen anzustellen. 

iOS 26 macht Schluss mit Jailbreaking. Das sind die Folgen für Entwickler und Sicherheitsteams

Mit der Veröffentlichung von iOS 26 hat Apple die letzte praktikable Möglichkeit für Sicherheitsteams geschlossen, tiefgreifende Sicherheitstests auf Root-Ebene unter iOS durchzuführen: Jailbreaks. Jahrelang boten Jailbreaks Teams eine Möglichkeit, das App-Verhalten auf echten Geräten zu untersuchen – nicht nur in Simulationen oder statischen Code-Reviews. 

Damit ist jetzt Schluss. Was Apple als verbesserten Schutz bezeichnet, hat eine neue Art von Risiko geschaffen: einen völligen Verlust der Sichtbarkeit für Entwickler, Penetrationstester und Sicherheitsverantwortliche, die verstehen müssen, wie sich Apps auf echten Geräten verhalten. 

Somit testen Organisationen keine Apps mehr. Sondern bloß Annahmen.

Ohne iOS-Jailbreaks keine Laufzeitvalidierung 

Jailbreaks waren nie ideal, aber sie boten Zugang zu dem, worauf es ankam. Sie machten es möglich zu testen, wie sich Apps innerhalb des Betriebssystems verhalten – nicht nur, wie sie zu funktionieren scheinen. Vorsichtig formuliert: Für alles oberhalb von iOS 18 gibt es keinen öffentlich verfügbaren Jailbreak. Viele Teams fragen: Lassen sich neue iPhones überhaupt jailbreaken? Die kurze Antwort lautet nein, nicht zuverlässig. Corellium bietet Sicherheitsteams Zugang zu virtuellem iOS und iPadOS, das mit oder ohne Jailbreak bereitgestellt werden kann – einschließlich Root-Zugriff für eingehendere Inspektionstests. Das verlieren Sicherheitsteams ohne Root-Zugriff: 

  • Inspektion des Keychain und des lokalen Dateispeichers 
  • Überwachung von Live-API-Aufrufen und Laufzeitverhalten 
  • Prüfung der App-übergreifenden Kommunikation und Berechtigungen 
  • Beobachtung der Schutzmechanismen auf Kernel-Ebene in Aktion 

Simulatoren bilden die hardwaregestützten Sicherheitskontrollen, das Betriebssystemverhalten oder die Gerätebedingungen eines physischen iPhones nicht vollständig ab. Die statische Analyse kann riskanten Code und Drittkomponenten erkennen, aber nicht bestätigen, wie sich ein SDK über die Laufzeit der Anwendung verhält. Ältere gejailbreakte Geräte eignen sich noch für Legacy-Forschung, repräsentieren aber nicht die aktuellen Geräte und iOS-Versionen, die Kunden in der Produktion einsetzen. 

Damit ergibt sich ein nur unvollständiges Risikoprofil mobiler Anwendungen. Teams testen möglicherweise den Code, den sie inspizieren können, ohne das Laufzeitverhalten zu sehen, das entsteht, wenn Anwendung, Betriebssystem, Dritt-SDKs, Speicher und Netzwerkverbindungen zusammenwirken.

iOS 26 schafft gefährliche blinde Flecken

Regulierungsbehörden interessiert nicht, was eine Testsuite sagt. Sie interessiert, ob Teams nachweisen können, dass ihre App sensible Daten auf echten Geräten und unter realen Bedingungen korrekt verarbeitet. 

Da iOS 26 keine Tests auf Root-Ebene zulässt, wird dieser Nachweis schwierig bis unmöglich. Sicherheits- und Compliance-Teams verlieren die Möglichkeit zu überprüfen, ob mobile Apps auch nur die grundlegenden Anforderungen an den Datenschutz erfüllen. 

Eine eingeschränkte Laufzeit-Transparenz kann es erschweren, mobile Sicherheitskontrollen zu validieren und Nachweise zu erbringen, die für regulatorische und Prüfanforderungen relevant sind: 

  • HIPAA: Schwierigkeit zu bestätigen, dass elektronisch geschützte Gesundheitsdaten angemessen geschützt sind, wenn sie von einer mobilen App gespeichert, zwischengespeichert, übertragen oder entfernt werden. 
  • PCI DSS: Eingeschränkte Möglichkeit zu überprüfen, wie Zahlungskontodaten während der App-Ausführung verarbeitet werden – einschließlich der Frage, ob sensible Daten entgegen der Richtlinie gespeichert, übertragen, protokolliert oder offengelegt werden. 
  • GDPR / RGPD / DSGVO: Schwierigkeit zu beurteilen, ob Erhebung, Weitergabe, Speicherung und Drittverarbeitung personenbezogener Daten in der mobilen App den dokumentierten Zwecken und Datenschutzanforderungen entsprechen.  
  • CCPA: Geringere Sichtbarkeit, wie personenbezogene Informationen über eingebettete Drittanbietertechnologien erfasst, offengelegt oder geteilt werden – und ob dieses Verhalten den Verbraucherhinweisen und den Beschränkungen für Dienstleister entspricht. 
  • DORA: Lücken in den Nachweisen, mit denen Finanzunternehmen die Resilienz mobiler Anwendungen bewerten und testen, die wichtige oder kritische Geschäftsdienste unterstützen. 
  • NIS2: Schwierigkeit zu validieren, ob die Maßnahmen zum Cybersicherheits-Risikomanagement, die mobile Dienste schützen, in der Praxis wirksam sind. 
  • FISMA: Begrenzte technische Nachweise zur Bewertung von Sicherheitskontrollen, wenn eine mobile App in den Geltungsbereich eines bundesstaatlichen Informationssystems fällt. 
  • CMMC: Schwierigkeit, die Umsetzung der anwendbaren Schutzmaßnahmen nachzuweisen, wenn mobile Apps oder Geräte Federal Contract Information (FCI) oder Controlled Unclassified Information (CUI) verarbeiten, speichern oder übertragen. 

In jedem Fall beruht Compliance auf überprüfbaren Nachweisen, nicht auf Annahmen oder Vertrauen. Apples geschlossenes Ökosystem lässt Organisationen – ob sie US-, EU-, UK- oder anderen Regulierungsbehörden unterstehen – ohne unabhängige Möglichkeit, zu validieren, was auf iOS-Geräten geschieht. 

Warum es illusorisch ist, sich zur Abwehr von Bedrohungen auf den App Store zu verlassen 

Da auf den neuesten iPhones und iPads keine leicht verfügbaren Jailbreaks existieren, ist Apples Prüfprozess für viele iOS- und iPadOS-Apps zur Standard-Verteidigungslinie geworden. Apple ist kein Sicherheitsunternehmen, und sein Prüfprozess ist nicht darauf ausgelegt, die Art von Risiken zu erkennen, die sensible Informationen preisgeben. Bei Millionen jährlich eingereichter Apps ist es unrealistisch zu erwarten, dass Apple jede riskante oder bösartige App blockiert. 

Das iOS-Dilemma: Sichtbarkeit oder Verwundbarkeit

Jede Organisation, die iOS-Apps veröffentlicht, steht letztlich vor derselben Entscheidung: Wo zieht man die Grenze bei der Unterstützung von Betriebssystemversionen? 

Die meisten Unternehmens-Apps decken derzeit mehrere Versionen ab, oft iOS 15 bis iOS 26. Doch diese Spanne bringt Anbieter in ein echtes Dilemma: 

H2: Ältere Versionen unterstützen (iOS 15/16) 

  • Jailbreak-Zugang und Sichtbarkeit auf Systemebene behalten 
  • Aber Kunden bekannten, aktiv ausgenutzten Schwachstellen aussetzen 

H2: Nur aktuelle Versionen unterstützen (iOS 17+) 

  • Die Angriffsfläche durch Wegfall der Legacy-Unterstützung verkleinern 
  • Aber die Möglichkeit verlieren zu testen, wie sich die App auf echten Geräten verhält 

Es gibt keine perfekte Antwort, und welchen Weg ein Unternehmen auch wählt, es geht ein Risiko ein: 

  • Bei älteren Versionen dringen Angreifer ein. 
  • Bei neueren Versionen können Sicherheitsteams nicht überprüfen, ob die App vollständig konform und sicher ist. 

Während die meisten Organisationen ihre Mindest-Betriebssystemversion auf 17+ anheben – was sinnvoll ist –, übersehen sie oft, was sie dabei verlieren: Transparenz. Simulatoren können das Verhalten der Secure Enclave, die Speicherverwaltung oder Hardwareschutzmechanismen nicht nachbilden. Die statische Analyse kann Laufzeitprobleme oder SDK-Verhalten nicht erkennen. Ohne Tests unter realen Bedingungen kann selbst eine App, die alle Prüfungen besteht, ein verborgenes Risiko bergen. 

Hartcodierte Geheimnisse: ein kostspieliges Risiko 

Wenn Sicherheitsteams an Einblick verlieren, wird die Offenlegung sensibler Daten zu einem stillen Risiko. Hartcodierte Geheimnisse sind ein häufiger Verursacher. In einer Studie von 2025 mit über 156.000 Apps stellten Forscher fest: 

  • 71 % dieser Apps enthielten mindestens ein hartcodiertes Geheimnis, etwa API-Schlüssel, Cloud-Anmeldedaten oder Verschlüsselungsschlüssel, die direkt in den Code eingebettet waren. 
  • In diesen Apps deckten sie 815.000 einzigartige Geheimnisse auf, viele davon mit echten Produktionssystemen verknüpft. 
  • Viele Geheimnisse waren für statische Scanner unsichtbar und würden von Apples Prüfprozess wahrscheinlich nicht erkannt. 

Das ist kein theoretischer Mangel, sondern ein Sicherheitsrisiko mit großer Tragweite, das sich in aller Öffentlichkeit verbirgt. Sind Anmeldedaten offengelegt, können Angreifer: 

  • Kundendaten exfiltrieren 
  • Sich lateral in Unternehmensumgebungen bewegen 
  • Compliance-Verstöße auslösen 

Ohne Zugriff auf die in einer realen Umgebung laufende App lässt sich nicht bestätigen, ob diese Geheimnisse zur Laufzeit zugänglich sind. Im Verizon Mobile Security Report 2025 räumten 85 % der Befragten ein, dass Bedrohungen für Mobilgeräte zunehmen, und mehr als die Hälfte hatte bereits einen mobilbezogenen Sicherheitsvorfall erlebt. 

Jailbreak-Scams auf dem Vormarsch 

Die Nachfrage nach Jailbreaks ist höher denn je, und böswillige Akteure nutzen das aus. Sicherheitsforscher und -tester greifen mitunter zu unzuverlässigen Behelfslösungen: 

  • Kauf gejailbreakter iPhones bei Online-Händlern 
  • Riskante Online-Jailbreak-Tools, etwa die neuesten Versionen von nekoJB 
  • Payloads aus Foren, sozialen Medien oder inoffiziellen GitHub-Repos 

Diese Ansätze sind kurzlebig und hochriskant: 

  • Jailbreaks funktionieren ab iOS 17 nicht mehr 
  • Manche Tools sind getarnte Schadsoftware, die bösartigen Code einschleust oder ein Lieferketten-Risiko schafft 
  • Selbst legitime Jailbreaks führen oft zu Geräteinstabilität, „Bricking“ (unbrauchbares Gerät) oder Sicherheitskompromittierung 

Es bleibt kein sicherer oder nachhaltiger Jailbreak-Weg mehr.

Corellium ist der einzige Zugang, der funktioniert

Corellium ist der Weg nach vorn für Teams, die tiefen Root-Zugriff auf iOS und iPadOS benötigen. Die Plattform stellt Teams virtuelle iOS-Geräte mit echter Firmware bereit – mit tiefen Einblicken auf Systemebene und kontrolliertem Zugriff auf Konfigurationen mit und ohne Jailbreak. 

[Vergleichsgrafik im Originalbeitrag: Corellium-Virtualisierung vs. Jailbreaking physischer Geräte.] 

Anders als Jailbreaks physischer Geräte stützt sich Corellium nicht auf ausgenutzte Schwachstellen, um dieses Zugriffsniveau zu bieten. Sicherheitsteams und Regierungsbehörden weltweit nutzen Corellium, um: 

  • Das Verhalten von Apps während der Laufzeit zu analysieren – einschließlich uneingeschränktem Dateizugriff, Zugriff auf Benutzer- und Kernel-Speicher, Keychain-Speicher und Interprozesskommunikation. 
  • Das Verhalten von Dritt-SDKs zu inspizieren – während der App-Ausführung, nicht nur das statisch Deklarierte. 
  • Apps und realen iOS-Bedingungen auszuführen – zur Beobachtung, was statische Tools und Simulatoren nicht offenbaren können. 
  • Probleme im Zusammenhang mit dem Laufzeitzustand zu reproduzieren – nicht nur Quellcode-Bugs. 
  • Sicherheits- und Datenschutzkontrollen zu validieren – so, wie sie ausgeführt werden, nicht nur wie sie geschrieben sind. 

Möchten Sie mehr erfahren? Sprechen Sie mit unserem Team über die Bereitstellung von Corellium.