CVE-2026-122159: Audio8_TTS 모델 경로 해석의 경로 순회 취약점 점검

Edge0-AI Audio8_TTS의 0.1B INT8 ONNX 런타임에는, 모델 패키지가 선언한 파일 경로를 그대로 받아들이는 동작이 있습니다. 이 동작이 CVE-2026-122159로 등록되었습니다. 표면상의 원인은 경로 검증 누락이지만, 문제의 무게중심은 신뢰 경계가 놓인 자리입니다. 무엇이 안전한 경로인지를 정하는 기준이 런타임 코드 안에 아니라, 외부에서 내려받은 모델 패키지의 선언문에 있기 때문입니다.

개요

VulDB(CNA)와 CVEProject 레지스트리 기록 기준, Edge0-AI Audio8_TTS는 커밋 1d64afcc2da56222b41ddcf53de7b8bc54be1fb6 이하 버전에서 경로 순회(path traversal, CWE-22) 약점을 갖습니다. 영향을 받는 구현은 0.1B INT8 ONNX 런타임이고, 취약 지점으로 지목된 함수는 onnx_runtime_0_1b_int8/arktts_runtime/runtime.py의 ArkTtsRuntime.__init__, Model Path Resolution 컴포넌트입니다. (CVE 레코드)

레지스트리에 담긴 심각도 지표도 함께 볼 필요가 있습니다. 같은 CVE 레코드에는 CVSS v3.1 6.3과 CVSS v4.0 5.3 점수가 수록되어 있어 등록기관 기준으로는 중간 수준으로 표시되며, CISA ADP의 SSVC 평가는 Exploitation 단계를 poc로 기재합니다. 공개된 재현은 확인되지만 실제 환경 악용은 확인되지 않았다는 현재 정황과 같은 선상에 놓인 평가입니다.

메커니즘은 프로젝트 커뮤니티에서 먼저 드러났습니다. 보고자 Dem000000이 Audio8_TTS 이슈 #41에서 모델 패키지 밖의 ONNX 그래프가 조용히 로드되는 과정을 정리했고, 연구 보고서(3em0 cve_repo)도 같은 흐름을 CWE-22로 분석했습니다.

두 자료와 CVE 레코드가 지칭하는 커밋 값은 서로 다릅니다. CVE 레코드는 1d64afcc2da56222b41ddcf53de7b8bc54be1fb6 이하를 취약 범위로 적고, 연구 보고서는 07e40f5d0b03 커밋을 검증 대상으로 삼았습니다. 어떤 커밋에서 문제가 시작됐고 어디부터 안전한지에 대한 공식 정보는 현재 증거에 없으므로, 버전 비교는 이 두 값의 범위로만 이해하는 것이 안전합니다.

영향 범위

이 약점의 직접적인 영향 대상은 Audio8_TTS 그 자체가 아니라, Audio8_TTS 0.1B INT8 ONNX 런타임에 모델 패키지를 공급해 로드하는 구성입니다. 전제 조건은 분명합니다. 공격자가 제어하거나 변조한 모델 패키지의 manifest를 런타임이 로드해야 합니다.

따라서 노출 정도는 배포 방식이 결정합니다.

• 검증된 사내 저장소나 통제된 저장소에서만 모델을 내려받고, 패키지 저장소와 접근 권한이 분리된 구성이라면 직접적인 노출은 제한적입니다.
• 반대로 외부에서 가져온 패키지를 별도 검증 없이 런타임에 그대로 연결하는 구성, 또는 사용자가 올린 모델 파일을 서비스가 로드하는 구성이라면 같은 코드가 훨씬 높은 위험을 갖습니다.

피해의 성격은 코드 주입과 조금 다릅니다. 준비된 ONNX 그래프가 런타임 프로세스 권한으로 실행되고, 그 그래프의 연산이 모델 패키지 디렉터리 밖 파일을 대상으로 수행될 수 있습니다. 실제로 어디까지 가능한지는 ONNX 런타임에 어떤 연산이 활성화되어 있는지에 따라 달라질 수 있으며, 이 범위에 대한 독립 검증 자료는 아직 확인되지 않았습니다.

