CVE-2026-3672

CVSS: 7.8

대상 서비스

JeecgBoot

• Java 기반의 저코드/엔터프라이즈 개발 프레임워크
• 코드 생성기, 권한 관리, 딕셔너리, 온라인 개발 등 백오피스 성격의 기능을 통합 제공함
• Spring Boot, MyBatis-Plus, Vue 기반으로 구성되며 국내외에서 빠른 업무 시스템 구축 용도로 사용됨
• 내부적으로 WAF 성격의 SQL 필터링 로직을 포함하고 있어 일부 동적 쿼리 입력에 대한 방어를 수행함

대상 버전

• 영향 받는 버전: JeecgBoot 3.9.0, 3.9.1

취약점 개요

취약점의 종류

• SQL Injection
• 인증 후 SQL 인젝션
• WAF 우회
  • JeecgBoot 내장 WAF의 정규식 및 블랙리스트 검증 로직을 우회할 수 있음.
• 동적 SQL 인젝션
  • 외부 입력이 filterSql로 해석되어 SQL의 where 절 뒤에 직접 결합됨.
• 블라인드 SQL 인젝션
  • 응답 차이를 기반으로 테이블명, 컬럼 존재 여부, 데이터 값을 추출할 수 있음.

발생한 원인

• 딕셔너리 조회 기능에서 설계적 결함이 있었음.
• GET /sys/dict/getDictItems/{dictCode} 또는 관련 API 경로로 전달된 dictCode 값이 서비스 계층으로 직접 전달되며, 특정 형식의 입력에 대해서는 네 번째 세그먼트가 필터 조건으로 해석됨.
• SysDictServiceImpl.java에서 4단 형식의 dictCode는 queryTableDictItemsByCodeAndFilter(params[0], params[1], params[2], params[3]) 경로로 처리되며, 여기서 네 번째 값이 ${filterSql}로 전달됨.
• 이후 SysDictMapper.xml에서 where ${filterSql} 형태로 동적 SQL 문자열 결합이 수행되어, 외부 입력이 SQL 구문 일부로 직접 반영되는 구조임.
• 원래는 SQL 인젝션 방지를 위한 필터링 로직이 존재하지만, 일반 검사 로직이 아니라 specialFilterContentForDictSql이라는 딕셔너리 전용 검사 로직을 타게 됨.
• 이 딕셔너리 전용 블랙리스트에는 일반 블랙리스트에 포함된 and, or가 빠져 있어 논리 조건 확장이 가능함.
• 또한 정규식 기반 탐지 로직이 단순 키워드 포함 여부가 아니라 특정 공백, 비공백 문자열, 특수문자 조합에 의존하는 방식이라 구문 배치만 바꾸면 우회가 가능함.
• 즉, 외부 입력을 SQL 조각으로 직접 받아들이는 구조와 불완전한 WAF 로직이 결합되어 SQL 인젝션이 발생함.

취약점 원리

공격 흐름

• 공격자 → 취약한 딕셔너리 조회 엔드포인트로 요청 전송
  • dictCode를 4단 형식으로 구성
  • 네 번째 항목에 SQL 조건식 삽입
• 서버 측 처리
  • 컨트롤러가 dictCode를 그대로 서비스 계층으로 전달함
  • 서비스 계층이 이를 분해한 뒤 네 번째 값을 필터 조건으로 해석함
• WAF 검사 수행
  • 기본 SQL 인젝션 검사 로직이 아니라 딕셔너리 전용 검사 로직이 적용됨
  • and, or 누락 및 정규식 결함으로 인해 필터 우회 가능
• SQL 조립
  • Mapper에서 where ${filterSql} 형태로 동적 SQL 결합 수행
• 블라인드 SQL 인젝션 수행
  • 참/거짓 응답 차이를 기반으로 데이터베이스 정보 추출 가능

공격자가 인증된 일반 사용자 권한만 가지고 있어도 딕셔너리 조회 API에 접근할 수 있는 시점에서, dictCode를 조작해 SQL 필터 구문을 삽입할 수 있음. 이 값은 내부적으로 filterSql로 해석되어 SQL 문장에 직접 결합되므로, 조건절 확장이 가능해짐.

이후 WAF가 이를 차단해야 하지만, 딕셔너리 전용 검사는 일반 블랙리스트보다 약하게 구성되어 있고 정규식 매칭 또한 실제 SQL 문법 전체를 안정적으로 탐지하지 못함. 예를 들어 select, from 같은 키워드도 특정 형태로 배치하면 필터를 통과할 수 있음.

그 결과 공격자는 1=1 and (...) 형태의 조건식을 삽입해 응답 참/거짓을 관찰하는 블라인드 SQL 인젝션을 수행할 수 있고, 이를 통해 현재 데이터베이스의 테이블 개수, 테이블명, 컬럼 존재 여부, 특정 필드의 길이와 내용까지 순차적으로 추출할 수 있음.

또한 일부 시스템 테이블이 차단되더라도 mysql.innodb_index_stats 같은 대체 가능한 메타데이터 경로를 사용하면 현재 데이터베이스의 테이블 구조를 계속 열거할 수 있음.

이후 패치 사항

권장 수정 방향

4단 형식의 dictCode를 금지하고 외부에서 filterSql을 직접 전달하지 못하도록 해야 함.

• dictCode의 네 번째 세그먼트를 필터 조건으로 해석하는 구조 제거
• tableFilterSql에 where 절이나 조건식이 포함되지 않도록 제한
• SysDictMapper.xml 내 where ${filterSql} 방식의 동적 SQL 결합 제거
• 구조화된 조회 방식으로 변경
  • 필드명은 화이트리스트로 제한
  • 값은 파라미터 바인딩으로만 처리
  • 서버 측에서 안전한 조건식만 조립하도록 수정

블랙리스트는 보조적인 방어 수단으로는 사용할 수 있으나, 문자열 필터링만으로 SQL 인젝션을 막는 것은 근본적인 해결이 될 수 없음. 이 취약점은 결국 외부 입력을 SQL 구문으로 직접 받아들이는 설계 자체가 문제이므로, 근본적으로는 동적 SQL 문자열 결합을 제거하는 방향으로 수정해야 함.