Mittwoch, 30. September 2026. Auf dem Patch-Board steht ein Eintrag, der aussieht wie hundert andere. Apple, CoreGraphics, Out-of-Bounds Write. Daneben ein Datum: Freitag, 2. Oktober 2026.

Das Datum stammt aus dem KEV-Katalog der US-Behörde CISA. Wie viele Tage bleiben? Drei, nach Redaktionsrechnung: 30. September, 1. Oktober, 2. Oktober. Das ist unsere Zählung, kein CISA-Wortlaut. CISA nennt das Datum, nicht die Tage.

Drei Tage klingen nach einem Fenster. Sind sie nicht. Ohne Triage-Checkliste ist das Hoffnung mit Kalendereintrag.

Denn der Patch von Apple beantwortet eine Frage: Ist die Lücke ab Installation zu? Laut Hersteller wurde das Problem mit verbesserter Grenzprüfung behoben („improved bounds checking“). Die andere Frage lässt der Patch offen: Ist bei den Personen, um die es geht, schon vor dem Update etwas passiert?

Dieser Text auf digital-magazin.de behandelt die zweite Frage. Organisatorisch, nicht technisch. Keine Anleitung, keine Details zur Lücke, keine Nachstellung. Es geht um Zuständigkeiten, Listen und Termine. Langweilig? Ja. Dafür überlebt es den Freitag.

Der KEV-Eintrag: Was CISA sagt und was nicht

Der Alert trägt das Release Date 29. September 2026. Laut dem CISA-Alert zur neuen Katalogaufnahme wurde eine Schwachstelle in den Katalog bekannter ausgenutzter Schwachstellen aufgenommen, „based on evidence of active exploitation“. Auf Deutsch: aufgrund von Belegen für aktive Ausnutzung. Der Eintrag heißt CVE-2026-86950, Apple Multiple Products Out-of-Bounds Write Vulnerability.

Das ist die Aussage. Ein Eintrag, ein Beleg, eine Bezeichnung.

Dazu liefert CISA einen Satz über den Schwachstellentyp. Sinngemäß: Diese Art von Lücke sei ein häufiger Angriffsvektor für böswillige Akteure und berge deutliche Risiken für die Bundesverwaltung. Spoiler für Eilige: Das ist eine Aussage über eine Klasse von Fehlern. Kein Beweis für ein konkretes zweites Opfer. Wer daraus eine Opferzahl liest, liest zu viel.

Was der Alert nicht enthält: Namen, Zahlen, Branchen, Zeiträume. Wer betroffen war, wie viele, seit wann. Dazu steht dort nichts. Alles Weitere wäre Spekulation. Wir spekulieren nicht. Wir planen.

Das Pikante daran: Der Alert ist kurz, die Folgen sind lang. Für Bundesbehörden in den USA ist ein KEV-Eintrag ein Arbeitsauftrag mit Datum. Für alle anderen ist er ein Signal, die eigene Reihenfolge zu prüfen. Wer die Reihenfolge nie festgelegt hat, entscheidet am Donnerstagabend nach Bauchgefühl. Bauchgefühl ist kein Prozess.

Zur Einordnung solcher Meldungen lohnt der Blick darauf, wie eine KEV-Priorisierung im Alltag aussieht. Das hat digital-magazin.de bereits aufgegriffen. Hier zählt der Einzelfall: eine Apple-Lücke, eine Frist, ein Board.

Katalogeintrag: Frist, Triage-Feld und die Produktfrage

Der KEV-Katalog (catalogVersion 2026.09.29, veröffentlicht am 29. September 2026) bestätigt die Eckdaten des Alerts. Hinzugefügt am 29. September 2026. Frist: 2. Oktober 2026. Hersteller: Apple. Produkt: „Multiple Products“. Schwächetyp: CWE-787, also ein Out-of-Bounds Write.

Zwei Felder verdienen einen zweiten Blick.

forensicTriage: Yes. Ein Katalogfeld. Es markiert, dass für diesen Eintrag Triage-Erwartungen gelten. Es ist keine Anleitung und in diesem Text auch keine.
knownRansomwareCampaignUse: Unknown. Unbekannt heißt unbekannt. Nicht „nein“, nicht „ja“. Wer daraus Entwarnung liest, ist wenig überraschend zu optimistisch.

Die Kurzbeschreibung im Katalog: iOS, macOS und iPadOS enthalten eine Out-of-Bounds-Write-Schwachstelle in CoreGraphics, die zu beliebiger Codeausführung führen kann. Merken Sie sich das Wort macOS. Es kommt gleich noch einmal vor.