추가로 알아 둘 점은 조용히 진행된다는 것입니다. 패키지 경계 밖 파일이 로드되어도 기본 동작에서는 별다른 경고나 실패가 발생하지 않습니다. 즉 이 약점은 오류 로그가 쌓여서 드러나는 유형이 아니며, 의식적으로 경로와 파일 접근을 살펴봐야만 발견할 수 있는 유형입니다.

기술적 분석

경로 해석 어디서 갈라지는가

ArkTtsRuntime.__init__는 모델 경로를 해석할 때 manifest가 선언한 파일 경로에 대해 is_file() 존재 여부만 확인하고, 그대로 onnxruntime.InferenceSession에 넘깁니다. 이 경로가 모델 패키지 디렉터리 내부로 정규화되는지, 상위 디렉터리 참조를 포함하지 않는지 검사하는 단계가 없습니다.

결과를 바꾸는 데 소스 코드 수정은 필요하지 않습니다. manifest에 다음과 같이 선언만 하면 됩니다.

{"slow_decode_models": {"int8": "../victim/slow_selected.onnx"}}

slow_decode_models.int8에 선언된 ../victim/slow_selected.onnx는 is_file() 관문을 통과하고, 이어지는 로드 단계에서 패키지 디렉터리 밖의 ONNX 그래프가 조용히 로드되어 실행됩니다. 존재 확인은 있었지만 경계 확인은 없었던 셈입니다.

공개 PoC·익스플로잇 분석

출처. 재현과 관련한 자료는 두 곳입니다. 보고자 Dem000000이 올린 Audio8_TTS 이슈 #41이 1차 보고로, manifest 경로 조작으로 패키지 밖 그래프가 로드되는 흐름과 함께 재현용 스크립트(make_poc.py) 첨부와 단계별 재현 절차가 담겨 있습니다. 3em0 cve_repo 연구 보고서는 같은 흐름을 CWE-22로 정리했습니다.

전제조건. 재현이 성립하려면 런타임이 공격자가 제어하거나 변조한 모델 패키지를 실제로 로드해야 하고, 해당 패키지의 manifest에 slow_decode_models.int8처럼 모델 파일을 가리키는 항목이 존재해야 하며, 그 값에 ../victim/slow_selected.onnx 같은 상위 디렉터리 참조가 들어 있어야 합니다. 반대로 검증된 경로로만 패키지를 배포하는 환경에서는 이 재현 흐름이 시작되지 않습니다.

입증 범위. 공개 자료들이 보이는 것은 manifest 선언 하나로 is_file() 관문을 통과해 패키지 디렉터리 밖의 ONNX 그래프가 로드되고 실행된다는 점까지입니다. 거기서 한 걸음 더 들어간 피해 범위, 즉 로드된 그래프의 연산이 파일 시스템에서 어디까지 도달하는지는 ONNX 런타임 설정에 따라 달라질 수 있으나, 이를 독립적으로 검증한 자료는 현재 증거에 없습니다. 또한 조사 시점 기준으로 실제 환경 악용 사례(in-the-wild exploitation)와 CISA KEV 등재는 확인되지 않았습니다. 정리하면 메커니즘의 공개 검증은 끝났고, 실질적 피해 규모의 검증은 남아 있습니다.

운영상 의미. 공개된 재현은 manifest 파일의 경로 선언을 바꾸는 형태로 설명됩니다. 다만 그 시작점은 언제나 모델 패키지 로드입니다. 따라서 대응의 첫 자리는 어떤 패키지를 실제로 로드하도록 허용하는가이며, 위에 적힌 전제 조건을 그대로 다시 읽어보고 내 구성이 그 조건을 충족하는지 확인하는 것이 PoC 공개 이후 가장 먼저 할 일에 해당합니다.

왜 이 차이가 중요한가

정규화된 경로와 모델 패키지 루트를 비교하는 검사가 없으면, manifest는 단순한 설정 파일이 아니라 어떤 그래프를 실행할지 가리키는 입력이 됩니다. 코드 리뷰를 통과한 런타임이라도, 그 런타임이 어떤 패키지를 받아들일지는 코드와 별개로 결정되기 때문입니다.

그래서 운영상의 첫 판단 기준은 배포 방식입니다. 검증된 경로로만 모델 패키지를 받아들이는 환경에서는 직접적인 노출이 제한적이고, 검증되지 않은 패키지가 로드될 수 있는 구성이라면 같은 코드가 더 높은 위험으로 작용합니다. 여기에 더해 런타임 코드에 경로 경계 검사를 두면 패키지 검증과 무관하게 한 단계의 안전망을 더할 수 있습니다. 다만 이는 supplied 자료에 명시된 요구 사항이 아니라, 확인된 메커니즘에서 도출한 추가 권고로 이해해야 합니다.

