RCE-Risikoscan für Node-Apps: gefährlichen Code schnell erkennen

Wie RCE in einer echten Node-App aussieht

Remote Code Execution (RCE) bedeutet, dass ein Angreifer Ihren Server dazu bringen kann, Code auszuführen, den Sie nicht beabsichtigt haben. Nicht nur eine Datei lesen oder ein Token stehlen, sondern tatsächlich Kommandos ausführen oder Code laden, wodurch er Kontrolle gewinnt. Wenn Ihre App über das Internet erreichbar ist, ist RCE einer der schnellsten Wege von einem kleinen Fehler zur vollständigen Übernahme.

In Node-Apps zeigt sich RCE oft, wenn untrusted Input wie Anweisungen behandelt wird. Ein klassisches Beispiel ist eine „Führe ein Tool für mich aus“-Funktion: ein Nutzer sendet Text, der Server baut einen Shell-Befehl und child_process führt ihn aus. Wenn der Code nicht strikt einschränkt, was erlaubt ist, kann eine manipulierte Anfrage den Befehl komplett umbiegen.

KI-generierter Code enthält häufiger riskante Abkürzungen, weil er hilfreich sein will. Er kann eval zum „Parsen“ von Daten hinzufügen, Shell-Befehle mit Template-Strings bauen oder Module dynamisch anhand eines Request-Parameters laden. Solche Muster mögen im Demo funktionieren, sind in Produktion aber gefährlich.

Ein Risikoscan ist ein schnelles Mittel, Code zu finden, der Eingaben möglicherweise ausführt. Er sagt Ihnen, wo Sie zuerst nachschauen sollten — nicht, ob Sie zu 100 % sicher sind. Jeder Fund erfordert eine manuelle Prüfung, um zu bestätigen, ob Nutzereingaben tatsächlich die riskante Zeile erreichen können.

Angreifer erreichen RCE typischerweise über alltägliche Eintrittspunkte:

• HTTP-Requests (Query, Body, Headers)
• Datei-Uploads (Namen, Pfade, Inhalte)
• Webhooks (Drittanbieter-„Events“, denen Sie zu sehr vertrauen)
• Admin-Panels (geringere Kontrolle, mächtige Aktionen)
• Hintergrundjobs (Nachrichten aus Queues oder Cron-Eingaben)

Wo untrusted Input in Ihren Code gelangt

Die meisten RCE-Bugs beginnen gleich: Ihre App behandelt fremde Daten, als wären sie sicher. Beim Scannen auf RCE-Risiken in einer Node-App sollten Sie alle Stellen kartieren, an denen Daten eintreten — selbst wenn sie „normalerweise" von Ihrem Team kommen.

Die offensichtlichen Eintrittspunkte sind HTTP-Requests. Alles, was ein Nutzer ändern kann, ist untrusted: Query-Strings, Route-Parameter, JSON-Bodies, Formular-Posts, Headers (besonders wenn sie für Feature-Flags oder Debug-Modi genutzt werden), Cookies, Session-Daten und hochgeladene Dateien (inklusive Dateinamen).

Nicht alle Inputs kommen übers Web. Schnelle Prototypen beinhalten oft Hilfsskripte und Admin-Funktionen, die normale Checks umgehen und später in Produktion landen. Achten Sie auf Hintergrundjobs und Cron-Tasks, die Daten aus einer DB ziehen, Message-Queues, Webhook-Payloads von Drittanbietern, Admin-Panels und „nur-intern“-Endpoints sowie CLI-Skripte, die Argumente akzeptieren oder Umgebungsvariablen lesen.

„Interne Tools“ sind nicht irrelevant. Tokens werden gestohlen, VPNs missbraucht und ein einziges geleaktes Admin-Cookie kann einen internen Endpoint ins Internet stellen.

Ein nützliches Modell ist:

input -> parsing -> execution

Parsing ist, wo Typen sich ändern (String zu JSON, JSON zu Objekt, Objekt zu Template). Execution ist die gefährliche Phase (Befehle bauen, Code evaluieren, Module laden). Ein Support-Endpoint, der JSON wie { "report": "weekly" } annimmt, kann später RCE werden, wenn jemand child_process oder einen Template-Render-Schritt hinzufügt, der dasselbe Feld nutzt.

