Ein Stichtag, der die Frage verschiebt

Am 14. Juli 2026 sind für SharePoint Server 2016 und SharePoint Server 2019 zwei Dinge zusammengefallen. Microsoft hat an diesem Tag Sicherheitsupdates ausgeliefert, unter anderem für Lücken, die bereits aktiv angegriffen werden. Und am selben Tag endete nach dem Microsoft-Lifecycle der Support für genau diese beiden Versionen.

Das ist die eigentliche Nachricht — nicht die einzelne Schwachstelle. Wir haben in den vergangenen Wochen bereits über SharePoint-Lücken berichtet, und in beiden Fällen lautete die Antwort: patchen. Diese Antwort steht ab jetzt nicht mehr zur Verfügung. Die Updates vom 14. Juli waren für 2016 und 2019 die letzten. Jede Schwachstelle, die von nun an in diesen Versionen gefunden wird, bleibt dort dauerhaft offen — unabhängig davon, wie kritisch sie ist und wie breit sie ausgenutzt wird.

Damit lautet die Frage nicht mehr „patchen oder nicht", sondern: migrieren oder abschotten.

Die Entwarnung gleich vorweg, weil sie für die meisten Leserinnen und Leser die entscheidende ist: Betroffen ist ausschließlich SharePoint Server als selbst betriebene Installation im eigenen Haus. SharePoint Online als Teil von Microsoft 365 ist nicht betroffen und wird von Microsoft unverändert weiter gewartet. Wer sein Portal aus der Cloud bezieht, muss hier nichts tun.

Auf einen Blick

  • Der Stichtag: Nach dem Microsoft-Lifecycle endete der Support für SharePoint Server 2016 und SharePoint Server 2019 am 14. Juli 2026. Die Updates dieses Tages waren die letzten für beide Versionen.
  • Kein ESU: Für SharePoint Server 2016 und 2019 gibt es kein Programm für erweiterte Sicherheitsupdates — anders als bei Windows 10. Es gibt keine bezahlbare Verlängerung, auch keine stille.
  • Der einzige On-Premises-Weg nach vorn: die SharePoint Server Subscription Edition. Sie hat im Lifecycle kein Enddatum und erhält weiter Updates.
  • Aktive Angriffe: Die US-Behörde CISA führt in ihrer Warnung vom 16. Juli vier SharePoint-Schwachstellen als aktiv ausgenutzt: CVE-2026-32201, CVE-2026-45659, CVE-2026-56164 und CVE-2026-58644. Eine fünfte, CVE-2026-55040, ist offengelegt, wird nach aktuellem Stand aber noch nicht ausgenutzt.
  • Patchen allein genügt nicht: Laut CISA stehlen Angreifer bei erfolgreichen Zugriffen unter anderem die IIS-Machine-Keys des Servers und richten sich dauerhaft ein. Ein Update entfernt einen bereits gewonnenen Zugang nicht.
  • Nicht betroffen: SharePoint Online / Microsoft 365.

Warum „kein ESU" hier den Unterschied macht

Beim Support-Ende von Windows 10 hat sich eine Erwartung eingeschliffen: Wenn der reguläre Support endet, gibt es notfalls ein kostenpflichtiges Programm für erweiterte Sicherheitsupdates, das noch ein bis drei Jahre Luft verschafft. Diese Erwartung ist hier falsch, und die Verwechslung ist teuer.

Für SharePoint Server 2016 und 2019 existiert kein solches Programm. Der Lifecycle nennt für beide Versionen den 14. Juli 2026 als Enddatum — und danach nichts mehr. Kein Übergangsjahr, keine Verlängerung gegen Aufpreis. Wer heute noch auf 2016 oder 2019 läuft, hat ab sofort einen Server im Netz, dessen Sicherheitsstand eingefroren ist.

Die Server arbeiten dabei ganz normal weiter. Das Portal ist erreichbar, Dokumente lassen sich öffnen und ablegen, im Alltag ändert sich nichts Sichtbares. Was endet, ist nicht der Betrieb, sondern die Absicherung. Der Unterschied zeigt sich erst über die Zeit: Bei einem unterstützten System werden gefundene Lücken nach und nach geschlossen. Bei einem System ohne Patch-Pfad sammeln sie sich. Die Angriffsfläche wächst nicht schlagartig, aber stetig — und sie schließt sich nicht wieder.

