JeeSite 5의 AI CMS 채팅 모듈에서 대화 주인만 열어볼 수 있어야 하는 AI 대화를 다른 로그인 사용자도 열람, 삭제, 가로채기할 수 있는 취약점이 보고됐습니다. CVE-2026-119048로 관리되는 이 문제는 정적 소스 리뷰에서 발견됐고, 유지관리자가 소유권 검증을 복원하는 수정 커밋을 확정했습니다.
개요
JeeSite 급속 개발 플랫폼의 AI CMS 채팅 모듈(jeesite-module-ai-cms)에서 대화별 소유권 확인이 깨진 IDOR(Insecure Direct Object Reference) 취약점이 확인됐습니다. GitHub 이슈 #43 보고에서 연구자는 v5.19.1 정적 소스 리뷰 중 문제를 찾았고, 유지관리자는 이를 받아들여 수정을 확정했습니다.
- 대상 컴포넌트: JeeSite 5의 AI CMS 채팅 모듈
jeesite-module-ai-cms - 취약점 유형: 객체 직접 참조 기반 접근 제어 실패(IDOR), 대화 단위 소유권 검증 무력화
- 공격 주체: 유효한 계정으로 로그인한 사용자. 익명 원격 공격은 아닙니다.
- 가능한 행위: 다른 사용자의 AI 채팅 대화 열람, 삭제, 가로채기
- 처리 상태: 유지관리자가 수정 커밋으로 소유권 검증 경로를 복원
핵심은 소유권 검사 로직이 한 곳도 없었던 것이 아니라는 점입니다. 수정 커밋은 checkPermiByConversationId의 인자 전달 순서를 교정하고 CacheChatMemoryRepository.java의 getChatMessage 경로에 가드를 추가하는 두 갈래로 이뤄져 있습니다. VulnCheck advisory도 소유권 확인이 누락되거나 뒤바뀐 상태를 원인으로 적시합니다. 확인된 근거는 여기까지이며, 자료에 명시되지 않은 다른 코드 경로까지 같은 문제로 일반화할 수는 없습니다.
영향 범위
VulnCheck advisory는 JeeSite 5.11.0부터 5.19.1까지의 AI CMS 채팅 모듈에서 인증된 사용자가 다른 사용자의 대화에 접근할 수 있다고 정리했습니다. 보고자가 코드 상태를 구체적으로 특정한 기준 버전은 v5.19.1로, 태그 v5.19.1.springboo4, v5.19.1.springboo3와 고정 커밋 5b5e2cf0adc45a1이 함께 적시됐습니다.
- 여러 사용자 계정이 하나의 JeeSite 인스턴스에서 AI CMS 채팅 모듈을 함께 쓰는 환경이 직접적인 영향권에 있습니다. 다른 사용자의 대화 데이터가 같은 저장소에 존재해야 성립하는 영향입니다.
- 다른 사용자 대화가 실제로 존재하는지 불분명한 구성은, 이번 근거 자료만으로 영향 범위를 판단할 자료가 없습니다. 버전 범위 확인과 별도로 대화 데이터의 소유 구조를 따로 살펴야 합니다.
- 5.11.0 미만이나 5.19.1 초과 버전에 대한 근거는 제공된 자료에 없습니다. 범위 밖 버전은 별도 확인이 필요합니다.
- CVSS 점수와 심각도 등급, CISA KEV 등재 여부, 수정이 반영된 정식 릴리스 버전 번호는 이번 근거 자료에서 확인되지 않았습니다.
기술적 분석
모듈은 대화 단위로 소유자를 확인하는 권한 검사 함수 checkPermiByConversationId를 이미 두고 있었습니다. 그러나 이 함수로 전달되는 인자의 순서가 잘못 맞아, 검사가 실제 대화 소유자를 기준으로 판정하지 못했습니다. 유지관리자의 수정 커밋 cbc5ba7은 인자 전달 순서를 바로잡고, AI CMS 모듈의 CacheChatMemoryRepository.java에서 getChatMessage 경로에 가드를 추가하는 방식으로 검증 흐름을 복원했습니다.
정리하면, 이번 자료의 근거가 가리키는 원인은 소유권 확인 코드의 완전한 부재가 아니라, 확인 단계가 존재했음에도 인자 조합이 어긋나 대화 단위 검증이 의도대로 작동하지 않은 상태입니다.
독자 입장에서 연결해 볼 의미는 두 갈래입니다. 첫째, 공격에 유효한 로그인 계정이 필요하므로 위험의 입구는 외부 익명 요청보다는 계정을 가진 사용자 쪽에 있습니다. 둘째, 열람만 가능한 취약점이 아니라 삭제와 가로채기가 함께 지목된 만큼, 피해는 대화 내용의 기밀성뿐 아니라 데이터의 무결성과 가용성으로 확장될 수 있습니다. AI 대화에 업무상 민감한 정보가 축적된다고 가정하면, 계정 수와 대화 이력이 많아질수록 노출 범위는 커집니다.
악용 현황과 자료의 한계
실제 악용 사례와 공개 PoC는 확인되지 않았습니다. 이 취약점은 연구자의 v5.19.1 정적 소스 리뷰에서 발견돼 GitHub 이슈로 보고됐고, VulnCheck advisory는 같은 취약점과 영향 범위를 별도로 기술한 보조 출처입니다. 따라서 현재로서는 확인된 침해가 아니라, 조건이 갖춰지면 실현될 수 있는 잠재 위험으로 다루는 편이 정확합니다. 공격 재현의 세부 단계와 대화 ID 형식, 로그에서 요청자와 대화 소유자를 대조할 때의 정확한 필드 구성도 제공된 자료 범위에서는 확정할 수 없습니다.
대응 방안
순서로 보면 첫 단계는 사용 여부 확인입니다.
- JeeSite AI CMS 채팅 모듈을 사용하는 자산이 목록에 있는지 즉시 확인하고, 버전이 5.11.0부터 5.19.1 범위에 해당하는지 점검합니다.
- 여러 일반 사용자 계정이 채팅 모듈에 접근하는 운영 환경이라면, 업그레이드 전까지 채팅 모듈 접근을 일시 제한하는 완화 조치 검토가 가능합니다.
근본 조치는 유지관리자가 확정한 수정이 반영된 버전으로 업그레이드하는 것입니다. 다만 수정을 담은 정식 릴리스 번호는 이번 자료에 명시되지 않았으므로, 커밋 포함 여부는 릴리스 정보로 직접 확인해야 합니다. 업그레이드 후에는 자신의 대화 ID와 타인의 대화 ID로 각각 접근해 소유권 검증이 실제로 동작하는지 테스트하는 것이 좋습니다.
모니터링 측면에서는 다음을 점검 거리로 볼 수 있습니다.
- AI 채팅 대화 접근 API 로그에서 요청자 계정과 대화 소유자가 서로 다른 요청이 남는지 확인합니다.
- 단일 계정이 다수의 대화 ID에 순차적으로 접근하는 비정상 패턴을 모니터링합니다.
- 구체적인 로그 필드와 endpoint 사양은 자료에 없으므로, 실제 환경에서 정상 접근과 차단 사례로 먼저 검증해야 합니다.
우선순위는 조건별로 다르게 잡을 수 있습니다. 다중 사용자 환경에서 대화 내용에 민감 정보가 쌓여 있고 즉시 업그레이드가 어렵다면 완화 조치와 로그 점검을 앞당기는 편이 합리적이고, 다른 사용자 대화가 얼마나 존재하는지 확인되지 않은 환경에서는 업그레이드 창을 정하는 것과 별도로 접근 로그 확인부터 하는 것도 가능합니다. 공개 PoC가 확인되지 않았다는 사실은 대응을 미룰 근거가 되지 않습니다. 요구 조건이 로그인 계정 하나뿐이라는 것은, 계정을 가진 내부 사용자에게는 조건이 이미 갖춰져 있을 수 있다는 뜻으로 읽을 수 있습니다.
참고자료
- JeeSite 5 AI CMS chat module: broken per-conversation ownership check (CVE-2026-119048)
- Fix commit cbc5ba7 - checkPermiByConversationId argument order correction and getChatMessage guard
- Issue #43 - maintainer confirms fix
- JeeSite 5.11.0 through 5.19.1 IDOR in AI CMS Chat Module advisory
함께 읽으면 좋은 글
- CVE-2026-76418: Cisco Secure Firewall ASA/FTD SSL VPN 원격 서비스 거부 취약점 분석
- CVE-2026-119050: Agno PandasTools의 unsafe reflection, 코드 실행 가능성과 점검 순서
- CVE-2026-48356: Adobe Commerce·Magento 파일 업로드 취약점(CWE-434)과 실제 악용 흐름 점검
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!