Ein einfacher Plan für einen RCE-Risikoscan

Sie brauchen keine teuren Tools, damit ein Risikoscan nützlich ist. Beginnen Sie damit, die Codeformen zu finden, die am häufigsten zu „führe aus, was der Nutzer gesendet hat“ führen — besonders bei KI-generiertem Code, wo unsichere Abkürzungen auftauchen.

Starten Sie mit einem Keyword-Sweep, um eine kurze Liste von Dateien zur Prüfung zu erstellen:

rg -n "\\beval\\b|new Function|child_process|exec\\(|execSync\\(|spawn\\(|spawnSync\\(|fork\\(|vm\\.run|ejs|pug|handlebars|nunjucks|import\\(|require\\(" .

Dann verwandeln Sie die Treffer in eine Input-Flow-Karte. Für jeden Treffer beantworten Sie zwei Fragen:

• Welche Daten können diese Zeile erreichen?
• Wer kontrolliert diese Daten?

Verfolgen Sie übliche Quellen wie Request-Parameter, Headers, Cookies, Webhook-Payloads und alles, was aus einer DB gelesen wird und ursprünglich von Nutzer:innen stammt.

Für die Triage konzentrieren Sie sich auf die riskante Kombination aus Erreichbarkeit und Potenz: internet-reachable Routes (inkl. Webhooks), jede Verwendung von OS-Kommandoausführung oder Code-Laden (child_process, vm, dynamisches import/require), und Stellen, an denen Strings aus Eingaben ohne Allowlist gebaut werden. Bestätigen Sie, was tatsächlich in Produktion läuft — Dead Code und Dev-only-Skripte sind niedriger priorisiert als Code, der von echten Requests getroffen wird.

eval und Function finden, die Input ausführen können

Fangen Sie damit an, Stellen zu suchen, an denen Code aus Strings gebaut wird. Die üblichen Verdächtigen sind eval() und new Function(). Sie verwandeln einen Textwert in etwas, das der Server ausführt. Wenn ein Angreifer diesen Text beeinflussen kann, kann er gegebenenfalls eigenen Code ausführen.

Markieren Sie Muster wie:

• eval(userInput) oder eval(someVar)
• new Function("return " + expr)()
• setTimeout("doThing(" + x + ")", 0) und setInterval("...", 1000)
• „Expression-Evaluator“, die Strings zusammenketteten, bevor sie ausgeführt werden

„Es wertet nur kleine Ausdrücke aus“ ist trotzdem gefährlich. Ein harmloser Taschenrechner kann zu process.env-Zugriff, Dateilesen, Netzwerkaufrufen oder Schlimmerem werden, wenn der String vom Angreifer formbar ist.

Eingaben müssen nicht direkt aus dem Request kommen. Sie schleichen sich oft über Konfigdateien, DB-Felder, CMS-Inhalte, Feature-Flags oder Templates ein, die von Nutzer:innen editierbare Regeln speichern. In schnellen Prototypen findet man gelegentlich eine schnelle Regeln-Engine wie eval(dbRow.rule), die im Demo funktionierte und dann live ging.

Sichere Alternativen hängen vom Ziel ab. Im Allgemeinen: bevorzugen Sie eine feste Menge von Operationen, die auf echte Funktionen abgebildet sind, oder speichern Sie Regeln als Daten (z. B. JSON) und interpretieren sie mit strikter Validierung. Wenn Sie wirklich eine Ausdruckssprache brauchen, verwenden Sie einen echten Parser und werten nur unterstützte Knoten aus.

child_process auf Kommando-Injektion prüfen

Wenn Ihre App Node’s child_process nutzt, behandeln Sie das als Top-RCE-Risiko. Die Gefahr ist nicht allein „eine Shell nutzen“. Die Gefahr entsteht, wenn nutzerkontrollierter Text Teil des Kommandos wird.

Am riskantesten sind exec und execSync, sowie spawn mit shell: true. Sie sind leicht zu missbrauchen, weil sie einen einzelnen Kommando-String akzeptieren. Wenn Sie diesen String mit + oder Template-Strings bauen, kann ein Nutzer zusätzliche Operatoren (wie ;, &&, |) einschmuggeln und etwas ausführen, das Sie nie wollten.