검증된 것과 남은 공백

공개된 이슈와 연구 보고서, 그리고 CVE 레코드의 지표로 확인된 것은 경로 순회 메커니즘과 manifest 조작을 통한 재현 흐름, 그리고 CVSS v3.1 6.3·CVSS v4.0 5.3이라는 공식 점수까지입니다. 반면 조사 시점 기준으로 실제 환경 악용 사례와 CISA KEV 등재는 확인되지 않았고, 패치로 처리된 수정 버전이나 커밋도 현재 증거에서 확인되지 않습니다. 독립 제3자의 추가 검증 보고 또한 확인되지 않았습니다. 대응 순위를 절대 등급으로 매기기보다, 내 배포 구조가 위 전제 조건에 얼마나 가까운지로 판단해야 하는 이유입니다.

대응 방안

지금 확인할 것

• Audio8_TTS 0.1B INT8 ONNX 런타임을 운영 중이라면, 배포된 모델 패키지의 manifest 모델 경로 선언부에 ../ 같은 상위 디렉터리 참조가 있는지부터 스캔합니다.
• 특히 slow_decode_models 등 모델 경로를 선언하는 항목을 열어, 패키지 디렉터리 밖을 가리키는 경로가 섞여 있지 않은지 확인합니다.
• 외부 출처에서 받은 패키지가 하나라도 섞여 있다면, 로드 전에 격리해 선언 내용과 파일 배치를 따로 검사합니다.
• 런타임이 외부 입력으로 모델 패키지를 받는 구조라면, 점검이 끝날 때까지 해당 기능의 노출을 줄이거나 허용 목록으로 대상을 제한하는 것이 우선입니다.

구조를 고치는 방법

• 경로 해석 시 manifest 선언 경로를 정규화한 뒤 모델 패키지 루트 디렉터리 내부에 있는지를 검사하는 경계 확인 단계를 추가합니다.
• 이 검사를 통과하지 못한 모델 선언은 조용히 따라가지 말고 로드를 거부하고 명시적으로 실패하도록 바꿉니다.
• 모델 패키지에 해시 또는 서명 기반 무결성 검증을 도입해, 배포 후 변조되거나 다른 파일과 교체되는 상황을 배포 시점에 막습니다.
• 패치 버전이 공개되면 즉시 업그레이드하되, 그 전까지는 경로 검증 우회가 어려운 배포 파이프라인으로 보완합니다. 목표 버전을 아직 특정할 수 없으므로, 업그레이드 계획은 공개 일정에 연동해 두는 편이 현실적입니다.

관찰 지점

• InferenceSession이 로드한 ONNX 파일의 절대 경로를 로그에 남기고, 모델 패키지 디렉터리 밖 경로가 나타나는지 모니터링합니다.
• TTS 서비스 프로세스의 파일 접근 이벤트, 특히 모델 디렉터리 밖 ONNX 파일 열기를 살펴봅니다.
• 위 항목은 공급자가 제공한 지침이 아니라 현재 확인된 메커니즘에서 도출한 운영 제안입니다. 조용히 로드되는 특성을 고려하면, 로그에 남은 절대 경로와 manifest 스캔이 사실상 가장 직접적인 관찰 수단에 가깝습니다.

참고자료

• CVE-2026-122159: Edge0-AI Audio8_TTS Model Path Resolution runtime.py ArkTtsRuntime.init path traversal
• Path traversal in runtime_manifest.json model resolution loads ONNX graphs from outside the model package (0.1B ONNX runtime)
• Edge0-AI Audio8_TTS 0.1B ONNX Runtime Manifest Path Traversal

함께 읽으면 좋은 글

• banks CompletionExtension의 도구 호출 해석이 importlib에서 레지스트리로 바뀐 건 — 확인되는 사실과 유보되는 판단
• 앵커 없는 ACR 호스트 검증 — docker-credential-acr-env가 Azure AD 토큰을 공격자 호스트로 보내는 구조
• CVE-2026-121419: SurrealDB MCP 세션 탈취 가능성 점검

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.