Wenn dein HubSpot-Portal Workflows mit benutzerdefiniertem Code nutzt, musst du jetzt handeln: Diese Aktionen laufen auf Node.js-Versionen, die eine aktuelle Sicherheitslücke nicht mehr geschlossen bekommen. HubSpot hat dafür Anfang November eine Sicherheitsmail an Super Admins und Sicherheitskontakte verschickt. Viele dieser Mails gehen im Postfach unter oder landen bei jemandem, der mit Node.js wenig anfangen kann.
In diesem Artikel erklären wir, was hinter der Lücke steckt, wie groß das Risiko wirklich ist und wie du deine Workflows Schritt für Schritt absicherst. Wir setzen das gerade in unserem eigenen Portal und bei unseren Kunden um und teilen, worauf du achten solltest.
Am 21. Oktober 2026 hat das Node.js-Projekt Sicherheitsupdates für die Versionen 22, 24 und 26 veröffentlicht. Die wichtigste Lücke steckt im Brotli-Decoder, den Node.js mitliefert: CVE-2026-111497, von Sicherheitsfirmen „Node2Shell“ getauft. Verarbeitet Node.js manipulierte Brotli-Daten, kann ein Angreifer im schlimmsten Fall eigenen Code ausführen.
Das Problem für HubSpot-Nutzer: Custom-Code-Aktionen in Workflows laufen bisher auf Node.js 16 oder 20. Diese Versionen sind End of Life und bekommen keinen Fix mehr. HubSpot stellt deshalb eine abgesicherte Node.js-24-Umgebung bereit.
Aber: HubSpot stellt bestehende Aktionen nicht automatisch um. Die Umstellung kann Code-Anpassungen erfordern und Workflows brechen, deshalb liegt sie bei dir.
Für die meisten Portale ist die Wahrscheinlichkeit eines Angriffs gering, der mögliche Schaden aber hoch. Laut HubSpot gibt es bisher keine Hinweise auf eine Ausnutzung. Gleichzeitig haben Forscher von Imperva gezeigt, dass sich auf einem offiziellen Node.js-Build Code einschleusen lässt. Es klappte allerdings nicht bei jedem Versuch.
Eine exakte Prozentzahl kann seriös niemand nennen. Für einen erfolgreichen Angriff müssen aber mehrere Bedingungen zusammenkommen:
fetch(). Dabei läuft der anfällige Brotli-Decoder automatisch.Gelingt das, sind vor allem deine Secrets in Gefahr: API-Keys, Private-App-Tokens und Zugangsdaten zu Drittsystemen. Ein abgegriffener Token mit Schreib- oder Löschrechten richtet deutlich mehr Schaden an als der Workflow selbst.
| Dein Custom Code … | Wahrscheinlichkeit | Was du tun solltest |
|---|---|---|
| ruft nur die HubSpot-API auf | sehr gering: Ein Angreifer müsste HubSpot selbst kompromittieren | Secrets rotieren, in Ruhe auf Node.js 24 umstellen |
| ruft etablierte Dritt-APIs auf (z. B. Enrichment, ERP) | gering: Der Anbieter müsste kompromittiert werden | Secrets rotieren, zeitnah umstellen |
| ruft URLs auf, die aus Daten stammen (z. B. Website-Adressen aus Firmendatensätzen, Webhooks) | erhöht: Jeder, der eine URL in dein CRM bringt, kontrolliert die Antwort | Workflow sofort ausschalten, Secrets rotieren, erst nach Umstellung wieder einschalten |
Der dritte Fall wird oft übersehen: Ruft ein Workflow etwa die Website eines neuen Leads auf, um Daten auszulesen, entscheidet im Zweifel ein Fremder, was dein Code verarbeitet.
Bei Workflows mit mehreren Code-Aktionen, Verzweigungen und Abhängigkeiten zu anderen Systemen solltest du nicht einfach die Runtime umschalten und hoffen. So gehst du strukturiert vor:
Kann ein geschäftskritischer Workflow nicht pausieren, rotiere die Secrets sofort und reduziere die Token-Berechtigungen auf das Nötigste. Ruft er nur die HubSpot-API auf, ist es vertretbar, ihn bis zur Umstellung weiterlaufen zu lassen. Ruft er URLs aus Daten auf, solltest du ihn trotzdem ausschalten.
HubSpot bringt dafür einen passenden Filter mit:
Prüfe dabei sowohl aktive als auch ausgeschaltete Workflows. Auch inaktive brauchen die Umstellung, sonst laufen sie beim Wiedereinschalten mit der alten Runtime.
Unser Tipp: Speichere die gefilterte Liste als eigene Ansicht, zum Beispiel „Custom Code – Node-Migration“. So hakst du den Fortschritt sauber ab. Welche Node-Version eine Aktion nutzt, siehst du in der Aktion selbst unter Sprache.
Priorisiere zuerst Workflows, die externe Server aufrufen oder mit mächtigen Tokens arbeiten. Dann gehst du pro Workflow so vor:
HubSpot prüft oder debuggt keinen Custom Code. Für Code-Fragen ist das HubSpot Developer Forum die erste Anlaufstelle, oder du holst dir Unterstützung von einem Partner.
Tests laufen echt. „Aktion testen“ führt den Code wirklich aus. Löscht oder überschreibt dein Workflow Datensätze, passiert das auch beim Test. Teste solche Aktionen deshalb nur mit einem eigens angelegten Dummy-Datensatz.
Tokens hängen oft an mehreren Stellen. Ein Private-App-Token wird gerne auch in Make, Zapier oder anderen Integrationen genutzt. Rotierst du ihn, ohne das zu prüfen, brechen diese Verbindungen. Kläre vorher, wo der Token überall im Einsatz ist.
Ausgeschaltete Workflows werden vergessen. Wer nur aktive Workflows filtert, übersieht Altlasten. Die laufen dann irgendwann wieder an, mit alter Runtime und alten Secrets.
Die Umstellung auf Node.js 24 ist kein Hexenwerk, aber sie erledigt sich nicht von selbst. Mit dem Filter „Aktionstyp“ hast du in wenigen Minuten den Überblick. Secrets zu rotieren kostet wenig und bringt viel.
Du willst das nicht selbst machen oder bist unsicher, was dein Custom Code genau tut? Als HubSpot Platinum Partner prüfen wir dein Portal, priorisieren die betroffenen Workflows und übernehmen die Migration inklusive Tests. Sprich uns an.