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.
Was ist passiert?
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.
Wie groß ist das Risiko wirklich?
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:
- Dein Code ruft einen Server auf und verarbeitet dessen Antwort, etwa per
fetch(). Dabei läuft der anfällige Brotli-Decoder automatisch.
- Dieser Server wird vom Angreifer kontrolliert oder wurde kompromittiert.
- Der Angreifer weiß, dass dein Workflow diesen Server abfragt, und liefert gezielt manipulierte Daten aus.
- Der Exploit funktioniert in HubSpots Laufzeitumgebung.
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.
Was tun bei komplexen Workflows?
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:
- Inventur pro Aktion. Notiere, welche Endpunkte der Code aufruft, welche Pakete und Secrets er nutzt und welche Ausgaben nachgelagerte Schritte verwenden.
- Mit einer Kopie arbeiten. Klone den Workflow, stelle im ausgeschalteten Klon auf Node.js 24 um und teste dort. Mit Enterprise-Lizenz eignet sich dafür auch ein Sandbox-Portal.
- Ausgaben prüfen. Verzweigungen und Folgeaktionen hängen oft an den Ausgabefeldern einer Code-Aktion. Ändern sich Feldnamen oder Datentypen, laufen Datensätze still in den falschen Zweig.
- Paketversionen mitziehen. Prüfe auch die Version des HubSpot-Clients und weiterer Bibliotheken, die dein Code nutzt.
- Schrittweise live gehen. Stelle einen Workflow nach dem anderen um und kontrolliere danach den Verlauf auf Fehler.
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.
So findest du die betroffenen Workflows
HubSpot bringt dafür einen passenden Filter mit:
- Öffne Automatisierung → Workflows.
- Klicke in der Filterleiste auf Aktionstyp.
- Wähle Benutzerdefinierter Code.
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.
Schritt für Schritt: So sicherst du deine Workflows ab
Priorisiere zuerst Workflows, die externe Server aufrufen oder mit mächtigen Tokens arbeiten. Dann gehst du pro Workflow so vor:
- Workflow ausschalten. Lies den Dialog beim Ausschalten genau, damit mit den eingeschriebenen Datensätzen nichts Ungewolltes passiert.
- Secrets rotieren. Generiere den Private-App-Token oder API-Key neu und aktualisiere das Secret in HubSpot. Das gilt auch für Tokens von Drittanbietern.
- Runtime auf Node.js 24 umstellen. Wähle in der Aktion unter „Sprache“ Node.js 24 und prüfe, ob der Code angepasst werden muss. Stolpersteine sind meist veraltete Pakete, seltener Node.js selbst.
- Testen. Nutze „Aktion testen“ mit einem passenden Testdatensatz.
- Workflow wieder einschalten. Schreibe bestehende Datensätze nur dann nachträglich ein, wenn du das wirklich willst.
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.
Drei Stolperfallen aus der Praxis
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.
Fazit: Jetzt handeln, aber mit Plan
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.
Quellen
