Am 31. Dezember 2026 endet der Sicherheitssupport für PHP 8.2 — jene Version, auf der derzeit rund ein Viertel aller WordPress-Installationen läuft. Zusammen mit den älteren Versionen sind das knapp zwei Drittel des gesamten Bestands. Bemerken wird davon zunächst niemand etwas: Die Websites laufen weiter, der Editor öffnet sich, Bestellungen kommen an. Dieser Beitrag zeigt, welche Folgen tatsächlich eintreten, wie Sie Ihren eigenen Stand in drei Minuten feststellen — und warum die Antwort für viele Betriebe entspannter ausfällt, als die Zahlen vermuten lassen.
Das Wichtigste in Kürze
- Das Datum ist gesetzt. PHP 8.2 erhält laut php.net bis zum 31. Dezember 2026 Sicherheitskorrekturen, danach nicht mehr. PHP 8.1 ist seit dem 31. Dezember 2025 durch, PHP 8.0 seit November 2023, PHP 7.4 seit November 2022.
- Der Bestand ist alt. Nach den Statistiken von WordPress.org laufen heute 39,1 Prozent der dort erfassten Installationen auf einer PHP-Version ohne Sicherheitspflege. Ab dem 1. Januar 2027 kommt PHP 8.2 mit weiteren 24,8 Prozent dazu.
- Entscheidend ist die Herkunft Ihres PHP. Wer PHP über eine Linux-Distribution mit langer Pflege bezieht, erhält Sicherheitskorrekturen über das Datum von php.net hinaus. Debian 12 liefert PHP 8.2 und wird bis zum 30. Juni 2028 gepflegt. Diese Unterscheidung fehlt in den meisten Darstellungen zum Thema.
- PHP ist selten der Einbruchsweg. Nach der Auswertung von Patchstack für 2025 entfielen 91 Prozent aller gemeldeten Schwachstellen im WordPress-Umfeld auf Plugins. Wer eine alte PHP-Version als Hauptrisiko darstellt, verschiebt die Aufmerksamkeit weg von der Stelle, an der Angriffe tatsächlich stattfinden.
- Der Aufwand ist heute klein und später gross. Solange die Website gepflegt ist, kostet eine Umstellung wenig. Teuer wird sie, wenn der Hoster sie erzwingt und dabei eine Installation trifft, die seit Jahren nicht angefasst wurde.
Was am 31. Dezember 2026 endet
PHP ist die Programmiersprache, in der WordPress geschrieben ist. Jede Seite, die ein Besucher aufruft, wird von einem PHP-Programm auf dem Server erzeugt. Diese Sprache wird von einem eigenen Projekt entwickelt, das jedem Versionszweig eine feste Lebensdauer gibt: zwei Jahre aktive Pflege mit Fehler- und Sicherheitskorrekturen, danach zwei Jahre, in denen nur noch Sicherheitslücken geschlossen werden. Danach endet die Pflege.
Für PHP 8.2 fällt dieses Ende auf den 31. Dezember 2026. Das ist kein angekündigter Plan und keine Prognose, sondern ein seit Jahren veröffentlichter Termin. Die folgende Übersicht gibt den Stand wieder, wie ihn php.net am 28. August 2026 auswies.
| PHP-Version | Sicherheitskorrekturen bis | Stand heute |
|---|---|---|
| 7.4 | 28. November 2022 | seit knapp vier Jahren ohne Pflege |
| 8.0 | 26. November 2023 | ohne Pflege |
| 8.1 | 31. Dezember 2025 | ohne Pflege |
| 8.2 | 31. Dezember 2026 | noch gepflegt, Frist läuft |
| 8.3 | 31. Dezember 2027 | gepflegt |
| 8.4 | 31. Dezember 2028 | gepflegt |
| 8.5 | 31. Dezember 2029 | gepflegt |
WordPress selbst empfiehlt in seinen Anforderungen die Version 8.3 oder neuer. Zugleich lässt es sich weiterhin auf PHP 7.4 betreiben — mit einem ausdrücklichen Zusatz: Diese Versionen hätten das offizielle Ende ihrer Lebensdauer erreicht und könnten die Website Sicherheitslücken aussetzen. WordPress verbietet die alte Version also nicht, es warnt davor.
Wie viele Installationen es betrifft
WordPress.org veröffentlicht eine laufend aktualisierte Statistik darüber, welche PHP-Versionen die Installationen einsetzen, die sich beim Aktualisierungsdienst melden. Wir haben diese Zahlen am 28. August 2026 direkt an der Schnittstelle abgerufen und zusammengefasst.
| Gruppe | Anteil | Bedeutung |
|---|---|---|
| PHP 7.3 und älter | 6,0 % | seit Jahren ohne Pflege |
| PHP 7.4 | 17,3 % | grösster Einzelblock ohne Pflege |
| PHP 8.0 | 4,1 % | ohne Pflege |
| PHP 8.1 | 11,6 % | ohne Pflege seit Ende 2025 |
| PHP 8.2 | 24,8 % | verliert die Pflege Ende 2026 |
| PHP 8.3 bis 8.6 | 36,1 % | gepflegt, entspricht der Empfehlung von WordPress |
Daraus folgt zunächst eine Zahl für heute: rund 39 Prozent der erfassten Installationen laufen auf einer PHP-Version, für die keine Sicherheitskorrekturen mehr erscheinen.
Die zweite Zahl wird häufig falsch gebildet, und wir bilden sie hier ausdrücklich anders. Wäre heute der 1. Januar 2027, lägen rund 64 Prozent ohne Sicherheitspflege — derselbe Anteil, der zugleich unterhalb der von WordPress empfohlenen Version 8.3 liegt. Das ist jedoch keine Vorhersage für den Stichtag, sondern eine Obergrenze unter der Annahme, dass sich bis dahin nichts bewegt. Diese Annahme ist falsch: Die Wanderung läuft, und sie wird von den Hostern getrieben, nicht von den Betreibern. Ablesbar ist sie an derselben Statistik — PHP 8.1 ist acht Monate nach seinem eigenen Support-Ende auf 11,6 Prozent gefallen. Der Anteil am Stichtag wird also mit einiger Wahrscheinlichkeit deutlich tiefer liegen als 64 Prozent. Aussagekräftig ist nicht die Höhe des Werts, sondern der Umstand, dass eine solche Wanderung überhaupt nötig ist — und dass sie bei denen am spätesten ankommt, die sich nicht darum kümmern.
Zur Belastbarkeit dieser Zahlen gehört eine Einschränkung, und sie geht in eine bestimmte Richtung. Erfasst wird ausschliesslich, was sich von selbst meldet: Bei der regelmässigen Abfrage nach Aktualisierungen übermittelt eine Installation ihre WordPress- und PHP-Version an WordPress.org. Wer diese Abfrage nicht ausführt — weil der ausgehende Verkehr gesperrt ist, weil die geplanten Aufgaben stillstehen oder weil jemand die Aktualisierungsprüfung abgeschaltet hat —, erscheint in der Statistik nicht. Das sind tendenziell genau die vernachlässigten Installationen, auf denen besonders altes PHP läuft. Die tatsächlichen Anteile dürften also eher höher liegen als gemessen. Die Statistikseite selbst erläutert ihre Methode nicht; sie beschreibt die Diagramme lediglich als Momentaufnahme der Systeme und Konfigurationen, die in der WordPress-Gemeinschaft im Einsatz sind. Die Grössenordnung trägt damit, die Nachkommastelle nicht.
Der entscheidende Einwand: Woher stammt Ihr PHP?
Über die Dringlichkeit entscheidet ein Umstand, der in den meisten Darstellungen zum Thema fehlt. Das Datum von php.net gilt für die Fassung, die das PHP-Projekt selbst veröffentlicht. Die wenigsten Server beziehen PHP auf diesem Weg. Üblich ist der Bezug über eine Linux-Distribution, und mehrere Distributionen pflegen die von ihnen ausgelieferte PHP-Version nach eigenem Zeitplan weiter: Sie übernehmen Sicherheitskorrekturen in ihre Fassung, auch wenn das PHP-Projekt den Zweig längst abgeschlossen hat.
| System | PHP-Version | Sicherheitspflege der Distribution bis |
|---|---|---|
| Debian 11 «bullseye» | 7.4 | LTS bereits ausgelaufen |
| Debian 12 «bookworm» | 8.2 | 30. Juni 2028 |
| Debian 13 «trixie» | 8.4 | regulärer Zyklus läuft |
| Ubuntu 22.04 LTS «jammy» | 8.1 | Mai 2027 |
| Ubuntu 24.04 LTS «noble» | 8.3 | Mai 2029 |
| Eigenbau, Container, Fremdquelle | beliebig | es gilt allein das Datum von php.net |
debian-security-support — eine Zusicherung bis zum letzten Tag ist das nicht, wohl aber der dokumentierte Stand.Ein Beispiel macht den Unterschied deutlich. Zwei Websites laufen beide auf PHP 8.2. Die eine liegt auf einem Server mit Debian 12; dort erscheinen Sicherheitskorrekturen bis Ende Juni 2028, weil das Debian-Projekt die Pflege am 11. Juni 2026 an sein Langzeit-Team übergeben hat. Die andere liegt in einem Container, dessen PHP direkt vom Projekt stammt; für sie ist am 31. Dezember 2026 Schluss. Beide melden dieselbe Versionsnummer, und in der Statistik von WordPress.org sind sie nicht zu unterscheiden.
Daraus ergibt sich die einzige Frage, die für Ihre Website wirklich zählt — und sie lautet nicht «Welche PHP-Version läuft?», sondern: Wer pflegt diese Version, und bis wann? Das ist eine Frage an den Hoster, und sie lässt sich in einer E-Mail stellen.
Was ein fehlender Sicherheitssupport praktisch bedeutet
Eine PHP-Version ohne Pflege macht eine Website nicht über Nacht angreifbar. Die Darstellung, wonach ein abgelaufenes Datum unmittelbar zu einem Einbruch führt, hält der Datenlage nicht stand. Die jährliche Auswertung von Patchstack für das Jahr 2025 verzeichnet 11’334 neue Schwachstellen im WordPress-Umfeld. Davon entfielen 91 Prozent auf Plugins und 9 Prozent auf Themes. Im WordPress-Kern wurden sechs gemeldet, sämtlich mit niedriger Priorität. Der Einbruchsweg in eine WordPress-Website führt in aller Regel über eine Erweiterung, nicht über die Sprache darunter.
Die tatsächlichen Folgen liegen woanders, und sie treten zeitversetzt ein.
- Eine Lücke in PHP selbst bleibt offen. Das ist der seltene, aber schwerwiegende Fall. Wird im Interpreter eine Schwachstelle gefunden, erhält der gepflegte Zweig eine Korrektur und der abgelaufene nicht. Betroffen wäre dann jede Anwendung auf diesem Server, nicht nur WordPress.
- Der Zeitpunkt der Umstellung geht an Sie über — bis er es nicht mehr tut. Solange Sie handeln, wählen Sie den Termin. Irgendwann stellt der Hoster den Server um, oft mit wenigen Wochen Vorlauf. Trifft das eine gepflegte Installation, ist es ein Wartungsfenster. Trifft es eine Installation mit vier Jahre alten Plugins, ist es ein Projekt.
- Die Nachweisbarkeit fehlt. Wer in einer Ausschreibung, gegenüber einem Versicherer oder in einer Lieferantenprüfung darlegen muss, dass die eigene Website auf gepflegter Software läuft, kann das mit einer abgelaufenen Version nicht. Das ist kein Sicherheitsproblem, sondern ein vertragliches.
- Die Website wird langsamer, als sie sein müsste. Zwischen PHP 7.4 und den aktuellen Zweigen liegen mehrere Runden an Leistungsverbesserungen. Das ist kein Sicherheitsargument, aber es ist das Argument, das im Betrieb am schnellsten sichtbar wird.
Das Gegenargument, das wir selbst geprüft haben
Ein verbreitetes Argument für eine rasche Umstellung lautet, die Erweiterungen selbst würden alte PHP-Versionen bald nicht mehr unterstützen. Wir haben das nachgemessen, statt es zu übernehmen. Über die Schnittstelle von WordPress.org lassen sich die hundert am weitesten verbreiteten Plugins abfragen, samt der PHP-Version, die jedes von ihnen mindestens voraussetzt. Der Stand vom 28. August 2026:
| Mindestens vorausgesetzte PHP-Version | Anzahl der hundert verbreitetsten Plugins |
|---|---|
| 8.1 oder höher | 3 |
| 7.4 | 52 |
| 7.0 bis 7.2 | 18 |
| 5.x | 20 |
| keine Angabe | 7 |
Das Ergebnis spricht gegen das Argument. Drei von hundert Plugins verlangen mehr als PHP 8.0; die grossen Erweiterungen halten unverändert an 7.4 fest. Zwei Einschränkungen gehören dazu, weil sie die Aussage begrenzen: Die Angabe zur benötigten PHP-Version ist für Plugin-Autoren freiwillig, eine fehlende oder niedrige Angabe belegt also keine Kompatibilität, sondern nur das Fehlen einer Zusage. Und die hundert verbreitetsten Plugins sind die bestgepflegten des Ökosystems; über den langen Schwanz seltener Erweiterungen sagt die Erhebung nichts. Belegt ist damit genau eine Aussage, und sie genügt: Die verbreiteten Erweiterungen zwingen derzeit niemanden zu einer Umstellung. Wer heute umstellt, tut das nicht, weil das Ökosystem ihn dazu zwingt. Wir führen den Befund trotzdem auf, weil ein Argument, das der Prüfung nicht standhält, in einer Beratung nichts verloren hat. Die tragenden Gründe stehen im vorigen Abschnitt, und sie kommen ohne diesen aus.
Selbst prüfen: drei Minuten im Adminbereich
Für die folgenden Schritte brauchen Sie einen Administratorzugang zu WordPress und keine weitere Software.
- Die eigene PHP-Version ablesen. Im Adminbereich unter «Werkzeuge» den Punkt «Website-Zustand» öffnen und dort auf den Reiter «Bericht» wechseln. Im Abschnitt «Server» steht die PHP-Version. Meldet WordPress im Reiter «Status» einen Hinweis mit dem Wortlaut, dass die Website eine veraltete PHP-Version verwende, ist die Sache bereits geklärt.
- Die Herkunft klären. Notieren Sie die Versionsnummer und stellen Sie Ihrem Hoster eine einzige Frage: Aus welcher Quelle stammt dieses PHP, und bis wann erhält es Sicherheitskorrekturen? Eine belastbare Antwort nennt ein Datum. Eine Antwort, die nur «wir halten alles aktuell» lautet, ist keine.
- Den Stand von WordPress prüfen. Im selben Bericht steht die WordPress-Version. WordPress führt für jede je veröffentlichte Version einen öffentlichen Status, und daran hängt eine Unterscheidung, die regelmässig untergeht: Ein älterer Zweig ist nicht zwangsläufig unsicher. Sicherheitskorrekturen werden auch in ältere Zweige zurückportiert; unsicher ist eine Installation dann, wenn sie nicht auf der zuletzt gepflegten Fassung ihres Zweigs steht. Entscheidend ist der Patch-Stand, nicht die Hauptversion.
- Eine Testumgebung verlangen, bevor umgestellt wird. Kein seriöser Wechsel der PHP-Version findet zuerst auf der Live-Website statt. Wer keine Kopie zum Prüfen anbietet, stellt die Reihenfolge auf den Kopf.
Aus der Werkstatt: der Stand unserer eigenen Installationen
Wir haben die Prüfung am 28. August 2026 für sämtliche WordPress-Installationen auf unserem eigenen Hosting durchgeführt und geben das Ergebnis unverändert wieder.
| Installation | PHP | WordPress | Einstufung |
|---|---|---|---|
| wp-profis.com | 8.5.4 | 7.1 | aktuell |
| Kundenwebsite 1 | 8.5.4 | 7.1 | aktuell |
| Kundenwebsite 2 | 8.5.4 | 7.0.4 | gepflegter Stand des 7.0-Zweigs |
| Kundenwebsite 3 | 8.5.4 | 7.1 | aktuell |
| Kundenwebsite 4 | 8.5.4 | 7.0.4 | gepflegter Stand des 7.0-Zweigs |
| interne Testumgebung | 8.5.4 | 7.1 | aktuell |
Zwei Einordnungen dazu. Sechs Installationen sind eine kleine Zahl und belegen keine Regel — sie belegen nur, dass wir den Stand kennen, den wir hier von anderen einfordern. Und der einheitliche Wert 8.5.4 erklärt sich daraus, dass alle sechs auf derselben Plattform laufen und gemeinsam aktualisiert werden. Genau darin liegt der Unterschied zu einem gewachsenen Bestand, in dem jede Website ihre eigene Geschichte hat.
Was eine Umstellung bricht — und was nicht
Die Sorge vor einer weissen Seite nach dem Versionswechsel ist der häufigste Grund, weshalb eine Umstellung aufgeschoben wird. Sie ist nicht unbegründet, aber sie richtet sich meist auf die falschen Stellen. Schwierigkeiten entstehen erfahrungsgemäss an vier Punkten.
| Risikostelle | Wie oft es Probleme gibt | Was hilft |
|---|---|---|
| Individuell programmierte Anpassungen im Theme oder in einem eigenen Plugin | häufig | Vor der Umstellung eine statische Prüfung des Codes gegen die Zielversion laufen lassen. |
| Plugins, die seit Jahren nicht aktualisiert wurden | häufig | Vor dem Wechsel ersetzen. Ein Plugin ohne Pflege ist ohnehin das grössere Risiko. |
| Gepflegte Plugins aus dem Verzeichnis | selten | Nichts. Die verbreiteten Erweiterungen laufen von 7.4 bis 8.5 ohne Anpassung. |
| WordPress-Kern und Standard-Themes | sehr selten | Nichts. Der Kern wird gegen alle unterstützten Versionen getestet. |
Der Ablauf, der sich bewährt hat, kommt ohne Überraschungen aus: Kopie der Website anlegen, dort die neue PHP-Version einschalten, die Fehlerprotokolle lesen statt nur die Startseite anzusehen, Formulare und Kasse durchspielen, danach die Live-Website in einem angekündigten Fenster umstellen und den Rückweg offenhalten. Für eine gepflegte KMU-Website liegt der Aufwand bei wenigen Stunden. Ausführlich beschrieben ist das Vorgehen in unserem Beitrag zu sicher durchgeführten WordPress-Updates.
Für Agenturen: der Bestand als Ganzes
Wer dreissig oder achtzig WordPress-Installationen betreut, hat ein anderes Problem als ein einzelner Betrieb. Die Umstellung selbst ist Routine; der Aufwand entsteht dadurch, dass sie dreissigmal anfällt, auf unterschiedlichen Hostings, mit unterschiedlichen Ansprechpartnern und unterschiedlich gepflegtem Code.
Drei Punkte verkürzen das erfahrungsgemäss deutlich:
- Zuerst eine Übersicht, dann Arbeit. PHP-Version, Herkunft des Pakets, WordPress-Stand und Anzahl eigener Code-Anpassungen je Installation in einer Tabelle. Ohne diese Übersicht wird jede Aufwandschätzung zur Vermutung.
- Nach Hosting bündeln, nicht nach Kunde. Installationen auf derselben Plattform lassen sich gemeinsam umstellen. Die Sortierung nach Kunde erzeugt Einzelvorgänge, wo Gruppen möglich wären.
- Statische Codeprüfung statt Klicktest. Für PHP existieren Werkzeuge, die den Code einer Website gegen eine Zielversion prüfen, ohne ihn auszuführen. Sie finden in Minuten, wonach ein manueller Durchgang stundenlang sucht — und sie finden auch die Stellen, die nur in selten aufgerufenen Funktionen liegen.
Für Agenturen, die den Betrieb nicht selbst leisten wollen, übernehmen wir die Wartung unter fremder Marke. Was dazugehört, steht auf der Seite zu Support und Wartung.
Häufige Fragen
Bricht meine Website, wenn ich nichts unternehme?
Nein. Am 1. Januar 2027 ändert sich am Betrieb nichts. PHP 8.2 funktioniert weiter, WordPress läuft weiter, Besucher merken nichts. Es erscheinen lediglich keine Sicherheitskorrekturen mehr für die Sprache selbst — sofern Ihre Version nicht über eine Distribution bezogen wird, die sie länger pflegt.
Auf welche Version sollte ich wechseln?
Auf PHP 8.3 oder 8.4. Version 8.3 entspricht der ausdrücklichen Empfehlung von WordPress und wird bis Ende 2027 gepflegt, 8.4 bis Ende 2028. PHP 8.5 ist seit November 2025 verfügbar und wird bis Ende 2029 gepflegt; wir setzen es selbst ein. Bei einem gewachsenen Bestand mit älteren Erweiterungen ist 8.3 der ruhigere Weg, weil die Erweiterungen dafür am längsten getestet sind.
Mein Hoster sagt, PHP 8.2 sei bei ihm weiterhin sicher. Stimmt das?
Möglicherweise ja. Wenn er PHP über eine Distribution mit langer Pflege ausliefert, etwa Debian 12, erhält die Version dort bis zum 30. Juni 2028 Sicherheitskorrekturen. Die Aussage ist dann zutreffend. Lassen Sie sich die Quelle und das Enddatum nennen — mit diesen beiden Angaben lässt sich die Auskunft überprüfen, ohne sie glauben zu müssen.
Kann ich die PHP-Version selbst umstellen?
Bei den meisten Anbietern ja, im Kundenbereich mit wenigen Klicks. Gerade deshalb ist der Hinweis wichtig: Die Umstellung ist der einfache Teil, die vorherige Prüfung der schwierige. Wer ohne Kopie und ohne Blick in die Fehlerprotokolle umschaltet, verlagert das Risiko in die Live-Website.
Warum lässt WordPress PHP 7.4 überhaupt noch zu?
Weil ein höheres Minimum Millionen von Installationen von Aktualisierungen abschneiden würde. WordPress wählt den umgekehrten Weg: Die technische Untergrenze bleibt bei 7.4, die Empfehlung liegt bei 8.3, und die Anforderungsseite benennt ausdrücklich, dass die alten Versionen die Website Sicherheitslücken aussetzen können.
Bringt eine neuere PHP-Version messbar mehr Tempo?
In der Regel ja, und der Effekt ist bei einem Sprung über mehrere Zweige am deutlichsten. Wie gross er ausfällt, hängt vom Anteil der Rechenzeit ab, den Ihre Website überhaupt in PHP verbringt; bei einer Seite, die aus dem Cache ausgeliefert wird, ist er gering. Belastbar wird die Aussage nur durch eine Messung vorher und nachher an der eigenen Installation.
Fazit
Das Datum vom 31. Dezember 2026 ist kein Grund zur Beunruhigung, und wer daraus eine Dringlichkeit ableitet, überzeichnet. Es ist ein Termin, der lange bekannt ist, der planbar ist und der für einen erheblichen Teil der Betroffenen durch die Pflege ihrer Linux-Distribution ohnehin um Jahre verschoben wird.
Der Befund, der bleibt, ist ein anderer. Auf knapp zwei Dritteln der erfassten WordPress-Installationen läuft heute eine PHP-Version, die das Projekt am 1. Januar 2027 nicht mehr pflegt — bis dahin wird ein Teil davon umgestellt sein, aber der überwiegende Teil der Betreiber weiss weder, welche Version bei ihm läuft, noch wer sie pflegt. Das ist keine Sicherheitslücke, sondern eine Wissenslücke. Sie schliesst sich mit zwei Angaben: der Versionsnummer aus dem eigenen Adminbereich und einem Datum vom Hoster.
Wenn Sie diese beiden Angaben nicht zusammenbekommen oder unsicher sind, was sie für Ihre Website bedeuten: Schicken Sie uns die Adresse. Sie erhalten innert einem Werktag eine Einschätzung, auch wenn sie lautet, dass Sie nichts zu tun haben. Wie wir Websites dauerhaft betreiben, steht unter Support und Wartung; der direkte Weg führt über das Kontaktformular.
Quellen
- php.net: Supported Versions ↗ — Ende der Sicherheitspflege für die Zweige 8.2 bis 8.5
- php.net: Unsupported Branches ↗ — Enddaten für PHP 7.4, 8.0 und 8.1
- WordPress.org: Statistics ↗ — Verteilung der PHP- und WordPress-Versionen; die zugrunde liegenden Werte haben wir über die Schnittstelle
api.wordpress.org/stats/php/1.0/abgerufen - WordPress.org: Requirements ↗ — Empfehlung «Version 8.3 or greater» und der Warnhinweis zu den abgelaufenen Versionen
- Debian: Security support for Bookworm handed over to the LTS team ↗ — Übergabe am 11. Juni 2026, Pflege bis zum 30. Juni 2028
- Canonical: Ubuntu release cycle ↗ — Enddaten der Sicherheitspflege für 22.04 LTS und 24.04 LTS
- Patchstack: State of WordPress Security in 2026 ↗ — 11’334 Schwachstellen im Jahr 2025, davon 91 Prozent in Plugins und sechs im Kern
Stand: 28. August 2026. Sämtliche Anteile stammen aus eigenen Abfragen der offenen Schnittstellen von WordPress.org, Debian und Launchpad an diesem Tag und verschieben sich mit jedem weiteren Tag geringfügig. Die Zuordnung der PHP-Versionen zu den Distributionen gilt für die jeweilige Standardausstattung; wer PHP aus einer zusätzlichen Paketquelle bezieht, hat eine andere Ausgangslage. Wir prüfen die Zahlen im Januar 2027 erneut und halten fest, wie sich der Bestand tatsächlich bewegt hat.
Ähnliche Beiträge
Responsive Styles ohne CSS: was WordPress 7.1 im Editor kannTablet und Handy werden zu Zuständen, die sich direkt einstellen lassen — für fast jeden Block. Dazu Hover,…
Woran Sie eine zuverlässige WordPress-Agentur erkennenSechs Punkte, die sich vor der Unterschrift klären lassen — und fünf Warnzeichen. Inklusive der Frage, die am…
WordPress in eine Schweizer Cloud migrieren: Ablauf, Fallstricke, KostenDer Umzug selbst ist Handwerk. Gefährlich sind E-Mail, alte Adressen ohne Weiterleitung und die Sperre für Suchmaschinen, die…