CVE-2026-125386란? langchain4j-aideepin 메시지 참조 조회 IDOR 취약점 핵심 정리

CVE-2026-125386은 langchain4j-aideepin 3.32.0 이하 버전의 CharacterMessageController에 보고된 IDOR(안전하지 않은 직접 객체 참조) 취약점이다. 소유권 검증이 빠져 있어, 인증된 사용자가 다른 사용자의 메시지 참조에 접근할 수 있다. 노출 경로는 다른 사용자의 메시지 uuid를 knowledge-embedding-ref, memory-embedding-ref, graph-ref 세 참조 엔드포인트 중 하나에 넘기는 것이며, 그 메시지에 연결된 지식베이스 청크, 장기 기억 텍스트, 지식 그래프 데이터가 반환될 수 있다.

핵심 사실을 먼저 표로 정리한다.

CVE-2026-125386 개요: 성격과 전제 조건

langchain4j-aideepin은 AI 채팅, 지식베이스(RAG), 워크플로우 오케스트레이션, 장기·단기 기억, MCP 도구 등을 묶어 지능형 업무 어시스턴트를 빠르게 구축하기 위한 라이브러리다. 이번에 문제가 된 기능은 메시지에 연결된 참조 데이터 조회, 다시 말해 지식 임베딩·장기 기억 임베딩·지식 그래프 참조다.

IDOR은 애플리케이션이 사용자 제공 식별자로 객체에 접근하면서 해당 인증 사용자의 객체별 접근 권한을 검증하지 않을 때 생기는 취약점이며, OWASP API Security Top 10에서는 같은 결함을 BOLA(API1:2023)로 부른다. CVE-2026-125386은 바로 이 검증이 메시지 참조 조회 경로에 빠져 있다는 보고다.

영향 버전 범위는 langchain4j-aideepin 3.32.0 이하로 명시돼 있다. 성격상 이는 계정 탈취나 원격 코드 실행이 아니라, 이미 로그인한 사용자의 가시 범위를 넓혀주는 정보 노출이다. 악용에는 인증된 사용자와 다른 사용자의 메시지 UUID가 모두 필요하다. 익명 원격 공격자가 아니라 이미 계정을 가진 사용자에 가까운 전제다. 취약 지점은 모델 자체가 아니라 그 모델을 뒷받침하는 지식과 기억 저장소로 향하는 조회 경로라는 점도 짚어둔다.

영향 범위와 실제 노출 크기

실제 노출량은 해당 메시지에 참조 데이터가 연결돼 있는지와 서비스의 접근 조건에 따라 달라진다. 참조가 비어 있는 메시지라면 노출 내용도 얕다. 같은 인스턴스를 여러 사용자가 공유하고 업무 자료가 지식베이스와 장기 기억에 모여 있는 구성일수록 점검이 급해진다. 다만 이는 해당 조건이 성립할 때의 판단이며, 단일 사용자 구성이라면 우선순위가 달라질 수 있다.

기술적 원인: user_id 조건 없는 메시지 조인

listByMsgUuid와 세 매퍼의 조인 구조

조회 경로 원인의 확인 근거는 Issue #118에서 제보자가 제시한 v3.31.0 코드 대상 정적 검토다. 이 정적 검토에 따르면 메시지 참조 서비스는 메시지 UUID를 단서로 listByMsgUuid를 호출하고, CharacterMessageRefEmbeddingMapper.xml, CharacterMessageRefMemoryEmbeddingMapper.xml, CharacterMessageRefGraphMapper.xml 세 매퍼는 where b.uuid = #{uuid} 조건으로 조인한다. 이 조인문에 user_id 조건이 없어, 조사된 참조 조회 경로에서는 데이터 계층이 메시지의 소유자를 확인하지 않는 것으로 제시됐다.

형제 메서드와의 비교와 검증 범위의 한계

CharacterMessageService의 softDelete, getTextByAudioUuid 같은 형제 메서드는 사용자를 확인한다. 제시된 형제 메서드에는 사용자 확인이 있는데 조사된 참조 조회에는 그 조건이 없었다는 것이 Issue #118이 보여준 비교 범위다.

다만 SQL 수준의 매퍼 분석은 제보자의 정적 검토에 의존하며, 3.32.0에서 같은 조인문이 그대로인지는 별도 확인이 필요하다. 본문의 원인 설명 역시 3.32.0의 SQL 구현을 별도로 검증한 것이 아니라, CVE 레코드가 3.32.0 이하에 같은 종류의 소유권 검증 누락을 보고하는 범위에서 인용한 것이다.

