모델 배포 포맷에 따른 취약점 발생 가능성

배경

vllm 서버 운영중 0.14.0 미만 버전에서 RCE 취약점이 발생했다고 해서 버전 패치를 했습니다. 
그런데 이전에 나와있던 취약점 중 모델 로드를 통해서 RCE 가 발생할 수 있다는 글을 보
고 이게 어떻게 가능한건지 찾아보게 되었는데요, 
배포포맷이나 일부 프레임워크에서 모델로드에서 가중치만 불러오는것이 아니라
파이썬 코드 로직을 탈 수 있다는 사실을 알게 되어 정리할 겸 글을 작성합니다.

 

CVE-2025-66448: vLLM Config Trust Bypass RCE | Miggo

 

모델 배포 포맷

인공지능 모델을 개발하다 보면 학습 자체보다 더 많은 문제가 발생하는 지점이 바로 배포입니다. 학습된 모델은 단순한 코드가 아니라 수백 MB에서 수십 GB에 이르는 가중치 데이터와 실행 구조를 함께 갖고 있기 때문입니다. 이때 모델을 어떤 형태로 저장하고 전달할 것인가에 대한 문제가 바로 모델 배포 포맷의 출발점입니다.

초기에는 학습한 프레임워크 내부에서만 모델을 사용했기 때문에, 단순히 메모리 객체를 그대로 직렬화하는 방식이 사용되었습니다. 하지만 모델이 커지고, 협업과 외부 공유가 늘어나면서 자연스러운 요구사항이 등장했습니다. 가장 큰 것은 다른 환경에서도 동일하게 모델을 로드할 수 있어야 한다는 것인데요, 모델을 만들고 학습시키는 것은 전체 파이프라인을 구성하지 않는 한 그다지 문제가 되지 않습니다만, 추론을 할 때에는 이식성이 중요하게 여겨졌습니다. 그래서 모델 파일만 export 하게 되었고, 이런 요구사항들을 해결하기 위해서 여러가지 모델 배포 포맷이 등장하게 되었습니다.

Pytorch .pt .pth

Pytorch 의 모델 저장 방식은 Python 객체를 그대로 데이터로 만드는 것인데 이것을 직렬화라고 합니다. 이 포맷도 다른 포맷들과 마찬가지로 모델 재현성의 요구사항을 해결했기 때문에 Research Level 에서는 편하게 사용될 수 있지만, 내부적으로 pickle 을 사용하고, 코드나 데이터 자체를 모두 직렬화 하기 때문에 해당 객체를 로드하는 경우 RCE가 가능하다는 치명적인 문제가 있습니다.

python 공시문서에서 pickle 은 직렬화와 역직렬화를 위한 모듈이라고 나와있습니다. 다른 예시로 사용되는 것들도 나중에 한번 찾아볼법 한 것 같습니다.

pickle — Python object serialization

그래서 Pytorch 의 모델은 배포환경에서는 사용을 지양하는 것이 좋은 것 입니다.

pytorch 는 모델의 형태를 저장할 때 아래와 같이 저장하면서 직렬화를 하는데요, 파라미터만 저장할 수도 있습니다.

import torch
#model 객체 그대로 직렬화
torch.save(model, 'model.pth')
torch.load('model.pth')

#model 파라미터 직렬화 
torch.save(model.state_dict(), 'model.pth')
model.load_state_dict(torch.load('model.pth'))

발생가능한 취약점

# Define model
class TheModelClass(nn.Module):
    def __init__(self):
        super(TheModelClass, self).__init__()
        self.conv1 = nn.Conv2d(3, 6, 5)
        self.pool = nn.MaxPool2d(2, 2)
        self.conv2 = nn.Conv2d(6, 16, 5)
        self.fc1 = nn.Linear(16 * 5 * 5, 120)
        self.fc2 = nn.Linear(120, 84)
        self.fc3 = nn.Linear(84, 10)

    def forward(self, x):
        x = self.pool(F.relu(self.conv1(x)))
        x = self.pool(F.relu(self.conv2(x)))
        x = x.view(-1, 16 * 5 * 5)
        x = F.relu(self.fc1(x))
        x = F.relu(self.fc2(x))
        x = self.fc3(x)
        return x

# Initialize model
model = TheModelClass()

만약 위와 같은 모델이 있다면 torch.save 하는 시점에서 TheModelClass 가 직렬화됩니다. 그럼 class 안에 있는 함수들에 뭔가 다른 목적의 코드가 있다면 torch.load() 하는 시점에서 그대로 실행되겠지요. 이것이 pytorch 의 model.state_dict() 를 저장하지 않고 save 했을 때의 문제점 입니다. 그래서 pytorch 권장사항은 파라미터만 저장되게 하는 torch.save(model.state_dict,’model.pth’) 메서드를 사용하게 합니다.

