- Verschifft
- 23. September 2026 um 01:50 UTC
- Autor
- Kamo
- Ausschuss
- 9060c7c
Drei unabhängige Befunde, die zusammen festgelegt sind, weil die ersten beiden Dateien und eine Klasse teilen. 1. AiMcpController hatte null richtige Kontrollen auf erstellen/update/löschen/test. die Organisation könnte einen MCP-Server config und mcp-Gateway-Service McpStdioTransport pflanzen läuft config.command mit config.envVars als realen OS-Prozess (neuer ProcessBuilder(...).start()), auf Gateway Start und wieder auf jedem 30er Gesundheitscheck. Das ist nicht authentifizierte RCE gegen mcp-gateway-Service. Jeder Mutating/Testhandler benötigt nun MANAGE_AI_SETTINGS, passend AiProviderController und STDIO wird für eine von Organisation erstellte Konfiguration komplett abgelehnt. Tenant kann nur SSE/HTTP konfigurieren. (ai_mcp_server_configs hat 0 Zeilen; keine Migration erforderlich.) 2. SSRF: **************** schickte den entschlüsselten Provider-Schlüssel einer Organisation was auch immer Host war in baseUrl und spiegelte die Antwort, und OpenAiCompatibleAdapter (die bedient 8 der 12 Anbietertypen) hatte keine Host-Regel auf einem seiner drei ausgehenden Anrufe einschließlich des realen Chat-Pfades, den jede Nachricht nimmt, nicht nur die manuelle Testtaste. Hinzugefügt OutboundUrlGuard, gebaut auf dem bestehenden PublicHostGuard von Kamo-Shared (bereits genutzt von SafeSiteFetcher und SafeImageFetcher von SecurityService für die gleiche Problemklasse: der Gastgeber und verweigert ************ Adressen und Cluster-only-Namen (*.svc, *.cluster.local, dotless), überprüft bei der Zeit in AiProviderController und AiMcpController und wieder unmittelbar vor jedem Anruf OpenAiCompatibleAdapter, da die DNS-Antwort eines Hostnamens im Sparzeitraum nicht für immer seine Antwort ist. Verweigerung ist eine einfache 400 mit unserer eigenen Botschaft - keine rohe Netzwerk-Ausnahme, und keine Verbindung ist jemals versucht, zu einem abgelehnten Ziel. 3. **************** userId) abgefragte Nutzungsdatensätze und dann, bedingungslos, zurückgegeben wahr - jede AiAccessPolicy Anfrage / Zeichen Grenze war dekorativ. Die zwei echte Call-Sites (ChatOrchestrationService Streaming und Sync Chat-Pfade) lösen jetzt jede Rolle, die das Mitglied in der Hand hält und durchsetzt jede Rolle kartiert: eine Rolle ohne kartierte Politikzuschüsse keine eigenen Beschränkungen, aber es kann auch nicht kündigen eine restriktive Politik durch eine eine andere Rolle, die ein Mitglied auch innehat. Die verschwendete 2-Arg-Überlastung ist weg. Tests: AiMcpControllerAuthzTest (Rechte + STDIO Ablehnung + URL Validierung), OutboundUrlGuardTest, AiProviderKeyExposureTest (2 neue SSRF Fälle), ************ AccessPolicyMultiRoleTest. Jeder Fall wurde vor diesem Commit-Code rot gegen den Pre-Fix-Code verifiziert (Fail-open-Rechte, Körper-Vertrauen, No-Op-Wache und immer-true Quoten-Kontrollen jeder wieder eingeführt lokal, ein zu einer Zeit, und nach der Bestätigung der passenden Test fehlgeschlagen wiederhergestellt). mcp-Gateway-Service erhält einen passenden Commit: eine unabhängige STDIO-Genehmigungsliste (Abwehr in der Tiefe, in Falls diese Prüfung jemals umgangen wird) und ihre eigene Vor-Verbindungsprüfung auf einer SSE/HTTP-Konfiguration url.