Wir haben kein PHP. Ihre Website schon.

Data Divers Dialogs · Analyse

Der meistgesagte Satz der Oktober-Lücken stimmte fast überall, wo er fiel. Er beschrieb das Team. Die Angreifer haben sich nur für die Server interessiert.

Von Christian Schappeit · Data Divers Dialogs · Oktober 2026 · ca. 6 Min. Lesezeit

Mittwochnacht, 21. Oktober, schließt HubSpot auf seiner Statusseite einen Vorfall mit einem Satz: PHP sei nicht Teil der HubSpot-Infrastruktur. Das stimmte. Bis zum Wochenende war daraus der Satz der Woche geworden, in etwas kürzerer Form.

Wir haben JS, kein PHP.

Ich habe ihn seitdem in irgendeiner Fassung von fast jedem Team gehört, mit dem ich gesprochen habe. Er fällt mit Erleichterung, so wie man sagt, man habe nicht in dem Flugzeug gesessen. Meistens stimmt er auch. Er beantwortet nur eine Frage, die niemand gestellt hat.

Vier Tage bevor PHP überhaupt etwas veröffentlichte, am Samstag, dem 17. Oktober, ging bei einem Honeypot von Amazon eine Anfrage ein, die genau auf diese Lücke zielte. Der Rechner, der sie schickte, hat nicht gefragt, welche Sprache die Entwickler am Ziel bevorzugen. Er hat gefragt, was antwortet.

DIE WEBSITE

Der eine Server, den niemand einzeichnet.

Fragt man ein Entwicklungsteam nach seiner Architektur, bekommt man die Systeme, die es baut, also Services und die CRM-Integration. Selten die Marketing-Website. Die gehört dem Marketing, wurde von einer Agentur gebaut und läuft auf WordPress bei einem Hoster, dessen Rechnung an eine andere Abteilung geht.

Auf genau dieser Website stehen die HubSpot-Formulare. Das Plugin, das sie dorthin bringt, läuft auf dem PHP darunter. HubSpots Trust Center hat diese Woche bestätigt, dass das Plugin selbst keinen Patch braucht. Das ist richtig und handelt, wie der Satz vom Mittwoch, von PHP.

Das Problem ist das PHP. Amazon beschreibt die Lücken inzwischen als „breit ausgenutzt“, watchTowr meldet Versuche gegen beide CVEs. Welche davon erfolgreich waren, hat niemand gezeigt. WordPress.org ging weiter, als Plattformen das sonst tun: Selbst gehostete Seiten auf PHP älter als 8.2 sollten erwägen, die Seite vom Netz zu nehmen, während sie das Update vorbereiten. Eine dritte CVE vom 23. Oktober beheben die Releases dieser Woche überhaupt nicht.

„Wir haben JS, kein PHP“ ist ein Satz über das Team. Angriffsfläche ist ein Satz über Server.

DIE ANDERE HÄLFTE

Und wer JS hat, hatte die schlechtere Woche.

Diesen Teil überspringt die Erleichterung gern. „Kein PHP“ heißt nur, dass es einen bei den anderen drei erwischt.

Am 23. Oktober wurde das Advisory für body-parser öffentlich. Eine einzige Anfrage mit komprimiertem Body und ein paar angehängten Bytes beendet den Node-Prozess. Gzip reicht, also trifft es Express 4 genauso wie Express 5. Der Parser läuft vor dem Routing, niemand braucht Login oder gültige Route. Ein HubSpot-Webhook-Empfänger kommt gar nicht bis zur Signaturprüfung. Er steht einfach. Am Freitag habe ich Express 4 noch als die sicherere Version beschrieben. Für diesen Fehler ist sie es nicht.

Next.js hatte derweil zwei kritische Lücken ohne Login, eine im Bild-Optimizer, eine in use cache. Der Fix ist ein Versionssprung, 16.4.3 oder 15.5.28. Einen Haken gibt’s allerdings. Auf der 15er-Linie kann ein altes sharp das Upgrade in der Lockfile überleben. Next.js 15 hat am 21. Oktober ohnehin den Support verlassen.

Und dann ist da Node2Shell, die Lücke mit dem kinoreifen Namen, dem funktionierenden Exploit und der meisten Berichterstattung. Bestätigte Opfer gibt es bisher keine. Der Fehler, den alle beim Namen nennen konnten, hat noch niemandem geschadet. Die, die heute einen Empfänger abschalten können, haben nur Nummern.

