CVE-2026-1839, Hugging Face Transformers Trainer의 unsafe checkpoint loading 경로를 지적

X post가 짚은 내용

2026년 4월 7일, Vulmon Vulnerability Feed는 X에서 CVE-2026-1839를 언급하며 Hugging Face Transformers의 Trainer checkpoint loading flow에 arbitrary code execution 문제가 있다고 알렸다. 포스트 자체는 짧지만, 연결된 CVE record와 fix commit은 핵심을 분명하게 보여준다. CVE.org에 따르면 취약 경로는 src/transformers/trainer.py의 Trainer._load_rng_state()에 있다.

문제의 본질은 단순하지만 중요하다. 해당 메서드가 torch.load()를 weights_only=True 없이 호출했다는 점이다. CVE record는 Transformers가 PyTorch 2.6 미만과 함께 사용될 때 주변의 safe_globals() context manager가 실질적인 보호를 제공하지 못한다고 설명한다. 그 결과 rng_state.pth 같은 malicious checkpoint artifact를 불러오는 순간 arbitrary code execution이 가능해질 수 있다. 이 record의 CNA는 Protect AI이며, 분류는 CWE-502, 즉 untrusted data의 deserialization이다.

영향 범위와 수정

CVE.org는 영향 범위를 v5.0.0rc3 이전의 huggingface/transformers로 적시한다. 공개된 CVSS score는 6.5 Medium이며, local attack vector와 user interaction이 필요하다. 즉 인터넷에서 자동 전파되는 종류의 bug는 아니다. 그렇다고 가볍게 볼 수도 없다. ML workflow에서는 checkpoint file이 experiments, repos, collaborators, model hubs, CI systems 사이를 계속 이동하기 때문이다. 팀이 직접 만들지 않은 artifact를 load한다면, “local” 역시 software supply chain 한가운데에 있다.

참조된 Hugging Face fix commit은 매우 직접적이다. patch는 safety check를 추가하고, 취약한 호출을 torch.load(rng_file, weights_only=True)로 바꾼다. diff는 작지만, 많은 팀이 그저 training plumbing으로 여기는 경로에서 실행 surface를 제거한다는 의미가 크다.

왜 중요한가

• 문제는 많은 개발자가 내부 로직처럼 여기는 Trainer checkpoint handling 안에 있다.
• exploit path가 malicious checkpoint artifact에 의존한다는 점은 실제 ML 협업 방식과 정확히 맞닿아 있다.
• 이번 fix는 checkpoint file과 trainer internals도 AI software supply chain의 일부라는 사실을 다시 보여준다.

더 큰 교훈은 ML infra가 새로운 이름으로 오래된 security 문제를 계속 받아들이고 있다는 점이다. unsafe deserialization 자체는 새로운 취약점 클래스가 아니다. 그러나 이번 사례는 그것이 widely used한 Transformers workflow 안에 들어와 있다는 데 의미가 있다. 이 X post가 high-signal인 이유도 여기에 있다. shared checkpoint를 사용하는 팀이라면 artifact trust policy와 dependency upgrade를 선택적 hardening이 아니라 기본적인 ML hygiene로 다뤄야 한다.

Sources: Vulmon X post · CVE record · Hugging Face fix commit