squeeze440/pasteguard-pocPoC — abuso del proxy cross-origin delle chiavi API del provider configurate in PasteGuard (GHSA-q94x-p9rc-q89f, CVE-2026-86998, CVSS 7.6).
Stato CVE: richiesto, in attesa di assegnazione. Questa segnalazione è pubblicata come GHSA-q94x-p9rc-q89f. All'assegnazione del CVE questo repository viene rinominato
CVE-YYYY-NNNNN-pasteguard-PoCe questo banner viene sostituito con il link al CVE.
| Ricercatore | Dostxodjayev Abdullox (@squeeze440) |
| Advisory | GHSA-q94x-p9rc-q89f |
| CVSS 3.1 | 7.6 (High) |
| Debolezza | CWE-352, CWE-942 |
Sintesi: La mancanza di protezione CORS/CSRF sulle route del proxy LLM in PasteGuard 0.9.1 consente a un attaccante remoto (qualsiasi sito web visitato dal browser dell'operatore, o qualsiasi host sulla rete locale) di attivare richieste autenticate all'API OpenAI/Anthropic configurata dall'operatore utilizzando la chiave API di fallback lato server di PasteGuard, e di leggerne la risposta, tramite una fetch() cross-origin verso /openai/v1/chat/completions (e la gemella /anthropic/v1/messages).
Prodotto: PasteGuard (github.com/sgasser/pasteguard)
Versione testata: commit 100718191499c52934f3b2ccca72ca16373fb765 (2026-07-30), versione package.json 0.9.1
CVSS v3.1 stimato: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H — 7.6 (High)
UI:R — l'operatore deve avere il browser aperto su una pagina (qualsiasi pagina, su qualsiasi sito) mentre PasteGuard è in esecuzione; non è necessaria alcuna altra interazione.C:L / I:L — il JS dell'attaccante legge solo la risposta al proprio prompt scelto dall'attaccante (non le conversazioni passate/dati della dashboard dell'operatore, che sono correttamente esclusi dal CORS), ma questo conferma/usa comunque un account attivo e finanziato e inquina il registro di utilizzo/audit dell'account sotto l'identità dell'operatore.A:H — l'impatto realistico e illimitato: una pagina dell'attaccante può ripetere questa richiesta all'infinito, generando utilizzo realmente fatturato sull'account/quota del provider dell'operatore (drenaggio finanziario, possibile esaurimento del rate-limit o flag di abuso lato provider) senza alcun rate limiting o controllo dell'origine a ostacolarlo.S:U — l'impatto rimane all'interno dello stesso confine di fiducia (viene utilizzata la credenziale configurata del proxy stesso); non viene attraversata alcuna autorità di sicurezza separata.Dettagli:
Il layer HTTP di PasteGuard applica una policy CORS permissiva con wildcard a ogni route tranne la dashboard:
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}`;
}
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).Poiché la policy CORS con wildcard si trova davanti a route che detengono questa credenziale di fallback, qualsiasi origine può (1) far inviare al browser la richiesta senza header Authorization, causando l'aggiunta da parte del server della propria chiave API reale, e (2) leggere la risposta JSON, poiché è presente Access-Control-Allow-Origin: *. Nessun controllo Origin/Referer o token CSRF protegge queste route.
Proof of Concept (confermato dinamicamente, non solo tracciato staticamente):
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.mock_upstream.py) su 127.0.0.1:9091 che registra qualsiasi header Authorization riceva.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 */ });
http://127.0.0.2:8001/attack.html. Confermato tramite l'ispezione di rete di DevTools:
origin: http://127.0.0.2:8001, sec-fetch-site: cross-site, nessun header Authorization inviato dalla pagina dell'attaccante.access-control-allow-origin: *, HTTP 200, corpo JSON completamente leggibile dal JS della pagina dell'attaccante.../evidence/cross_origin_csrf_success.png.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.Evidenza grezza: ~/engagements/pasteguard/evidence/cross_origin_csrf_success.png, ~/engagements/pasteguard/evidence/mock_upstream_log.txt.
La route /anthropic/v1/messages è stata confermata staticamente (file:riga sopra) come condivisione dello schema identico di fallback + CORS con wildcard, ma non è stata rieseguita separatamente attraverso il PoC live nel browser, nell'interesse della linea guida della sessione di profondità-sulla-ampiezza/regola dei 5 minuti, una volta che la causa radice era già confermata su /openai.