FÜNF STELLEN

„JS“ wird an fünf Stellen gepatcht.

Das andere Problem mit „Wir haben JS“ ist, dass es nach einem einzigen Posten klingt. Tatsächlich sind es die Node-Laufzeit, die npm-Pakete, das Framework, das Docker-Image und der CI-Runner, und jede Stelle wird woanders gepatcht und anders geprüft.

npm audit prüft die Pakete. Für den body-parser-Absturz ist es ein gültiger Nachweis, zu Node2Shell schweigt es, weil der Fehler in Node steckt und nicht in einem Paket. Der Docker-Build kann still ein altes Basis-Image wiederverwenden. GitHubs gehostetes Runner-Image vom 23. Oktober liefert weiterhin ungepatchtes Node 22 und 24, wer node-version: 22 schreibt, bekommt also ein ungepatchtes Build. Debians eigenes nodejs-Paket gilt weiterhin als verwundbar. Jeder dieser Checks kann über einem ungepatchten Bestand grün leuchten.

Für diese Art Verdrängung braucht es keinen Starrsinn. Ein Dashboard, das einem recht gibt, reicht völlig.

DIE NACHTSCHICHT

Ich habe eine Routine geschrieben, die meinem Bauchgefühl widerspricht.

Die Nacht nach dem Freitagsartikel habe ich damit verbracht, all das in ein Verfahren zu übersetzen, das in jedem Repository läuft und ein Protokoll hinterlässt. Das Bauchgefühl sagte: mit Node anfangen, Node war die Schlagzeile. Die Routine beginnt mit body-parser, weil der heute einen Prozess auf beiden Express-Versionen abschießen kann. Dann Next.js, dann die Laufzeit, dann Zertifikate, PHP, Images und CI. HubSpot kommt zuletzt, weil der Kunde dort messen, aber nicht patchen kann.

Sie misst, bevor sie etwas ändert, denn eine Versionsnummer belegt eine Installation, keinen ausgetauschten Decoder. Sie weigert sich, einen Zertifikatsfehler durch Abschalten der Prüfung zu beheben. Und sie meldet Node 20 oder PHP 8.1 als Risiko mit einem Verantwortlichen, nicht als erledigte Arbeit. Klug ist daran nichts. Ein Dashboard schlägt diese Reihenfolge bloß nie vor.

EMUDHRA

Die Einzigen, die eine Konsequenz gezogen haben, sind gegangen.

In einer Woche voller „nicht unser Problem“ hat eine Firma etwas anderes gesagt. Am 22. Oktober beschloss der Vorstand von eMudhra, sich „freiwillig aus dem globalen SSL/TLS-Zertifikatsgeschäft zurückzuziehen“. Das Geschäft machte etwa 1 % des Umsatzes aus. Mozillas Analyse hatte ergeben, dass einige der betroffenen privaten Schlüssel ganze Zahlen unter 256 waren. So eine Zahl probiert man vor dem Mittagessen von Hand durch.

Chrome entfernt die G3-Wurzel von eMudhra am 27. Oktober. Über den Rest entscheidet Google noch.

Und HubSpot dokumentiert der Vollständigkeit halber weiterhin nodejs20.x als einzige Serverless-Laufzeit, auf einer Node-Linie ohne weitere Fixes, und hat zu Node.js und eMudhra weiterhin nichts gesagt. Seine beiden Stellungnahmen der Woche betrafen PHP. Beide stimmten.

Wenn Sie JS betreiben

Zuerst body-parser. 1.20.9 oder 2.4.0, auf Express 4 und 5. npm update body-parser, Lockfile committen. Bis dahin inflate: false, wo Endpunkte nie komprimierte Bodies empfangen.

Dann Next.js. 16.4.3 oder 15.5.28, danach npm ls sharp: 0.35.5 oder neuer. Den Abschied von 15 planen.

Dann Node. 22.23.4, 24.22.1 oder 26.12.1. Mit der zlib-Konstante prüfen, nicht mit dem Audit.

Dann die Stellen, die keiner prüft. docker build --pull, check-latest: true im CI, das offizielle Node-Binary statt Debians Paket.

Wenn Ihre Website auf WordPress läuft