Im Lifecycle ohne Enddatum steht nur die SharePoint Server Subscription Edition. Sie ist der On-Premises-Nachfolger und bekommt weiterhin Updates. Wer sein Portal im eigenen Haus behalten will, für den führt der Weg dorthin. Wer es abgeben kann, für den ist SharePoint Online die Alternative.

Vier Lücken, die bereits ausgenutzt werden

In ihrer Warnung vom 16. Juli 2026 führt die CISA vier SharePoint-Schwachstellen auf, die in laufenden Angriffen verwendet werden. Sie stehen dort nebeneinander, jede für sich in den Katalog aktiv ausgenutzter Schwachstellen aufgenommen — zu unterschiedlichen Zeitpunkten: CVE-2026-32201 im April, CVE-2026-45659 Anfang Juli, CVE-2026-56164 am 14. Juli und CVE-2026-58644 am 16. Juli. Zwei davon verdienen einen genaueren Blick, weil sie jeweils etwas über den Umgang mit solchen Meldungen zeigen.

CVE-2026-56164 ist ein Beispiel dafür, dass sich offizielle Quellen widersprechen können. Das US-amerikanische NIST führt die Lücke in seiner Schwachstellendatenbank mit einem Schweregrad von 9,8 von 10 und der Einstufung „kritisch". Microsoft bewertet dieselbe Lücke mit 5,3 und „mittel". Beide Angaben sind offiziell, und der Abstand ist erheblich — je nachdem, welche Quelle ein Unternehmen liest, landet dieselbe Schwachstelle in der Warteschlange ganz oben oder weit unten. Die Praxis entscheidet die Frage: Die Lücke wird nachweislich ausgenutzt. Wer nach Schweregrad priorisiert, sollte hier die höhere Einstufung ansetzen. Ob der Patch drin ist, lässt sich am Build ablesen — geschlossen ist die Lücke ab Build 16.0.5561.1001 (2016), 16.0.10417.20175 (2019) und 16.0.19725.20434 (Subscription Edition).

CVE-2026-58644 ist ein Fehler bei der Deserialisierung nicht vertrauenswürdiger Daten und ermöglicht die Ausführung fremden Programmcodes auf dem Server. Microsoft bewertet die Lücke selbst mit 9,8 von 10 als kritisch und führt sie als aktiv ausgenutzt; öffentlich beschrieben wurde sie vor der Ausnutzung nicht. Interessant ist hier die Zeitachse — und sie spricht ausdrücklich für Patch-Disziplin: Der Fix wurde laut Microsoft bereits mit den Juni-Updates ausgeliefert, die zugehörige CVE-Meldung war in der Juni-Dokumentation nur versehentlich nicht enthalten und wurde nachgetragen. Anders gesagt: Wer im Juni regulär gepatcht hat, war gegen diese Lücke bereits geschützt, bevor sie überhaupt bekannt war. Nicht jeder Schutz kündigt sich an. Genau das ist der Wert eines laufenden Update-Prozesses gegenüber dem Reagieren auf Schlagzeilen. Sicherheitsupdates liegen für alle drei Versionen vor — für 2016, 2019 und die Subscription Edition.

Warum Patchen allein nicht reicht

Der zweite Kernpunkt der CISA-Warnung wird leicht überlesen, ist aber für betroffene Betriebe der wichtigere. Ein Update schließt eine Tür. Es entfernt niemanden, der schon im Haus ist.

Laut CISA holen sich Angreifer bei erfolgreichen Zugriffen auf SharePoint-Server unter anderem die IIS-Machine-Keys — kryptografische Schlüssel, mit denen der Server unter anderem prüft, ob Anfragen echt sind. Wer diese Schlüssel besitzt, kann gültig aussehende Anfragen selbst erzeugen und braucht die ursprüngliche Lücke nicht mehr. Dazu kommen Techniken zur dauerhaften Einnistung und nachgeladene Schadsoftware. Ein Server, der vor dem Patch bereits kompromittiert wurde, bleibt es also auch danach.

Daraus folgt eine Reihenfolge, die CISA ausdrücklich betont und die man leicht falsch herum macht: Erst nach Spuren eines Einbruchs und nach Werkzeugen suchen, die Schlüssel abgreifen — und diese beseitigen. Dann die Machine-Keys rotieren. Wer sofort rotiert, ohne vorher aufzuräumen, verteilt nur frische Schlüssel an einen Angreifer, der noch mitliest.