Die geforderte Maßnahme lautet sinngemäß: Mitigations gemäß Herstelleranweisung anwenden, im Einklang mit BOD 26-04 und den dort genannten Erwartungen an die Forensics-Triage. Sind keine Mitigations verfügbar, gelten die Vorgaben der BOD 26-04 für Cloud-Dienste, oder das Produkt wird nicht weiter genutzt. Außerdem bewerten Betreiber die Internet-Exposition jedes Assets. Das sind Erwartungen, keine Untersuchungsrezepte. Ein solches Rezept steht dort nicht, und hier steht auch keins.

Drei Plattformen im Katalog, zwei im Dokument

Der Katalog nennt iOS, macOS und iPadOS. Das hier zitierte Apple-Dokument trägt den Titel „About the security content of iOS 26.7.1 and iPadOS 26.7.1“. Es geht darin also um iPhone und iPad. Für Macs nennt dieses Dokument keine Version. Wir nennen deshalb keine macOS-Nummer und erfinden auch keine.

Für Ihr Inventar heißt das: Macs stehen als eigene Zeile mit der Aufgabe „Herstellerangabe prüfen“. Als Aufgabe, nicht als Vermutung. Wer nur auf iPhones schaut, hat die Macs im Rücken. Wer nur auf Freitag schaut, hat die Produktfrage nicht beantwortet.

Apple und CoreGraphics: Was im Security-Dokument steht

Das Security-Dokument von Apple zu iOS 26.7.1 und iPadOS 26.7.1 ist auf den 28. September 2026 datiert, Release am selben Tag. Es erschien also einen Tag vor dem CISA-Alert. Im Abschnitt CoreGraphics nennt der Hersteller die Geräte, für die das Update verfügbar ist:

iPhone 11 und neuer
iPad Pro 12,9 Zoll ab der 3. Generation
iPad Pro 11 Zoll ab der 1. Generation
iPad Air ab der 3. Generation
iPad ab der 8. Generation
iPad mini ab der 5. Generation

Als Auswirkung nennt Apple: Das Verarbeiten einer manipulierten Datei kann zu beliebiger Codeausführung führen. Mehr steht dazu nicht im Dokument. Weitere technische Einzelheiten nennen wir bewusst nicht. Für die Triage brauchen Sie sie nicht.

Der brisante Satz kommt danach. Apple sei ein Bericht bekannt, wonach dieses Problem in einem „extremely sophisticated attack“ gegen „specific targeted individuals“ ausgenutzt worden sein könnte, auf iOS-Versionen vor iOS 27. Das ist die Formulierung des Herstellers, nicht unsere.

Beachten Sie, was dort nicht steht: keine Berufsgruppen, keine Länder, keine Zahl. „Specific targeted individuals“, also bestimmte, gezielt angegriffene Einzelpersonen. Mehr sagt der Hersteller nicht. Alles, was wir weiter unten über Führungsebene, Journalistinnen und Journalisten und Legal schreiben, ist ein Szenario der Redaktion. Es ist keine Opferliste.

Zum Fix: Der Hersteller schreibt, ein Out-of-Bounds-Write-Problem sei mit verbesserter Grenzprüfung behoben worden. Die Credit-Zeile lautet: CVE-2026-86950, Meta Product Security. Das war es zum Credit.

Ein Wort zum Kontext. Nach eigener Angabe bestätigt Apple Sicherheitsprobleme erst, wenn sie untersucht sind und ein Patch bereitsteht. Das ist Herstellerroutine, keine Verschwörung. Es erklärt nur, warum ein Dokument wie dieses erst mit dem Fix erscheint. Wann die Ausnutzung begann, sagt es nicht.

Und die Geräte, die nicht in der Liste stehen? Dazu sagt das Dokument nichts. Sie kommen ins Inventar als eigener Punkt: Wer entscheidet, was mit ihnen geschieht? Ohne Antwort ist das ein Risiko mit Kaffeetasse.

Plot Twist: Der Patch schließt nach vorn

Jetzt zum Clou. Ein Update auf 26.7.1 schließt die Lücke ab dem Zeitpunkt der Installation. Ein Schloss, das nach vorn hält.

Über die Zeit davor sagt es nichts. Der Hersteller schreibt, die Lücke könnte auf Versionen vor iOS 27 ausgenutzt worden sein. CISA schreibt, es gebe Belege für aktive Ausnutzung. Keiner der beiden Sätze datiert das für Ihr Gerät. Beide lassen die Zeit vor dem Update offen.

