0.1.11까지의 Trail of Bits 변덕스러운 버전에서 UnsafeImportsML 분석 단계는 가져오기가 안전하지 않은 것으로 플래그 지정되었는지 여부에 관계없이 검사하는 모든 가져오기 노드에서 무조건 AnalysisContext.shorten_code(node)를 호출합니다. 이 호출은 공유 AnalysisContext.reported_shortened_code 세트에 단축 코드 표현을 등록합니다. 이후에 MLAllowlist 분석 단계가 실행되면 동일한 short_code() 메서드를 호출하고 모든 가져오기에 대해 이미_reported=True를 수신합니다.
0.1.11까지의 Trail of Bits 변덕스러운 버전에서 UnsafeImportsML 분석 단계는 가져오기가 안전하지 않은 것으로 플래그 지정되었는지 여부에 관계없이 검사하는 모든 가져오기 노드에서 무조건 AnalysisContext.shorten_code(node)를 호출합니다. 이 호출은 공유 AnalysisContext.reported_shortened_code 세트에 단축 코드 표현을 등록합니다. 이후에 MLAllowlist 분석 단계가 실행되면 동일한 short_code() 메서드를 호출하고 모든 가져오기에 대해 이미_reported=True를 수신하며 허용 목록 검사를 완전히 건너뛰는 continue 문을 실행합니다. 이는 모든 가져오기에 대해 MLAllowlist 데드 코드를 렌더링합니다. 가져오기가 ML 허용 목록에 있는지 여부를 평가하지 않습니다. MLAllowlist 패스는 UnsafeImports 거부 목록을 통과하는 안전한 것으로 알려진 ML 생태계(토치, numpy, 변환기 등) 외부의 모듈 가져오기를 포착하도록 설계되었습니다. MLAllowlist가 작동하지 않으면 UNSAFE_IMPORTS 거부 목록에 없는 표준 라이브러리 모듈은 피클 역직렬화를 통해 호출될 수 있으며 fickleing의 check_safety()는 LIKELY_SAFE를 반환합니다. fickling.load() API는 check_safety()를 명시적인 보안 게이트로 pickle.loads()에 연결합니다. 즉, LIKELY_SAFE 결과로 인해 페이로드가 역직렬화되고 실행됩니다. 근본 원인은 독립적으로 올바른 분석 패스 간에 변경 가능한 상태를 공유하는 것입니다. UnsafeImportsML은 격리된 상태로 설계된 대로 작동하고, MLAllowlist는 격리된 상태로 작동하지만, 공유된 reporter_shortened_code 세트로 인해 UnsafeImportsML이 MLAllowlist의 중복 제거 논리를 손상시킵니다.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 88.00 |
| 악용 신호(PoC 존재) | ×1.20 |
| VPI | 100.00 |
VPI 공식 vpi-v1 기준
| 소스 | CVSS 버전 | 기본 점수 | 심각도 | 벡터 문자열 | 평가일 |
|---|---|---|---|---|---|
| OSV3rd | 3.1 | 9.8 | CRITICAL | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | 2026. 07. 13. |
| NVDNIST | 3.1 | 8.8 | HIGH |
| CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H |
| 2026. 07. 05. |