Zur Absicherung nennt die CISA weiter: die Installation der Updates tatsächlich verifizieren statt sie nur anzustoßen; die AMSI-Integration je Webanwendung aktivieren, wo es möglich ist im vollen Modus mit Prüfung des Anfrage-Inhalts; SharePoint nicht direkt aus dem Internet erreichbar machen, und wo externer Zugriff nötig ist, ihn über einen vorgelagerten Reverse-Proxy mit Authentifizierung führen; externen Zugriff auf die Zentraladministration vollständig sperren; und die Kommunikation zwischen Farm- und Datenbankservern auf die Systeme begrenzen, die sie wirklich brauchen.

Was Sie jetzt tun sollten

Für 2016 und 2019 ist die Liste kurz, aber sie duldet keinen Aufschub:

  • Bestand feststellen. Die erste Frage ist die einfachste und wird trotzdem oft nicht beantwortet: Läuft bei Ihnen ein SharePoint Server im eigenen Haus, und in welcher Version? Nur On-Premises-Installationen sind betroffen. Wer ausschließlich SharePoint Online über Microsoft 365 nutzt, ist an dieser Stelle fertig.
  • Den letzten Patch einspielen — und die Installation verifizieren. Die Updates vom 14. Juli sind für 2016 und 2019 der Endstand. Prüfen Sie anhand des Builds, ob sie tatsächlich aktiv sind, statt sich auf die Meldung des Update-Vorgangs zu verlassen. Diesen Stand können Sie nicht mehr nachholen, wenn Sie ihn verpassen.
  • Auf Kompromittierung prüfen, nicht nur patchen. Bei einem Server, der zuletzt aus dem Internet erreichbar war und Update-Rückstand hatte, gehört die Suche nach Einbruchsspuren zum Pflichtprogramm — vor jeder Schlüsselrotation. Ein sauberer Patch-Stand ist kein Nachweis, dass nichts passiert ist.
  • Die Erreichbarkeit aus dem Internet beenden. Ein Server ohne Patch-Pfad hat im offenen Netz nichts verloren. Wo externer Zugriff fachlich nötig bleibt, gehört er hinter eine vorgelagerte Authentifizierung; der Zugriff auf die Zentraladministration von außen wird gesperrt.
  • Die Migration terminieren, nicht vertagen. Zwei unterstützte Wege stehen offen: die SharePoint Server Subscription Edition, wenn das Portal im Haus bleiben soll, oder SharePoint Online, wenn Sie Betrieb und Updates abgeben wollen. Ein Versionswechsel bei SharePoint ist kein Knopfdruck — Inhalte, Berechtigungen und gewachsene Strukturen müssen geordnet übernommen werden. Deshalb braucht er ein Datum, keinen guten Vorsatz. Alles zwischen jetzt und diesem Datum ist Abschottung auf Zeit.

Fazit

Support-Ende und aktive Angriffe am selben Tag — das ist die unangenehme Kombination, die aus einem planbaren Termin einen Handlungsdruck macht. Der entscheidende Satz ist trotzdem nicht der über die einzelne Lücke, sondern der über den Kalender: Für SharePoint Server 2016 und 2019 gibt es ab jetzt keine Sicherheitsupdates mehr, und es gibt kein ESU-Programm, das das auffängt. Was bleibt, ist die Wahl zwischen einem geplanten Wechsel und einem Server, der still älter wird, während sich seine offenen Punkte sammeln.

Der Fall zeigt daneben zwei Dinge, die über SharePoint hinausreichen. Erstens: Ein laufender Update-Prozess schützt auch vor dem, was noch niemand gemeldet hat — wer im Juni gepatcht hat, war gegen eine Lücke geschützt, die erst im Juli einen Namen bekam. Zweitens: Der Lebenszyklus eingesetzter Software gehört ins laufende IT-Management, nicht in die Rubrik „fällt schon auf, wenn es so weit ist".

Wenn Sie nicht sicher sind, ob bei Ihnen ein betroffener Server läuft, wie es um seinen Zustand steht oder welcher Weg der passende ist, sehen wir uns das gemeinsam an: Wir nehmen den Bestand auf, prüfen Patch-Stand und Auffälligkeiten, begrenzen die Erreichbarkeit und planen den Übergang so, dass Ihr Betrieb dabei weiterläuft.