당신의 로컬 LLM은 생각만큼 프라이빗하지 않습니다

Bleeding Llama 취약점은 왜 AI를 로컬에서 실행하는 것이 보안 전략이 될 수 없는지 보여줍니다

LLM을 로컬에서 실행하는 것은 프라이버시 측면에서 승리한 것처럼 느껴집니다.

클라우드 API도 없고, 제3자 모델 제공자도 없으며, 프롬프트가 자신의 기기를 떠나지도 않습니다.

그러한 가정은 위안을 줍니다. 하지만 불완전하기도 합니다.

2026년 5월, Cyera Research는 Ollama에서 발견된 'Bleeding Llama'라고 불리는 심각한 취약점을 공개했습니다. Ollama는 오픈 소스 모델을 로컬에서 실행하는 가장 인기 있는 방법 중 하나입니다. 개발자들은 노트북, 워크스테이션 및 내부 서버에서 Llama, Mistral 등의 모델을 실행하기 위해 이를 사용합니다.

이 취약점은 CVE-2026-7482로 추적됩니다. 이는 0.17.1 이전 버전의 Ollama에 영향을 미치며, Echo CNA에 의해 9.1점의 Critical(심각) 등급을 받았습니다.

이 문제가 중요한 이유는 로컬 AI 시스템에 대한 흔한 가정, 즉 '모델이 로컬에서 실행되면 데이터는 프라이빗하다'는 가정을 뒤흔들기 때문입니다.

Bleeding Llama는 왜 그것만으로는 충분하지 않은지를 보여줍니다.

Bleeding Llama가 노출하는 것

기술적인 수준에서 Bleeding Llama는 Ollama의 GGUF 모델 로딩 경로에서 발생하는 힙 범위 초과 읽기(heap out-of-bounds read) 취약점입니다.

이는 전통적인 메모리 안전성 버그(memory-safety bug)처럼 들리며, 어떤 의미에서는 그렇습니다. 근본적인 약점은 CWE-125: 범위 초과 읽기(Out-of-bounds Read)입니다.

AI 특유의 영향은 이 버그가 존재하는 위치에서 발생합니다.

Ollama 서버는 프로세스 메모리에 여러 사용자의 프롬프트, 시스템 프롬프트, 도구 출력(tool outputs), 환경 변수, API 키 및 데이터를 보유할 수 있습니다. 만약 해당 메모리가 유출된다면, 모델이 의도적으로 무언가를 드러낼 필요도 없습니다. 인프라가 먼저 유출해 버리는 것입니다.

Cyera에 따르면, 인증되지 않은 세 번의 API 호출로 공격이 가능합니다:

# 1단계: 텐서 메타데이터(tensor metadata)를 부풀린 악성 GGUF 파일 업로드
POST /api/blobs/sha256:<hash>

...

공격자는 악성 GGUF 파일을 업로드합니다. 이 파일은 실제 파일 크기와 일치하지 않는 텐서 메타데이터를 선언합니다. 그러면 Ollama는 모델 생성 중에 해당 파일을 처리합니다. 취약한 경로가 예상된 버퍼를 넘어 읽게 되고, 관련 없는 힙 메모리(heap memory)를 결과물인 모델 아티팩트(model artifact)로 복사하게 됩니다.

공격자는 그 다음 Ollama의 /api/push 엔드포인트를 사용하여 해당 모델 아티팩트(model artifact)를 공격자가 제어하는 레지스트리(registry)로 푸시(push)합니다.

비밀번호가 필요하지 않습니다. 사용자의 상호작용도 필요하지 않습니다. 서버가 충돌(crash)할 필요도 없습니다.

이것이 바로 이 취약점을 특히 골치 아프게 만드는 지점입니다. 단순히 메모리가 유출될 수 있다는 것만이 문제가 아닙니다. 유출된 내용이 정상적인 모델 작업처럼 보이도록 패키징될 수 있다는 점이 문제입니다.

로컬(Local)이 프라이빗(Private)을 의미하지 않는 이유

Ollama는 로컬 사용을 위해 설계되었습니다. 그것이 Ollama의 매력 중 하나입니다.

개발자는 이를 설치하고, 모델을 풀(pull)하고, 빠르게 실험을 시작할 수 있습니다. localhost에 묶인 노트북 전용 설정에서는 리스크 프로파일(risk profile)이 공유되거나 노출된 서버와는 매우 다릅니다.

문제는 로컬 도구들이 종종 팀 인프라(infrastructure)가 된다는 점입니다.