수정 내용: 커밋 483499b의 소유자 기준 SQL 조인

수정 커밋 483499b1a6b4a27d856f85d88c28ae6152660953은 ref 매퍼의 메시지 조인을 호출 사용자 기준으로 좁혀, 다른 사용자의 메시지 uuid가 들어오면 어떤 호출자가 서비스에 도달하든 행이 반환되지 않게 한다. 커밋의 설명에 따르면 이 가드는 컨트롤러가 아니라 SQL과 함께 이동한다.

수정이 담당하는 것과 담당하지 않는 것

SQL에 둔 가드의 실효성은 수정된 ref 매퍼를 지나는 조회 경로에 한정된다. 참조 조회 외 경로까지 같은 방식으로 막혔는지는 이 자료만으로 판단할 수 없다. 소유자 기준 조인은 향후 노출을 막는 방향의 수정이지, 이미 조회된 이력을 되돌리는 조치가 아니다. 수정 적용 후에도 과거에 다른 사용자의 uuid로 참조가 반환됐을 가능성에 대한 검토는 별개로 남는다.

수정이 포함된 공식 배포 버전과 일정은 확인되지 않았다. 코드 적용 시점과 배포 경로는 따로 정해야 하고, 배포판 발표만 기다려서는 종료 시점을 특정할 수 없다.

대응 방안: 점검 순서, 임시 조치, 수정 검증

영향 범위로 판단되는 구성이라면 다음 순서로 점검한다.

1. 사용 여부 확인: 도입한 langchain4j-aideepin 버전이 3.32.0 이하인지, 지식 임베딩·기억 임베딩·지식 그래프 참조 기능을 실제로 호출하는 구성인지 먼저 본다. 참조 기능을 쓰지 않는 배포라면 이 취약점의 실제 영향은 크게 줄어든다.
2. 직접 점검: 권한을 갖춘 환경에서 진행하고, 반환 여부와 무관하게 테스트 데이터로 수행하는 편이 안전하다.
3. 임시 조치 검토: 운영상 가능한 경우, 수정 반영 전까지 해당 참조 엔드포인트의 접근을 제한하는 방안을 검토한다.
4. 수정 검증: 정당한 소유자의 조회가 그대로 동작하는지, 동시에 다른 사용자의 메시지 uuid에서는 참조 행이 반환되지 않는지 함께 확인한다.

침해 여부를 돌아볼 때는 접근 기록을 대조해 의심 사례를 추려볼 수 있다. 단, 기록에 사용자와 메시지를 연결하는 정보가 있어야 하고, 이 방법만으로 악용 여부를 확정할 수는 없다. 이 취약점 전용의 로그 항목이나 탐지 지표는 제공된 자료에 나오지 않는다. 위 대응은 모두 자료의 공백을 전제한 조건부 판단이며, 우선순위는 참조 기능의 실제 사용 여부와 다 사용자 구성 여부를 확인한 뒤 재산정한다.

확인되지 않은 사항과 자료의 한계

실제 환경에서의 악용이 확인됐다는 기록은 없으며, 공개 공격 코드의 존재 여부도 확정할 수 없다. 확정되지 않은 항목은 세 가지다. 수정 사항을 담은 공식 배포 버전과 일정, 메시지 UUID가 유출되거나 수집되는 구체적 경로, 취약점 전용 탐지 지표다. 메시지 UUID를 얻는 구체적 경로와 실제 운영 환경의 노출 범위, UUID의 생성 방식과 예측 난이도 역시 제공된 자료에서 확인되지 않았다.

본문의 CVE-2026-125386 관련 확인 사실은 SecurityDesk 명의로 2026.11.11에 발행된 리포트에 근거한다(IDOR·BOLA 일반 정의는 별도 전문 자료에서 인용). 해당 리포트는 CVE 레코드 JSON(cvelistV5 저장소), GitHub Issue #118, 수정 커밋, langchain4j-aideepin GitHub 저장소 4건을 참고자료로 제시한다. 원인 분석이 제보자의 v3.31.0 정적 검토에 의존한다는 점을 감안하면, 3.32.0 운영 환경에서는 해당 버전의 실제 SQL 조인을 직접 확인한 뒤 판단하는 편이 안전하다.