Huggingface .safetensors

safetensors 는 가중치를 빠르게 저장하고 불러오기 위한 형식인데요, 다른 모델에서 발생할 수 있는 취약점 문제 특히 pickle 을 사용하면서 발생하는 python 객체저장이나 실행가능한 구조를 포함하고 있지 않습니다. safetensors 파일 구조는 헤더와 블록으로 구성되어 있습니다.

헤더는 JSON 형식으로 된 텐서들의 메타데이터이고, 데이터블록은 weight들이 존재하는 바이너리 형태입니다. 실제로 safetensors 를 열어서 확인해볼 수 있는데요

https://huggingface.co/Qwen/Qwen3-ASR-1.7B/tree/main

Qwen/Qwen3-ASR-1.7B at main

 

의 두번째 safetensors 가 발견한것중 용량이 좀 작네요, 이거로 테스트 해보셔도 좋을 듯 합니다.

from safetensors import safe_open

safetensors_file = 
with safe_open(safetensors_file, framework="pt") as f:
  tensor_name = f.keys()
  print(f"tensor list {tensor_name}")

  for key in tensor_name:
    tensor = f.get_tensor(key)
    print(f"tensor name {key} 의 데이터타입 : {tensor.dtype}")
    print(f"tensor name {key} 의 shape : {tensor.shape}")

tensor list ['thinker.model.layers.5.mlp.gate_proj.weight', 'thinker.model.layers.5.mlp.up_proj.weight', 'thinker.model.layers.5.post_attention_layernorm.weight', 'thinker.model.layers.5.self_attn.k_norm.weight', 'thinker.model.layers.5.self_attn.k_proj.weight', 'thinker.model.layers.5.self_attn.o_proj.weight', 'thinker.model.layers.5.self_attn.q_norm.weight', 'thinker.model.layers.5.self_attn.q_proj.weight', 'thinker.model.layers.5.self_attn.v_proj.weight', 'thinker.model.layers.6.input_layernorm.weight', 'thinker.model.layers.6.mlp.down_proj.weight', 'thinker.model.layers.6.mlp.gate_proj.weight', 'thinker.model.layers.6.mlp.up_proj.weight', 'thinker.model.layers.6.post_attention_layernorm.weight', 'thinker.model.layers.6.self_attn.k_norm.weight', 'thinker.model.layers.6.self_attn.k_proj.weight', 'thinker.model.layers.6.self_attn.o_proj.weight', 'thinker.model.layers.6.self_attn.q_norm.weight', 'thinker.model.layers.6.self_attn.q_proj.weight', 'thinker.model.layers.6.self_attn.v_proj.weight', 'thinker.model.layers.7.input_layernorm.weight', 'thinker.model.layers.7.mlp.down_proj.weight', 'thinker.model.layers.7.mlp.gate_proj.weight', 'thinker.model.layers.7.mlp.up_proj.weight', 'thinker.model.layers.7.post_attention_layernorm.weight', 'thinker.model.layers.7.self_attn.k_norm.weight', 'thinker.model.layers.7.self_attn.k_proj.weight', 'thinker.model.layers.7.self_attn.o_proj.weight', 'thinker.model.layers.7.self_attn.q_norm.weight', 'thinker.model.layers.7.self_attn.q_proj.weight', 'thinker.model.layers.7.self_attn.v_proj.weight', 'thinker.model.layers.8.input_layernorm.weight', 'thinker.model.layers.8.mlp.down_proj.weight', 'thinker.model.layers.8.mlp.gate_proj.weight', 'thinker.model.layers.8.mlp.up_proj.weight', 'thinker.model.layers.8.post_attention_layernorm.weight', 'thinker.model.layers.8.self_attn.k_norm.weight', 'thinker.model.layers.8.self_attn.k_proj.weight', 'thinker.model.layers.8.self_attn.o_proj.weight', 'thinker.model.layers.8.self_attn.q_norm.weight', 'thinker.model.layers.8.self_attn.q_proj.weight', 'thinker.model.layers.8.self_attn.v_proj.weight', 'thinker.model.layers.9.input_layernorm.weight', 'thinker.model.layers.9.mlp.down_proj.weight', 'thinker.model.layers.9.mlp.gate_proj.weight', 'thinker.model.layers.9.mlp.up_proj.weight', 'thinker.model.layers.9.post_attention_layernorm.weight', 'thinker.model.layers.9.self_attn.k_norm.weight', 'thinker.model.layers.9.self_attn.k_proj.weight', 'thinker.model.layers.9.self_attn.o_proj.weight', 'thinker.model.layers.9.self_attn.q_norm.weight', 'thinker.model.layers.9.self_attn.q_proj.weight', 'thinker.model.layers.9.self_attn.v_proj.weight', 'thinker.model.norm.weight']
tensor name thinker.model.layers.5.mlp.gate_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.mlp.gate_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.5.mlp.up_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.mlp.up_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.5.post_attention_layernorm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.post_attention_layernorm.weight 의 shape : torch.Size([2048])
tensor name thinker.model.layers.5.self_attn.k_norm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.k_norm.weight 의 shape : torch.Size([128])
tensor name thinker.model.layers.5.self_attn.k_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.k_proj.weight 의 shape : torch.Size([1024, 2048])
tensor name thinker.model.layers.5.self_attn.o_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.o_proj.weight 의 shape : torch.Size([2048, 2048])
tensor name thinker.model.layers.5.self_attn.q_norm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.q_norm.weight 의 shape : torch.Size([128])
tensor name thinker.model.layers.5.self_attn.q_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.q_proj.weight 의 shape : torch.Size([2048, 2048])
tensor name thinker.model.layers.5.self_attn.v_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.5.self_attn.v_proj.weight 의 shape : torch.Size([1024, 2048])
tensor name thinker.model.layers.6.input_layernorm.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.input_layernorm.weight 의 shape : torch.Size([2048])
tensor name thinker.model.layers.6.mlp.down_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.mlp.down_proj.weight 의 shape : torch.Size([2048, 6144])
tensor name thinker.model.layers.6.mlp.gate_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.mlp.gate_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.6.mlp.up_proj.weight 의 데이터타입 : torch.bfloat16
tensor name thinker.model.layers.6.mlp.up_proj.weight 의 shape : torch.Size([6144, 2048])
tensor name thinker.model.layers.6.post_attention_layernorm.weight 의 데이터타입 : torch.bfloat16