Ein häufiger Slip ist ein „Datei konvertieren“-Endpoint, der exec( convert ${req.body.path} -resize 200x200 out.png ). Wenn path image.png; cat /etc/passwd enthält, interpretiert die Shell das als zwei Kommandos.

Ein sichereres Muster ist, die Shell zu vermeiden und ein Argument-Array zu übergeben. Zum Beispiel: spawn('convert', [inputPath, '-resize', '200x200', outPath], { shell: false }). Sie müssen inputPath weiterhin validieren, aber die meisten Shell-Parsing-Tricks entfallen.

Beim Scannen achten Sie auf Warnsignale wie Kommando-Strings, die aus Request-Feldern gebaut werden, shell: true, manuelles Argument-Joinen (args.join(' ')) und „Escape“-Helfer, die nur einige Zeichen ersetzen.

Wenn Sie Logging zur Triage hinzufügen, loggen Sie das Wichtige (vorsichtig): den Kommando-Namen, das Args-Array (oder den kompletten String, falls nötig) und genau, woher die Eingabe kam (Route und Feldname). Geben Sie keine Secrets in Logs aus.

Server-seitige Template-Injection-Pfade erkennen

Server-side Template Injection (SSTI) entsteht, wenn Ihre App ein Template aus Nutzereingaben baut und es serverseitig rendert. Wenn die Template-Engine Ausdrücke ausführen kann, kann ein Angreifer aus einer „custom message“-Funktion eine Code-Ausführung machen.

Ein einfaches Beispiel: Nutzer dürfen eine E-Mail-Vorlage speichern, die Sie dann kompilieren oder rendern. Unterstützt die Engine {{ someExpression }} oder Helper-Aufrufe, kann der Nutzer Geheimnisse lesen, Funktionen aufrufen oder in andere gefährliche APIs gelangen.

Im Schnellscan achten Sie auf Stellen, an denen nutzerkontrollierte Strings zu Templates, Partials, Layouts oder Helper-Namen werden. Häufige Muster: Templates direkt aus Nutzer-Input kompilieren/rendern, Request-Daten als Locals ohne Allowlist übergeben (z. B. res.render("view", req.body)), Nutzern erlauben, einen Partial-/Layout-Namen auszuwählen und Pfade zu konkatenieren, Helper dynamisch aus Request-Daten registrieren oder gespeicherte „markdown“/„handlebars“/„ejs“-Felder ohne Sicherheitslayer rendern.

Übliche Gegenmaßnahmen, die funktionieren:

• Kompilieren Sie Templates nicht aus rohem Nutzertext. Speichern Sie Content, rendern Sie ihn aber als Plain Text oder als sicheres Markup-Subset.
• Behalten Sie eine strikte Variable-Map für Templates. Übergeben Sie nicht ganze Objekte wie req, res oder process.
• Behandeln Sie Template-Namen wie Dateipfade: Allowlisten Sie bekannte Templates und lehnen Sie den Rest ab.

Risikoreiche dynamische Imports und Modul-Ladung prüfen

Dynamisches Laden von Modulen ist bequem, aber ein häufiger Weg, wie RCE in Node-Apps einschleicht — besonders wenn Code schnell generiert wurde. Wenn irgendein Teil des Modulnamens oder Pfads vom Nutzer stammt, behandeln Sie ihn als untrusted.

Die gefährlichsten Muster sehen harmlos aus: import(userInput), require(userInput) oder einen Pfad bauen wie require('./plugins/' + name). Leute nehmen oft an „es lädt nur lokale Dateien“, aber Angreifer können Pfad-Tricks, unerwartete Dateistandorte oder Code erreichen, den Sie nicht freigeben wollten.

Scannen Sie nach:

• import(something) wo something kein String-Literal ist
• require(something) wo something aus Variablen gebaut wird
• require(path.join(base, userValue)) und Traversal-Risiken wie ../
• „Plugin“-Features, die Module nach Name laden
• Dateinamen, die aus Requests, DB oder Config gelesen und dann geladen werden

Wenn Sie dynamisches Laden wirklich brauchen, halten Sie es explizit. Nutzen Sie eine hartkodierte Allowlist, die Namen auf exakte Pfade mappt, lehnen Sie alles ab, was nicht in der Map ist, und übergeben Sie niemals rohe Eingaben an require() oder import().

Unterstützende Probleme nicht übersehen, die RCE ermöglichen

