Executive Threat Dashboard

CVE-2026-45659 ist eine Remote-Code-Execution-Schwachstelle in Microsoft SharePoint Server (On-Premise). CISA hat die Schwachstelle Anfang Juli 2026 in den KEV-Katalog aufgenommen nach bestätigter aktiver Ausnutzung durch mehrere Angreifergruppen und US-Bundesbehörden eine Patch-Frist auf den 4. Juli 2026 gesetzt. FCEB-Behörden hatten Fixes bis zum 10. Juli 2026 durchzusetzen. On-Premise-SharePoint bleibt in DACH-Konzernen weiterhin die dominierende Kollaborationsplattform für Dokumente, Vertragsentwürfe und M&A-Materialien.

SharePoint On-Premise ist im DACH-Mittelstand und in DACH-Konzernen jene Plattform, in der zwischen Legal, Deal-Team und C-Suite die sensibelsten Dokumente ausgetauscht werden – Vertragsentwürfe, LOIs, Term-Sheets, Board-Materialien. Eine RCE auf dem SharePoint-Server bedeutet nicht Datenzugriff, sondern Kontrollzugriff: das Recht, Dokumente zu ändern, Notifications zu unterdrücken, Session-Tokens zu extrahieren. Wer die Patch-Frist des 4. Juli nicht durchziehen konnte, hat ein Dokumentations- und Haftungsproblem – nicht nur ein Patch-Problem.

SharePoint-Server-Fixes sofort einspielen (siehe Microsoft Security Update Guide für CVE-2026-45659). Alle SharePoint-Admin-Sessions seit Ende Juni auf ungewöhnliche Aktivitäten prüfen, Web-Application-Firewall-Logs auf Exploit-Muster durchsuchen. In Umgebungen mit externer SharePoint-Erreichbarkeit: bis zum verifizierten Patch-Deployment als kompromittiert behandeln.

BSI CERT-Bund hat unter WID-SEC-2026-2050 eine als kritisch (CVSS 9.3) eingestufte Sammlung von Schwachstellen im IBM WebSphere Application Server und in IBM Application Server Liberty veröffentlicht. Angreifer können durch die Schwachstellen Vertraulichkeit, Integrität und Verfügbarkeit betroffener Systeme kompromittieren; Systeme, die Web-Endpoints exponieren, sind besonders exponiert. IBM hat Fixes bereitgestellt.

WebSphere ist in DACH-Bankenlandschaften und im Enterprise-Backoffice eine ruhige, aber ubiquitäre Java-Middleware – oft nicht auf dem Patch-Radar von Vulnerability-Management-Teams, weil die Systeme intern stabil laufen. Genau diese "unauffälligen" Anwendungsserver werden zunehmend zur Angriffsfläche, weil sie Sessions, Business-Logik und häufig Datenbank-Anmeldedaten in Reichweite haben. Eine BSI-Warnung mit CVSS 9.3 auf einer WebSphere-Instanz ist ein Board-Level-Thema in jeder betroffenen Bank oder Versicherung.

Von IBM bereitgestellte Fixes für WebSphere Application Server und Liberty einspielen. Externe Web-Endpoints hinter Reverse Proxy / WAF absichern und ausgehende Verbindungen auf Ungewöhnlichkeiten prüfen. Regulierte Finanzdienstleister: BSI-Meldung und – bei betroffenen Systemen – DORA-relevante Ereignismeldung intern prüfen.

CVE-2026-48282 ist eine Path-Traversal-Schwachstelle in Adobe ColdFusion, die einem entfernten Angreifer Zugriff auf sensitive Dateien außerhalb des vorgesehenen Web-Root ermöglicht. CISA hat die Schwachstelle im Juli 2026 in den KEV-Katalog aufgenommen nach bestätigter aktiver Ausnutzung. Parallel wurden drei weitere aktiv ausgenutzte Schwachstellen (Joomla-Ökosystem: JoomShaper SP Page Builder CVE-2026-48908, Joomlack CVE-2026-56290; Langflow CVE-2026-55255) am selben Tag ergänzt.

Adobe ColdFusion läuft in DACH-Umgebungen oft in Legacy-Webportalen, Kundenauthentifizierungs-Frontends oder Formular-Servern von Banken, Behörden und Gesundheitsdienstleistern. Path Traversal bedeutet: der Angreifer liest Konfigurationen mit Datenbank-Credentials, extrahiert Session-Cookies oder platziert Web-Shells über beschreibbare Pfade. Die parallele Aufnahme von Langflow und Joomla-Komponenten zeigt: Angreifer arbeiten aktuell breit in Content-Management- und LLM-Orchestrierungs-Werkzeugen. Das ist die Kategorie, in der SBOM-Prozesse den Unterschied machen.