weight 에 대한 데이터가 있는것을 볼 수 있습니다. RCE 를 원천적으로 막기 위해 설계 된 만큼 safetensors 모델자체에 대해서는 발견된 취약점이 없습니다.

Microsoft ONNX(Open Neural Network Exchange)

ONNX 는 많은 머신러닝 프레임워크 간의 모델을 통합할 수 있도록 설계된 오픈소스 포맷입니다. ONNX 를 통해서 개발자들은 Pytorch 나 Tensorflow 등 상이한 머신러닝 프레임워크에서 개발해도 ONNX 를 통해서 서로다른 프레임워크로 쉽게 전환해서 사용할 수 있습니다. 이 역시 배포를 원활하게 하자는 정신에서 개발되었습니다.

import torch
import torchvision.models as models
import onnx

# 사전 훈련된 PyTorch 모델 로드
model = models.resnet18(pretrained=True)
model.eval()

# 더미 입력 데이터 생성
x = torch.randn(1, 3, 224, 224, requires_grad=True)

# 모델을 ONNX 포맷으로 변환
torch.onnx.export(model,               # 실행할 모델
                  x,                   # 모델 입력값 (튜플 또는 여러 입력값을 위한 튜플도 가능)
                  "resnet18.onnx",     # 저장될 모델의 이름
                  export_params=True,  # 모델 파일 내 학습된 모델 가중치를 저장할지의 여부
                  opset_version=10,    # 모델을 변환할 때 사용할 ONNX 버전
                  do_constant_folding=True,  # 최적화: 상수 폴딩을 수행할지 여부
                  input_names = ['input'],   # 모델의 입력값에 대한 이름
                  output_names = ['output'], # 모델의 출력값에 대한 이름
                  dynamic_axes={'input' : {0 : 'batch_size'},    # 배치 크기에 따라 동적으로 변하는 입력 차원
                                'output' : {0 : 'batch_size'}})  # 배치 크기에 따라 동적으로 변하는 출력 차원

ONNX 발생 가능한 취약점

최근까지는 ONNX 의 보고된 취약점들에서 ONNX 자체의 취약점은 거의 없다고 해도 될정도로 없었고, 게다가 RCE 는 전혀 볼수 없었습니다. 이 마저도 C/C++ 엄밀히 말하면 런타임 유형의 취약점이라고 할 수 있었다는데요, 최근 발표 된 Path Traveling 취약점도 ONNX 포맷의 문제라기보다는, ONNX 모델을 처리하는 라이브러리 구현의 취약점이라고 합니다.

 

ONNX Path Traversal Vulnerability Exploited | Matt T.님이 토픽에 대해 올림 | LinkedIn

 

