Stell dir vor: Du findest im offiziellen Katalog von Hermes einen nützlichen MCP-Server, klickst auf Installieren, er fragt nach ein paar Umgebungsvariablen, du fügst deinen API-Key ein, und alles funktioniert. Jetzt stell dir vor, der Katalogeintrag wäre bösartig – oder einfach nur schlampig geschrieben. Vor dem am 26. August gemergten Fix wurde jede Umgebungsvariable aus der Install-Request wortwörtlich in die .env-Datei deines Profiles geschrieben – inklusive HERMES_YOLO_MODE, einem Schalter, der deine Sicherheitslage komplett verändert. Mit anderen Worten: Ein MCP-Tool zu installieren war theoretisch der Schlüssel zu „Auto-Yolo bei jedem künftigen Start“. Dieses Loch ist jetzt geschlossen (PR #91139).

Wie die Schwachstelle aussah

Das Problem saß in POST /api/mcp/catalog/install. Vor dem Fix akzeptierte der Endpoint ein beliebiges env-Mapping und persistierte jeden nicht-leeren Wert in der .env-Datei des gewählten Profiles, bevor die Installation lief. Der Endpoint sollte die Zugangsdaten erhalten, die du in den Wizard tippst – aber da er alles akzeptierte, konnte eine Request HERMES_YOLO_MODE (oder jede andere Runtime-Steuerung) an eine sonst legitime Zugangsdaten-Übermittlung anhängen, in .env schreiben, und beim nächsten Prozessstart wirkte es.

Die subtilere Gefahr war die generische Persistenz selbst: Kann ein Endpoint erst einmal beliebige Keys in .env schreiben, wird er zu einer generischen Schreib-Primitive – fähig, die Trust-Root des MCP-Katalogs zu ersetzen, die Executable-Autorität von Copilot ACP zu erlangen oder beliebige HERMES_*-Kontrollen einzuschleusen. Der Katalog soll dir helfen, Zugangsdaten auszufüllen – nicht über solche Macht verfügen.

Der Fix: Katalog-Zugangsdaten sind ein geschlossenes Schema

Das gepatchte Verhalten:

• Closed-Schema-Validierung: Jeder Katalogeintrag deklariert, welche Umgebungsvariablen er braucht (seine auth.env-Liste). Jeder Name in der Übermittlung, der nicht deklariert ist → HTTP 400, abgelehnt vor dem ersten Write oder der ersten Install-Aktion;
• Die ganze Map wird vor dem ersten Write validiert: Eine Request, die gültige und ungültige Keys mischt, kann keine Zugangsdaten teilweise persistieren;
• Denylist auf Namensebene: Der gemeinsame Environment-Writer weigert sich, Hermes-Runtime- und Approval-Control-Variablen zu persistieren – HERMES_YOLO_MODE, HERMES_ACCEPT_HOOKS, HERMES_REDACT_SECRETS, HERMES_INTERACTIVE, HERMES_EXEC_ASK, HERMES_GATEWAY_SESSION, HERMES_CRON_SESSION, HERMES_SESSION_KEY, HERMES_CONFIG_PATH, HERMES_ENV_PATH und Co. – damit sich ein fehlerhafter Katalogeintrag nicht selbst autorisieren kann;
• Fehler leaken keine Secrets: Nur abgelehnte Namen; übermittelte Werte werden nie zurückgespiegelt.

Beachte: Die Denylist ist namensspezifisch, kein pauschaler Block auf HERMES_* – viele Integrations-Zugangsdaten folgen selbst der HERMES_*-Konvention (z. B. HERMES_LANGFUSE_PUBLIC_KEY), und das ganze Präfix zu kippen würde jeden Provider-Setup-Wizard zerstören. Das Gate blockiert Runtime-Kontrollen und lässt Integrations-Zugangsdaten durch.

Was sich für normale Nutzer ändert

Praktisch nichts. Der Desktop rendert und übermittelt bereits nur die vom Katalogeintrag deklarierten Zugangsdatenfelder, legitime Installationen behalten also exakt ihre Request-Form; manuell konfigurierte MCP-Server bleiben unberührt. Das ist reine defensive Härtung: Du nutzt es wie gewohnt, Angreifer verlieren einen Einstiegspunkt.

Tipps für dich

• Nutze die Katalog-Installationen weiter: Der Flow steht jetzt auf einem geschlossenen Schema – Zugangsdaten landen nur noch in deklarierten Keys;
• Manuelle MCP-Konfiguration – wirf einen Blick in deine .env: Wenn du MCP-Server-Konfigurationen von Hand schreibst und Variablen selbst in .env legst, folge dem Prinzip der geringsten Rechte – lege dort keine Schalter der HERMES_YOLO_MODE-Klasse ab; nutze hermes config oder die dedizierten CLI-Kontrollen, wenn du sie brauchst;
• Katalogeinträge beitragen: Deklariere jede Umgebungsvariable, die dein Eintrag braucht, in auth.env – das formt das Formular für die Nutzer und verhindert, dass Installationen mit 400 abgelehnt werden.

Fazit

Im Kern verengt dieser Fix die Berechtigungen: Katalog-Installationen gingen von „darf beliebige Umgebungsvariablen schreiben“ zu „darf nur deklarierte Zugangsdaten schreiben“, mit einer Denylist auf Namensebene über die Sicherheits-Kontrollvariablen. Sicherheitsfixes sind die am leichtesten übersehenen Updates – dabei schützen sie genau den Moment, in dem du am entspanntesten bist: die Install-Wizards von Drittanbietern. Wer tiefer in die MCP-Seite von Hermes eintauchen will, findet mehr in MCP-Konfigurations-Kontextvariablen und im offiziellen Remote-MCP-Katalog; und wer Webhook-basiertes Monitoring betreibt, bekommt mit diesem Fix ein einfaches Upgrade fürs gute Gewissen.