Als angegriffen behandeln. Die PHP-Version unter Website-Zustand nachsehen. Unter 8.2 ohne bestätigten Backport des Hosters: den Rat von WordPress.org erwägen und die Seite bis zum Update vom Netz nehmen.

session.upload_progress.enabled=0 setzen. Das deckt die dritte CVE ab, für die es noch keinen Fix gibt.

Das HubSpot-Plugin in Ruhe lassen. Es braucht keinen Patch. Das PHP darunter schon.

Den Hoster fragen, an welchem Tag er gepatcht hat.

Termine für den Kalender

27. Oktober 2026: Chrome entfernt die eMudhra-G3-Wurzel. Eine zweite Welle für die übrigen Wurzeln ist möglich.

31. Dezember 2026: PHP 8.2 erreicht das Ende seiner Lebensdauer.

8. Januar 2027: die HubSpot-CLI verlangt Node 22.

ZURÜCK ZUM HONEYPOT

Ihr Architekturbild liest niemand.

„Wir haben JS, kein PHP“ stimmt in den meisten Unternehmen, die ich kenne. Es ist eine völlig brauchbare Beschreibung dafür, wer was schreibt. Es ist nur keine Beschreibung dafür, was erreichbar ist, und entschieden wurde diese Woche ausschließlich über das Zweite.

Am 17. Oktober hat irgendwo ein Rechner eine einzige Anfrage ins Netz geschickt und abgewartet, was antwortet.

Ihre Website hat geantwortet.

Zahlen und Quellen. HubSpot-Statusvorfall „Update on PHP security vulnerability“, gelöst, 21. Oktober 2026, 23:31 Uhr EDT. PHP CVE-2026-109618 und CVE-2026-109619, behoben am 21. Oktober; CVE-2026-115560 vom 23. Oktober, in diesen Releases nicht behoben. body-parser CVE-2026-111181 / GHSA-27r3-jxmh-p828: CVSS 3.1 7,5, betroffen 2.0.0 bis unter 2.4.0 und alle Versionen unter 1.20.9, veröffentlicht am 23. Oktober. Next.js CVE-2026-96889 / GHSA-2464-fhr4-w9xw: CVSS v4 9,5, glibc-Linux, setzt sharp 0.35.5 voraus; GHSA-673q-mjm6-r5xr (use cache, 16.x); Zielversionen 16.4.3 oder 15.5.28. Node.js CVE-2026-111497 („Node2Shell“), behoben in 22.23.4, 24.22.1 und 26.12.1. Ausstieg von eMudhra angekündigt am 22. Oktober 2026. Entfernung von emSign ECC Root CA - G3 aus Chrome ab 27. Oktober 2026.

Zur Belastbarkeit. Die Meldungen zur Ausnutzung der PHP-Lücken stammen von Amazon Threat Intelligence (berichtet von Tenable, 23. Oktober) und von watchTowr; keine zeigt eine erfolgreiche Kompromittierung, und CISA hatte die CVEs bis 23. Oktober nicht gelistet. Für Node2Shell gab es Stand 23./24. Oktober keine bestätigte Ausnutzung in freier Wildbahn (Sysdig, The Hacker News). Die Empfehlung von WordPress.org, die Aussage des HubSpot Trust Center zum Plugin, Mozillas Befund zur Schlüsselgröße, der Inhalt des GitHub-Runner-Images und der Status des Debian-Pakets nodejs wurden am 25. Oktober in protagx' eigener Remediation-Recherche geprüft und werden von dort zitiert. Das Support-Ende von Next.js 15 folgt der Support-Policy von Next.js, wie berichtet. Dass der Satz von vielen Teams zu hören war, ist eine Beobachtung des Autors, keine Umfrage.

Primärquellen: HubSpot-Status: Update on PHP security vulnerability · Tenable: php2shell FAQ · watchTowr: PHP2Shell · OSV: body-parser GHSA-27r3-jxmh-p828 · OSV: Next.js GHSA-2464-fhr4-w9xw · Node.js: October 2026 Security Releases · Sysdig: Node2Shell · eMudhra: Ausstieg aus dem globalen SSL/TLS-Geschäft · The Record · Debian Security Tracker: brotli.

Tags: HubSpot, WordPress, PHP2Shell, body-parser, Next.js, Angriffsfläche, Change-Management

Ende