ColdFusion-Instanzen auf aktuelle Adobe-Patches heben und Web-Root-Berechtigungen restriktiv setzen. Aktuelle SBOM-Prozesse gegen Langflow / Joomla-Komponenten prüfen – wo diese in Toolchains eingebettet sind, aktiv patchen oder deaktivieren. Web-Application-Firewall-Regeln auf Path-Traversal-Muster (../../, encoded traversal) verschärfen.

Aktuelle Ransomware-Analysen für 2026 zeigen einen strukturellen Anstieg der durchschnittlichen Verweildauer (Dwell Time) von Angreifern in kompromittierten Systemen: 31 Tage in den Sommermonaten Juli und August, gegenüber 22 Tagen im Rest des Jahres. Die Verlängerung wird primär auf urlaubsbedingte Personalengpässe in Security-Operations-Teams und späteres Erkennen anormaler Aktivitäten zurückgeführt. Deutschland bleibt mit 82 % Anteil das dominierende Ziel im DACH-Raum (Check Point 2026); das Hasso-Plattner-Institut bestätigt Deutschland als europäisches Top-Ransomware-Ziel.

Neun zusätzliche Tage Dwell-Time sind kein statistisches Detail – sie sind neun zusätzliche Tage, in denen ein Angreifer Backups lokalisiert, Domänen-Kontrollstruktur mappt und Exfiltration priorisiert. Für Unternehmen ohne 24/7-SOC oder ohne belastbare Rufbereitschaft im Juli/August ist das der Zeitraum, in dem aus einem Foothold ein Enterprise-Vorfall wird. Der Mittelstand ist besonders exponiert, weil Vertretungsregelungen für IT-Sicherheit häufig informell sind – und weil Vorstände in der Sommerpause seltener reagieren können.

Ferienzeit-Bereitschaftsplan schriftlich fixieren: benannte Deputy-Rollen für Security-Escalation, Rufbereitschafts-SLAs, dokumentierter Kontakt zum externen Forensik-Partner. EDR-Anomalie-Alerts in dieser Periode absenken (mehr False-Positives akzeptieren). Offline-Backups verifizieren – nicht nur konfigurieren.

Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller vernetzter Produkte ab dem 11. September 2026 zur Meldung aktiv ausgenutzter Schwachstellen und schwerer Vorfälle – 24 Stunden Frühwarnung, 72 Stunden vollständige Meldung, 14 Tage Abschlussbericht. Meldungen laufen über die ENISA Single Reporting Platform. In Deutschland wird das BSI zur zentralen Marktüberwachungsbehörde (§ 65 BSIG-E) — der Bundesrat hat das CRA-Durchführungsgesetz am 12. Juni 2026 passieren lassen. Reporting-Pflichten gelten auch für bereits vor dem 11.12.2027 in Verkehr gebrachte Produkte.

Der 11. September ist der Zeitpunkt, ab dem die operative Melde-Disziplin verlangt wird – nicht die volle Konformität. Genau das macht das Zeitfenster für viele Hersteller ungemütlich: sie werden gefragt, ob ihre Prozesse Vorfälle innerhalb von 24 Stunden zu ENISA melden können, obwohl die zugrundeliegenden CRA-Anforderungen (CE-Kennzeichnung, technische Dokumentation) noch nicht vollständig umgesetzt sein müssen. Wer noch nie eine 24-Stunden-Frühwarnung testweise durchgespielt hat, wird das im Ernstfall nicht sauber schaffen.

CRA-Anwendungsbereich für das eigene Produkt-Portfolio bewerten und dokumentieren (inkl. RDPS-Test für SaaS-Komponenten). 24/72/14-Meldeprozess bis auf Board-Ebene ausrollen — Rollen benennen, Legal-Review-Fenster definieren, ENISA-Meldeweg als Playbook üben. EN 18031-Basislinie als CRA-Vorbereitung implementieren; Fragen zur CRA-Historie ab Herbst 2026 in jede M&A-Cyber-Due-Diligence einziehen.

Der Mai hat ein Muster gezeigt, das ich in meinen Gesprächen mit Vorständen immer wieder ansprechen muss: Die kritischsten aktiv ausgenutzten Schwachstellen lagen nicht in irgendeiner Schatten-IT, sondern in den Komponenten, die offiziell als „Kontrolle" geführt werden. Der Cisco Catalyst SD-WAN Controller. Ivanti EPMM, das Mobile-Device-Management. Microsoft Defender, der Endpoint-Schutz. Trend Micro Apex One, das EDR. Wer auf diese Werkzeuge als Schutz vertraut, hat im Mai 2026 einen Zustand erlebt, in dem genau diese Werkzeuge zur Angriffsfläche wurden – inklusive aktiver Ausnutzung in der Praxis.