GGUF / GGML

GGML (Georgi Gerganov Machine Learning Format)

GGML은 Georgi Gerganov가 개발한 경량 머신러닝 라이브러리로, 대규모 언어 모델을 포함한 신경망 모델을 CPU 환경에서 효율적으로 추론하기 위해 설계된 C/C++ 기반 프로젝트입니다. Hugging Face의 소개 글에서도 강조하듯, GGML은 기존 딥러닝 프레임워크가 갖는 복잡성과 무거운 의존성을 최소화하는 것을 목표로 만들어졌습니다.

일반적인 머신러닝 프레임워크인 PyTorch나 TensorFlow는 매우 강력하지만, 대규모 라이브러리 의존성과 복잡한 빌드 환경을 요구합니다. 이는 서버 환경에서는 문제가 되지 않을 수 있지만, 개인 PC나 내부망, 오프라인 환경, 혹은 리소스가 제한된 시스템에서는 부담으로 작용합니다. GGML은 이러한 문제를 해결하기 위해 외부 의존성을 거의 갖지 않는 구조, 그리고 단순한 C 코드 기반 구현을 선택했습니다.

GGML의 핵심 철학은 “작고, 단순하며, 예측 가능한 실행”입니다. 실제로 GGML은 몇 개의 소스 파일만으로 구성되어 있으며, 컴파일된 바이너리 크기 역시 매우 작습니다. 별도의 Python 런타임이나 대형 프레임워크 없이도 모델을 실행할 수 있기 때문에, 환경 이식성이 매우 뛰어납니다. Linux, macOS, Windows는 물론이고 ARM 아키텍처나 Apple Silicon 환경에서도 비교적 쉽게 빌드하고 실행할 수 있습니다.

또 하나의 중요한 특징은 메모리 효율성입니다. GGML은 텐서 표현과 연산에서 불필요한 오버헤드를 제거하고, CPU 캐시 친화적인 메모리 레이아웃을 사용합니다. 특히 GGML이 널리 주목받게 된 이유 중 하나는 강력한 양자화(quantization) 지원입니다. float32 기반 모델을 int8, int5, int4 수준으로 압축해 메모리 사용량을 크게 줄이면서도, 추론 성능을 실용적인 수준으로 유지할 수 있도록 설계되었습니다.

이러한 특성 덕분에 GGML은 학습보다는 추론 중심 라이브러리로 사용됩니다. 이미 학습된 모델을 가능한 한 적은 자원으로 빠르게 실행하는 것이 목적이며, 실제로 llama.cpp, whisper.cpp, GPT4All, LM Studio, Ollama와 같은 여러 프로젝트들이 GGML을 저수준 연산 엔진으로 활용하고 있습니다. 이 경우 GGML은 단순한 모델 포맷이라기보다는, 모델 실행을 담당하는 저수준 런타임에 가깝다고 볼 수 있습니다.

구조적으로 보면 GGML은 내부에 텐서와 연산 그래프를 관리하는 context를 두고, 연산 그래프를 기반으로 계산을 수행합니다. 또한 CPU, CUDA, Metal 등 다양한 백엔드를 지원할 수 있도록 설계되어 있으며, 백엔드별로 메모리 할당과 연산 스케줄링을 분리해 관리합니다. 이러한 구조 덕분에 가볍지만 단순한 수준을 넘는 유연성을 확보할 수 있었습니다.

다만 GGML은 이러한 장점과 함께 한계도 갖고 있습니다. C/C++ 기반 라이브러리 특성상 사용 난이도가 높고, Python 기반 프레임워크에 익숙한 사용자에게는 진입 장벽이 될 수 있습니다. 또한 모델 메타데이터 표현이 제한적이고, 토크나이저나 specia1 token, rope 설정과 같은 부가 정보를 함께 관리하는 데에는 불편함이 존재했습니다. 이러한 한계는 모델이 복잡해질수록 점점 더 문제가 되었습니다.

이러한 배경 속에서 GGML은 점차 GGUF(GGML Unified Format)로 발전하게 됩니다. GGUF는 GGML의 철학을 유지하면서도, 모델 실행에 필요한 메타데이터를 보다 명확하고 확장 가능하게 담기 위해 설계된 포맷입니다. 현재 llama.cpp 생태계에서도 GGML보다는 GGUF 사용이 권장되고 있으며, GGML은 점차 레거시 포맷의 위치로 이동하고 있습니다.

