솔직히 이제 이런 레퍼토리 지겹다. 보안 업계는 수년간 제로데이 취약점이 공개된 후에도 몇 달씩이나 은밀하게 숨어있다가 뒤늦게 악용되는 시나리오에 익숙했다. 공개와 악용 사이에는 어느 정도의 ‘춤’이 있을 거라고 예상했다. 하지만 CVE-2026-42208 사태는 그 춤을 긴박한 스프린트로 바꿔놓았다. 오픈소스 AI 인프라 분야의 총아였던 BerriAI의 LiteLLM이 맹공격을 받았고, 공격자들은 기다릴 인내심조차 챙기지 않았다.
이건 인터넷의 허름한 구석 이야기가 아니다. LiteLLM은 GitHub에서만 무려 4만 5천 개의 스타를 보유하고 있다. OpenAI, Anthropic 같은 주요 LLM 제공업체의 민감한 API 키와 설정을 처리하는 데 개발자들이 믿고 쓰는 수준의 프로젝트다. 그런데 CVSS 점수 9.3에 달하는 심각한 SQL 주입 취약점이 터졌으니, 잠시 숨을 고르거나 멈칫할 시간이 있을 법도 했다. 하지만 웬걸. 36시간. 그것이 위협 행위자들이 공개된 취약점을 실제 악용 가능한 공격 코드로 만드는 데 걸린 시간이다.
취약점 자체는 돌이켜보면 거의 우스꽝스러울 정도로 단순하다. 개발팀의 설명은 명확하다: “프록시 API 키 확인 중에 사용된 데이터베이스 쿼리가 호출자가 제공한 키 값을 별도의 매개변수로 전달하는 대신 쿼리 텍스트에 혼합했습니다.” 쉽게 말해, 특별히 조작된 Authorization 헤더를 보낼 수 있다면 LiteLLM 프록시 데이터베이스 쿼리에 악의적인 SQL 명령을 몰래 끼워 넣을 수 있다는 뜻이다.
인증되지 않은 공격자는 어떤 LLM API 경로(예: POST /chat/completions)로든 특별히 조작된 Authorization 헤더를 보내 프록시의 오류 처리 경로를 통해 이 쿼리에 접근할 수 있었습니다. 공격자는 프록시 데이터베이스에서 데이터를 읽을 수 있었으며, 이를 수정할 수도 있어 프록시와 관리하는 자격 증명에 대한 무단 접근이 가능했습니다.
그리고 이 공격자들이 노린 것은 무엇이었을까? 사용자 테이블 같은 게 아니다. 그들은 litellm_credentials.credential_values와 litellm_config를 노렸다. 이건 단순한 데이터베이스 항목이 아니다. OpenAI, Anthropic 등 상위 LLM 제공업체의 API 키, 월 수천만 원대 지출 한도가 있는 키, 콘솔 관리자 권한, 심지어 AWS Bedrock IAM 자격 증명까지 품고 있는 보물 상자다. Sysdig는 그들의 꼼꼼한 분석으로, 이런 데이터베이스 추출은 일반적인 웹 애플리케이션 SQL 주입과는 비교도 안 되게 완전한 클라우드 계정 탈취와 유사하다고 지적했다. 이건 현관문 열쇠가 아니라 왕국의 열쇠를 훔치는 수준이다.
진정으로 소름 끼치는 것은 관찰된 운영상의 정교함이다. Sysdig는 공격자가 무작위로 뒤지고 있지 않았다고 언급했다. 그들은 테이블과 열 이름을 열거하고 있었는데, 이는 공개된 PoC(Proof-of-Concept) 없이도 사전 공격 정찰이 가능하다는 것을 의미한다. 보안 권고와 오픈소스 스키마만으로도 공격을 설계하기에 충분한 정보였다는 것이다. 이건 무차별 공격이 아니라 외과 수술급 공격이다.
그리고 LiteLLM이 악당들에게 당한 게 이번이 처음이 아니다. 바로 지난달, TeamPCP 해킹 그룹에 의한 공급망 공격의 대상이기도 했다. 이제 이건 단순한 사고가 아니라 중요한 AI 인프라에 대한 패턴처럼 느껴지기 시작한다. 높은 스타 수와 개발자들의 신뢰를 받는 이 프로젝트들은 광범위한 발판을 마련하려는 공격자들에게 최고의 사냥감이 되고 있다.
그럼 실제로 누가 돈을 버는 걸까? 익스플로잇 판매자, 암시장 데이터 브로커, 그리고 훔친 자격 증명을 악의적인 목적으로 재활용할 음침한 그룹들이다. 그 대가는? LiteLLM을 운영하는 조직에게는 천문학적인 데이터 손실, 자격 증명 탈취, 그리고 사고 대응 및 복구에 드는 막대한 비용이 발생할 위험이다. 이 악용의 신속성은 강력한 경고다: 취약점 공개와 실제 악용 사이의 간격이 사라지고 있다. 우리는 ‘패치하거나 망하거나’라는 사고방식에서 ‘어제 패치했어야 했다’는 절박함으로 나아가고 있다.
제안된 완화 조치인 disable_error_logs: true 설정은 즉시 업데이트할 수 없을 때 임시방편일 뿐이다. 특정 구멍을 막아주지만 근본적인 구조적 약점을 해결하지는 못한다. 진정한 해결책은 1.83.7-stable 버전으로 업그레이드하는 것이다. 하지만 배포 중이거나 업데이트를 지연하는 경우, 그 결과는 심각할 수 있다. CVE-2026-42208의 신속한 악용은 근본적인 변화를 강조한다: AI 시대에는 공격 속도가 가속화되고 있다. 우리는 더 이상 소프트웨어 취약점만이 아니라, 보안 권고에 잉크도 마르기 전에 침해당하는 중요 인프라에 대해 이야기하고 있다.
개발자에게 이 문제가 왜 중요할까?
이것은 보안팀만의 문제가 아니다. LiteLLM 또는 이와 유사한 오픈소스 AI 인프라 구성 요소를 사용하는 개발자들은 보안상의 의미를 명확히 인지해야 한다. 민감한 키 관리를 위해 이러한 도구에 의존한다는 것은 도구 자체의 취약점이 클라우드 자격 증명과 시크릿에 직접적인 경로가 된다는 것을 의미한다. 이는 서드파티 라이브러리, 특히 민감한 데이터를 처리하는 라이브러리를 통합할 때 엄격한 보안 검증과 선제적인 패치 전략이 필요함을 뼈저리게 상기시킨다. 모든 종속성을 잠재적인 공격 벡터로 취급하는 것은 편집증이 아니라, 오늘날의 위협 환경에서 올바른 보안 위생이다.
LiteLLM은 여전히 신뢰할 수 있을까?
LiteLLM 자체도 피해자이며, 이를 배포한 조직들도 마찬가지다. 이번 취약점은 버그였고, 개발팀은 이미 이를 패치했다. 진짜 문제는 더 넓은 AI 인프라 생태계에 관한 것이다. 빠르게 인기를 얻고 중요한 자격 증명을 처리하는 프로젝트는 공격자들의 자석이 될 것이다. 신뢰는 버그가 발생할 수 있는지 여부가 아니라, 프로젝트가 얼마나 신속하게 대응하고 커뮤니티가 얼마나 보안에 민감한지에 관한 것이다. LiteLLM 개발팀은 신속하게 문제를 해결했지만, 악용의 속도는 의도된 인기 오픈소스 프로젝트조차 고가치 표적이 되는 더 큰 추세의 증상이다. 개발자들은 계속 LiteLLM을 사용해야 하지만, 경계심과 신속한 패치가 필수불가결하다는 이해를 바탕으로 해야 한다.
🧬 관련 인사이트
자주 묻는 질문
LiteLLM이란 무엇인가요? LiteLLM은 다양한 대규모 언어 모델(LLM)과의 상호작용을 단순화하고 표준화하는 오픈소스 AI 게이트웨이입니다. 다양한 모델 간 전환과 API 키 관리를 용이하게 하는 프록시 역할을 합니다.
CVE-2026-42208은 무엇이었나요? CVE-2026-42208은 LiteLLM 프록시 데이터베이스의 심각한 SQL 주입 취약점이었습니다. 이를 통해 인증되지 않은 공격자는 특정 헤더를 조작하여 LLM 제공업체의 API 키 및 자격 증명과 같은 민감한 데이터를 수정하거나 탈취할 수 있었습니다.
CVE-2026-42208은 얼마나 빨리 악용되었나요? 이 취약점은 공개된 지 약 36시간 만에 실제 공격에 악용되었으며, 새로 식별된 보안 결함에 대한 공격자들의 신속한 대응 속도를 보여주었습니다.
