수백만 개의 AI 에이전트를 위협하는 오픈소스 패키지의 심각한 취약점 발견

Starlette는 FastAPI가 내부적으로 의존하는 경량 ASGI(Asynchronous Server Gateway Interface) 프레임워크로, 최근 폭증한 LLM 기반 API·AI 에이전트 서버의 사실상 표준 기반 계층입니다. 주당 3억 2,500만 다운로드라는 수치는 Starlette를 직접 쓰는 개발자보다도 FastAPI를 통해 간접적으로 끌려오는 전이 의존성(transitive dependency)이 압도적으로 많다는 뜻입니다. 이번 "BadHost" 취약점은 이름에서 드러나듯 들어오는 요청의 Host 헤더(또는 호스트/오리진 신뢰 경계) 처리 과정에서 입력 검증이 충분치 않아 발생하는 문제로, 공격자가 조작한 헤더를 통해 서버가 신뢰하지 말아야 할 값을 신뢰하게 만들 수 있는 부류입니다. ASGI 계층은 HTTP 요청을 가장 먼저 받아 라우팅·미들웨어로 넘기는 입구이기 때문에, 이 지점의 결함은 그 위에 올라간 모든 애플리케이션 로직에 그대로 전파됩니다.

실무 관점에서 위험한 부분은 "내 코드에는 Starlette를 import한 적이 없다"는 개발자조차 영향권에 든다는 점입니다. FastAPI로 만든 추론 API, 사내 RAG 백엔드, 도구 호출(tool-calling)을 수행하는 자율 에이전트 서버 대부분이 Starlette를 깔고 있으며, 특히 AI 에이전트는 외부에서 받은 입력을 다시 내부 시스템·외부 API 호출로 연결하는 구조라 Host/Origin 신뢰가 깨지면 SSRF, 캐시 포이즈닝, 인증 우회, 잘못된 리다이렉트 같은 2차 피해로 번질 수 있습니다. 수백만 대 규모로 배포된 에이전트가 동일한 기반 라이브러리를 공유한다는 것은, 단일 취약점이 곧 광범위한 동시 노출(monoculture risk)을 의미합니다.

개발자가 지금 해야 할 일은 명확합니다. 첫째, `pip show starlette` 또는 `pip freeze`로 실제 설치된 버전을 확인하고, 패치된 버전으로 즉시 업그레이드하십시오. 이때 직접 의존성뿐 아니라 FastAPI·Uvicorn 등을 통해 끌려온 전이 의존성까지 락파일(poetry.lock, requirements.txt, uv.lock) 기준으로 점검해야 합니다. 둘째, 단순 버전업으로 끝내지 말고 애플리케이션 레벨에서 `TrustedHostMiddleware`로 허용 호스트를 명시하고, 리버스 프록시(nginx 등) 단에서도 Host 헤더를 화이트리스트로 강제해 다층 방어를 구성하는 것이 안전합니다. 셋째, 에이전트가 받은 호스트/오리진 값을 그대로 내부 호출 URL이나 콜백에 사용하고 있지 않은지 코드 경로를 직접 점검하고, 가능하면 CI에 `pip-audit`나 Dependabot/Renovate 같은 자동 취약점 스캐닝을 붙여 다음 번 "BadHost" 류 사고에 자동으로 대응할 수 있는 체계를 갖추길 권합니다.