CVE-2026-17566

요약

pgAdmin 4의 Import/Export Data 도구는 사용자가 제공한 SQL 쿼리를 Jinja 템플릿에 삽입하여 psql \copy (...) 명령줄을 구성하고, 렌더링된 줄을 --command를 통해 psql에 전달합니다. 공격자가 (...) 래퍼를 벗어나는 것을 막기 위해, create_import_export_job() (POST /import_export/job/<sid> 라우트, 일반적으로 널리 부여되는 tools_import_export_data 권한으로만 보호됨)은 수작업으로 작성된 괄호 균형 검사기인 _is_query_parens_balanced()로 쿼리를 검증했습니다. 해당 검사기는 작은따옴표 앞의 백슬래시(\')를 항상 따옴표를 이스케이프하는 것으로 처리했습니다. 즉, standard_conforming_strings가 꺼져 있는 것처럼 간주했습니다. PostgreSQL은 9.1(2010)부터 standard_conforming_strings를 기본적으로 on으로 설정했으며, pgAdmin 4가 현재 지원하는 모든 PostgreSQL 버전(13-18)에서도 기본값입니다. 해당 기본값에서 psql 자체의 \copy 토크나이저는 \를 일반 문자로 취급하므로, 그 직후의 작은따옴표는 문자열 리터럴을 닫습니다. 따라서 SELECT 'a\') TO PROGRAM 'echo pwned' x' 와 같은 쿼리는 pgAdmin의 검사기(이 검사기는 )가 여전히 문자열 내부에 있다고 판단)에 의해 "균형이 맞는" 것으로 승인되었지만, 실제 렌더링된 명령줄을 통해 실행되는 psql은 해당 지점에서 문자열을 닫고 뒤따르는 )를 래핑된 \copy (...) 하위 쿼리의 끝으로 처리하여, 공격자가 선택한 TO PROGRAM '<command>' 절이 노출되고 psql이 이를 popen()을 통해 실행합니다. 이는 같은 줄의 이후 지점에서 발생하는 구문 오류와는 무관합니다. 이는 CVE-2025-12762/CVE-2025-13780(PLAIN 형식 덤프 복원 중 psql 메타 명령/COPY 주입을 통한 RCE)과 동일한 계열의 버그로, 다른 모듈(Restore가 아닌 Import/Export Data)에서 독립적으로 작성된 방어 메커니즘을 통해 도달하며, 해당 방어 메커니즘에는 자체적으로 다른 논리 버그(BOM에 의해 무력화되는 정규식 앵커가 아닌 반전된 백슬래시 이스케이프 의미론)가 있었습니다. 수정 사항은 두 가지 가능한 psql 해석 중 하나를 선택하는 대신, 쿼리의 작은따옴표 문자열 내부에 있는 모든 백슬래시를 완전히 거부합니다. 이는 의도적으로 보수적인 접근입니다. \의 올바른 해석은 대상 서버의 standard_conforming_strings 설정에 따라 달라지며, 검사기는 검증 시점에 이를 확실히 알 수 없으므로, 추측하는 것보다 쿼리를 거부하는 것이 더 안전합니다. 이 문제는 pgAdmin 4에 영향을 미칩니다: 9.18 이전에 _is_query_parens_balanced()가 도입된 시점부터.

• CVE-2026-17566PoC

  pgAdmin 4 가져오기/내보내기 RCE (CVE-2026-17566) PoC - 백슬래시 이스케이프 불일치를 통한 TO PROGRAM 주입