Drupal Core 데이터베이스 SQL 인젝션 취약점 (CVE-2026-9082)

1. CVE-2026-9082 이란?

이 취약점은 PostgreSQL 데이터베이스를 사용하는 Drupal 사이트에서 발생하며, 공격자가 인증 없이(Unauthenticated) 원격으로 데이터베이스를 조작할 수 있는 CVSS 9.8점의 매우 심각한 결함입니다.

 

• 취약점 유형 : CWE-89, SQL Injection
• 유형 : 프로세스 종료 시 발생하는 레이스 컨디션(Race Condition) 및 논리적 오류(Logic Flaw)
• 영향 위험: 인증 불필요, 정보 유출, 데이터 변조/삭제, 권한 상승 및 RCE 가능
• 취약 버전: PostgreSQL 사용 시 8.9.0 이상, 각 브랜치의 패치 버전 미만(10.4·10.5·10.6·11.1·11.2·11.3)
• 패치 버전: 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10, 10.4.10(EOL 8.9·9.5는 수동 패치 제공)

---

2. 기술적 분석

왜 '키(Key)'가 문제인가?

일반적인 SQL Injection이 사용자가 입력한 '데이터 값(Value)'을 조작하는 것과 달리, 이번 취약점은 데이터의 배열 키(Array Key)를 공격 지점으로 삼습니다.

Drupal의 PostgreSQL 드라이버는 특정 조건에서 쿼리를 생성할 때, 배열 내의 키 값을 적절한 검증 과정 없이 SQL 구문에 그대로 삽입합니다.

 

1. 패치 전: 위험한 신뢰

패치 전, Condition.php의 로직은 사용자가 입력한 배열의 키를 그대로 가져와 쿼리 조립에 사용했습니다.

// [패치 전]
foreach ($condition['value'] as $key => $value) {
    // 공격자는 여기서 $key 값을 조작하여 SQL 구문을 주입할 수 있었습니다.
}

 

공격자가 악의적으로 키 값을 변경(예: 1 OR 1=1)해서 보내면, Drupal은 이 키를 쿼리의 구성 요소로 인식하여 그대로 데이터베이스에 전달했습니다.

 

2. 패치 후: 강력한 정규화 (Normalization)

보안 패치는 입력된 배열의 '키' 정보를 완전히 무시하도록 로직을 변경했습니다.

// [패치 후: 로직 변경]
foreach (array_values($condition['value']) as $key => $value) {
    // array_values()는 배열의 기존 키를 버리고 0부터 시작하는 정수로 재구성합니다.
}

// [패치 후: 코어 측 정규화]
if (is_array($condition['value'])) {
    $condition['value'] = array_values($condition['value']);
}

 

3. 핵심 포인트: 왜 array_values()인가?

• 키값 제거: array_values() 함수는 연관 배열(Associative Array)의 키를 모두 제거하고 오직 값(Value)만을 가진 인덱스 배열로 변환합니다.
• 공격 경로 차단: 공격자가 배열의 키 위치에 아무리 교묘한 SQL 인젝션 구문을 심어두었더라도, 이 함수를 거치는 순간 해당 키들은 사라집니다. 결과적으로 데이터베이스 쿼리에는 오직 안전하게 정제된 '값'들만 전달되게 됩니다.
• 구조적 방어: 이는 데이터의 필터링을 넘어, 데이터가 처리되는 구조 자체를 정규화하여 취약점을 원천적으로 봉쇄하는 방식입니다.

---

3. 공격 시연

Step 1) PoC 공격코드를 다운로드합니다.

 

Step 2) 공격 소스 코드 파일을 확인합니다.

 

Step 3) docker-compose.yml 파일에 정의된 서비스들을 실행합니다.

 

Step 4) 서비스가 실행되는 것을 알 수 있습니다.

 

Step 5) 페이지 접속되는 것을 알 수 있습니다.

 

Step 6) docker-compose.yml 파일에서 drupal 정보를 확인할 수 있습니다.

 

Step 7) 데이터베이스 정보를 입력합니다.

 

Step 8) 설치가 완료되어 페이지를 확인할 수 있습니다.

 

Step 9) JSON:API 모듈을 설치합니다.

 

Step 9) 게시글을 작성합니다.

 

Step 10) PoC공격을 통해 DBA 계정 정보를 알 수 있습니다.

 

Step 11) PostgreSQL 데이터베이스 버전 정보를 확인할 수 있습니다.

 

Step 12) Database를 확인할 수 있습니다.

 

Step 13) PoC 공격영상입니다.

 

---

4. 대응 방안

1. 보안 업데이트 적용 (권장 사항)

가장 확실하고 근본적인 해결책은 Drupal 코어를 최신 버전으로 업데이트하는 것입니다. 각 브랜치별로 배포된 보안 패치 버전을 확인하여 업데이트를 진행하십시오.

• 주요 패치 버전: 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10, 10.4.10
• 주의 사항: 만약 운영 중인 사이트의 버전이 8.9~9.5(EOL) 범위에 해당한다면, 정식 업데이트 지원이 종료되었으므로 별도로 제공되는 수동 패치를 반드시 적용해야 합니다.

2. 기술적 완화 조치 (코드 수준)

패치 적용이 즉시 어려운 상황이라면, 취약점이 발생하는 로직을 수정하여 공격 경로를 차단해야 합니다.

• 배열 키 정규화: 공격자가 제어 가능한 배열의 키(Key) 값을 쿼리 생성에 직접 사용하지 않도록 수정해야 합니다.
• array_values() 활용: 입력된 배열 구조를 array_values() 함수를 통해 값(Value) 위주로 재구성함으로써, 악의적인 키 값이 쿼리에 삽입되는 것을 방지합니다.
  • 패치 후 적용 로직:

    if (is_array($condition['value'])) {
        $condition['value'] = array_values($condition['value']);
    }

  • 위와 같이 코어를 정규화하면 기존의 공격자가 키 값을 이용해 시도하는 SQL 인젝션을 원천 차단할 수 있습니다.