---
title: Gepatcht wird nicht bei HubSpot. Sondern nebenan.
description: Der Artikel beleuchtet Sicherheitsanfälligkeiten in HubSpot-Integrationen, insbesondere bei PHP- und Node.js-Anwendungen, und gibt Handlungsanweisungen zur Risikominderung.
image: https://www.protagx.com/hubfs/Cyberpunk%20PHP%20and%20Node.js%20Data%20Fortress.png
---

[Skip to content](https://www.protagx.com/de/ddd/gepatcht-wird-nicht-bei-hubspot-sondern-nebenan#main-content)

- [Deutsch](https://www.protagx.com/de/ddd/gepatcht-wird-nicht-bei-hubspot-sondern-nebenan)
- [English](https://www.protagx.com/en/ddd/the-patch-isnt-in-hubspot-its-next-door)

 Deutsch

Dies ist ein Suchfeld mit einer automatischen Vorschlagsfunktion.

- Es gibt keine Vorschläge, da das Suchfeld leer ist.

[![protagx-logo (1024 × 300 px)](https://www.protagx.com/hubfs/logos/protagx-logo%20(1024%20%C3%97%20300%20px).svg "protagx-logo (1024 × 300 px)")](https://protagx.com?hsLang=de)

- Produkt 
    - [protagx für Hubspot, Salesforce & Co](https://www.protagx.com/de/crm)
    - [protagx Neukundenmaschine](https://www.protagx.com/de/neukundenmaschine)
    - [protagx Digital Ads Kraftwerk](https://www.protagx.com/de/crm-service-ad-conversion-machine)
    - [protagx Tag 1 CRM Schnellstart](https://www.protagx.com/de/crm-setup-services)
- Warum protagx? 
    - [Fall: Datenwälder und Seen](https://www.protagx.com/en/ddd/revolutionizing-healthcare-through-data-mesh-framework)
    - [Fall: Klinische Studien](https://www.protagx.com/en/ddd/embracing-modernization-in-clinical-trials)
- [DDD Blog](https://www.protagx.com/en/ddd) 
    - [Data Diver's Dialogs](https://www.protagx.com/en/ddd)
- Unternehmen 
    - [Über](https://www.protagx.com/de/ueber-uns)
    - [Kundendienst](https://www.protagx.com/de/support)
    - [Meine Tickets](https://portal.protagx.com/my-tickets)
    - Ressourcen 
          - [Kundenprojekte](https://www.protagx.com/de/referenzen)
          - Ebooks (demnächst)
- [Kontakt](https://www.protagx.com/de/kontakt)

- [Support](https://www.protagx.com/en/support?hsLang=de)
- [Book a Meeting](https://www.protagx.com/en/consultation?hsLang=de)
- Search

- [Hubspot](https://www.protagx.com/de/ddd/tag/hubspot),
- [Cybersecurity](https://www.protagx.com/de/ddd/tag/cybersecurity),
- [GxP-Validierung](https://www.protagx.com/de/ddd/tag/gxp-validierung),
- [Wordpress Plugin](https://www.protagx.com/de/ddd/tag/wordpress-plugin),
- [php2shell](https://www.protagx.com/de/ddd/tag/php2shell),
- [node2shell](https://www.protagx.com/de/ddd/tag/node2shell)

# Gepatcht wird nicht bei HubSpot. Sondern nebenan.

![HubSpots Referenz für CMS Serverless Functions nennt genau eine gültige Laufzeit: nodejs20.x. Node.js 20 hat am 30. April 2026 das Ende seiner Lebensdauer erreicht.](https://www.protagx.com/hubfs/Cyberpunk%20PHP%20and%20Node.js%20Data%20Fortress.png)

- Oktober 23, 2026

![Christian Schappeit](https://app.hubspot.com/settings/avatar/25b53a713bed514f3afd959a888660b9)

[Christian Schappeit](https://www.protagx.com/de/ddd/author/christian-schappeit)

*Data Divers Dialogs · Analyse*

**Eine Zertifizierungsstelle, zwei Laufzeitumgebungen, zwölf CVEs in einer Woche. Der Anbieter hat sich einmal geäußert — zu dem einen, was er gar nicht betreibt. Die verwundbarste Maschine in vielen HubSpot-Setups ist der Webhook-Empfänger, von dem der Kunde vergessen hat, dass er ihm gehört.**

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

---

Mittwochnacht, 23:31 Uhr Ostküstenzeit, schließt HubSpot auf seiner Statusseite einen Vorfall mit dem Titel *Update on PHP security vulnerability*. Der entscheidende Satz ist kurz: PHP sei nicht Teil der HubSpot-Infrastruktur, Auswirkungen auf Plattform oder Kunden seien nicht bekannt.

Das stimmt. Soweit ich sehe, war es auch das Einzige, was HubSpot in dieser Woche gesagt hat.

Dabei hätte die Woche ein paar Wortmeldungen mehr vertragen. Am Samstag, dem 17., begannen Mozilla und Google, acht Zwischenzertifikate von eMudhra zu sperren, einer öffentlich vertrauenswürdigen Zertifizierungsstelle. Deren private Schlüssel sind kompromittiert oder ableitbar, je nachdem, ob man die Browserhersteller fragt oder die CA selbst. Am Mittwoch lieferte Node.js Fixes für zehn Schwachstellen, PHP für zwei weitere mit jeweils 9,2 Punkten. Wenige Tage später hatte der Brotli-Fehler aus dem Node-Release einen Spitznamen, Node2Shell, und einen funktionierenden Exploit. Am Dienstag, dem 27., wirft Chrome eine der eMudhra-Wurzeln ganz hinaus.

Im Bundestag gibt es für so etwas die Aktuelle Stunde. Eine Fraktion verlangt sie, wenn ein Thema nicht bis zur nächsten Tagesordnung warten kann. Fünf Minuten pro Redner, am Ende kein Beschluss. Diese Woche hat das Internet eine abgehalten. Die CA hat gesprochen, die Browser, die Laufzeitprojekte, die Sicherheitsforscher. Der Redner, auf den die meisten meiner Kunden gewartet haben, sprach über PHP.

**RICHTIGE ANTWORT**

## Die Auskunft war korrekt. Gefragt war etwas anderes.

Für das eigene Haus hat HubSpot recht. Das CMS läuft nicht auf PHP, es arbeitet mit HubL, einer Template-Sprache, die von Jinja abstammt. Auf PHP läuft dagegen ein großer Teil der Kunden-Websites. Denn das HubSpot-Plugin für WordPress, das Formulare, Pop-ups und Live-Chat auf die Firmenhomepage bringt, läuft auf dem PHP, das der Betreiber der Seite darunter pflegt. Oder eben nicht pflegt.

Die Readme des Plugins nennt als Minimum PHP 7.2. Das ist keine Schwachstelle. Das ist eine Beschreibung der Kundschaft. Ein Plugin, das 7.2 noch akzeptiert, hat Nutzer auf 7.4, 8.0 und 8.1, also genau auf den Versionen, für die PHP in dieser Woche kein Release veröffentlicht hat. Das Security-Team hat dafür minimale Fixes als Git-Branches bereitgestellt.

Einen Git-Branch installiert keine Marketingleiterin. Diese Seiten hängen jetzt vollständig davon ab, dass ihr Hoster das erledigt hat.

Die Statusseite hat also die Frage „Ist HubSpot betroffen?“ vollkommen korrekt beantwortet. Geholfen hätte eine andere.

*Welche Teile unseres HubSpot-Setups betreiben wir eigentlich selbst?*

**DAS INTEGRATIONSDIAGRAMM**

## In jeder Integration steckt ein Server. Er gehört nicht HubSpot.

Fragt man einen HubSpot-Kunden, ob er Node.js betreibt, sagt er meistens nein. Er hat SaaS ja gerade deshalb gekauft.

Dann schaut man sich an, was um das Portal herum tatsächlich läuft. Der Webhook-Empfänger: HubSpot liefert Ereignisse per HTTPS-POST an eine URL, die der Kunde einrichtet und betreibt. Das OAuth-Backend: HubSpots eigene Dokumentation sagt ohne Umschweife, man müsse einen OAuth-Backend-Service aufsetzen und hosten. Die Private App, die jede Nacht mit dem ERP abgleicht. Die Pipeline, die Theme-Änderungen mit der HubSpot-CLI veröffentlicht. Der Entwickler-Laptop mit derselben CLI.

In jeder Integration, die ich für Kunden gebaut habe, läuft ein Node-Prozess, und er gehört dem Kunden. Nicht HubSpot. Nach der Übergabe auch nicht mehr mir. Dem Kunden.

> „Wir haben SaaS gekauft, damit wir keine Server betreiben müssen. Dann haben wir die Integration gebaut.“

**DIE HAUSTÜR**

## Der Webhook-Empfänger öffnet das Paket, bevor er den Absender prüft.

Node beschreibt den Brotli-Fehler nüchtern: Wer Brotli-Daten liefern kann, die eine Anwendung entpackt, kann den Prozessspeicher beschädigen. Das könne zum Absturz führen, zur Preisgabe von Speicherinhalten oder zur Ausführung von Code aus der Ferne. Forscher von Imperva melden inzwischen Codeausführung auf dem offiziellen, unveränderten Node.js-24.22.0-Image, ohne Debugger. Sie bleiben vorsichtig: Es klappte nicht bei jedem Versuch, getestet wurde eine Plattform. Theoretisch ist das Risiko trotzdem nicht mehr.

Unangenehmer ist die Frage, wer die Daten liefern darf. Express 5 und das zugehörige body-parser 2.x entpacken jeden Request-Body mit Content-Encoding: br, standardmäßig. Eine Express-5-App mit nichts als express.json() reicht einen anonymen POST direkt an den verwundbaren Decoder weiter. Express 4 hat das nie getan, es hat Brotli-Bodies abgelehnt. Wer dieses Jahr brav sein Framework aktualisiert hat, hat die Tür weiter geöffnet.

Jetzt der HubSpot-Webhook-Empfänger. Seine URL ist öffentlich, sonst käme HubSpot nicht hin. Er prüft HubSpots Signatur, wie es die Dokumentation verlangt. Aber der Body-Parser läuft vorher, als Middleware, vor der ersten Zeile des Handlers. Wenn der Code fragt, ob die Anfrage wirklich von HubSpot stammt, ist das Paket längst ausgepackt.

*Die Signaturprüfung ist weiterhin korrekt. Sie kommt nur nach dem Schaden.*

Nest.js 11 und 12 erben das über ihren Express-Adapter, Fastify ebenso, wenn @fastify/compress registriert ist. Next.js entpackt eingehende Bodies gar nicht. Es geht aber nicht darum, welches Framework sicher ist. Es geht darum, dass der Empfänger in vielen HubSpot-Setups die exponierteste Maschine ist. Und die, für die am seltensten jemand namentlich zuständig ist.

**DAS EDITIERBARE FELD**

## Im CRM sind Daten auch Konfiguration.

Die Berichterstattung begann außerdem mit drei Wegen an der TLS-Hostnamenprüfung vorbei. Liest man die Fix-Commits, schrumpft dieses Drama. Alle drei betreffen Host-Angaben, die ein nachsichtiger Parser in eine IP-Adresse verwandelt: 0x7f.0.0.1, 2130706433, 127.1, Ziffern in voller Breite. Eine Integration, die api.hubapi.com als festen String im Quellcode aufruft, ist von keiner der drei betroffen. Das darf man ruhig klar sagen. Sicherheitshinweise tun es selten.

Nur haben CRMs eine Angewohnheit, die anderer Software fehlt. Sie speichern URLs in Feldern. Die Logo-URL am Unternehmensdatensatz. Der Dokumentlink am Deal. Das Webhook-Ziel in einer eigenen Property. Der Anreicherungs-Workflow, der jene Adresse aufruft, die zufällig im Datensatz steht.

In all diesen Fällen bestimmt das Ziel einer ausgehenden Verbindung, wer ein Feld bearbeiten darf. In den meisten Portalen sind das ziemlich viele Leute, einige davon bei der Partneragentur. Und für den Brotli-Fehler muss niemand ein Zertifikat fälschen oder sich dazwischenschalten. Wer die URL eingetragen hat, betreibt einfach den Server am anderen Ende. fetch() und axios entpacken, was er schickt, und kündigen ihm das sogar vorher an.

**DAS GRÜNE DASHBOARD**

## Jeder Check meldet: alles gut. Keiner schaut hin.

Diesen Teil der Woche finde ich am lehrreichsten, weil darin niemand etwas falsch gemacht hat.

npm audit meldet: sauber. Es liest die npm-Advisory-Datenbank, und dies ist ein Fehler in Node selbst, nicht in einem Paket. Die mitgelieferte Brotli-Version hat sich ebenfalls nicht geändert, weil Node den Decoder an Ort und Stelle repariert hat, ohne die Bibliothek hochzuzählen. Gepatchtes und ungepatchtes Node melden denselben String.

Wer den Container neu baut, bekommt womöglich die alte Laufzeit zurück, denn Docker nimmt das gecachte Basis-Image, solange man nicht --pull sagt. Wer GitHub Actions um node-version: 22 bittet, bekommt die Kopie aus dem lokalen Cache des Runners, derzeit ein ungepatchtes 22.23.3. HubSpots eigene CMS-Deploy-Action verlangt 22.x und bekommt genau das. Und wer FROM node:20 baut, bekommt eine Node-Linie, die nie mehr repariert wird, eingefroren im April, mit der gesperrten Wurzel noch im Trust Store.

Jedes Werkzeug tut exakt, wofür es gebaut wurde. Zusammen ergeben sie ein grünes Dashboard über einem ungepatchten Bestand. Der verlässliche Test ist langweilig: die Node-Version, und ob require('zlib').constants.BROTLI\_DECODER\_ERROR\_FORMAT\_BLOCK\_SWITCH existiert. Die Konstante gibt es nur im reparierten Decoder.

**NODEJS20.X**

## Die eine Laufzeit, die HubSpot selbst betreibt, lässt sich jetzt messen.

Es gibt eine Stelle, an der HubSpot das Node tatsächlich selbst betreibt. Sie verdient einen genauen Blick, keinen lauten.

HubSpots Referenz für CMS Serverless Functions nennt genau eine gültige Laufzeit: nodejs20.x. Node.js 20 hat am 30. April 2026 das Ende seiner Lebensdauer erreicht. Sein letztes Release enthält Brotli 1.1.0, mitten im betroffenen Bereich, und am Mittwoch bekam es nichts. Das Node-Projekt sagt unmissverständlich, was das heißt: End-of-Life-Versionen seien bei einem Security-Release immer betroffen.

Das heißt weiterhin nicht, dass HubSpot verwundbaren Code betreibt. Vielleicht portiert HubSpot die Fixes in einen eigenen Build zurück, und ein Backport würde die Versionsnummer nicht ändern. Die Konstante schon. Damit hat die Frage zum ersten Mal einen Test: eine kleine, rein lesende Funktion ins Portal laden, einmal aufrufen, festhalten, was die Laufzeit über sich selbst sagt, wieder löschen.

Ich habe diese Funktion diese Woche geschrieben, laufen lassen und ein klares Ergebnis bekommen: Windows, Node 24.14.1, ungepatcht. Gemessen hatte sie meinen eigenen Rechner. HubSpots lokaler Entwicklungsserver führt Funktionen auf dem Rechner des Entwicklers aus. Das ist ein guter Witz und eine bessere Lektion. Das nächstgelegene ungepatchte Node war das, auf dem ich gerade tippte.

Die Messung hat noch einen Haken. CMS Serverless Functions gibt es nur in Content-Hub-Enterprise-Portalen und in Developer-Sandboxes. Viele Mittelstandskunden auf CMS Professional haben gar keine, für sie stellt sich die Frage also nicht. Für die Enterprise-Kunden, für die sie sich stellt, gehört das Ergebnis datiert in die Lieferantenakte, zusammen mit einer schriftlichen Anfrage an HubSpot. Eine von HubSpot gehostete Laufzeit habe ich bis Redaktionsschluss nicht gemessen. Diesen Satz aktualisiere ich lieber, als eine Vermutung zurückzunehmen.

**DIENSTAG, 27. OKTOBER**

## Nur eine Sache in dieser Woche hat eine Uhr.

Am Dienstagmorgen entfernt Chrome *emSign ECC Root CA – G3* aus seinem Root Store. Zertifikate, die darauf aufbauen, funktionieren dann nicht mehr.

Eine direkte Verbindung zu api.hubapi.com lieferte diese Woche ein Zertifikat von Google Trust Services, ausgeliefert über Cloudflare. HubSpots API hängt nicht an der eMudhra-Wurzel. Das gilt für einen Hostnamen zu einem Zeitpunkt. Über Ihre eigenen Endpunkte sagt es nichts: den Webhook-Empfänger, den Origin hinter Ihrem CDN, das Client-Zertifikat, das ein Partner vor drei Jahren ausgestellt hat und das seitdem niemand mehr angesehen hat.

Und irgendwann am Dienstag wirft eine Integration einen Zertifikatsfehler, der genau aussieht wie eine kaputte Integration. Die schnellste Lösung ist eine Zeile Konfiguration, die die Prüfung abschaltet. Cloudflare formuliert es mit der Geduld von jemandem, der das schon erlebt hat: Man solle diese Fehler nicht lösen, indem man die Prüfung deaktiviert.

> „Unter Termindruck sieht ein gefälschtes Zertifikat genauso aus wie eine kaputte Schnittstelle.“

### Wenn Sie Node.js neben HubSpot betreiben

- **Jedes Node finden.** Webhook-Empfänger, OAuth-Callback-Service, Sync-Jobs, CI-Pipelines, jeder Laptop mit der HubSpot-CLI. Gepatcht heißt 22.23.4, 24.22.1 oder 26.12.1 oder neuer. Alles auf 20 oder 18 hat keinen Fix und muss umziehen.
- **Den Decoder prüfen, nicht das Audit.** npm audit sieht diesen Fehler nicht. node -p "require('zlib').constants.BROTLI\_DECODER\_ERROR\_FORMAT\_BLOCK\_SWITCH" ausführen: undefined heißt ungepatcht, -17 heißt gepatcht.
- **Neu bauen, nicht nur neu starten.** docker build --pull --no-cache, gepinnte Digests anheben, weg von node:20. In GitHub Actions check-latest: true setzen oder die exakte Version pinnen. Wer HubSpots CMS-Deploy-Action nutzt, installiert das gepatchte Node in einem Schritt davor.
- **Die Haustür heute schließen.** Läuft ein Webhook-Empfänger auf Express 5 oder Nest 11–12, zuerst Node patchen. Bis dahin inflate: false an den Body-Parsern für Endpunkte setzen, die nie komprimierte Bodies erwarten, oder Content-Encoding: br am Proxy abweisen, und prüfen, dass HubSpots Zustellungen weiter ankommen. Für ausgehende Aufrufe hilft das nicht.
- **Die Felder mit URLs auflisten.** Jede Integration, die eine Adresse aus einer Kontakt-, Unternehmens- oder Deal-Property abruft: einschränken, wer das Feld bearbeiten darf, oder die erlaubten Hosts festlegen.
- **Nachsehen, wie Node installiert wurde.** Debians eigenes nodejs-Paket nutzt das System-Brotli, für das es noch keinen Fix gibt. Ein Server, der mit apt install nodejs gebaut wurde, ist ein anderes Risiko als einer mit dem offiziellen Binary oder Docker-Image.

### Wenn HubSpot-Formulare über WordPress kommen

- **Die PHP-Version nachschlagen.** In WordPress unter Werkzeuge → Website-Zustand → Bericht → Server. Auf 8.2 bis 8.5 den Hoster bitten, 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 zu bestätigen.
- **Auf 8.1 oder älter schriftlich nachfragen.** Für diese Versionen gibt es kein Release, nur Source-Backports. Der Hoster hat einen eingespielt oder nicht. Wenn nicht, jetzt das Upgrade planen; das HubSpot-Plugin steht dem nicht im Weg, die Formulare verdienen danach einen Test.
- **Das Plugin zu entfernen, behebt nichts.** Der Fehler steckt in PHP, und die Seite läuft auch ohne Plugin auf PHP.
- **Wer diese Woche nicht upgraden kann**, findet im PHP-Advisory Teilmaßnahmen, mit einer ausdrücklichen Warnung: kein RLIMIT\_AS und kein RLIMIT\_DATA. Den Hoster fragen, ob die Seite auf mod\_php läuft, wo PHP das Risiko am höchsten einstuft.

### Drei Termine für den Kalender

- **27. Oktober 2026 — Chrome entfernt die eMudhra-Wurzel.** Zertifikate, die auf *emSign ECC Root CA – G3* aufbauen, müssen bis zum Morgen ersetzt sein, auch CDN-Origins, interne Dienste und mTLS-Clients.
- **31. Dezember 2026 — PHP 8.2 erreicht das Ende seiner Lebensdauer.** Der Patch dieser Woche verschafft einer 8.2-Seite zehn Wochen.
- **8. Januar 2027 — die HubSpot-CLI verlangt Node 22.** Node 20 bekommt seit April keine Patches mehr. Arbeitsplätze und CI-Runner, die noch darauf laufen, gehören zuerst umgestellt.

**KEIN BESCHLUSS**

## Die Debatte ist vorbei. Das Change-Ticket nicht.

Eine Aktuelle Stunde endet nach der Geschäftsordnung ohne Abstimmung. Die Redner sagen ihren Teil, der Saal leert sich, formal ist nichts entschieden.

Ungefähr dort lässt die Woche einen HubSpot-Kunden zurück. Die CA hat gesprochen, die Browser haben gehandelt, die Laufzeitprojekte haben geliefert, die Forscher haben gezeigt, dass es funktioniert. Der Anbieter hat bestätigt, völlig zu Recht, dass er kein PHP betreibt.

Jede offene Entscheidung liegt in einem System, das dem Kunden gehört und das er nicht selten vergessen hat: ein Webhook-Empfänger, den seit der Übergabe durch die Agentur niemand mehr angefasst hat, der HubSpot noch immer bei jeder Kontaktänderung antwortet und noch immer jedes Paket auspackt, bevor er das Etikett liest.

---

**Zahlen und Quellen.** Node.js-Security-Release vom 21. Oktober 2026: zehn CVEs, gepatcht in v26.12.1, v24.22.1 und v22.23.4; die TLS-Hostnamenfehler sind CVE-2026-105483, CVE-2026-106069 und CVE-2026-106072, der Brotli-Fehler („Node2Shell“) CVE-2026-111497, im Upstream-Code von Google Brotli 1.0.3 bis 1.2.0, von der Google-CNA mit CVSS v4 9,2 bewertet. PHP-Release vom 21. Oktober 2026: CVE-2026-109618 und CVE-2026-109619, jeweils CVSS v4.0 9,2, behoben in 8.5.12, 8.4.27, 8.3.36 und 8.2.35; für 7.4, 8.0 und 8.1 gibt es Source-Backports als Git-Branches, keine Releases. Ende der Lebensdauer von Node.js 20: 30. April 2026; das letzte Release 20.20.2 enthält Brotli 1.1.0. @hubspot/api-client 14.0.1 deklariert engines.node \>=22.0.0. Die HubSpot-CLI beendet die Unterstützung für Node 20 am 8. Januar 2027. CMS Serverless Functions setzen Content Hub Enterprise oder eine CMS-Developer-Sandbox voraus.

Zur Belastbarkeit. CVE-Liste, Versionen und Daten stammen von den Seiten der Hersteller und sind gesichert. Das Ergebnis zur Codeausführung stammt von Imperva, auf dem offiziellen Node.js-24.22.0-Image für Linux arm64; Imperva schreibt, es sei nicht bei jedem Versuch gelungen und nicht jeder Build getestet worden. Ausnutzung in freier Wildbahn ist nicht gemeldet. Das Verhalten von Express 5 wurde im veröffentlichten Quellcode von body-parser 2.x nachgelesen; dass der Parser vor der Signaturprüfung eines Handlers läuft, folgt aus der Reihenfolge der Express-Middleware und ist eine Schlussfolgerung, kein getesteter Angriff auf einen HubSpot-Empfänger. Der Befund zum setup-node-Cache bezieht sich auf das GitHub-Runner-Image ubuntu-24.04 20261012. Ob HubSpots gehostete Laufzeit nodejs20.x einen zurückportierten Fix enthält, ist nicht belegt; HubSpot hat sich zum Node.js-Release und zum eMudhra-Vorfall nicht geäußert, und dieses Schweigen wird hier weder als Entwarnung noch als Alarm gelesen. Die Zertifikatsbeobachtung für api.hubapi.com beruht auf einer einzelnen Verbindung am 23. Oktober. Das „Requires PHP: 7.2“ des WordPress-Plugins stammt aus einem Spiegel der Readme auf wordpress.org. „Node2Shell“ ist ein kursierender Name, nicht die Bezeichnung des Node-Projekts.

Primärquellen: [HubSpot-Status: Update on PHP security vulnerability](https://status.hubspot.com/incidents/1vjy2fdyvnv5) · [Node.js: October 2026 Security Releases](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) · [PHP: Sicherheitshinweis vom 21. Oktober 2026](https://www.php.net/archive/2026.php) · [HubSpot: Getting started with serverless functions](https://developers.hubspot.com/docs/cms/start-building/features/serverless-functions/getting-started-with-serverless-functions) · [eMudhra: Statement on Recent Certificate Security Incident](https://emudhra.com/en/post/certificate-security-incident) · [Mozilla Security Blog](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/) · [Google: Schutz für Chrome- und Android-Nutzer](https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/) · [Cloudflare: 8 eMudhra certificates are compromised](https://blog.cloudflare.com/emudhra-certificate-compromise).

Tags: HubSpot, Node2Shell, Express 5, eMudhra, PHP, Lieferantenmanagement, GxP

— Ende —

 Related Posts

## You may also like this

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique.

[![Gearbeitet hat der Agent. Unterschrieben haben Sie.](https://www.protagx.com/hubfs/Gemini_Generated_Image_szokxbszokxbszok.jpg)](https://www.protagx.com/de/ddd/gearbeitet-hat-der-agent.-unterschrieben-haben-sie?hsLang=de)

[Claudeforce](https://www.protagx.com/de/ddd/tag/claudeforce), [Agentforce](https://www.protagx.com/de/ddd/tag/agentforce), [Audit-Trail](https://www.protagx.com/de/ddd/tag/audit-trail), [GxP-Validierung](https://www.protagx.com/de/ddd/tag/gxp-validierung), [Annex 11](https://www.protagx.com/de/ddd/tag/annex-11)

### [Gearbeitet hat der Agent. Unterschrieben haben Sie.](https://www.protagx.com/de/ddd/gearbeitet-hat-der-agent.-unterschrieben-haben-sie?hsLang=de)

 September 4, 2026

 Data Divers Dialogs · Analyse · Von Christian Schappeit · September 2026 · ca. 7 Min. Lesezeit

[Read more](https://www.protagx.com/de/ddd/gearbeitet-hat-der-agent.-unterschrieben-haben-sie?hsLang=de)

[![Die Tür, an die niemand mehr dachte.](https://www.protagx.com/hubfs/AI-Generated%20Media/Images/Server%20Room%20in%20Overgrown%20Berlin%20Building%20with%20Open%20Door%20and%20Light.png)](https://www.protagx.com/de/ddd/die-t%C3%BCr-an-die-niemand-mehr-dachte?hsLang=de)

[Cybersecurity](https://www.protagx.com/de/ddd/tag/cybersecurity), [Schatten IT](https://www.protagx.com/de/ddd/tag/schatten-it), [Governance](https://www.protagx.com/de/ddd/tag/governance), [Berlin](https://www.protagx.com/de/ddd/tag/berlin), [Verwaltung](https://www.protagx.com/de/ddd/tag/verwaltung), [Digitalisierung](https://www.protagx.com/de/ddd/tag/digitalisierung)

### [Die Tür, an die niemand mehr dachte.](https://www.protagx.com/de/ddd/die-t%C3%BCr-an-die-niemand-mehr-dachte?hsLang=de)

 August 19, 2026

 Data Divers Dialogs

[Read more](https://www.protagx.com/de/ddd/die-t%C3%BCr-an-die-niemand-mehr-dachte?hsLang=de)

[![Auf der Welle reiten: Wie clevere Unternehmen 2026 vorne bleiben](https://www.protagx.com/hubfs/Canva%20images/protagx%20blog%20(Blog%20Banner)%2014.jpg)](https://www.protagx.com/de/ddd/how-smart-businesses-stay-ahead-in-2026?hsLang=de)

[Trends](https://www.protagx.com/de/ddd/tag/trends), [CRM](https://www.protagx.com/de/ddd/tag/crm), [AI](https://www.protagx.com/de/ddd/tag/ai), [Dynamics365](https://www.protagx.com/de/ddd/tag/dynamics365), [Hubspot](https://www.protagx.com/de/ddd/tag/hubspot), [Salesforce](https://www.protagx.com/de/ddd/tag/salesforce)

### [Auf der Welle reiten: Wie clevere Unternehmen 2026 vorne bleiben](https://www.protagx.com/de/ddd/how-smart-businesses-stay-ahead-in-2026?hsLang=de)

 Januar 7, 2026

 Sieben Tage ins neue Jahr, und die Spielregeln haben sich bereits geändert. Hier ist, warum die Marktführer davonziehen...

[Read more](https://www.protagx.com/de/ddd/how-smart-businesses-stay-ahead-in-2026?hsLang=de)

 Free Guide

### How to increase your Facebook reach by over 200% with this simple trick

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique.

[Download Guide](https://484997.hs-sites.com/lively/contact)

### Subscribe to our newsletter

[![protagx-logo (1024 × 300 px)](https://www.protagx.com/hubfs/logos/protagx-logo%20(1024%20%C3%97%20300%20px).svg "protagx-logo (1024 × 300 px)")](https://protagx.com?hsLang=de)

Christian Schappeit - Unternehmensberatung für Digital Business Consulting und Datenintegration.

Als erfahrener CRM-Integrationsexperte und CMS-Stratege bin ich spezialisiert auf den Einsatz führender CRM-Plattformen wie Hubspot und Salesforce Health Cloud, ergänzt durch leistungsfähige Integrationstools wie Mulesoft. Mein Schwerpunkt liegt auf der Konzeption, Implementierung und Optimierung von datengesteuerten CRM-Systemen, die speziell für Unternehmen im Gesundheitswesen und in der Forschung entwickelt wurden. Ich bringe fundiertes Fachwissen bei der Erstellung und Verfeinerung von CRM-Strategien, der Verwaltung der nahtlosen Integration von CPQ-Prozessen und der Entwicklung effektiver Plattformen für Kunden- und Patientenbeziehungen mit, die die Patientenversorgung und Kundenzufriedenheit verbessern sollen.

#### Pages

- [Home](https://www.protagx.com/en/)
- [About](https://www.protagx.com/de/ueber-uns)
- [Support](https://www.protagx.com/en/support)
- [Contact](https://www.protagx.com/de/kontakt)

#### Resources

- CRM Experts
- Smart Tagging
- Services
- [Blog](https://www.protagx.com/en/ddd)

[Customer Support](https://www.protagx.com/en/support?hsLang=de)

---

- [Geschäftsbedingungen](https://www.protagx.com/de/terms-of-service)
- [Datenschutz](https://www.protagx.com/de/privacy-policy)
- [Impressum](https://www.protagx.com/de/impressum)

 follow protagx on social media [Follow us on LinkedIn](https://www.linkedin.com/showcase/protagx) [Follow us on Twitter](https://x.com/protagxcom) [Follow us on Facebook](https://www.facebook.com/protagx) [Follow us on Facebook](https://www.instagram.com/instaprotagx) [Follow us on Facebook](https://www.youtube.com/@protagx)

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Christian Schappeit",
    "url" : "https://www.protagx.com/de/ddd/author/christian-schappeit"
  },
  "dateModified" : "2026-10-23T18:04:00.018Z",
  "datePublished" : "2026-10-23T17:47:53.000Z",
  "headline" : "Gepatcht wird nicht bei HubSpot. Sondern nebenan.",
  "image" : [ "https://www.protagx.com/hubfs/Cyberpunk%20PHP%20and%20Node.js%20Data%20Fortress.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://www.protagx.com/de/ddd/gepatcht-wird-nicht-bei-hubspot-sondern-nebenan",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://www.protagx.com/hubfs/protagx-logo%20(1024%20%C3%97%20300%20px).svg"
    },
    "name" : "protagx Inh. Christian Schappeit"
  }
}
```