ash_ai의 영향 버전에서는 도구 액션이 예외를 발생시키거나 처리되지 않은 오류 값을 반환하는 등 도구 호출이 실패했을 때 오류의 원문이 정제 과정 없이 호출자에게 그대로 전달되면서 내부 구현 정보가 유출됩니다. 이 원문에는 내부 모듈과 함수 이름, 실행 중이던 값까지 담길 수 있습니다. 호출자는 MCP 클라이언트 또는 AshAi.ToolLoop 안에서 도구 결과를 돌려받는 LLM이라, 정보가 도구 경계를 넘어 흘러나가는 구조입니다.
이 글은 CVE-2026-119613의 작동 구조, 영향 버전, 노출 경로, 개발자와 보안 관리자가 바로 수행할 수 있는 점검 순서를 근거와 함께 다룹니다.
CVE-2026-119613 개요: 도구 오류 응답으로 새어 나가는 내부 정보
CVE-2026-119613은 ash_ai에서 도구 오류의 원문이 MCP 클라이언트와 모델에게 그대로 전달되어 내부 구현 정보가 노출되는 정보 노출 취약점입니다. 도구 호출의 실패 자체는 어떤 LLM 애플리케이션에서도 흔한 상황이지만, 이 취약점의 특징은 실패 원인을 요약하거나 일반화된 메시지로 대체하지 않고 원문을 그대로 밖으로 내보낸다는 점에 있습니다. CVE 레코드는 Erlang Ecosystem Foundation이 CNA(CVE Numbering Authority)로서 등재했습니다. 다만 GHSA 권고와 CNA 레코드 원문은 직접 수집되지 않았으므로, 이 서술은 수집 리포트 인용에 따른 이차 인용입니다.
수치형 CVSS 점수는 수집 자료에 존재하지 않지만, CyStack 취약점 DB는 이 취약점을 2026-11-09에 공개된 것으로 기록하고 심각도를 정성적으로 Medium으로 표기했습니다. 수집된 근거 기준으로 이 취약점의 실제 환경 악용 여부는 확인되지 않았고(CyStack 취약점 DB도 Not confirmed로 기록), 최종 심각도 판단은 아래의 작동 구조와 노출 경로를 자신의 배포 환경에 대입해 수행하는 것이 적절합니다.
핵심 사실을 먼저 표로 정리해 둡니다.
| 항목 | 내용 | 근거 |
|---|---|---|
| 취약점 식별 번호 | CVE-2026-119613 | |
| 영향 버전 | 1.5.0 이상 1.5.1 미만 | |
| 트리거 조건 | 도구 액션의 예외 발생, 처리되지 않은 오류 값 반환, 결과의 JSON 인코딩 불가 | |
| 노출 정보 | 내부 모듈·함수 이름, 실행 중인 값 | |
| 노출 경로 | MCP 클라이언트, AshAi.ToolLoop 내의 LLM | |
| 오류 원문 형식 | Exception.format/2의 전체 출력 | |
| 로그 기록 여부 | 해당 경로의 오류는 로그에 기록되지 않음 | |
| CNA | Erlang Ecosystem Foundation | |
| 공개일(CyStack 기록) | 2026-11-09 | |
| 심각도(CyStack 정성 기록) | Medium | |
| 악용 여부(CyStack 기록) | Not confirmed |
영향 범위: ash_ai 1.5.0 이상 1.5.1 미만
취약한 ash_ai 버전 범위는 1.5.0 이상 1.5.1 미만입니다. 이 범위에 해당하는 배포는 모두 영향권으로 보고 점검 대상이 됩니다.
해석 시 두 가지를 유의해야 합니다. 첫째, 1.5.0 미만 버전의 노출 여부는 수집 자료에서 근거가 확인되지 않아 영향이 없다고 단정할 수 없습니다. 둘째, 구체적인 수정 버전, 패치 내용, 배포 절차는 수집 자료에 존재하지 않습니다. 영향 범위 표기상 1.5.1 미만이 취약 구간이므로 갱신 검토의 기준점으로 삼을 수는 있지만, 실제 패치 여부와 절차는 공식 권고 원문과 프로젝트 저장소 발표에서 확정해야 합니다.
작동 구조: Exception.format/2 전체 출력과 남지 않는 로그
오류 원문이 흘러가는 세 가지 트리거
도구 호출의 결과가 원문 형태로 호출자에게 전달되는 조건은 세 가지입니다.
- 도구의 액션이 예외를 발생시키는 경우
- 도구가 처리되지 않은 오류 값을 반환하는 경우
- 결과를 JSON으로 인코딩할 수 없는 경우
세 조건 모두 도구가 정상 응답을 만들어내지 못하는 상황이라는 공통점이 있습니다. 도구 구현이 예외와 오류 값을 스스로 처리하도록 되어 있을수록 이 취약점의 트리거 기회 자체를 줄일 수 있다는 점이 점검의 출발점이 됩니다.
무엇이 노출되는가
예외가 발생한 경우 전달되는 원문은 Exception.format/2의 전체 출력입니다. 여기에는 내부 모듈과 함수 이름이 적히고, 많은 예외 유형에서는 코드가 실패한 값까지 포함됩니다. 모듈과 함수 이름은 코드 구조와 내부 인터페이스를 추론하는 단서가 됩니다. 실행 중이던 값에는 실제 처리 대상이던 데이터가 담겨 있을 수 있다는 점에서 단순한 오류 메시지 노출과는 정보 가치가 다릅니다.
로그에 남지 않는다는 것의 의미
이 경로를 통해 발생한 오류는 로그에 기록되지 않습니다. 오류의 원문이 호출자에게 그대로 전달되고 로그에는 아무것도 남지 않는다는 구조는 운영 관점에서 이중 부담을 만듭니다. 외부로 나간 정보의 양과 시점을 서버 측 기록으로 재구성할 수 없어 사후 감사와 침해 대응이 어려워지고, 오류 전달 동작 자체가 관측되지 않아 평시에 문제를 발견하기도 어렵습니다.
노출 경로와 전제 조건: MCP 클라이언트와 AshAi.ToolLoop의 LLM
오류 정보가 전달되는 주요 경로는 두 가지입니다.
- MCP 클라이언트: ash_ai는 MCP 서버 기능을 제공하는 패키지이므로, 이 서버에 접속하는 클라이언트가 오류 원문을 수신하게 됩니다.
- AshAi.ToolLoop 내의 LLM: 도구를 돌려받는 LLM이 오류 원문을 입력으로 받으므로, 오류에 담긴 내부 정보가 모델의 컨텍스트로 유입됩니다.
두 경로의 신뢰 수준은 배포 형태에 따라 다릅니다. MCP 서버를 조직 외부에 노출한 환경이라면 검증되지 않은 클라이언트가 오류 원문을 받을 수 있고, ToolLoop 경로라면 오류 정보가 모델의 응답 생성 과정에 함께 들어간다는 점을 점검 기준으로 삼아야 합니다. 취약점 분류상 이 문제는 정보 노출에 해당하며, 노출이 일어나려면 도구 실패 조건이 먼저 성립해야 합니다.
점검 순서: 버전 확인, 오류 응답 도달 범위 정리, 갱신 검토
- 버전 확인: 운영 환경의 ash_ai 버전을 확인하고 1.5.0 이상 1.5.1 미만 범위에 해당하는지 대조합니다.
- 트리거 조건 점검: 등록된 도구들이 예외를 발생시키거나 처리되지 않은 오류 값을 반환하거나 JSON으로 인코딩할 수 없는 결과를 만들어내지 않는지 점검합니다.
- 도달 범위 정리: 오류 원문이 도달하는 호출자를 정리합니다. MCP 서버에 접속하는 클라이언트 목록과 AshAi.ToolLoop에서 도구 결과를 돌려받는 LLM 경로를 함께 확인합니다.
- 관측성 확보: 이 경로의 오류는 로그에 남지 않으므로, 오류 전달 이력을 서버 측에서 별도로 확보할 수단이 있는지 점검합니다.
- 갱신 검토: 영향 범위가 1.5.1 미만으로 표기되어 있으므로 범위 밖 버전으로의 갱신을 검토하되, 수정 버전과 패치 내용은 수집 자료에서 확인되지 않으므로 공식 권고에서 확정한 뒤 진행합니다.
참고로 이 취약점에 대한 검증된 탐지 규칙이나 경고 문구는 수집 자료에서 확인되지 않았습니다. 현재 시점에서는 시그니처 기반 대응보다 위 순서의 구조적 점검이 맞는 접근입니다.
배경: ash_ai는 무엇인가, 그리고 최근 90일 취약점 동향
ash_ai는 Ash Framework의 LLM 확장 패키지로, 구조화된 출력을 지원하는 프롬프트 기반 액션, 도구 정의, 벡터화, MCP 서버 등의 기능을 제공합니다. 이 가운데 도구 정의와 MCP 서버 기능은 이번 취약점의 노출 경로와 직결됩니다. 도구가 실패했을 때 오류 원문이 MCP 클라이언트와 ToolLoop의 LLM으로 전달되는 구조가 곧 이 패키지의 핵심 기능이 만들어내는 통신 경로이기 때문입니다.
CyStack 취약점 DB는 2026-11-10 기준 ash_ai에 최근 90일간 8건의 보안 취약점이 기록되었고 그중 4건이 High 또는 Critical 등급이라고 정리합니다. 같은 요약에서 ‘능동 악용 취약점이 없다’는 서술은 CISA KEV 카탈로그 등재 기준이며, 같은 페이지의 개별 항목에는 CyStack 자체 판단에 따른 악용 표기가 별도로 붙어 있으므로 두 기준을 분리해 읽어야 합니다. 이번 취약점 CVE-2026-119613 자체는 Not confirmed로 기록되어 있습니다.
ash_ai를 도입한 환경이라면 도구 규모와 무관하게 이 취약점을 잠재 노출면으로 다루는 것이 맞습니다. 점검 우선순위는 앞선 순서대로 버전, 트리거 조건, 도달 범위, 관측성, 갱신으로 잡으면 됩니다.