--- title: "Sicherheitslücken in PHP, Node.js und Next.js: Was Sie im Oktober 2026 patchen müssen" url: https://coding9.de/blog/sicherheitsluecken-php-nodejs-nextjs-oktober-2026 author: "Alexander Schikowsky" datePublished: 2026-10-25T00:00:00.000Z dateModified: 2026-10-25T00:00:00.000Z description: "php2shell, Node.js- und Next.js-Lücken im Oktober 2026: betroffene Versionen, Updates und der Weg für Systeme auf PHP 7.4, Node 20 oder Next.js 14." --- # Sicherheitslücken in PHP, Node.js und Next.js: Was Sie im Oktober 2026 patchen müssen Zwischen dem 14. und dem 23. Oktober 2026 haben PHP, Node.js und Next.js Sicherheitsupdates veröffentlicht, darunter mehrere Lücken, über die Angreifer ohne Anmeldung Code auf dem Server ausführen können. Für PHP gibt es bereits Angriffe in freier Wildbahn. Wer seine Systeme auf aktuellen Versionen betreibt, spielt jetzt die Patches ein und ist damit fertig. Wer noch PHP 7.4, Node.js 20 oder Next.js 14 im Einsatz hat, bekommt für diese Lücken keinen offiziellen Fix mehr und braucht ein Upgrade. Dieser Beitrag fasst zusammen, welche Versionen betroffen sind, welche Updates helfen und wie Sie vorgehen, wenn ein Legacy-System dazwischen hängt. Stand ist der 25. Oktober 2026, die Quellen stehen am Ende. ## Die Kurzfassung - **PHP (php2shell):** CVE-2026-109618 und CVE-2026-109619, beide CVSS 4.0 9.2, Codeausführung ohne Anmeldung. Behoben in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21. Oktober. Erste Angriffsversuche wurden bereits am 17. Oktober beobachtet. - **Node.js:** Zehn CVEs, darunter ein Out-of-Bounds-Write im Brotli-Decoder (CVE-2026-111497) und zwei Umgehungen der TLS-Hostnamenprüfung. Behoben in v26.12.1, v24.22.1 und v22.23.4 vom 21. Oktober. - **Next.js:** Zwei kritische RCEs (use cache und Bildoptimierung mit SVG) und eine DoS-Lücke in Server Actions. Behoben in 16.4.1 und 15.5.28 vom 14. Oktober, die CVE für die DoS-Lücke (CVE-2026-94482) folgte am 22. Oktober. - **Symfony:** Drei Advisories vom 15. Oktober zu Abstürzen durch präparierte Eingaben, unter anderem über den Cache-Control-Header. Relevant für alle Anwendungen auf Symfony-Basis, also auch Shopware 6. - **Ohne Patch:** PHP 8.1 und älter, Node.js 20 und älter sowie Next.js 13 und 14. Hier hilft nur ein Versionssprung. ## PHP: php2shell (CVE-2026-109618 und CVE-2026-109619) Am 20. Oktober kündigte das PHP-Projekt ein außerplanmäßiges Sicherheitsrelease an, nachdem Details zu den Lücken vorab öffentlich geworden waren. Am 21. Oktober folgten die Updates. Beide Lücken stecken im PHP-Kern und betreffen damit jede Anwendung, die auf PHP läuft: WordPress, Shopware, Magento, Symfony- und Laravel-Projekte genauso wie selbst entwickelte Software. - **CVE-2026-109618:** Läuft PHP während der Verarbeitung einer Anfrage in einen Out-of-Memory-Fehler, können Request-Daten halb initialisiert zurückbleiben. Die anschließende Aufräumroutine behandelt sie als gültig, und daraus lässt sich Codeausführung bauen. - **CVE-2026-109619:** Zustand aus einer Anfrage überlebt den freigegebenen Speicher und wird von einer späteren Anfrage auf demselben Worker weiterverwendet (Use-after-free). Neben Codeausführung ist auch das Auslesen von Speicher bestätigt. Betroffen sind alle Varianten, die Webanfragen verarbeiten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei mod_php, weil dort eine einzige Anfrage ohne Anmeldung den Angriff auslösen kann, bevor Ihr Anwendungscode überhaupt startet. Amazon Threat Intelligence hat den ersten Angriffsversuch am 17. Oktober gesehen, vier Tage vor der Veröffentlichung, und spricht inzwischen von breiter Ausnutzung durch mehrere Akteure. ### Welche PHP-Version Sie jetzt brauchen | PHP-Linie | Status | Was zu tun ist | | --- | --- | --- | | 8.5 | unterstützt | auf 8.5.12 aktualisieren | | 8.4 | unterstützt | auf 8.4.27 aktualisieren | | 8.3 | nur Sicherheitsfixes | auf 8.3.36 aktualisieren, Upgrade auf 8.4 einplanen | | 8.2 | Sicherheitsfixes bis 31.12.2026 | auf 8.2.35 aktualisieren, Upgrade auf 8.4 vor Jahresende | | 7.4 bis 8.1 | End-of-Life | nur Quellcode-Backports oder Distributionspakete, Upgrade nötig | | 5.4 bis 7.3 | End-of-Life | kein Fix vom PHP-Projekt, Upgrade nötig | Die US-Behörde CISA empfiehlt, PHP-Systeme vom Netz zu nehmen, die sich nicht patchen lassen, ausdrücklich auch solche auf PHP 8.1 und älter. ### Übergangslösungen, bis das Update läuft Das PHP-Projekt nennt Einstellungen, die das Risiko senken. Sie ersetzen das Update nicht und müssen in der Server- oder FPM-Konfiguration gesetzt werden, damit die Anwendung sie nicht überschreiben kann. Danach alle PHP-Worker neu starten. - `memory_limit=-1` nicht überschreibbar setzen, etwa per `php_admin_value` im FPM-Pool (gegen CVE-2026-109618) - `session.upload_progress.enabled=0` in php.ini oder im FPM-Pool, nicht per `ini_set()` oder .user.ini (gegen CVE-2026-109619) - auf PHP 8.5 zusätzlich `fatal_error_backtraces=0` - `post_max_size` niedrig halten, etwa 8M ohne Datei-Uploads und 32M mit Uploads Am 23. Oktober hat das PHP-Projekt einen weiteren Hinweis zum Session-Upload-Progress nachgeschoben und eine neue Lücke (CVE-2026-115560) angekündigt, die mit dem nächsten regulären Release ein eigenes Advisory bekommt. Wer `session.upload_progress.enabled=0` setzt, ist auch dafür auf der sicheren Seite. ## Node.js: Sicherheitsupdate vom 21. Oktober Node.js hat für die drei unterstützten Linien 26.x, 24.x und 22.x zehn Lücken geschlossen. Die korrigierten Versionen sind v26.12.1, v24.22.1 und v22.23.4. Vier Lücken stuft das Projekt als hoch ein: - **CVE-2026-111497:** Out-of-Bounds-Write im mitgelieferten Brotli-Decoder, der Codeausführung erlaubt. Betroffen ist jede Anwendung, die Brotli-komprimierte Daten entpackt, etwa Antworten über fetch(). - **CVE-2026-105483 und CVE-2026-106069:** Die TLS-Prüfung des Hostnamens lässt sich mit speziell geschriebenen IP-Adressen umgehen. Damit wird ein Zertifikat für einen anderen Host akzeptiert. - **CVE-2026-105482:** dns.resolve schneidet Namen mit NUL-Zeichen ab und löst damit einen anderen Host auf als angefragt. Dazu kommen Updates gebündelter Bibliotheken (c-ares, OpenSSL, SQLite, Undici) und das Entfernen eines kompromittierten Zwischenzertifikats von eMudhra aus dem Zertifikatsspeicher. Node.js 20 und ältere Linien sind End-of-Life und bekommen diese Fixes nicht. Wer Next.js, Nuxt, NestJS oder Express auf einem eigenen Server oder in Containern betreibt, aktualisiert also nicht nur die Pakete im Projekt, sondern auch das Basis-Image beziehungsweise die Node.js-Installation auf dem Server. ## Next.js: zwei kritische RCEs und eine DoS-Lücke Am 14. Oktober hat Vercel ein außerplanmäßiges Update veröffentlicht, das zwei im September verschobene Fixes nachliefert. Patches gibt es für die beiden LTS-Linien 16.4.1 und 15.5.28. - **use cache (GHSA-673q-mjm6-r5xr), kritisch:** Anwendungen mit App Router und Cache Components, in denen eine use-cache-Funktion mehrere Typed Arrays zurückgibt, erlauben Codeausführung ohne Anmeldung. Einen Workaround gibt es nicht, Vercel empfiehlt das Update auch für Anwendungen ohne solche Funktionen. - **Bildoptimierung mit SVG (CVE-2026-96889), kritisch:** Eine Speicherlücke in der Bildbibliothek sharp erlaubt Codeausführung, wenn Next.js auf glibc-basiertem Linux läuft. Als Workaround muss sharp mindestens in Version 0.35.5 installiert sein. - **Server Actions (CVE-2026-94482), hoch:** Präparierte Anfragen lasten die CPU so aus, dass der Prozess keine weiteren Anfragen mehr bearbeitet. Betroffen sind App-Router-Anwendungen mit mindestens einer Server Action in den Versionen 13.0.0 bis 15.5.27 und 16.0.0 bis 16.4.0. Für Next.js 13 und 14 gibt es keine Patches. Wer auf diesen Versionen sitzt, muss mindestens auf 15.5 wechseln. Das ist ein echter Versionssprung mit asynchronen Request-APIs, geändertem Caching-Verhalten und React 19, den man testen und planen sollte. Wie wir Next.js-Frontends an Shopware anbinden, beschreibt unser [Beitrag zu Headless Commerce mit Next.js](https://coding9.de/blog/headless-commerce-nextjs-shopware-2026). ## Symfony und Shopware: drei Advisories vom 15. Oktober Symfony hat am 15. Oktober drei Lücken veröffentlicht, mit denen sich Prozesse durch präparierte Eingaben zum Absturz bringen lassen: einen ReDoS in HeaderUtils::split(), der ohne Anmeldung über den Cache-Control-Header erreichbar ist (CVE-2026-108082), unbegrenzte Verschachtelung im Expression-Parser (CVE-2026-109449) und unbegrenzte Rekursion im YAML-Inline-Lexer (CVE-2026-109413). Shopware 6 baut auf Symfony auf. Ein `composer update` der Symfony-Komponenten innerhalb der erlaubten Versionsgrenzen schließt die Lücken, sofern Ihre Shopware-Version eine unterstützte Symfony-Linie verwendet. Ältere Shopware-Versionen hängen an Symfony-Linien ohne Support; dazu mehr in unserem [Leitfaden zur Migration auf Shopware 6.7](https://coding9.de/blog/shopware-67-migration-leitfaden-2026). ## Was Sie jetzt tun sollten 1. **Versionen erfassen.** Notieren Sie für jedes System die PHP-, Node.js- und Next.js-Version, auch für Staging, interne Tools und Cronjob-Server. Vergessene Nebensysteme sind häufig das Einfallstor. 2. **Patchen, wo eine unterstützte Linie läuft.** PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, Node.js auf v26.12.1, v24.22.1 oder v22.23.4, Next.js auf 16.4.1 oder 15.5.28. Container-Images neu bauen, Worker neu starten. 3. **Übergangsmaßnahmen setzen, wo das Update dauert.** Die PHP-Einstellungen oben, eine WAF vor der Anwendung, im Zweifel den Zugriff auf bekannte IP-Bereiche beschränken. 4. **Logs ab dem 17. Oktober prüfen.** Auffällige Abstürze von PHP-Workern, Out-of-Memory-Meldungen, unbekannte Dateien im Webroot und ausgehende Verbindungen, die es vorher nicht gab. 5. **Legacy-Systeme einplanen.** Alles auf PHP 8.1 oder älter, Node.js 20 oder älter und Next.js 13 oder 14 bekommt einen Termin für das Upgrade. PHP 8.2 gehört gleich dazu, der Support endet am 31. Dezember 2026. Die installierten Versionen lesen Sie so aus: ```bash php -v # PHP-Version auf dem Server php -i | grep -i "server api" # FPM, mod_php oder CGI node -v # Node.js-Version npm ls next sharp # Next.js und sharp im Projekt composer show 'symfony/*' # Symfony-Komponenten ``` ## Wenn kein Patch mehr kommt: Legacy-Systeme modernisieren Ein Sicherheitsupdate innerhalb einer unterstützten Linie ist Routine. Schwierig wird es bei Systemen, die über Jahre gewachsen sind und auf einer Version stehen, für die es keine Fixes mehr gibt. Typische Gründe kennen wir aus vielen Projekten: ein Plugin, das nur mit PHP 7.4 läuft, eine Bibliothek, die den Sprung auf Node 22 nicht mitmacht, ein Next.js-Frontend, das noch auf dem Pages Router mit Version 13 steht. Ein Upgrade solcher Legacy-Systeme gehen wir in festen Schritten an. Zuerst prüfen wir den Code automatisiert auf Inkompatibilitäten, etwa mit Rector und PHPStan für PHP oder mit den Next.js-Codemods. Dann ersetzen oder aktualisieren wir Abhängigkeiten, die die neue Version blockieren. Wo Tests fehlen, sichern wir die wichtigsten Abläufe vorher mit Tests ab, damit der Versionssprung prüfbar bleibt. Am Ende steht ein System auf einer Version mit mehreren Jahren Support und eine Deployment-Pipeline, die das nächste Update zur Routine macht. Oft ist das auch der richtige Moment für mehr als den Versionssprung: veraltete Schnittstellen erneuern, ein Monolith-Modul herauslösen oder Monitoring ergänzen, damit Sie den nächsten Angriffsversuch in den Logs sehen. Was dabei für eine gute Übergabe wichtig ist, steht in unserem Beitrag zu [wartbarem Code und Übergabe](https://coding9.de/blog/wartbarer-code-und-uebergabe). ## So unterstützen wir Sie CODING 9 entwickelt und betreibt seit Jahren PHP-Anwendungen, Shopware- und Magento-Shops sowie Node.js- und Next.js-Frontends. Bei der aktuellen Sicherheitslage übernehmen wir gern: - **Sicherheits-Check:** Wir erfassen Ihre Systeme, prüfen Versionen und Konfiguration und sagen Ihnen, was sofort gepatcht werden muss. - **Patch und Übergangsmaßnahmen:** Updates einspielen, Container neu bauen, PHP-Konfiguration härten, Logs auf Spuren prüfen. - **Upgrade von Legacy-Systemen:** PHP 7.x auf 8.4, Node.js 18 oder 20 auf 24, Next.js 13 oder 14 auf 16, inklusive Tests und Deployment. - **Laufende Betreuung:** Sicherheitsupdates als Monatspaket, damit Ihr System bei der nächsten Lücke am selben Tag aktuell ist. Wenn Ihr System auf einer der betroffenen Versionen läuft, [schreiben Sie uns](https://coding9.de/kontakt?service=security-review). Wir schauen uns Ihren Stand an und melden uns mit einer Einschätzung, was jetzt zu tun ist und welcher Rahmen für ein Upgrade realistisch ist. Mehr zu unserer Arbeit an Backends und Schnittstellen finden Sie unter [Backend & Schnittstellen](https://coding9.de/leistungen/individualsoftware/backend-schnittstellen), zu Betrieb und Deployment unter [Hosting & DevOps](https://coding9.de/leistungen/devops). ## Quellen - [PHP-Projekt: News und Security-Advisory vom 20. bis 23. Oktober 2026](https://www.php.net/) - [Node.js: October 2026 Security Releases](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) - [Next.js: Security Update vom 14. Oktober 2026](https://nextjs.org/blog/nextjs-security-update-october-14-2026) - [Symfony: Security Advisories](https://symfony.com/blog/category/security-advisories) - [Tenable: php2shell FAQ mit Zeitleiste zur Ausnutzung](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote) ## Häufige Fragen ### Muss ich nach den PHP-Lücken auch WordPress, Shopware oder Magento aktualisieren? Die Lücken CVE-2026-109618 und CVE-2026-109619 stecken im PHP-Kern. Ein Update der Anwendung schließt sie nicht, dafür muss PHP selbst auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisiert werden. Bei Shared Hosting übernimmt das meist der Hoster, bei eigenen Servern und Containern Ihr Betriebsteam oder Ihre Agentur. ### Gibt es einen Patch für PHP 7.4, 8.0 oder 8.1? Eine offizielle Release-Version gibt es für diese Linien nicht mehr. Das PHP-Sicherheitsteam hat minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht, die Sie selbst kompilieren müssten. Einige Linux-Distributionen und LTS-Anbieter liefern Backports aus. Für PHP 5.4 bis 7.3 gibt es vom PHP-Projekt keinen Fix. Der dauerhafte Weg ist das Upgrade auf PHP 8.4 oder 8.5. ### Welche Node.js-Version ist nach dem Oktober-Update sicher? Die korrigierten Versionen sind v26.12.1, v24.22.1 und v22.23.4, veröffentlicht am 21. Oktober 2026. Node.js 20 und ältere Linien sind End-of-Life und bekommen keine Fixes mehr, ebenso ungerade Linien wie 25.x. ### Ist meine Next.js-Anwendung betroffen, wenn ich den Pages Router nutze? Die Denial-of-Service-Lücke in Server Actions betrifft nur den App Router mit mindestens einer Server Action, die use-cache-Lücke nur den App Router mit Cache Components. Die Lücke in der Bildoptimierung (CVE-2026-96889) betrifft dagegen alle Anwendungen, die die Image Optimization API auf glibc-basiertem Linux nutzen. Aktualisieren Sie in jedem Fall auf 15.5.28 oder 16.4.1. ### Wie schnell kann CODING 9 ein veraltetes PHP- oder Node.js-System aktualisieren? Ein Patch innerhalb einer unterstützten Linie ist meist in wenigen Stunden eingespielt und getestet. Ein Versionssprung, etwa von PHP 7.4 auf 8.4 oder von Next.js 13 auf 16, hängt vom Code, den Abhängigkeiten und den vorhandenen Tests ab. Den Umfang schätzen wir nach einem kurzen Blick auf Ihr Repository und nennen Ihnen dann einen festen Rahmen. --- Quelle: [Sicherheitslücken in PHP, Node.js und Next.js: Was Sie im Oktober 2026 patchen müssen](https://coding9.de/blog/sicherheitsluecken-php-nodejs-nextjs-oktober-2026)