Das ist der Plot Twist: Der Patch beantwortet zuerst die falsche Frage. Wer am Freitag „grün“ meldet, meldet: Version erreicht. Nicht: nichts passiert. Grün ist ein Versionsstand, kein Gesundheitszeugnis.

Die BOD 26-04 verlangt deshalb neben Tempo auch Basiserwartungen zur Frage, ob Angreifende das System vor dem Patch kompromittiert hatten. Compromise-vor-Patch. Organisatorisch übersetzt: kein Kommando, sondern ein Auftrag mit Namen und Datum.

Das bedeutet zwei Spalten statt einer. Spalte eins: gepatcht ja oder nein. Spalte zwei: Prüfung der Zeit davor beauftragt ja oder nein, durch wen, bis wann. Bleibt Spalte zwei leer, ist Spalte eins die halbe Wahrheit.

Wenig überraschend ist Spalte zwei genau die Spalte, die in Ticketsystemen nicht existiert. Ticket „iOS-Update ausrollen“, Status „erledigt“. Niemand hat gefragt. Niemand wurde beauftragt. Ein Vorfall, falls es einen gibt, schläft weiter.

Dazu kommt: Der Versionsstand ist nur ein Teil des Gerätezustands. Wer den Gerätezustand ernst nimmt, wie es das Zero-Trust-Denken mit Blick auf Gerätezustand und MDM verlangt, führt im Inventar mehr als eine Zahl. Die CoreGraphics-Lücke ist dafür ein brauchbarer Anlass.

BOD 26-04: Pflicht für Behörden, Einladung für alle anderen

KEV: Smartphones mit dem Display nach unten in einer Schublade — Geräteinventar ohne lesbare Labels (Symbolbild)

Laut CISA trägt die Direktive den Titel „Prioritizing Security Updates Based on Risk“. Sie legt Anforderungen an das Schwachstellenmanagement für zivile Bundesbehörden der USA fest (Federal Civilian Executive Branch, FCEB). Verpflichtend ist sie nur dort.

Inhaltlich, so CISA: Die Direktive stärkt die Rolle des KEV-Katalogs und verlangt, hochriskante Schwachstellen schnell zu beheben. Gemeint sind konkret CVEs aus dem KEV-Katalog auf öffentlich exponierten Assets, die nach einer Ausnutzung die volle Kontrolle über das Asset gewähren. Weniger riskante Lücken werden zurückgestellt. Zusätzlich legt die Direktive Basiserwartungen fest, wann Behörden prüfen müssen, ob Angreifende das System vor dem Patch kompromittiert haben.

Und alle anderen? CISA ermuntert ausdrücklich alle Organisationen, risikobasiertes Schwachstellenmanagement zu übernehmen und Katalogeinträge vorrangig zu beheben. Eine Empfehlung. Keine Pflicht.

Der Clou liegt im Priorisierungssatz. Er zielt auf öffentlich exponierte Assets mit totaler Kontrolle nach Ausnutzung. Ein iPhone in der Jackentasche ist nicht automatisch dieser Satz. Man kann darüber streiten, wie „öffentlich exponiert“ ein Mobilgerät ist.

Der CoreGraphics-Eintrag streitet nicht. Er nennt ein Datum und verweist auf die BOD 26-04. Betreiber sollen außerdem die Internet-Exposition jedes Assets bewerten. Bewerten, nicht abhaken.

Der Unterschied zwischen Direktiven-Logik und Katalogdatum ist deshalb ein Bewertungsauftrag. Kein Freibrief zum Liegenlassen. Wer sagt „ist ja kein exponiertes Asset“, muss das Gerät bewertet haben: schriftlich, mit Namen, mit Datum. Sonst bleibt eine Ausrede mit Aktenzeichen.

DACH-Szenario: Das Tier, das auf dem Board fehlt

Ab hier arbeiten wir mit einem Szenario der Redaktion. Es ist ausdrücklich keine Aussage des Herstellers und keine Opferliste. Nehmen wir eine mittelgroße Organisation in Deutschland, Österreich oder der Schweiz. Ein MDM verwaltet die iPhones und iPads der Organisation. Die Masse gehört zu Vertrieb, Logistik und Verwaltung. Eine kleine Gruppe besteht aus der Führungsebene (Execs), aus Journalistinnen und Journalisten und aus Legal.

Warum diese Gruppen? Redaktionsannahme: Ihre Geräte tragen Inhalte, die für Dritte interessant sind. Belegt ist das durch den Hersteller nicht. Apple sagt nur „specific targeted individuals“. Das Szenario ist ein Denkwerkzeug, kein Befund.