Das eigentliche Problem ist nicht die Häufung von Schwachstellen. Das ist die Realität des Betriebs komplexer Software und wird nicht besser werden. Das Problem ist die strategische Annahme dahinter: Wenn Audit-Reports und Versicherungsfragebögen „Endpoint-Schutz: vorhanden" abhaken und damit das Restrisiko als adressiert betrachten, dann ist die nächste Stufe der Reife nicht „mehr Tools", sondern eine andere Frage: Wer prüft, ob die Tools selbst gehärtet, aktuell und unkompromittiert sind? Wenn CISA eine Drei-Tage-Patchfrist setzt – wie im Fall des Ivanti-EPMM-Zero-Days – ist das keine IT-Meldung mehr. Das ist eine Geschäftsentscheidung, weil der ungesicherte Weiterbetrieb mit bekanntem Exploit eine bewusste Risikoakzeptanz durch die Geschäftsführung darstellt, ob die Geschäftsführung das weiß oder nicht.

Meine Empfehlung für Juni: Prüfen Sie nicht, ob Ihre IT Patches einspielen kann. Prüfen Sie, ob Ihre Organisation in der Lage ist, eine Kritisch-Warnung innerhalb von 72 Stunden – und im Ausnahmefall innerhalb von 3 Tagen – durchzuziehen, inklusive Genehmigungsprozess, Kommunikation und Dokumentation. Und prüfen Sie, ob Ihre Sicherheitswerkzeuge selbst in den Patch-Zyklus eingebunden sind, nicht nur das, was sie schützen. Wenn nicht, ist das die eigentliche Schwachstelle. Und die lässt sich nicht mit einem weiteren Tool beheben.

Die geopolitische Unsicherheit des ersten Quartals 2026 hat eine paradoxe Situation erzeugt: Unternehmen, die angesichts wirtschaftlicher Unsicherheit Budgets kürzen, tun das häufig zuerst bei Sicherheitsausgaben – während genau diese Unsicherheit die Angriffsfläche dramatisch vergrößert. Staatlich gesteuerte Akteure nutzen wirtschaftliche Instabilität gezielt aus, weil sie wissen, dass Unternehmen in Konsolidierungsphasen organisatorisch und technisch verwundbarer werden.

Hinzu kommt ein strukturelles Problem: In einem Umfeld steigender Finanzierungskosten und rückläufiger Bewertungsmultiplikatoren gerät IT-Security in Budgetverhandlungen systematisch unter Druck. Die klassische Argumentation – „wir investieren in Security, weil wir es müssen" – verfängt in Board-Diskussionen über Kostensenkung immer weniger. Was verfängt: die Sprache der Werterhaltung. Ein nicht behobenes Sicherheitsrisiko ist kein IT-Problem. Es ist ein Abwertungsrisiko für das Unternehmen – und das ist genau die Sprache, die PE-Investoren und Kreditgeber sprechen.

Meine Empfehlung für April: Wenn Sie in einem Budget-Review-Gespräch sitzen und Security-Ausgaben verteidigen müssen – rahmen Sie die Frage nicht als Kostendebatte, sondern als Bewertungsfrage. Ein ungesichertes Unternehmen wird bei der nächsten Due Diligence abgewertet. Das ist keine Theorie – das ist der Markt, der seit 2024 Sicherheitsreife systematisch bepreist.

In den letzten Wochen führe ich auffällig viele Gespräche mit Geschäftsführern, die dasselbe sagen: „Das macht meine IT." Wenn es um NIS2 geht. Wenn es um Lieferkettensicherheit geht. Wenn es um Incident Response geht. Und jedes Mal denke ich: Das ist das eigentliche Risiko.

NIS2 ist kein Technik-Gesetz. Es ist ein Governance-Gesetz. Es regelt, wer persönlich haftet, wenn ein Unternehmen seiner Sorgfaltspflicht nicht nachkommt – und das ist nicht der IT-Leiter. Die erste Welle der BSI-Bußgeldverfahren, die wir gerade sehen, richtet sich gezielt gegen Unternehmen, bei denen die Geschäftsführung nachweislich keine Kenntnis von den eigenen Sicherheitsprozessen hatte. Das ist keine Fahrlässigkeit. Das ist Gleichgültigkeit vor dem Gesetz.

Meine Empfehlung für den März: Setzen Sie sich mit Ihrer IT zusammen und beantworten Sie drei Fragen schriftlich: (1) Was würde in unserem Unternehmen passieren, wenn wir morgen einen Ransomware-Angriff erleben? (2) Wer ist verantwortlich, das BSI zu informieren, und in welchem Zeitfenster? (3) Können wir das belegen? Wenn Sie auf eine dieser Fragen keine klare Antwort haben – sprechen Sie mit uns.