Letzte Woche saß ich bei einem Maschinenbauer mit 80 Mitarbeitenden. ERP-Anbindung läuft über eine selbst gebastelte .NET-Middleware, die deren Hausdienstleister vor vier Jahren aufgebaut hat. Version? .NET 6. End-of-Life seit November 2024. Patches? Zuletzt im Herbst letzten Jahres. Der Verantwortliche wusste nicht einmal, welche .NET-Version im Einsatz ist — er wusste nur, dass "die Schnittstelle läuft".
Das ist kein Einzelfall. Das ist mein Alltag.
Was Microsoft im Juni 2026 veröffentlicht hat
Der monatliche Servicing-Update-Post vom .NET-Team ist diesmal überschaubar, aber nicht harmlos. Microsoft schließt drei Sicherheitslücken (CVE-2026-45591, CVE-2026-45490, CVE-2026-45491), die alle drei aktiven .NET-Versionen betreffen: .NET 8.0, .NET 9.0 und .NET 10.0. Neue Patch-Releases stehen bereit: 8.0.28, 9.0.17 und 10.0.9. Für .NET Framework gibt es in diesem Monat hingegen keine neuen Updates — weder sicherheitsrelevante noch sonstige.
Die Botschaft von Microsoft ist klar und kurz: Update heute. Ende.
Wie das in einem KMU mit 30 bis 300 Mitarbeitenden ankommt
Gar nicht, meistens.
Das ist keine Kritik am .NET-Team — die machen ihren Job, und zwar gut. Aber der Blogpost adressiert implizit DevOps-Teams mit CI/CD-Pipelines, automatisierten Deployment-Prozessen und einer klaren Übersicht darüber, welche .NET-Version wo läuft. Das ist Enterprise-Realität. In mittelständischen Unternehmen sieht die Welt anders aus.
Problem 1: Niemand weiß, was läuft. Ich frage in fast jedem Erstgespräch: Welche .NET-Versionen habt ihr im Einsatz? Die ehrliche Antwort in 70 % der Fälle: "Irgendwas mit .NET, das müssten wir nachschauen." Ohne Inventar kein gezieltes Patchen. Ohne gezieltes Patchen passiert: nichts.
Problem 2: Patches brauchen einen Prozess — und den gibt es nicht. "Update heute" setzt voraus, dass du weißt, wo du was updatest, dass du ein Testfenster hast, dass du ein Rollback-Konzept hast und dass jemand verantwortlich ist. In einem KMU ohne dediziertes Operations-Team sind das vier Voraussetzungen, von denen oft keine einzige erfüllt ist. Das Ergebnis: Der Patch wartet auf "nächstes Quartal" und landet dann im Nirwana.
Problem 3: Die CVE-Details fehlen — und das ist ein echtes Problem. Microsoft nennt die CVE-Nummern, aber zum Zeitpunkt des Posts sind die Detail-Seiten oft noch nicht vollständig befüllt. Für einen Senior-Entwickler ist das vertretbar — der weiß, dass .NET-Sicherheitslücken typischerweise Remote Code Execution oder Privilege Escalation bedeuten und updatet ohne lange zu fackeln. Für einen KMU-IT-Generalisten, der gegenüber der Geschäftsführung begründen muss, warum er ein Produktivsystem anfasst, ist "CVE ohne Details" keine ausreichende Argumentationsgrundlage.
Problem 4: .NET Framework — kein Update bedeutet nicht "alles gut". Der Satz "This month, there are no new security updates for .NET Framework" wird im KMU-Kontext oft als Freifahrtschein gelesen. Dabei laufen viele interne Anwendungen auf .NET Framework 4.6, 4.7 oder 4.8 — und das seit Jahren wartungsfrei. Kein Update in einem Monat heißt nicht, dass die Infrastruktur sicher ist. Es heißt nur, dass gerade nichts Neues nachgepatcht werden muss.
Was ich konkret empfehle
Drei Dinge, abgestuft nach Aufwand:
Sofort (zwei Stunden): Mach ein einfaches Inventar. Suche auf allen Windows-Servern und Applikationsmaschinen nach installierten .NET-Versionen. PowerShell macht das in einer Zeile:
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse |
Get-ItemProperty -Name Version -EA 0 | Where-Object { $_.PSChildName -match '^(?!S)\p{L}' } |
Select-Object PSChildName, Version
Für modernes .NET (8/9/10) reicht dotnet --list-runtimes auf jedem System. Schreib das in eine Tabelle. Eine einfache Excel-Tabelle reicht. Du brauchst kein CMDB.
Kurzfristig (ein bis zwei Tage): Leg einen Patch-Rhythmus fest. Ich empfehle: Microsoft Patch Tuesday ist der Trigger, zwei Wochen danach ist der interne Patch-Termin. Das gibt dir Zeit, CVE-Details zu lesen, und verhindert, dass du ungetestete Day-1-Patches auf Produktion schiebst. Wer dafür keine Kapazität hat, sollte zumindest eine Wiedervorlage in seinem Kalender haben — einmal im Quartal, automatisch.
Mittelfristig (zwei bis vier Wochen Projektarbeit): Wenn du noch .NET Framework 4.x im Einsatz hast und die darunterliegende Anwendung businesskritisch ist, brauchst du eine ehrliche Einschätzung: Kann das migriert werden? Was kostet das? Was kostet es, wenn eine ungepatchte Lücke ausgenutzt wird? Die meisten KMUs schieben diese Abwägung auf — bis ein Incident sie zwingt, sie unter Zeitdruck zu treffen.
Die Differenzierung, die im Originalartikel fehlt
Der .NET-Blog macht seinen Job: Er informiert die .NET-Community schnell und präzise über Patches. Was er nicht leistet — und auch nicht leisten muss — ist die Übersetzung in betriebliche Realität.
Konkret: Die drei CVEs diesen Monat betreffen ausschließlich .NET 8, 9 und 10. Wer ausschließlich auf .NET Framework läuft, ist von diesem spezifischen Patch-Zyklus nicht betroffen — aber das bedeutet nicht Entwarnung, sondern nur eine andere Risikolage. Und wer auf .NET 6 oder 7 sitzt (beide EOL), bekommt diese Patches gar nicht mehr. Für den ist jede neue CVE ein offenes Fenster.
Das ist die Aussage, die im Originalartikel implizit steckt, aber nicht ausgesprochen wird: EOL bedeutet, dass du für zukünftige Sicherheitslücken keine Patches mehr bekommst — egal wie kritisch sie sind. Das müssen Entscheider im Mittelstand verstehen, bevor sie "der Server läuft ja" als Argument akzeptieren.
Der vollständige Original-Beitrag von .NET Blog (MS): .NET and .NET Framework June 2026 servicing releases updates
Wenn du wissen willst, wie dein konkreter Stack aussieht, welche Versionen ein Risiko darstellen und was ein realistischer Sanierungsplan für euer Umfeld kostet — ohne dass ich dir danach ein Angebot für ein halbjähriges Transformationsprojekt schicke:
— Bernhard