Web-Sicherheit
Am 21. Oktober 2026 hat das PHP-Projekt auf php.net die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Lücken im Kern von PHP, CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 9.2 bewertet: Unter bestimmten Bedingungen lässt sich darüber ohne Anmeldung Code auf dem Server ausführen. Die US-Behörde CISA führt beide seit dem 26. Oktober als aktiv ausgenutzt, das BSI hat gewarnt. Betroffen sind Onlineshops mit Shopware, Magento oder WooCommerce, Websites mit TYPO3 oder WordPress und Webanwendungen auf PHP, Symfony oder Laminas — denn die Lücke steckt in PHP selbst, nicht im Shop. Die Sharpness Solutions GmbH aus Oldenburg prüft den Patchstand, aktualisiert PHP samt Erweiterungen, härtet Server und Anwendung und betreibt Systeme auf eigenen Servern in Deutschland.
Ein Sicherheitsrelease wie das vom Oktober trifft selten auf eine aufgeräumte Lage. Meist fehlt eine Information: welche Version läuft, wer den Server betreut, welche Erweiterung den Wechsel blockiert. Sechs Ausgangslagen kehren dabei immer wieder. Gemeinsam haben sie eins: Das Risiko liegt weniger in der Lücke als in der Frage, wer sie schließt.
Die Agentur hat den Shop gebaut, der Hoster stellt den Server, und die PHP-Version steht in keiner Unterlage. Dazu kommt: Distributionen behalten oft ihre Versionsnummer, auch wenn das Paket gepatcht ist. Wer nur auf die Nummer schaut, zieht leicht den falschen Schluss — in beide Richtungen.
Shopware, TYPO3 oder WordPress stehen auf dem neuesten Stand, und trotzdem ist das System verwundbar. Die Oktober-Lücken stecken in der PHP-Laufzeit, nicht in der Anwendung. Ein Update des Shops oder CMS ändert daran nichts; gepatcht werden muss PHP selbst.
PHP 8.2 bekommt vom PHP-Projekt Sicherheitsfixes nur noch bis zum 31. Dezember 2026. Die Oktober-Lücken sind mit 8.2.35 geschlossen, die nächste wird es auf dieser Linie nicht mehr sein. Viele Systeme laufen auf 8.2, weil es ihre Mindestversion ist.
Für diese Linien gibt es keine Unterstützung des PHP-Projekts mehr. Diesmal hat das PHP-Security-Team ausnahmsweise Quellcode-Korrekturen bereitgestellt, fertige Pakete kommen nur über Distributionen. Auf diese Ausnahme lässt sich nicht bauen; das System braucht einen Plan für den Versionswechsel.
Ein Shopware-Plugin, eine TYPO3-Extension oder ein WordPress-Theme ist für die neue PHP-Version nicht freigegeben, und bei Magento bestimmt die Magento-Version, welche PHP-Linie überhaupt geht. Dann wird aus einem Paketupdate ein kleines Projekt mit Testsystem und Reihenfolge.
Unbekannte Dateien, ein neues Administratorkonto, Weiterleitungen, die nur Besucher von Google sehen, oder eine Mail des Hosters wegen Spamversands. Dann ist der Patch nicht mehr der erste Schritt, sondern das Sichern von Spuren. Für diesen Fall gibt es einen eigenen, festen Ablauf.
Am 20. Oktober 2026 kündigte das PHP-Projekt auf php.net ein Sicherheitsrelease für den Folgetag an, mit zwei kritischen Schwachstellen, beide nach CVSS v4.0 mit 9.2 bewertet. Am 21. Oktober erschienen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, reine Sicherheitsreleases ohne neue Funktionen. Sie beheben CVE-2026-109618 und CVE-2026-109619, zwei Fehler im Kern der PHP-Laufzeit. Der eine betrifft den Umgang mit Speichermangel während einer Anfrage, der andere internen Zustand, der nach einer Anfrage im selben Prozess übrig bleiben kann. In beiden Fällen kann das unter bestimmten Bedingungen dazu führen, dass fremder Code mit den Rechten des Webserver-Prozesses läuft. Weder ein Login noch eine Handlung eines Nutzers ist dafür nötig; die Angriffskomplexität stuft die Bewertung als hoch ein.
Betroffen ist nach dem Sicherheitshinweis von php.net jede PHP-Installation, die Webanfragen beantwortet, gleich ob über PHP-FPM, Apache mod_php, php-cgi, FrankenPHP oder LiteSpeed; am höchsten ist das Risiko bei mod_php. Verwundbar sind alle Stände unterhalb der genannten Versionen, also 8.2 vor 8.2.35, 8.3 vor 8.3.36, 8.4 vor 8.4.27 und 8.5 vor 8.5.12. Das PHP-Projekt schreibt dazu, es gebe keine vollständigen Gegenmaßnahmen, das Update sei der einzige sichere Weg. Übergangseinstellungen, die es nennt, verringern das Risiko nur teilweise und machen eine Installation ausdrücklich nicht sicher. Auch die Vorabversion PHP 8.6.0 RC4 enthält die Korrekturen; für den Produktivbetrieb ist 8.6 noch keine Option.
Zum zeitlichen Ablauf: Amazon Threat Intelligence beobachtete einen ersten Ausnutzungsversuch bereits am 17. Oktober, vier Tage vor der Veröffentlichung; ob Versuche erfolgreich waren, ließ der Bericht offen. Das BSI veröffentlichte die Cybersicherheitswarnung 2026-297981-1032 und empfiehlt, die Patches ohne Aufschub einzuspielen. Am 26. Oktober nahm die US-Behörde CISA beide Schwachstellen in ihren Katalog aktiv ausgenutzter Lücken auf. Das BSI meldet auf seiner Lageseite Angriffsversuche im zweistelligen Millionenbereich, in Deutschland bislang aber keine großflächige Ausnutzung und keine erfolgreichen Angriffe mit Datenabfluss. Das ist die nüchterne Lage: ein ernstes, gut beschriebenes Risiko mit einer klaren Antwort. Wer auf einer gepatchten Version läuft, hat diesen Punkt erledigt. Wer es nicht weiß, sollte es jetzt prüfen.
Das PHP-Projekt unterstützt jede Version zwei Jahre aktiv mit Fehler- und Sicherheitskorrekturen, danach zwei weitere Jahre nur mit kritischen Sicherheitsfixes nach Bedarf. Stand Ende Oktober 2026 heißt das: PHP 8.5 und 8.4 sind in aktiver Unterstützung — 8.4 aktiv bis Ende 2026 und mit Sicherheitsfixes bis zum 31. Dezember 2028, 8.5 aktiv bis Ende 2027 und mit Sicherheitsfixes bis zum 31. Dezember 2029. PHP 8.3 bekommt nur noch Sicherheitsfixes, und zwar bis zum 31. Dezember 2027. PHP 8.2 bekommt Sicherheitsfixes nur noch bis zum 31. Dezember 2026; ab dem 1. Januar 2027 kommen vom PHP-Projekt keine mehr. PHP 8.1 hat sein Lebensende am 31. Dezember 2025 erreicht, 8.0 im November 2023, 7.4 im November 2022.
Für die älteren Linien ist der Oktober eine Ausnahme: Wegen der Schwere der Lücken hat das PHP-Security-Team minimale Quellcode-Korrekturen für 7.4, 8.0 und 8.1 bereitgestellt — für Betreiber, die PHP selbst übersetzen. Fertige Pakete gibt es dafür nur über Linux-Distributionen oder Anbieter mit Langzeitunterstützung; Ubuntu etwa hat auch für 22.04 mit PHP 8.1 ein Update geliefert, ältere LTS-Versionen über ESM. Darauf, dass sich diese Ausnahme wiederholt, sollte niemand bauen. Ein Shop oder CMS auf PHP 8.1 oder älter läuft ohne Unterstützung des PHP-Projekts, und die nächste Lücke trifft ihn möglicherweise ohne Korrektur. Für solche Systeme ist nicht das nächste Paketupdate die Aufgabe, sondern der Versionswechsel.
Was das für die großen Systeme bedeutet: Shopware 6.7 verlangt PHP 8.2 oder neuer und empfiehlt 8.4. TYPO3 v14 und v13 LTS laufen mit PHP 8.2 bis 8.5. WordPress empfiehlt PHP 8.3 oder neuer und läuft zwar noch ab 7.4, das aber ohne Support. Bei Magento Open Source und Adobe Commerce hängt die PHP-Version an der Magento-Version: 2.4.9 nur mit PHP 8.5, 2.4.8 mit 8.4 oder 8.3, 2.4.7 mit 8.3 oder 8.2, 2.4.6 mit 8.2 oder 8.1. Eine Mindestversion ist keine Empfehlung für den Betrieb. Wer heute auf PHP 8.2 läuft, weil das System es zulässt, steht in zwei Monaten ohne Sicherheitsfixes da — und sollte den Wechsel auf 8.3, 8.4 oder 8.5 jetzt planen, nicht im Dezember.
Der erste Schritt ist eine Bestandsaufnahme, keine Vermutung. Welche PHP-Version läuft im Web, welche auf der Kommandozeile, welche in Cronjobs und Workern? Aus welcher Quelle kommt PHP: aus den Paketen der Distribution, aus einem Fremd-Repository, aus einem Container-Image oder aus dem Angebot eines Hosters? Wichtig dabei: Distributionen behalten oft ihre alte Versionsnummer und sind trotzdem gepatcht. Ubuntu 24.04 liefert PHP weiter als 8.3.6 aus, die Korrektur steckt im Paketstand 8.3.6-0ubuntu0.24.04.13. Debian 12 hat php8.2 8.2.35-1~deb12u1 bereitgestellt, Debian 13 php8.4 8.4.27-1~deb13u1. Den Patchstand liest man deshalb am Paket ab, nicht an der PHP-Versionsnummer. In Docker-Umgebungen gehört dazu, die Images neu zu bauen und die Container tatsächlich neu zu starten.
Steht nur ein Paketupdate innerhalb derselben PHP-Linie an, ist das in der Regel ein Wartungsfenster: einspielen, PHP-FPM oder Webserver neu starten, prüfen, dass der neue Stand tatsächlich ausgeliefert wird. Anders ist es beim Wechsel der Linie, etwa von 8.2 auf 8.4. Dann muss jede Komponente mit: Shopware-Plugins und Apps, Magento-Module, TYPO3-Extensions, WordPress- und WooCommerce-Plugins und Themes, dazu eigene Erweiterungen und Composer-Abhängigkeiten. Bei Magento kann der Wechsel ein Update von Magento selbst voraussetzen, weil jede Version nur bestimmte PHP-Linien unterstützt. Wir prüfen das vorab gegen die Systemanforderungen der Hersteller und die Angaben der Erweiterungen und testen auf einem Staging-System mit einer Kopie der Live-Daten, bevor der Live-Betrieb umgestellt wird.
Bei Webanwendungen und Individualsoftware auf PHP, Symfony oder Laminas gilt dasselbe Prinzip mit anderen Werkzeugen. Wir lesen composer.json und composer.lock, prüfen die Abhängigkeiten auf bekannte Lücken und auf Unterstützung der Ziel-PHP-Version und sehen in den Code, wo veraltete Sprachkonstrukte oder entfernte Funktionen stecken. Hilfreich sind dabei automatisierte Tests; wo es keine gibt, schreiben wir für die wichtigsten Abläufe welche, bevor die Version wechselt. Auch Werkzeuge neben dem Shop gehören dazu: Der Hersteller von Matomo weist ausdrücklich darauf hin, dass ein Matomo-Update die PHP-Lücken nicht behebt. Am Ende steht ein Plan mit Reihenfolge und Aufwand je Schritt, kein Bauchgefühl.
Ein gepatchtes PHP schließt diese Lücke, nicht die nächste. Härtung verkleinert die Angriffsfläche, damit eine künftige Schwachstelle weniger trifft. Auf Serverebene heißt das: aktuelles Betriebssystem, nur die Dienste, die gebraucht werden, Verwaltungszugänge per Schlüssel und nicht für jeden erreichbar. Der Webserver liefert nur aus, was öffentlich sein soll; Konfigurationsdateien, Sicherungskopien und Versionsverwaltung liegen außerhalb des Webverzeichnisses oder sind gesperrt. PHP läuft mit einer Konfiguration, die zum System passt: keine Fehlerausgaben an Besucher, Grenzen für Laufzeit, Uploads und Anfragegröße nach Bedarf und keine PHP-Erweiterungen, die niemand nutzt. Jede Anwendung bekommt ihren eigenen Prozess und Benutzer, damit ein Fehler in einem System nicht das nächste erreicht.
Rechte entscheiden, wie weit ein Fehler reicht. Der Webserver-Prozess darf schreiben, wo die Anwendung schreiben muss — Cache, Uploads, Logs — und sonst nirgends. Datenbankbenutzer haben nur die Rechte ihrer Anwendung, Schnittstellen eigene, eng gefasste Zugangsdaten. Verwaltungszugänge im Shop- und CMS-Backend bekommen einen zweiten Faktor, verwaiste Konten werden entfernt. Dazu gehören Updates in festen Intervallen für Betriebssystem, PHP, Datenbank, Shop- oder CMS-Kern und Erweiterungen, getestet und mit Rückweg. Backups liegen getrennt vom Produktivsystem, in mehreren Ständen, und die Rücksicherung wird geprobt. Monitoring meldet Ausfälle, auffällige Fehlerraten und unerwartete Änderungen an Dateien, bevor Kunden es tun.
Vor den Server lässt sich eine Web Application Firewall setzen, bei uns meist Cloudflare. Sie filtert bekannte Angriffsmuster, bremst Automaten, schützt Verwaltung und Logins und nimmt Massenverkehr ab, bevor er den Server erreicht. Für Shopware und TYPO3 beschreiben eigene Seiten, wie Cache-Regeln, Ausnahmen für Zahlungsanbieter und Schnittstellen und die Abschottung des Servers zusammenpassen. Eine WAF ist eine zusätzliche Linie, kein Ersatz für Patches: Gegen die Lücken in der PHP-Laufzeit hat das PHP-Projekt keine vollständige Gegenmaßnahme genannt, und eine Firewall-Regel kann nur abfangen, was sie als Muster erkennt. Die Reihenfolge bleibt deshalb dieselbe: zuerst gepatchte Versionen, dann Härtung, dann die vorgelagerte Firewall.
Gibt es Anzeichen, dass ein System bereits betroffen ist — fremde Weiterleitungen, unbekannte Dateien oder Konten, Spamversand, eine Sperre durch den Hoster —, dann ist ein Update allein nicht mehr die Antwort. Dann zählt die Reihenfolge: sichern, verstehen, wiederherstellen, schließen. Wie wir dabei vorgehen, beschreibt unsere Seite zur Soforthilfe bei gehackten Websites. Für die Oktober-Lücken gilt zusätzlich: Ein Angriff liefe mit den Rechten des Webserver-Prozesses. Deshalb prüfen wir bei Systemen, die im fraglichen Zeitraum ungepatcht erreichbar waren, Zugriffsprotokolle, Dateien und Konten gezielt, statt nur den Patch nachzuziehen. Sind personenbezogene Daten möglicherweise betroffen, liefern wir die technische Grundlage für die Prüfung der Meldepflicht nach Artikel 33 DSGVO; die rechtliche Bewertung liegt bei Ihnen.
Laufende Absicherung ist bei uns Teil von Betrieb und Wartung mit einer Service-Level-Vereinbarung. Die Stufen BASIC, STANDARD und ADVANCED stehen für 24, 8 oder 4 Stunden Reaktionszeit, jeweils für ein Jahr gebucht. Die Arbeit rechnen wir nach Aufwand oder im vereinbarten Rahmen mit Stunden ab; der Stundensatz ist nach Zeitpunkt gestaffelt — werktags in der Arbeitszeit, werktags außerhalb, Wochenende und Feiertage. Rufbereitschaft außerhalb der Geschäftszeiten gibt es nur mit SLA. Ohne Vereinbarung bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Mit SLA ist ein Sicherheitsrelease wie das vom Oktober keine Frage mehr, wer sich zuständig fühlt, sondern ein geplanter Termin.
Am meisten Kontrolle gibt es, wenn das System auf unseren eigenen Servern läuft: Proxmox-PVE-Cluster im Hetzner-Rechenzentrum Falkenstein, Deutschland, mit Docker, Monitoring, Backups und Staging. Dann liegt der Patchstand von Betriebssystem und PHP in unserer Hand, und niemand muss erst bei einem Hoster nachfragen, welche Pakete installiert sind. Shops wie den B2B-Shop von M&S Armaturen betreiben wir auf diesen Servern. Läuft Ihr System bei einem anderen Anbieter, prüfen wir den Patchstand dort, setzen um, was die Umgebung zulässt, und sagen klar, wo sie es nicht tut. Sharpness gibt es seit 1999, mit mehr als 250 Projekten seitdem und einer IT-Haftpflichtversicherung. Die Domain bleibt immer auf Ihren Namen, der Code liegt in einem Git-Repository, das Ihnen gehört.
Ablauf
Schicken Sie uns System, PHP-Version, falls bekannt, und wer den Server betreibt. Sie bekommen eine erste, unverbindliche Einordnung: ob Ihr System von den Oktober-Lücken betroffen ist, ob ein Paketupdate genügt oder ein Versionswechsel ansteht und was als Erstes zu tun ist. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Wir arbeiten bundesweit remote, Termine in Oldenburg und im Nordwesten nach Absprache.
Sie schildern, was Sie wissen: Shop, CMS oder Anwendung, PHP-Version, wer den Server betreibt, ob etwas auffällig ist. Wir sagen, was als Erstes ansteht und ob es um ein Paketupdate, einen Versionswechsel oder einen Vorfall geht — unverbindlich.
Wir lesen PHP-Version und Paketstand für Web, Kommandozeile und Worker und prüfen Shop- oder CMS-Kern, Erweiterungen, Abhängigkeiten, Zugänge, Rechte und Backups. Ergebnis ist eine priorisierte Liste: was jetzt ansteht, was in den nächsten Wochen und was warten kann.
Wo die PHP-Linie bleiben kann, spielen wir das Sicherheitsrelease oder das gepatchte Distributionspaket ein, starten die Dienste neu und prüfen, dass der neue Stand tatsächlich ausgeliefert wird. Gibt es Anzeichen für einen Vorfall, sichern wir vorher Dateien, Datenbank und Protokolle.
Steht ein Wechsel der PHP-Linie an, etwa weg von 8.2, testen wir Shop, CMS oder Anwendung samt Erweiterungen auf einem Staging-System mit einer Kopie der Live-Daten. Umgestellt wird im vereinbarten Wartungsfenster, mit Backup davor und einem Rückweg.
Server, Webserver und PHP-Konfiguration, Dateirechte, Datenbank- und Verwaltungszugänge mit zweitem Faktor, Backups mit geprobter Rücksicherung und Monitoring. Auf Wunsch eine vorgelagerte Firewall mit Cloudflare, abgestimmt auf Zahlungsanbieter und Schnittstellen.
Danach Wartung mit Service-Level-Vereinbarung: Sicherheitsreleases und Updates in festen Intervallen, Monitoring, Backup-Prüfung und ein klarer Ablauf für den Ernstfall — auf unseren eigenen Servern in Deutschland mit dem Patchstand in unserer Hand.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Zwei kritische Lücken im Kern von PHP: CVE-2026-109618 und CVE-2026-109619, beide nach CVSS v4.0 mit 9.2 bewertet. Unter bestimmten Bedingungen erlauben sie, ohne Anmeldung und ohne Zutun eines Nutzers Code mit den Rechten des Webserver-Prozesses auszuführen. Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21. Oktober 2026 auf php.net. Das PHP-Projekt schreibt, es gebe keine vollständigen Gegenmaßnahmen; das Update sei der einzige sichere Weg. Die US-Behörde CISA führt beide Lücken seit dem 26. Oktober als aktiv ausgenutzt, das BSI hat dazu die Cybersicherheitswarnung 2026-297981-1032 herausgegeben.
Ja, sofern PHP dort Webanfragen beantwortet und noch nicht auf einen gepatchten Stand gebracht wurde. Laut php.net sind alle PHP-Installationen betroffen, die Webanfragen bedienen — über PHP-FPM, Apache mod_php, php-cgi, FrankenPHP oder LiteSpeed. Verwundbar sind 8.2 vor 8.2.35, 8.3 vor 8.3.36, 8.4 vor 8.4.27 und 8.5 vor 8.5.12, ältere Linien ohnehin, sofern sie keine Korrektur über die Distribution bekommen haben. Das gilt für Shopware, Magento und WooCommerce genauso wie für TYPO3, WordPress und eigene Anwendungen, weil die Lücke in der Laufzeit steckt. Ob Ihr System gepatcht ist, lässt sich anhand von Version und Paketstand in der Regel schnell klären.
Nein. Die Oktober-Lücken stecken in der PHP-Laufzeit, nicht in Shopware, Magento, TYPO3 oder WordPress. Ein Update des Shops oder CMS ändert an PHP nichts; gepatcht werden muss PHP selbst, also die Version, die der Server ausführt. Darauf weisen php.net, das BSI und etwa auch der Hersteller von Matomo ausdrücklich hin. Umgekehrt gilt: Ein aktuelles PHP ersetzt keine Updates von Shop- oder CMS-Kern und Erweiterungen, denn die haben ihre eigenen Lücken und Korrekturen. Beides gehört zusammen in einen festen Wartungsrhythmus. Wir prüfen und aktualisieren deshalb beide Ebenen und achten darauf, dass jede Erweiterung zur gewählten PHP-Version passt.
Am Paketstand, nicht allein an der Versionsnummer. Wer PHP in der Fassung des PHP-Projekts nutzt, braucht mindestens 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Linux-Distributionen behalten dagegen oft ihre Versionsnummer und liefern die Korrektur als neuen Paketstand: Ubuntu 24.04 etwa weiterhin als PHP 8.3.6, gepatcht ab Paket 8.3.6-0ubuntu0.24.04.13; Debian 12 mit php8.2 8.2.35-1~deb12u1, Debian 13 mit php8.4 8.4.27-1~deb13u1. Auf Shared Hosting entscheidet der Hoster, dann hilft eine konkrete Nachfrage nach dem Patchstand. Wichtig ist außerdem, dass nach dem Update PHP-FPM oder der Webserver neu gestartet wurde — sonst läuft der alte Stand weiter.
Ab dem 1. Januar 2027 liefert das PHP-Projekt für 8.2 keine Sicherheitsfixes mehr. Die Oktober-Lücken sind mit 8.2.35 noch geschlossen worden, die nächste Lücke wird es auf dieser Linie nicht mehr sein. Viele Systeme stehen auf 8.2, weil es ihre Mindestversion ist: Shopware 6.7, TYPO3 v13 und v14 sowie Magento 2.4.6 und 2.4.7 lassen es zu. Mindestversion heißt aber nicht, dass sich das System damit dauerhaft sicher betreiben lässt. Der Wechsel auf 8.3, 8.4 oder 8.5 braucht einen Test aller Erweiterungen und manchmal ein Update von Shop oder CMS. Zwei Monate sind dafür knapp, aber ausreichend, wenn die Planung jetzt beginnt.
Den Versionswechsel planen und bis dahin die Oktober-Lücken über den Weg schließen, den es für Ihre Umgebung gibt. PHP 8.1 ist seit dem 31. Dezember 2025 ohne Unterstützung des PHP-Projekts, 8.0 seit November 2023, 7.4 seit November 2022. Ausnahmsweise hat das PHP-Security-Team diesmal minimale Quellcode-Korrekturen für 7.4, 8.0 und 8.1 bereitgestellt; fertige Pakete kommen nur über Distributionen oder Anbieter mit Langzeitunterstützung. Bei der nächsten Lücke gibt es diese Ausnahme womöglich nicht. Ein System auf diesem Stand braucht deshalb einen Plan für PHP 8.3 oder neuer, meist zusammen mit einem Update von Shop, CMS oder Framework.
Die neueste Linie, die Ihr System und alle Erweiterungen unterstützen — heute meist PHP 8.4 oder 8.5. Shopware 6.7 verlangt mindestens 8.2 und empfiehlt 8.4. TYPO3 v14 und v13 LTS laufen mit 8.2 bis 8.5. WordPress empfiehlt 8.3 oder neuer. Bei Magento Open Source und Adobe Commerce bestimmt die Version die PHP-Linie: 2.4.9 nur mit 8.5, 2.4.8 mit 8.4 oder 8.3, 2.4.7 mit 8.3 oder 8.2. Wegen des Supportendes Ende 2026 empfehlen wir 8.2 nicht mehr als Ziel. Entscheidend sind am Ende die Erweiterungen: Ein Plugin, das die Zielversion nicht unterstützt, bestimmt den Zeitplan.
Eine Bestandsaufnahme von Laufzeit, Anwendung und Betrieb mit einer priorisierten Maßnahmenliste als Ergebnis. Wir prüfen PHP-Version und Patchstand, Betriebssystem und Dienste, Webserver- und PHP-Konfiguration, Shop- oder CMS-Kern, Erweiterungen und Composer-Abhängigkeiten auf bekannte Lücken, dazu Dateirechte, Zugänge und ihre Rechte, Backups und Monitoring. Bei Onlineshops gehört der Zahlungsweg dazu: Kartendaten sollen den Server nie berühren, sondern direkt beim Zahlungsdienstleister landen. Die Liste sagt, was jetzt ansteht, was in den nächsten Wochen und was warten kann, jeweils mit Aufwand je Maßnahme. Was davon umgesetzt wird, entscheiden Sie.
Teilweise, aber sie ersetzt das Update nicht. Eine vorgelagerte Web Application Firewall filtert bekannte Angriffsmuster, bremst Automaten und nimmt Massenverkehr ab, bevor er den Server erreicht. Gegen eine Lücke in der PHP-Laufzeit hilft sie nur so weit, wie sie den Angriff als Muster erkennt. Das PHP-Projekt nennt für die Oktober-Lücken keine vollständige Gegenmaßnahme; auch die Übergangseinstellungen, die es beschreibt, machen eine Installation ausdrücklich nicht sicher. Sinnvoll ist Cloudflare als zusätzliche Linie nach Patch und Härtung. Wie wir es für Shopware und TYPO3 einrichten, ohne Zahlungsanbieter und Schnittstellen auszusperren, beschreiben eigene Seiten.
Nichts löschen, Spuren sichern und uns anrufen. Bringen Sie die Seite in den Wartungsmodus oder lassen Sie sie beim Hoster vorübergehend abschalten, und ändern Sie von einem sauberen Gerät aus die Passwörter von E-Mail-Postfach und Hoster-Kundenkonto. Auffällige Dateien zu entfernen zerstört Spuren und schließt die Tür meist nicht. Bei den Oktober-Lücken liefe ein Angriff mit den Rechten des Webserver-Prozesses; dann reicht es nicht, PHP nachträglich zu patchen. Den vollständigen Ablauf beschreibt unsere Seite zur Soforthilfe bei gehackten Websites. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr; außerhalb dieser Zeiten über das Formular.
Ja. Wir prüfen den Patchstand auch auf fremden Hostings und Servern, setzen um, was die Umgebung zulässt, und sagen klar, wo sie Grenzen setzt. Auf Shared Hosting entscheidet der Hoster über PHP-Version und Patchstand; dort klären wir mit ihm, ob die Oktober-Korrekturen eingespielt sind, und stellen im Verwaltungsbereich die passende PHP-Linie ein, soweit er das erlaubt. Auf eigenen Servern oder VMs übernehmen wir Paketupdates, Konfiguration und Härtung selbst. Die meiste Kontrolle haben Sie, wenn das System auf unseren eigenen Servern in Deutschland läuft: Dann liegen Patchstand, Backups und Monitoring in einer Hand, und ein Sicherheitsrelease wird ohne Umweg eingespielt.
Laufende Absicherung ist Teil unserer Wartung mit Service-Level-Vereinbarung: BASIC mit 24, STANDARD mit 8 und ADVANCED mit 4 Stunden Reaktionszeit, jeweils für ein Jahr gebucht. Die Arbeit rechnen wir nach Aufwand oder im vereinbarten Rahmen mit Stunden ab; Rufbereitschaft außerhalb der Geschäftszeiten gibt es nur mit SLA. Ohne Vereinbarung bearbeiten wir Anfragen innerhalb von 48 Stunden in unseren Geschäftszeiten Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr. Zum Umfang gehören Sicherheitsreleases und Updates in festen Intervallen, Backup-Prüfung und Monitoring. Der Code gehört Ihnen: Er liegt in einem Git-Repository, das Ihnen gehört, und die Domain ist immer auf Ihren Namen registriert.
Anfrage
Ein paar Angaben genügen: welches System, welche PHP-Version, wo es läuft und was Ihnen aufgefallen ist. Wir melden uns mit Rückfragen und einer ersten Einordnung — unverbindlich. Bitte schicken Sie keine Passwörter oder Zugangsdaten über dieses Formular.