Selbst wenn Sie einen offensichtlichen Ausführungs-Bug finden, brauchen Angreifer oft noch weitere Fehler, um ihn auszunutzen und die Aufräumarbeiten zu erschweren. Ein guter Scan umfasst die unterstützenden Probleme, die Exploits erleichtern.

Beginnen Sie mit Secrets. Prototypen lassen oft API-Keys, JWT-Secrets, Datenbank-URLs und Cloud-Tokens im Klartext, in Beispiel-env-Dateien oder in Logs zurück. Wenn ein Angreifer irgendeine Code-Ausführung erreicht, erlauben exponierte Secrets den schnellen Sprung zu Daten und anderen Systemen.

Berechtigungen sind ebenso wichtig. Läuft die App als ein Nutzer mit zu vielen Rechten, wird aus einer RCE schnell „verändere den Server“. Achten Sie auf zu breite Dateiberechtigungen, beschreibbare App-Verzeichnisse und zu mächtige Cloud-Rollen.

Prüfen Sie auch Produktions-Einstellungen, die Türen öffnen: Dev-Mode in Produktion, aktivierte Debug-Flags (verbose errors, Stacktraces, Hot Reload), verbleibende Admin-Routes, unsicheres CORS und Schreib-/Exposed-Upload- oder Temp-Verzeichnisse.

Schließlich können Abhängigkeiten die schwächste Stelle sein. Veraltete Pakete mit bekannten RCE-CVEs können eine harmlose Route kompromittierbar machen. Ein kurzer Blick in Ihre Lockfile und Advisories gehört dazu.

Häufige Fehler bei der Behebung von RCE-Risiken

Die schnellste Art, Zeit bei RCE zu verlieren, ist, nur das Sichtbare zu beheben, ohne zu beweisen, wie der Code erreichbar ist. Ein aufgeräumter Helper kann gefährlich bleiben, wenn er hinter einer Route, Middleware, einem Cron-Job oder Webhook sitzt, der externe Eingaben akzeptiert.

Eine Falle ist zu denken „ist nicht erreichbar“, weil Sie keinen Button im UI sehen. Verfolgen Sie den Pfad trotzdem: request -> router -> middleware -> controller -> helper. Dasselbe gilt für Background Worker und Webhook-Handler. Viele reale Vorfälle starten in Pfaden, die selten getestet werden, wie Payment-Webhooks, OAuth-Callbacks oder interne Job-Queues.

Ein weiterer Fehler ist, das Symptom statt die Ursache zu behandeln. Output-Escaping oder Encoding macht eval, Function, exec oder spawn nicht sicher, wenn untrusted Input sie erreichen kann. Wenn Ihr Scan dynamische Ausführung findet, ist das Ziel meist, sie zu entfernen, nicht „zu sanitizen".

Regex-basierte „Sanitizer“ sind oft Sackgassen. Wenn ein Fix auf „blockiere diese Zeichen“ beruht, gehen Sie davon aus, dass jemand es mit Whitespace, Quotes, Shell-Metazeichen oder Encodings umgeht.

Gute Gewohnheiten, die Wiederholungen verhindern:

• Beweisen Sie Erreichbarkeit durch Trace von Routes, Middleware, Worker und Webhooks
• Ersetzen Sie dynamische Ausführung durch feste Kommandos, feste Templates oder geprüfte Bibliotheken
• Validieren Sie Input nach Typ und Zweck (IDs, Enums, strikte Schemata), nicht per Regex-Raten
• Fügen Sie Tests für böse Payloads hinzu, damit das Problem nicht zurückkehrt

Schnelle Checkliste vor dem Deployment

Nutzen Sie diese Liste nach Ihrem Scan und nochmal vor dem Release. Ziel: Nichts auf Ihrem Server sollte Nutzereingaben in Code, Shell-Kommandos oder Modulpfade verwandeln können.

• Kein eval, new Function oder string-basierte setTimeout/setInterval im Server-Code.
• Kein exec oder execSync. Für spawn/execFile: Argumente als Array übergeben und shell: true nicht aktivieren.
• Server-seitige Templates nicht aus nutzer-provided Text kompilieren.
• Dynamische Imports/Modul-Ladung sind allowlisted und akzeptieren keine vom Nutzer gebauten Pfade.
• Eingabevalidierung an den Grenzen (HTTP-Handler, Queue-Consumer, Webhooks) mit klaren Regeln pro Feld.