개발자는 로컬 실험으로 시작합니다. 그러다 팀원이 접근하기를 원합니다. 그다음 서비스가 더 넓은 네트워크 인터페이스(network interface)에 바인딩(bound)됩니다. 그러고 나서 데모 환경, 내부 도구, 노트북 서버, CI 워크플로(workflow), 또는 공유 AI 게이트웨이(gateway)의 일부가 됩니다.

그 시점에서 '로컬'이라는 단어는 오해의 소지가 생깁니다.

모델은 여전히 팀이 제어하는 하드웨어에서 실행되고 있을지 모르지만, 서비스는 이제 다른 시스템에서 도달할 수 있는 상태가 됩니다. 엔드포인트(endpoint)가 생기고, 모델 로딩 경로가 생기며, 외부 유출(egress) 동작이 생깁니다. 비밀(secrets), 프롬프트(prompts), 그리고 도구 출력(tool output)에 대한 접근 권한도 갖게 됩니다.

그것은 더 이상 단순한 로컬 모델이 아닙니다.

그것은 인프라입니다.

그리고 인프라에는 보안 테스트가 필요합니다.

공개(Disclosure) 문제

Bleeding Llama는 두 번째 문제인 보안 가시성(security visibility)도 보여줍니다.

Cyera의 타임라인에 따르면, 이 취약점은 2026년 2월 2일에 Ollama에 보고되었습니다. 2월 25일에 수정 사항이 확인되었습니다. CVE 할당 및 공개적인 가시성은 그 이후에 이루어졌습니다.

실질적인 결과로, 운영자들은 패치 가용성과 명확한 보안 인식 사이에 간극을 겪게 되었습니다.

이것은 매우 중요한 문제입니다.

만약 릴리스 노트(release note)가 보안 수정 사항을 명확하게 표시하지 않는다면, 팀은 해당 업데이트를 일상적인 것으로 취급할 수 있습니다. 스캐너(scanners)에 아직 CVE가 등록되지 않았다면, 패치 관리 시스템(patch management systems)은 이를 우선순위로 격상시키지 않을 수 있습니다. 만약 영향을 받는 소프트웨어가 운영 인프라(production infrastructure)가 아닌 개발 편의 도구로 취급된다면, 전혀 밀착 관리되지 않을 수도 있습니다.

이것이 실제 상황에서 AI 인프라가 위험해지는 방식입니다.

위험한 시스템이 항상 공식적으로 운영(production)용이라고 라벨링된 것들만 있는 것은 아닙니다. 때로는 유용해져서 계속 온라인 상태를 유지하며, 조용히 민감한 데이터에 더 가까워진 실험용 서버들이 그 대상이 되기도 합니다.

엔지니어가 확인해야 할 사항

만약 귀하의 팀이 Ollama를 실행하고 있다면, 기본 사항부터 시작하십시오.

0.17.1 버전 이상으로 업그레이드하십시오.
Ollama가 공용 인터넷에 노출되어 있지 않은지 확인하십시오.
서비스가 localhost에만 바인딩(bound)되어 있는지, 아니면 더 넓은 인터페이스에 바인딩되어 있는지 확인하십시오.
다른 사용자나 시스템이 접근 가능한 모든 배포(deployment) 앞단에 인증(authentication)을 배치하십시오.
Ollama 프로세스가 클라우드 자격 증명(cloud credentials), API 토큰, 데이터베이스 자격 증명 또는 기타 비밀 정보(secrets)에 접근할 수 있는지 검토하십시오.
발생해서는 안 되는 모델 푸시(model push) 동작이 있는지 주시하십시오.

이것들은 즉각적인 점검 사항입니다. 이것이 전체 테스트 전략은 아닙니다.

더 넓은 교훈은 모델 서빙(model-serving) 인프라가 민감한 데이터를 처리하는 다른 모든 서버와 동일한 정밀 조사(scrutiny)를 필요로 한다는 점입니다.

시스템이 신뢰할 수 없는 모델 파일을 로드할 수 있다면, 모델 로딩 경로를 테스트하십시오.
모델 생성 엔드포인트(endpoints)를 노출한다면, 해당 엔드포인트에 인증이 필요한지 테스트하십시오.
모델 아티팩트(artifacts)를 외부 위치로 푸시할 수 있다면, 송신 제어(egress controls)를 테스트하십시오.
비밀 정보에 접근 권한을 가진 상태로 실행된다면, 프로세스 메모리 노출의 폭발 반경(blast radius)을 테스트하십시오.

모델 출력은 위험의 일부분일 뿐입니다.

QA 팀이 테스트해야 할 사항

QA 팀은 종종 프롬프트 계층(prompt layer)을 통해 AI 테스트에 접근합니다.