Eine erfundene Szene zur Veranschaulichung. Donnerstag, 17:40 Uhr. Das Dashboard zeigt einen grünen Balken, fast voll. Die Bereichsleitung ist zufrieden. Die Restlichen sind unterwegs, im Flugmodus, im Nachtzug, in Terminen. In unserem Szenario sind es ausgerechnet die Geräte mit dem vollsten Kalender.

Die Masse zu patchen ist Routine. MDM, Push, Rollout-Ringe. Die Zielpersonen zu erreichen ist Organisation: Termin, Vertretung, Vertrauen. Wer die Masse patcht und die Zielpersonen aus dem Blick verliert, meldet den Rollout als erledigt und hat die Geräte mit dem vollsten Kalender trotzdem offen.

Deshalb braucht es ein eigenes Tier auf dem Patch-Board. Es hat einen Namen, einen MDM-Ring, eine verantwortliche Person und eine eigene Frist: Freitag, 2. Oktober 2026. Eskalationspunkt bei Nichterreichen ist Donnerstagmittag. Nicht Freitag, 16:55 Uhr.

Apple-Geräte sind in Organisationen längst Alltag, und ihr Schutz reicht bis in hochsichere Arbeitsumgebungen. Einen Einblick gibt der Beitrag zu Apple-Geräten in Organisationen mit hohem Schutzbedarf. Für den heutigen Fall gilt: Geräte im Tier sind keine Sonderwünsche, sondern der Kern der Aufgabe.

Ein organisatorischer Hinweis noch: Ein Inventar, das Personen und Geräte verknüpft, berührt Datenschutz und Mitbestimmung. Beziehen Sie beide früh ein, am besten Donnerstag früh statt Freitag spät. Das ist keine Rechtsberatung, sondern Terminlogik.

Und die Menschen selbst? Wer als Execs oder Legal ein Gerät abgeben soll, fragt zu Recht nach dem Grund. Die Antwort sollte ehrlich und kurz sein: Hersteller und CISA melden Ausnutzung, wir schließen die Lücke und klären, ob davor etwas war. Kein Drama, kein Schweigen. Vertrauen ist hier Teil der Patch-Strategie.

Die Triage-Checkliste bis Freitag

Die folgende Liste ist organisatorisch. Sie beschreibt Fragen an Ihre eigene Organisation, keine Handgriffe am Gerät. Jede Zeile hat drei mögliche Antworten: ja, nein, unbekannt. Unbekannt zählt als nein.

Asset-Tier benannt: ja oder nein. Steht auf dem Board ein eigenes Tier für die Geräte der Zielgruppe? Ohne Namen keine Zuständigkeit, ohne Zuständigkeit keine Frist.
MDM-Ring benannt. Welcher Ring im MDM bildet das Tier ab? Wer darf ihn ändern, wer beobachtet ihn? Ein Ring ohne Besitzer ist ein Gerücht.
Zielstand erreicht. Erreicht die installierte Version den gefixten Stand 26.7.1? Der Abgleich läuft gegen das MDM-Inventar. Kein Forensik-Kommando, nur der Vergleich zweier Listen. Macs und Geräte außerhalb der Apple-Liste stehen separat.
Personengruppe inventarisiert. Sind Execs, Journalistinnen und Journalisten und Legal namentlich einem Gerät zugeordnet? Ohne Zuordnung bleibt „die Zielpersonen schützen“ ein Wunsch.
Auftrag vor dem Patch. Existiert für die Zeit vor dem Update ein Auftrag: wer schaut, bis wann? Quelle ist das MDM-Inventar. Ein Auftrag hat einen Namen und ein Datum, sonst ist es ein Vorsatz.
Eskalation an Legal und Kommunikation. Wer entscheidet, ob und wann intern oder extern informiert wird? Legal ist hier doppelt beteiligt: als betroffene Gruppe und als Instanz. Wenigstens sind die Zuständigen schon im Raum.

Mittwoch: Tier und Ring benennen

Heute, am 30. September 2026, geht es um Benennung. Tier festlegen, Ring festlegen, verantwortliche Person festlegen. Kein Rollout, kein Aktionismus. Wer das heute nicht schafft, hat morgen zwei Probleme.

Parallel entsteht die Personenliste. Sie ist vertraulich zu behandeln und knapp zu halten. Zu viele Namen verwässern das Tier, zu wenige lassen Zielpersonen durchrutschen.

Donnerstag: Lücken schließen, Ausnahmen dokumentieren