Ein einfacher Sanity-Test: Tun Sie so, als kontrolliere ein Angreifer einen Query-Parameter, einen Header und ein JSON-Feld. Kann einer dieser Werte ohne Ablehnung zu einem Code-Executor (eval), einem Command-Runner (child_process), einem Template-Compiler oder einem Import-Pfad gelangen?

Beispiel: Ein kleines Feature, das aus Versehen zu RCE wird

Ein häufiges echtes Problem ist eine intern erstellte Admin-Seite mit einer „Run maintenance“-Box. Die Idee ist harmlos: reindex-users oder clear-cache eintippen, Run klicken, und der Server führt es aus.

Das erste Problem ist oft die Anbindung. Der Endpoint nimmt req.body.command und leitet es an child_process.exec() weiter, oder baut einen Skriptpfad und import()t die Datei. Kann ein Angreifer diesen Endpoint erreichen (schwache Auth, geleaktes Admin-Cookie, fehlende Rollenprüfung), probiert er Inputs wie reindex-users && cat .env oder ../../../../tmp/payload und Sie haben RCE.

Ein Scan markiert typischerweise schnell: child_process.exec() mit Request-Daten, dynamische import()/require() aus Strings, Template-Rendering, das Nutzer-Input kompiliert, und Helper wie eval() oder new Function() von Generatoren.

Nach dem Scan bestätigen Sie manuell: Ist die Route ohne strikte Admin-Prüfung erreichbar, werden die Inputs tatsächlich kontrolliert, und was läuft auf dem Server (Shell, Node oder ein Script-Runner)? Gefährlicher Code steckt oft hinter „temporären" Feature-Flags.

Was Sie zuerst fixen sollten, sind die Ausführungs-Primitiven:

1. Entfernen Sie die Frei-Text-Command-Box und ersetzen Sie sie durch eine Allowlist benannter Aktionen.
2. Tauschen Sie exec gegen sichere APIs aus (oder führen Sie die Arbeit im Prozess mit normalen Funktionen aus).
3. Sperren Sie die Route auf eine echte Admin-Rolle und loggen Sie jede Aktion.
4. Führen Sie den Service mit minimalen Rechten aus und entfernen Sie Secrets aus der Runtime-Umgebung.

Das Ergebnis: weniger Pfade zur Ausführung und kein direkter Weg, Eingaben auszuführen.

Nächste Schritte: Findings in sicheren, produktionsreifen Code überführen

Behandeln Sie jeden Fund als Produktentscheidung, nicht nur als Bug. Manche riskanten Muster sind lohnend zu patchen, andere sollten entfernt werden, weil sie bei künftigen Änderungen wieder auftauchen.

Eine praktische Entscheidungshilfe ist, jedes Problem zu labeln:

• Patch: Der aktuelle Ansatz lässt sich mit strikter Validierung, Allowlists und sicheren APIs absichern.
• Refactor: Das Feature wird gebraucht, aber das Design lädt zu Fehlern ein.
• Remove/Replace: Das Feature existiert meist, weil ein Generator es hinzugefügt hat.

Nach den Fixes schreiben Sie eine kurze Security-Notiz im Repo. Klar und konkret: kein eval/Function mit Request-Daten, keine nutzer-gesteuerten Strings in child_process, Templates dürfen kein rohes User-Input kompilieren, dynamische Imports nur aus Allowlists. Das hilft Ihrem zukünftigen Ich und beschleunigt Code-Reviews.

Fügen Sie leichte Guardrails hinzu, damit die gleichen Probleme nicht zurückkommen. Eine gespeicherte Suche oder Review-Checkliste für eval, new Function, child_process.exec, Template-Compilation und dynamische import()-Variablen fängt vieles ab.

Wenn Sie einen Prototyp geerbt haben, der von Tools wie Lovable, Bolt, v0, Cursor oder Replit generiert wurde und Sie eine schnelle zweite Meinung wollen: FixMyMess (fixmymess.ai) konzentriert sich darauf, solche riskanten Muster zu diagnostizieren und zu reparieren und ergänzt das mit menschlicher Prüfung, damit die App in Produktion standhält.