정리하자면, GGML은 “모델을 안전하게 저장한다”는 배포 포맷의 개념보다는, “모델을 가볍고 효율적으로 실행한다”는 목적에 충실한 라이브러리입니다. Python 객체 직렬화나 실행 가능한 코드 로딩과는 거리가 멀기 때문에, 구조적으로 RCE와 같은 취약점과도 무관한 편입니다. 다만 다른 모든 실행 엔진과 마찬가지로, 최종적인 안정성과 보안성은 런타임 구현과 운영 방식에 의해 결정된다는 점은 동일하게 적용됩니다.

GGUF (GGML Unified Format)

GGUF는 GGML을 기반으로 한 개선된 포맷입니다. 이름에서 알 수 있듯 '통합된(Unified)' 형식을 지향하며, 더 많은 메타데이터를 포함하고 확장성을 높였습니다. 이름을 붙일때에도

<BaseName><SizeLabel><FineTune><Version><Encoding><Type><Shard>.gguf 라는 네이밍 규칙을 만들었습니다. 더 많은 메타데이터를 포함할 수 있게 파일구조가 개선되었습니다.

GGUF 는 너무 많은 이야기들이 있는데 따로 다루도록 하겠습니다. 결론은 GGML 은 트랜스포머 모델 서빙 특화 배포 포맷이고, GGUF 는 여기서 관리적인 측면을 고도화한 포맷이라고 생각하면 될 것 같습니다.

GGML /GGUF 의 취약점 발생 가능성

GGML 이나 GGUF 둘다 Python 객체를 포함하지 않고 같은 의미로 pickle 이나 어떤 스크립트를 포함하지 않습니다. 그래서 모델 자체가 코드를 실행시킨다던지의 취약점은 발생하지 않습니다.

프레임워크를 알아보다 보니 정말 너무 많은 프레임워크들이 있더라구요, 그래서 GPT 에게 정리를 좀 해달라 했더니 어디서 사용하고 있는지도 모르는 녀석들까지 가져다 정리를 했네요,

포맷 / 형태	주 사용처	포함 내용	코드 실행 가능성	보안 위험도	장점	단점	권장 사용 여부
safetensors	HF, 내부망, 보안 환경	순수 텐서 가중치	❌ 없음	⭐ 매우 낮음	pickle 미사용, fast mmap, 안전	가중치만 저장	✅ 강력 권장
PyTorch .pt / .pth	연구/개발	Python 객체 + 가중치	🔥 가능	🔥🔥🔥	저장 유연성	pickle 기반 RCE	❌ 배포 금지
HF .bin (pytorch_model.bin)	HF 구버전	pickle 가중치	🔥 가능	🔥🔥🔥	호환성	사실상 .pt	❌
ONNX .onnx	추론/서빙	정적 그래프 + 가중치	❌	⭐ 낮음	프레임워크 독립, 빠름	동적 구조 제한	✅ 추론용
TorchScript .ts / .pt	PyTorch 서빙	IR 그래프 + 가중치	⚠️ 제한적	⚠️ 중간	Python 제거	디버깅 어려움	⚠️ 제한적
TensorFlow SavedModel	TF 서빙	그래프 + 가중치	❌	⭐ 낮음	TF Serving 최적	TF 종속	⚠️
HDF5 .h5	Keras	가중치 + 구조	❌	⭐ 낮음	단순	대규모 모델 한계	⚠️
GGUF / GGML	llama.cpp	양자화 가중치	❌	⭐ 낮음	CPU 친화	학습 불가	✅ 로컬
MLflow model	MLOps	모델 + 메타 + 코드	🔥 가능	🔥🔥	관리 편함	코드 포함	⚠️ 검증 필수
Triton model repo	NVIDIA Triton	모델 + config	❌	⭐ 낮음	고성능 서빙	설정 복잡	✅
Docker image	배포	모델 + 코드 + OS	🔥🔥🔥	🔥🔥🔥	재현성	공격면 큼	⚠️ 내부검증
HF repo (전체)	공유	가중치 + Python	🔥🔥🔥	🔥🔥🔥	편의성	trust_remote_code	❌ 무검증
LoRA / Adapter	파인튜닝	가중치 delta	❌	⭐ 낮음	경량	base 필요	✅

그래서 결론은 모델은 여러 요구사항들을 해결하기 위해서 통합된 프레임워크를 사용했고, 그곳에서 발생하는 취약점은 대체로 pickle 의 직렬화를 사용해서 기대되는 문제점들이였습니다.

그래서 pickle 의 직렬화를 사용하지 않는다면, RCE 같은 치명적인 문제들은 모델 자체에서 생기지 않을 것 같습니다. 다만 모델 런타임 프레임워크에서 발생하는 취약점들은 전혀 다른 영역이니 사용에 참고해야할 것 같습니다.

틀린 정보가 있다면 알려주세요!