Am Donnerstag geht es um die Differenz. Welche Geräte im Tier haben 26.7.1 noch nicht? Warum nicht? Wer holt sie ab, wann, mit wem? Jede Ausnahme bekommt eine Begründung und einen zweiten Termin. „Ist im Urlaub“ ist ein Grund. „Wissen wir nicht“ ist ein Befund.

Der Auftrag für die Zeit vor dem Patch wird ebenfalls Donnerstag vergeben, nicht erst nach Rollout. Sonst wird das Ergebnis der Checkliste ein sauberes Board und eine ungeklärte Vergangenheit.

Freitag: melden, was wahr ist

Am Freitag, dem 2. Oktober 2026, melden Sie zwei Zahlen. Wie viele Geräte des Tiers haben den Zielstand? Wie viele Aufträge für die Zeit davor sind vergeben, wie viele abgeschlossen? Die zweite Zahl ist unbequem. Sie ist die ehrlichere.

Und wenn der Freitag nicht reicht? Dann steht im Bericht, was fehlt, warum, und bis wann es nachgeholt wird. Ein KEV-Termin, der offen verfehlt und dokumentiert wird, ist besser als einer, der leise verschwindet.

Das Exposure-Inventar: Fünf Spalten, keine Technik

Die Checkliste steht und fällt mit einem Inventar. Nicht mit dem großen Inventar aller Geräte, sondern mit dem kleinen, scharfen für die Personen im Tier. Fünf Spalten reichen.

Person und Rolle. Wer trägt das Gerät, in welcher Funktion? Vertraulich geführt, mit klar begrenztem Leserkreis.
Gerät. Modell und Zuordnung im MDM. Damit lässt sich klären, ob das Gerät in der Apple-Liste zu 26.7.1 steht.
Ring. Welchem MDM-Ring gehört das Gerät an? So bleibt sichtbar, wer Änderungen auslösen kann.
Version. Der laut MDM erfasste Stand. Erreicht er 26.7.1, ja oder nein? Die Quelle ist das Inventar, nicht ein Bauchgefühl.
Auftrag. Wer schaut auf die Zeit vor dem Patch, bis wann, mit welchem Ergebnisvermerk? Diese Spalte ist die unbeliebteste. Sie ist die wichtigste.

Die Spalte „Auftrag“ enthält keine Methode. Wie eine Prüfung im Einzelnen abläuft, gehört in Ihre Incident-Prozesse und zu den dafür zuständigen Stellen. Dieser Text beschreibt bewusst nur, dass es einen Auftrag geben muss.

Schatten-IT ist der natürliche Feind dieser Tabelle. Private Geräte mit Firmenzugang, vergessene Zweitgeräte, Leihgeräte aus der Schublade: Alles, was nicht im Inventar steht, steht auch nicht auf dem Board. Wie solche blinde Flecken im Inventar entstehen, ist bekannt. Bei einer Frist von drei Tagen (Redaktionsrechnung) bleibt keine Zeit für Überraschungen, also fragen Sie heute nach.

Ein letzter Punkt: Das Inventar ist ein Arbeitsdokument, kein Trophäenregal. Es gehört nach Freitag nicht in die Schublade, sondern in den nächsten KEV-Fall. Der kommt. Fragt sich nur, ob mit oder ohne Tabelle.

Freitag beantwortet die Vergangenheit nicht

Trockene Einschätzung. Der Freitag, 2. Oktober 2026, ist ein Termin für die Gegenwart. Bis dahin sollen die Geräte den Zielstand haben. Das ist machbar, wenn die Zuständigkeiten stehen. Es ist unmöglich, wenn Sie erst am Donnerstagabend fragen, wem das Tier gehört.

Die Vergangenheit hat kein Datum im Katalog. Weder CISA noch Apple sagen, wann die Ausnutzung begann, wen sie traf oder ob Ihre Organisation dazugehört. Der Hersteller spricht von gezielten Angriffen auf bestimmte Einzelpersonen. CISA spricht von Belegen für aktive Ausnutzung. Das reicht, um einen Auftrag zu vergeben. Es reicht nicht, um Entwarnung zu geben.

Darum bleibt die Bilanz nüchtern. Die CoreGraphics-Lücke ist geschlossen, sobald 26.7.1 installiert ist. Ob davor etwas geschah, klärt kein Update. Das klären Menschen mit Aufträgen. Wer die Aufträge nicht vergibt, hat am Freitag ein grünes Board und eine offene Frage.

Der Plot Twist bleibt also der Alltag: Nicht der Patch ist das Problem, sondern das Schweigen danach. Und Schweigen lässt sich verhindern. Mit einer Liste, einem Namen und einem Datum.