모델이 올바르게 답변하는가? 제품 규칙을 따르는가? 안전하지 않은 요청을 거부하는가? 응답에서 민감한 데이터를 노출하는가?

그러한 테스트들도 중요합니다. 다만 그것만으로는 충분하지 않을 뿐입니다.

Bleeding Llama는 모델이 스스로 비밀을 드러내기로 선택한 사례가 아닙니다. 이는 모델을 둘러싼 인프라(infrastructure)가 서버를 절대 떠나서는 안 될 메모리를 노출할 수 있는 사례입니다.

이 점이 테스트 계획을 변화시킵니다.

QA 및 보안 팀은 데이터가 어디로 흐르는지, 어디에 저장되는지, 누가 접근할 수 있는지, 그리고 공격자가 입력 경로(input path)의 일부를 제어할 때 어떤 일이 발생하는지를 테스트해야 합니다.

로컬 LLM 서버의 경우, 이는 노출된 엔드포인트(endpoints), 모델 임포트(import) 동작, 인증(authentication), 이그레스(egress) 동작, 비밀 정보(secrets) 배치, 로깅(logging), 업데이트 가시성, 그리고 버전 추적을 테스트하는 것을 의미합니다.

또한 모델 파일을 신뢰할 수 없는 입력(untrusted input)으로 취급해야 함을 의미합니다.

모델 아티팩트(artifact)는 단순한 데이터가 아닙니다. 그것은 파서(parsers), 컨버터(converters), 로더(loaders), 양자화기(quantizers), 그리고 파일 처리 코드를 실행합니다. 만약 귀하의 제품이 모델 파일을 수락하거나 외부 레지스트리(registries)에서 모델을 가져온다면, 해당 경로들은 보안 테스트 계획에 포함되어야 합니다.

더 넓은 패턴

Bleeding Llama는 단지 Ollama만의 이야기가 아닙니다.

이는 AI 인프라에서 나타나는 더 큰 패턴의 일부입니다.

개발자의 편의를 위해 구축된 도구들은 빠르게 채택됩니다. 이들은 노트북에서 공유 서버로 이동합니다. 이들은 코딩 에이전트(coding agents), 내부 도구, 데이터 파이프라인(data pipelines), 그리고 지식 베이스(knowledge bases)에 연결됩니다. 그러고 나서 운영 시스템(production systems)에 기대되는 보안 강화(hardening) 과정을 항상 거치지는 않은 채 제품의 일부가 됩니다.

그 결과, 도구가 설계된 방식과 실제로 사용되는 방식 사이에 간극이 발생합니다.

그 간극이 바로 보안 실패가 발생하는 지점입니다.

모델을 직접 실행하는 것은 일부 리스크를 줄일 수 있습니다. 데이터를 제3자 API로부터 격리할 수 있습니다. 팀에게 배포 및 보존(retention)에 대한 더 많은 통제권을 부여할 수 있습니다.

하지만 이는 또한 새로운 책임들을 만들어냅니다.

이제 귀하가 서버를 소유합니다. 귀하가 네트워크 노출을 소유합니다. 귀하가 업데이트 프로세스를 소유합니다. 귀하가 해당 프로세스에서 사용 가능한 비밀 정보(secrets)를 소유합니다. 귀하가 모델 로딩 경로를 소유합니다.

로컬 제어는 유용합니다. 하지만 그것이 보안 테스트의 대체재는 아닙니다.

핵심 요약

시스템이 데이터를 유출하기 위해 모델이 반드시 잘못된 말을 할 필요는 없습니다.

인프라가 잘못된 입력을 신뢰하기만 하면 됩니다.

이것이 바로 Bleeding Llama가 주는 진정한 교훈입니다.

AI 보안 테스트 (AI security testing)는 프롬프트 계층 (prompt layer)에서 멈춰서는 안 됩니다. LLM 서버가 제품의 일부가 되는 순간, 그 서버는 공격 표면 (attack surface)의 일부가 됩니다.

만약 해당 서버가 프롬프트 (prompts), 시스템 프롬프트 (system prompts), 도구 출력값 (tool outputs), 자격 증명 (credentials), 그리고 개인 데이터 (private data)를 메모리 (memory)에 보유하고 있다면, 메모리는 민감한 데이터 저장소 (sensitive data store)가 됩니다.

데이터 저장소처럼 테스트하십시오.

LLM을 사용하는 제품의 QA 또는 보안 업무를 담당하고 계신다면, 저의 강의 AI Security Testing: Finding Sensitive Data Leaks (OWASP LLM-02)에서 테스트 방법론을 심도 있게 다룹니다.

참고 문헌 (References)