워드프레스 코어 업데이트 레이스 컨디션: 업데이트가 공격 경로가 되는 순간

워드프레스 7.1.4 버전에서 패치된 이번 '코어 업데이트 레이스 컨디션'은 공격자가 인증 과정 없이도 원격에서 코드를 실행할 수 있는 치명적인 취약점입니다. Xint 연구팀은 해당 취약점이 대중에 공개되기 전 독자적으로 이를 발견했으며, 실제 업데이트 과정에서 발생할 수 있는 익스플로잇 경로와 7.1.4 버전의 패치 내역을 모두 검증했습니다.

이 글에서는 취약점의 근본적인 원인을 짚어보고, 현재 및 향후 업데이트 과정에서 각별히 주의해야 할 상황과 가장 안전하게 업데이트하는 방법에 대해 자세히 알아봅니다.

핵심 요약

• 취약점 원리: 패치 이전 버전의 워드프레스는 코어 업데이트 시 다운로드한 ZIP 파일을 wp-content/upgrade/ 아래의 예측 가능한 디렉터리에 압축 해제했습니다. 공격자는 이 경로에 있는 setup-config.php 파일에 접근해 자신의 데이터베이스(DB) 설정값을 전송하여 새로운 wp-config.php 파일을 생성할 수 있었습니다. 이후 업데이터가 이 악성 설정 파일을 운영 중인 사이트에 그대로 덮어쓰면서, 결과적으로 피해 사이트가 공격자의 데이터베이스에 연결되는 치명적인 문제가 발생했습니다.

• 발견 및 패치: Xint 연구팀은 워드프레스 코어 업데이트 과정에서 인증 없는 원격 코드 실행으로 이어지는 레이스 컨디션 취약점을 독자적으로 발견했습니다. 워드프레스 측은 7.1.4 버전과 함께 배포된 유지보수 브랜치 보안 릴리스를 통해 문제의 근본 원인을 해결했습니다. (참고로 워드프레스 7.1.4 공식 보안 크레딧은 동일한 문제를 별도로 제보한 Picus의 Umut Bayram 연구원에게 부여되었습니다.)

• 안전한 환경: 이미 자동 보안 업데이트를 통해 수정 릴리스(5.1 섹션 목록 참고)를 설치한 사이트는 안전합니다. 이후 전체 ZIP 파일을 사용하는 업그레이드를 진행하더라도 해당 취약점의 영향을 받지 않습니다. 워드프레스 7.0.8 및 5.1 섹션에 명시된 유지보수 브랜치 수정 릴리스에는 7.1.4 버전과 동일한 보안 패치가 적용되어 있습니다.

• 주의 대상 (수동 업데이트): 당장 가장 주의해야 할 대상은 패치되지 않은 구버전 환경에서 수동으로 '지금 업데이트(Update Now)' 버튼을 누르려는 관리자입니다. 미패치 상태의 워드프레스 2.7~7.0.7(3.x~6.x 버전대의 각 미패치 릴리스 포함)에서 7.1.4 버전으로 업데이트를 시도할 경우, 공격자가 취약점을 트리거할 수 있는 파일이 포함된 전체 ZIP 파일을 다운로드하게 되어 공격에 노출됩니다. 클린 상태의 7.1~7.1.3 버전은 현재 7.1.4로 업데이트할 때 해당 파일이 제외된 부분 업데이트(partial) 파일을 받으므로 당장은 안전하지만, 7.1.4 버전 이상의 새로운 업데이트 버전이 배포될 경우 동일한 위험에 노출될 수 있습니다.

🔧 즉시 조치 사항

이미 수정 릴리스를 쓰고 있다면 코어 체크섬을 검증하세요. 다음 경우에는 Update Now를 누르기 전에 5.2 섹션의 업데이트 전 핫픽스를 먼저 적용해야 합니다.

• 패치되지 않은 WordPress 2.7~7.0.7을 업데이트하는 경우

• 7.1~7.1.3을 쓰는 상태에서 7.1.4 이후의 새 업데이트를 적용하는 경우

• 어떤 ZIP이 선택될지 확실하지 않은 경우

1. 업데이트 과정을 분석하게 된 배경

거의 모든 워드프레스 사이트는 보안과 기능 유지를 위해 언젠가는 코어 업데이트를 진행하게 됩니다. 이 업데이트 과정은 웹 서버 계정의 권한을 이용해 외부에서 파일을 다운로드하고, 운영 중인 시스템 코어 전체를 교체하는 중대한 작업입니다.

일반적으로 보안 검토는 새로 릴리스된 '코드 자체'에 초점을 맞춥니다. 하지만 Xint 연구팀은 관점을 바꿔, 새로운 코드가 설치되는 '단 몇 초' 동안 서버에서 어떤 임시 프로세스가 동작하는지를 면밀히 추적했습니다. 그 결과, 지극히 정상적인 공식 ZIP 파일이 압축 해제되는 아주 짧은 순간 동안 외부 요청을 처리할 수 있는 일종의 '두 번째 워드프레스 인스턴스(Second WordPress Instance)'로 돌변하는 취약 구간을 발견해 냈습니다.

2. 정상적인 코어 업데이트의 동작 원리

2.1 업데이트 프로세스 개요

자동 업데이트의 경우 워드프레스가 주기적으로 새로운 릴리스를 확인하고 사이트 설정에 따라 백그라운드에서 진행됩니다. 수동 업데이트는 관리자가 워드프레스 대시보드(알림판)에서 '업데이트' 버튼을 클릭하는 순간 시작됩니다. 시작되는 방식만 다를 뿐, 백단의 설치 프로세스는 동일하게 진행됩니다.

1. 현재 설치된 버전과 파일 상태를 분석하여 적합한 업데이트 ZIP 파일을 선택합니다.

2. 워드프레스 공식 서버에서 해당 ZIP 파일을 다운로드합니다.

3. 현재 서버에 구동 중인 워드프레스 코어가 다운로드한 ZIP 파일을 wp-content/upgrade/ 경로 아래에 압축 해제합니다.

4. 다운로드된 파일을 확인하고, 새로운 wp-admin/includes/update-core.php 파일을 로드하여 후속 작업을 준비합니다.

5. 임시 디렉터리에 풀린 새로운 파일들을 실제 운영 중인 워드프레스 디렉터리로 덮어쓰기 복사하며, 필요한 경우 데이터베이스(DB) 스키마를 업데이트합니다.

6. 작업이 완료되면 임시 디렉터리를 삭제하고 사이트의 유지보수 모드를 해제합니다.

2.2 업데이트 ZIP 파일의 종류 (Partial, No-content, Full)

워드프레스 업데이트에 사용되는 패키지는 구성에 따라 여러 종류로 나뉩니다.

• Partial: 이전 버전과 새 버전 사이에서 변경된 파일만 포함된 경량 패키지입니다.

• No-content: 기본 제공 테마나 플러그인 등 번들 콘텐츠를 제외한 코어 파일 전체 패키지입니다.

• Full: 모든 구성 요소가 포함된 전체 코어 배포본입니다.

• New-bundled: 구버전 환경에서 새롭게 추가된 번들 콘텐츠까지 포함하여 업데이트할 때 사용됩니다.

워드프레스 서버가 업데이트 대상이 될 수 있는 여러 후보 ZIP 파일을 응답하면, 사이트에 설치된 워드프레스 업데이터(Updater) 로직이 다음 기준에 따라 사용할 파일을 최종 선택합니다.

1. 현재 설치된 버전과 일치하는 Partial 파일이 존재하고, 재설치가 아니며, 현재 설치된 코어 파일의 해시값(Checksum)이 공식 파일과 일치할 경우 Partial을 우선 선택합니다.

2. 조건이 맞지 않을 경우, 번들 콘텐츠 업데이트가 필요하다면 New-bundled를, 그렇지 않다면 가급적 No-content를 선택하며, 최후의 수단으로 Full 패키지를 선택합니다.

3. 중요한 점은 Full, No-content, New-bundled 패키지에는 모두 wp-admin/setup-config.php 파일이 포함되어 있다는 것입니다. 반면 Partial 패키지의 경우, 두 릴리스 사이에서 해당 파일 자체의 코드가 변경되었을 때만 포함됩니다.

즉, 어떤 방식의 업데이트 파일이 선택될지는 단순히 '목표로 하는 새 버전'만으로 결정되지 않습니다. 현재 설치된 출발 버전, 조건에 맞는 Partial 파일의 존재 유무, 재설치 여부, 업데이트 직전 수행되는 코어 파일 무결성 검증 결과 등 복합적인 요인이 작용합니다.

따라서 현재 제공되는 특정 Partial 패키지 안에 setup-config.php가 빠져 있다고 해서, 현재 서버에 설치된 구버전 워드프레스의 취약한 업데이트 로직 자체가 수정되었음을 의미하는 것은 아닙니다. 만약 관리자가 패치를 미루고 사이트를 방치한다면, 향후 API가 제안하는 패키지의 종류나 구성은 달라질 수 있지만, 처음 ZIP 파일을 다운로드하고 압축을 푸는 행위 자체는 여전히 취약점을 가진 구버전 업데이터 로직이 수행하게 됩니다.

3. 버그 분석: 정상 업데이트 중 열리는 찰나의 '공격 창(Window of Opportunity)'

3.1 3단계와 5단계 사이의 치명적인 레이스 컨디션(Race Condition)

워드프레스 7.1.3 이하 버전에서는 코어 업데이트 과정 중 다음 세 가지 동작 메커니즘이 한 지점에서 맞물리며 치명적인 결함을 만들어냈습니다.

1. 예측 가능한 임시 디렉터리 이름: 다운로드한 업데이트 ZIP 파일을 압축 해제할 때 생성되는 임시 디렉터리의 이름이, 공개적으로 알려진 ZIP 파일명 규칙을 그대로 따랐습니다. 이는 공격자가 압축 해제될 정확한 URL 경로를 100% 예측할 수 있음을 의미합니다.

2. 웹 접근이 가능한 경로에 생성: 워드프레스는 이 임시 디렉터리를 wp-content/upgrade/ 아래, 즉 일반적인 Apache 웹 서버 환경에서 외부 접근이 허용된 웹 루트(Web Root) 디렉터리 내부에 생성했습니다. 워드프레스는 upgrade/ 하위 경로의 HTTP 접근이나 PHP 실행을 막는 파일을 배포하지도, 생성하지도 않았기 때문에 압축 해제된 임시 PHP 파일을 웹 브라우저나 악성 스크립트로 직접 호출하여 실행할 수 있었습니다.

3. 복사 시점의 무결성 검증 부재: 워드프레스 업데이터는 3단계에서 ZIP 파일을 풀 때 목록을 미리 기록해 두지 않고, 5단계에서 임시 파일들을 실제 운영 경로로 덮어쓰기 직전에 임시 디렉터리의 파일 목록을 다시 읽어 들여 통째로 복사했습니다. 이로 인해 3단계와 5단계 사이의 아주 짧은 시간(레이스 컨디션 구간) 동안 공격자가 외부 요청을 통해 임시 디렉터리 내에 악성 파일을 생성해 두면, 업데이터가 이 악성 파일까지 정상적인 코어 파일로 착각하여 운영 사이트로 덮어써 버리는 문제가 발생했습니다.

모든 안정화(Stable) 버전의 코드를 분석한 결과, 이러한 취약한 업데이트 구조는 코어 업데이트 기능이 최초로 도입된 워드프레스 2.7 버전부터 7.1.3 버전까지 오랜 기간 방치되어 왔습니다. 다행히 2.6.5 이하 버전은 이 자동화된 코어 업데이트 로직 자체가 존재하지 않아 영향받지 않습니다. (2026년 10월 28일에 공개된 유지보수 보안 릴리스들과 워드프레스 7.1.4 버전부터는 업데이트 시 생성되는 모든 임시 디렉터리명에 무작위 문자열을 추가하여 문제를 해결했습니다.)

3.2 setup-config.php를 활용한 RCE 공격 시나리오

wp-admin/setup-config.php 파일은 본래 워드프레스를 최초 설치할 때 관리자 권한 인증 없이 DB 접속 정보 등을 설정하기 위해 존재하는 스크립트입니다. 정상적인 환경에서는 이미 wp-config.php(설정 파일)가 있으므로 설정 단계가 진행되지 않습니다. 하지만 업데이트용 임시 디렉터리에서 이 파일을 실행하면, 그 위치에서는 운영 사이트의 기존 wp-config.php를 찾지 못하므로 공격자는 임시 디렉터리 내부에 마음대로 새로운 wp-config.php 파일을 생성할 수 있게 됩니다.

이를 이용한 실제 익스플로잇 흐름은 다음과 같습니다.

1. 공격 준비 및 반복 요청: 공격자는 공개된 업데이트 패키지의 이름을 바탕으로 임시 디렉터리에 생성될 setup-config.php의 정확한 URL을 미리 계산합니다. 그리고 이 URL을 향해 자신이 제어하는 악성 DB 접속 설정(Host, User, Password 등)을 담은 POST 요청을 반복해서 전송합니다.

2. 공격 성공: 관리자가 업데이트를 시작하여 서버가 ZIP 파일을 wp-content/upgrade/ 하위에 압축 해제하는 찰나의 순간, 공격자가 지속적으로 보내던 요청 중 하나가 마침내 성공합니다. 즉, 피해 서버의 PHP 프로세스가 취약한 setup-config.php를 실행하여 공격자가 지정한 외부 데이터베이스로 연결을 맺고, 임시 디렉터리에 공격자의 설정이 담긴 새로운 wp-config.php를 생성합니다.

3. 악성 설정 파일의 운영망 침투: 패치 이전 버전의 업데이터 로직은 임시 파일들을 실제 서비스 경로로 복사하기 직전에 디렉터리를 새로 읽어 들입니다. 이때 공격자가 2단계에서 몰래 생성해 둔 악성 wp-config.php가 파일 목록에 포함되어, 정상적인 코어 파일들과 함께 덮어쓰기 되며 실제 운영 중인 사이트의 핵심 설정(DB 연결 정보)을 바꿔치기합니다.

4. 사이트 제어권 탈취: 코어 업데이트 복사 작업이 끝나는 순간, 피해 사이트는 기존 DB가 아닌 공격자의 DB를 바라보며 동작하기 시작합니다. 공격자는 이미 자신의 DB에 최고 관리자(Admin) 권한을 가진 계정을 미리 세팅해 두었으므로, 손쉽게 피해 사이트의 워드프레스 관리자 페이지(/wp-admin/)에 로그인합니다.

5. 원격 코드 실행 (RCE): 관리자 권한을 얻은 공격자는 워드프레스의 기본 기능인 플러그인 업로드(또는 테마 편집 기능 등)를 악용하여 악성 웹셸(PHP 스크립트)을 서버에 업로드하고 실행합니다. 결과적으로 공격자는 웹 서버를 구동하는 시스템 계정(예: www-data, apache)의 권한을 온전히 획득하게 됩니다.

Xint 연구팀이 취약점 제보 플랫폼을 통해 제출한 PoC(Proof of Concept)는 WordPress 7.0.4에서 공식 7.1.3 No-content ZIP 패키지로 넘어가는 공식 업데이트를 사용했습니다. 그 결과 수동 업데이트와 자동 업데이트 모두에서 임시로 생성된 악성 wp-config.php가 운영 서버의 정상 설정 파일을 덮어쓰는 데 성공했습니다.

업데이트 프로세스 자체는 성공적으로 마무리되어 시스템은 워드프레스 7.1.3 버전으로 정상 구동되는 것처럼 보였지만, 코어 내부의 DB_HOST 값은 이미 공격자의 데이터베이스 서버를 가리키고 있었습니다. 연구팀은 이 탈취된 DB 연결을 기반으로 관리자 대시보드에 로그인하여 악성 플러그인을 업로드하고 정상적으로 PHP 코드를 실행하여 시스템 제어권을 확보할 수 있었습니다.

이 취약점의 가장 무서운 점은 공격자의 영향력이 단순히 업데이트가 진행되던 '임시 복사본'에만 머물지 않는다는 것입니다. 취약한 로직으로 인해 서비스 중인 운영 사이트의 핵심 설정 파일 자체가 영구적으로 교체되어 버리며, 관리자가 이상을 감지하고 백업을 복구하거나 설정을 원복하기 전까지 웹 사이트는 공격자의 수중에 놓이게 됩니다.

게다가 공격자는 보안 패치가 발표된 직후부터 취약한 버전의 사이트 목록을 추려 즉시 반복 요청을 보내 두고 대기할 수 있습니다. 레이스 컨디션이 발동하는 취약한 시간은 단 몇 초에 불과하지만, 자동화된 스크립트로 요청을 반복해 둔다면 며칠 뒤 관리자가 무심코 '업데이트(Update Now)' 버튼을 누르는 바로 그 찰나의 순간에 공격이 적중하게 됩니다. 이 모든 과정은 타깃 사이트에 등록된 기존 관리자 계정 정보, DB 자격 증명, SSH 접속 권한, 워드프레스 침해, 또는 중간자 공격(MITM) 환경 등 그 어떤 사전 요구 조건 없이 오직 외부에서의 HTTP 요청만으로 가능합니다.

3.3 버전별 7.1.4 업데이트 및 향후 업데이트 시나리오에 따른 취약점 노출 위험도 분석

2026년 10월 29일 기준, 공식 제공되는 en_US 배포판과 업데이트 API 응답 내역을 바탕으로 분석한 노출 범위는 다음과 같습니다.

• 위험군 1: 미패치 구버전 (2.7 ~ 7.0.7 및 각 하위 브랜치)에서 7.1.4로 수동 업데이트 시 가장 즉각적이고 높은 위험에 노출된 그룹입니다. 3.x 버전부터 6.x 버전대까지 보안 패치가 적용되지 않은 모든 릴리스가 포함됩니다. 이 환경에서는 구버전에서 최신 버전(7.1.4)으로 단번에 건너뛰기 위한 적합한 Partial(부분 업데이트) 패키지가 존재하지 않으므로, 워드프레스 업데이터는 출발 버전에 따라 Full, New-bundled, 또는 No-content 패키지 중 하나를 강제로 선택하여 전체 코어 덮어쓰기를 시도합니다. 이 세 가지 전체 패키지 유형에는 공통적으로 취약점의 트리거가 되는 setup-config.php 파일이 포함되어 있습니다. 7.1.4 ZIP에 든 새 update-core.php가 임시 wp-config.php의 복사를 차단하긴 하지만, 첫 번째 ZIP 압축 해제 작업을 수행하는 주체는 여전히 서버에 설치된 구버전 워드프레스의 취약한 class-wp-upgrader.php입니다. 따라서 공격자는 여전히 레이스 컨디션을 유발하여 임시 디렉터리 내에서 RCE(원격 코드 실행)를 달성하고, 이 임시 환경을 발판 삼아 웹 서버 권한으로 악성 코드를 주입하거나 탈취를 시도할 수 있습니다.

• 위험군 2: 7.1 ~ 7.1.3 버전에서 7.1.4로 일반 업데이트 시 만약 현재 설치된 코어 파일들이 변조되지 않고 공식 배포본과 100% 동일한 상태(Checksum 일치)라면, 서버의 업데이터가 경량화된 Partial 패키지를 선택합니다. 현재 제공 중인 4종류의 7.1.x 버전용 Partial 패키지에는 모두 setup-config.php 파일이 제외되어 있습니다. 따라서 이 정상적인 Partial 업데이트 경로(기본 경로)를 밟는다면 당장의 공격은 발생하지 않습니다. 하지만 서버 내부에 구동 중인 코어 파일 추출 로직(업데이터 자체)은 여전히 패치되지 않은 취약한 상태라는 점을 명심해야 합니다.

• 안전군: 유지보수 브랜치 내 보안 릴리스(수정 릴리스)를 적용한 경우 구버전 유지보수 브랜치 환경에서 제공되는 최신 보안 수정 릴리스용 Partial 패키지에는 setup-config.php가 포함되어 있지 않습니다. 이러한 보안 릴리스 업데이트가 한 번이라도 성공적으로 완료된 사이트는, 향후 업데이트 시 압축 해제 단계부터 완전히 무작위화된 임시 디렉터리 이름을 사용하므로 이 취약점 공격으로부터 영구적으로 안전해집니다.

결론적으로, 향후 이어질 추가적인 업데이트 과정에서 사이트의 운명을 가르는 결정적 기준은 '이번 업데이트가 Partial ZIP을 쓰느냐, Full ZIP을 쓰느냐'하는 단순한 파일 구성의 차이가 아닙니다. 핵심은 '해당 ZIP 파일을 서버 단에서 최초로 다운로드하고 압축을 풀어주는 현재 구동 중인 업데이터 모듈 자체의 코드가 패치된 버전인가, 아닌가'입니다.

예를 들어, 워드프레스 7.0.8 버전은 단순히 7.1.4보다 숫자가 낮은 구버전이 아니라, 7.1.4에 적용된 핵심 보안 패치를 7.0.x 브랜치 사용자들을 위해 동일하게 백포트(Backport)하여 적용한 안전한 '유지보수 릴리스'입니다. 따라서 이미 7.0.8 버전이 설치된 사이트는, 나중에 워드프레스 7.2와 같은 완전히 새로운 메이저 릴리스로 판올림을 하면서 전체 ZIP 파일(Full 패키지)을 다운로드해 압축을 풀더라도 취약점이 발동하지 않습니다.

반면, 보안 패치가 적용되지 않은 7.0.7 이하 버전 환경은, 업데이트 버튼을 누르는 순간 예측 가능한 취약한 디렉터리 경로를 생성하는 예전 레거시 로직을 그대로 실행하게 됩니다. 따라서 API가 내려준 업데이트 패키지 안에 setup-config.php 파일이 단 하나라도 섞여 들어오면 즉시 공격에 노출됩니다.

여기서 언급된 '워드프레스 2.7 ~ 7.0.7' 범위는 현재 배포된 7.1.4 업데이트 API의 응답 패키지를 기준으로 당장 확인 가능한 '미패치 고위험군'을 분류한 것일 뿐, 취약점을 내포한 소스코드 자체의 범위는 7.1.3 버전까지 모두 해당합니다. 즉, 워드프레스 7.1 ~ 7.1.3 버전 사용자 역시, 7.1.4 버전 패치가 시스템에 완전히 설치되기 전까지는 업데이트 과정에서 예측 가능한 임시 경로를 생성하는 취약한 상태를 유지합니다. 당장은 7.1.x 용 Partial 패키지에 트리거 파일(setup-config.php)이 빠져 있어서 안전한 것처럼 보이지만, 만약 7.1.4 설치를 건너뛰고 추후 발표될 새로운 마이너 버전이나 메이저 버전으로 다이렉트 업데이트를 시도할 경우, API 응답 조건에 따라 해당 트리거 파일이 포함된 전체 패키지(Full, No-content 등)가 다운로드될 수 있으며, 이 경우 언제든 동일한 공격에 다시 노출될 위험이 존재합니다.

어떤 종류의 패키지 파일이 선택되건, 예측 가능한 이름의 '임시 워드프레스 인스턴스'가 웹 루트에 노출되는 구조 자체가 문제의 핵심입니다. 차기 릴리스 버전의 코어 파일 내부에 '임시 설정 파일을 운영망으로 복사하지 못하도록 차단(7.1.4 버전의 패치 방식)'하는 방어 로직이 포함되어 있더라도, 공격자는 여전히 예측 가능한 임시 디렉터리에 직접 접근하여 PHP 스크립트를 실행하고 시스템을 장악하기 위한 추가적인 익스플로잇 체인을 구성할 수 있습니다.

요약하자면, 현재 7.1 ~ 7.1.3 버전에서 진행되는 Partial 업데이트가 당장 공격당하지 않는 이유는 단순히 '운 좋게 압축 파일 안에 문제의 파일이 들어있지 않아서'일 뿐, 근본적인 시스템 코어의 취약점이 해결되었기 때문이 아닙니다. 따라서 단순히 대시보드의 '자동 업데이트 활성화' 설정만 믿고 안심해서는 안 됩니다. 과거 시점의 백업본으로 복원된 사이트이거나, 알 수 없는 이유로 이전 업데이트가 실패하여 꼬여버린 사이트라면 반드시 현재 설치된 코어의 버전과 무결성을 관리자가 직접 점검해야 합니다.

3.4 근본 원인을 타격한 워드프레스 7.1.4의 3중 방어막

워드프레스 7.1.4 릴리스에 적용된 보안 패치는 다음 세 가지 강력한 방어 로직을 복합적으로 적용하여 취약점의 근본 원인을 제거했습니다.

1. 임시 디렉터리명 무작위화 (Randomization): 업데이트 과정에서 압축이 풀리는 모든 임시 디렉터리의 이름 끝에 16자리의 예측 불가능한 난수 문자열을 추가하도록 로직을 변경했습니다.

2. 디렉터리 리스팅 차단 (Directory Indexing Prevention): wp-content/upgrade/ 디렉터리 내부에 빈 index.php 파일을 선제적으로 생성하도록 수정했습니다. 이는 웹 서버 설정 미비로 인해 디렉터리 리스트가 외부에 노출(Directory Listing 취약점)되어 무작위 생성된 디렉터리 이름이 유출되는 2차적인 사고를 원천 차단합니다.

3. 악성 설정 파일 복사 차단 (Blacklisting): 코어 업데이트 로직이 임시 디렉터리의 파일들을 운영 경로로 덮어쓰기 위해 스캔할 때, 임시 디렉터리 내부에 생성된 wp-config.php 파일은 절대 운영 사이트 측으로 복사되지 않도록 예외 처리(블랙리스트)를 추가했습니다.

이러한 다층적인 방어 설계는 취약점의 발생 구조 자체를 직접적으로 해결합니다. 7.1.4 버전이나 하위 버전의 보안 유지보수 릴리스가 정상적으로 설치된 이후부터는 공격자가 압축이 해제될 임시 디렉터리의 URL을 사전에 계산할 수 없습니다. 수정된 업데이터가 압축을 풀기 전부터 이미 예측 불가능한 무작위 경로를 할당하므로, 향후 사이트 관리자가 어떤 형태의 거대한 전체 패키지(Full ZIP)를 사용하여 대규모 업데이트를 진행하더라도 이 레이스 컨디션 공격으로부터는 보호됩니다.

4. 수정 릴리스를 향한 '첫 번째 업데이트'는 여전히 공격 표면이다

보안 패치가 적용된 새로운 릴리스가 발표되었다고 해서, 아직 패치되지 않은 구버전 사이트 관리자가 대시보드에서 무턱대고 '지금 업데이트(Update Now)' 버튼을 누르는 것은 매우 위험합니다.

왜냐하면 '보안 패치가 포함된 ZIP 파일을 다운로드하는 것'과 '그 ZIP 파일을 서버에서 안전하게 압축 해제하는 것'은 완전히 다른 차원의 문제이기 때문입니다.

만약 패치되지 않은 구버전 환경에서 관리자가 7.1.4 버전을 설치하기 위해 업데이트를 시도할 경우, 내부적으로 다음과 같은 과정이 진행됩니다.

1. 현재 서버에 구동 중인 취약한 구버전 class-wp-upgrader.php 파일이 7.1.4 업데이트 ZIP 파일을 다운로드한 뒤, 예측 가능한 임시 디렉터리 이름으로 압축을 해제해 버립니다. 7.1.4 ZIP 패키지 내부에는 디렉터리 이름을 무작위화하는 안전한 코드가 들어있지만, 이 파일들은 아직 시스템에 '적용'되기 전이므로 구버전의 취약한 첫 번째 압축 해제 동작을 막을 수 없습니다.

2. 압축이 풀리는 바로 이 찰나의 순간, 공격자가반복해서 보내던 POST 요청 중 하나가 임시 디렉터리의 setup-config.php에 도달하여 성공합니다. 그 결과, 공격자의 데이터베이스에 연결된 악성 '임시 워드프레스 인스턴스'가 생성됩니다.

3. 이후 워드프레스 업데이터는 임시 파일들을 운영 경로로 덮어쓰기 위해 7.1.4 ZIP 패키지 내부에 있던 새로운 update-core.php 로직을 로드하여 실행합니다. 새롭게 작성된 이 7.1.4 코드는 임시 디렉터리에 생성된 wp-config.php를 운영 환경으로 복사하지 못하도록 차단(블랙리스트)합니다. 덕분에 운영 중인 사이트의 핵심 설정(DB 연결 정보)이 변조되는 최악의 상황(원래의 익스플로잇 기법)은 1차적으로 방어됩니다.

4. 하지만 진짜 문제는 그다음입니다. 비록 운영 설정 파일 덮어쓰기는 막혔지만, 공격자가 2단계에서 만들어 둔 '임시 워드프레스 복사본' 자체는 여전히 웹상에서 실행 중이며 외부 접근이 가능한 상태입니다. 업데이트 마지막의 '정리(Cleanup)' 단계에서 이 임시 디렉터리가 삭제되기 전까지의 짧은 시간 동안, 공격자는 자신의 DB에 미리 준비해 둔 관리자 계정을 이용해 이 임시 복사본에 로그인할 수 있습니다. 그리고 이를 발판 삼아 악성 PHP 스크립트를 실행하여, 종국에는 웹 서버 권한을 획득해 실제 운영 중인 워드프레스 디렉터리 곳곳에 백도어 파일을 심어놓을 수 있습니다.

5. 모든 설치 과정이 완전히 끝나고 취약했던 class-wp-upgrader.php 파일이 새 버전으로 교체된 이후에야, 비로소 다음 업데이트부터 임시 디렉터리 무작위화 로직이 정상 작동하게 됩니다.

Xint 연구팀의 실제 검증 결과에서도 이러한 공격 양상의 차이가 명확히 확인되었습니다.

• 7.0.4에서 7.1.3으로 업데이트 시: 기존의 취약한 update-core.php가 동작하여 악성 wp-config.php를 운영 환경으로 복사해 버렸고, 사이트 전체가 공격자의 데이터베이스에 종속되었습니다.

• 7.0.4에서 7.1.4(패치 버전)로 업데이트 시: 7.1.4의 새로운 update-core.php가 방어 로직을 가동하여 악성 설정 파일의 복사를 차단했고, 운영 DB 설정은 무사히 유지되었습니다. 그러나 공격자는 여전히 임시 워드프레스 인스턴스에 접속하여 PHP를 실행하고, 운영 디렉터리에 악성 파일을 생성하는 데 성공했습니다.

결론적으로, 패치되지 않은 구버전에서 최신 보안 릴리스로 향하는 가장 첫 번째 업데이트 시도는 여전히 공격에 무방비로 노출되어 있습니다. 따라서 안전한 7.1.4(또는 하위 브랜치 보안 릴리스) 버전이 서버에 온전히 설치되기 전까지는, ‘Update Now’ 버튼을 누르기 전에 반드시 5.2 섹션의 '업데이트 전 핫픽스(Pre-update Hotfix)'를 먼저 적용해야 합니다.

5. 대응 방안 및 권고 조치

5.1 현재 설치된 코어 버전 정확히 확인하기

서버 터미널(SSH 등)에 접근 권한이 있다면, 워드프레스 공식 명령줄 도구인 WP-CLI를 활용하여 현재 구동 중인 코어 버전을 가장 정확하게 확인할 수 있습니다.

wp core version --path=/var/www/html

2026년 10월 29일 기준으로 해당 취약점이 근본적으로 해결된 공식 릴리스 버전은 다음과 같습니다. 아래 나열된 25개의 태그 버전 모두에서 ① 임시 디렉터리명 무작위화, ② upgrade/ 디렉터리 리스팅 차단(index.php 생성), ③ 악성 wp-config.php 복사 차단이라는 3중 방어막이 정상 작동함을 검증했습니다.

같은 브랜치에서 이보다 낮은 릴리스는 모두 패치되지 않은 상태입니다. 예를 들어 6.9.10 이하는 미패치 버전이고, 수정은 6.9.11부터 적용됩니다. 표의 릴리스는 모두 이 취약점을 수정했지만, 현재 워드프레스는 7.1.4만 latest로, 나머지 구버전 브랜치 릴리스는 모두 outdated로 표시합니다. 가능하다면 7.1.4로 업그레이드하세요.

위 표는 이미 서버에 설치된 릴리스를 분류하기 위한 것입니다. 표에 있는 릴리스도 설치가 완료된 뒤에야 안전해집니다. 패치되지 않은 릴리스에서 이 버전들로 업데이트하는 과정 자체도 취약합니다. 예전의 미패치 코드가 예측 가능한 디렉터리에 첫 압축 해제를 하기 때문입니다. Update Now를 누르기 전에 5.2 섹션의 업데이트 전 핫픽스를 적용하세요.

버전 확인 결과에 따라 다음 조치를 단계별로 수행하시기 바랍니다.

• 위 표에 명시된 수정 릴리스가 이미 설치된 경우 (안전): 취약한 업데이터 모듈이 이미 안전한 코드로 교체되어 있습니다. WP-CLI를 통해 코어 파일의 무결성만 한 번 더 교차 검증하면 됩니다. wp core verify-checksums --path=/var/www/html 명령을 실행해 서버의 코어 파일 해시값이 공식 배포본과 일치하는지 점검하세요. 변조되거나 누락된 파일이 없다면 최신 보안 상태를 유지하시면 됩니다. 만약 의심스러운 파일 변경이 탐지되었다면 즉시 침해 사고 대응(5.3 섹션) 절차를 밟아야 합니다.

• 워드프레스 2.7 ~ 7.0.7 사이의 미패치 릴리스인 경우 (고위험군): 대시보드에서 7.1.4로 수동 업데이트를 시도할 경우 RCE 취약점의 트리거가 되는 setup-config.php가 포함된 전체 ZIP 파일이 다운로드됩니다. 절대 'Update Now' 버튼을 누르지 마세요. 5.2 섹션에서 제공하는 '업데이트 전 핫픽스' 스크립트를 서버에 적용하여 업데이터를 먼저 패치해야 합니다.

• 워드프레스 7.1 ~ 7.1.3 버전인 경우 (잠재적 위험군): 현재 시점에서 7.1.4 버전용 Partial(부분 업데이트) 패키지 안에는 다행히 setup-config.php가 빠져 있습니다. 하지만 서버 구동을 담당하는 업데이터 코어 자체는 여전히 패치가 누락된 구버전입니다. 만약 이 버전 상태를 그대로 유지하다가 7.1.4를 건너뛰고 향후 7.1.5나 7.2 같은 새로운 업데이트가 발표되어 패키지 구성이 변경될 경우, 다시 심각한 보안 위협에 직면하게 됩니다. 다음 릴리스로 업데이트를 시도하기 전, 예방 차원에서 5.2 섹션의 핫픽스를 적용하세요.

• 워드프레스 2.6.5 이하 버전인 경우 (지원 종료, 시스템 개편 필요): 이 버전은 문제의 원인이 되는 자동화된 내장 코어 업데이터 기능이 존재하지 않아 해당 취약점의 영향은 받지 않습니다. 하지만 이미 수년 전 보안 지원이 완전히 종료(EOL)되어 수많은 다른 치명적인 취약점들에 노출되어 있습니다. 대시보드를 통한 강제 업데이트를 시도하지 마시고, 최신 PHP 및 데이터베이스 환경으로의 전면적인 마이그레이션(이전) 계획을 수립해야 합니다.

• 버전 확인이 불가능한 경우: 절대 시스템이 안전하다고 섣불리 단정 짓지 마세요. 서버 로그나 파일 시스템을 직접 조사하여 버전을 우선 확인한 뒤 대응 절차를 따르시고, 업데이트 버튼을 누르지 마세요.

5.2 (P0 긴급 조치) 코어 업데이트 진행 전 선행 핫픽스 적용 가이드

패치는 PHP 파일 하나입니다. 설치된 릴리스를 읽고 코어 파일 하나만 변경합니다.

• WordPress 2.7~2.7.1: wp-admin/includes/update.php

• WordPress 2.8~7.1.3: wp-admin/includes/class-wp-upgrader.php

예전 코어 파일을 새 릴리스의 파일로 바꿔치기하는 방식이 아닙니다. 설치된 업데이트 코드가 무작위 임시 디렉터리 이름을 쓰고 upgrade/index.php를 만들도록 바꿀 뿐입니다. 이 도구는 원본 파일을 웹 루트 밖에 백업하고, 생성한 PHP의 문법을 검사하고, 동시 변경 여부를 감지한 뒤 파일을 안전하게 교체하고 최종 해시를 검증합니다.

2.7부터 7.1.3까지 모든 공식 태그를 대상으로 패치 지점, setup-config.php, 필요한 무작위 비밀번호 함수를 점검했습니다. 업데이트 코드가 바뀐 대표 지점마다 7.1.4로 실제 업데이트를 끝까지 진행해 최종 공식 체크섬을 검증했고, 이미 수정된 릴리스는 변경되지 않았습니다. 2.7~4.6은 지원 종료(EOL) 릴리스이므로, 패치 적용 가능 여부와는 별개로 현재 PHP·데이터베이스와 호환되는 마이그레이션 계획이 필요합니다.

일반적인 서버라면 Update Now를 누르기 전에 아래 명령 하나만 실행하면 됩니다.

curl -fsSL --pinnedpubkey 'sha256//cPNKVMMSBKRsqcDzoa/6g1kBw43KpwPCZYPU38YC1Ig=' https://files.xint.io/wp-patch | sh

--pinnedpubkey 옵션을 추가한 이유는 2026년 10월에 발생한 eMudhra 중간 인증기관(CA) 키 유출 사고에 대비하기 위해서입니다. CA 번들이 아직 업데이트되지 않은 시스템에서는 curl 명령어가 위조된 files.xint.io 인증서를 정상으로 오인해 받아들일 위험이 있는데, 이 옵션을 통해 이를 원천적으로 차단합니다.

부트스트랩 스크립트는 현재 디렉터리, 그 상위 디렉터리, 그리고 /var/www/html 경로를 순차적으로 탐색하여 워드프레스 설치 위치를 찾습니다. 이후 안전성 검토를 마친 PHP 패처(Patcher)를 다운로드하며, 코드를 실행하기 전에 고정된 SHA-256 해시값을 대조해 무결성을 먼저 확인합니다. 이상이 없다면 원본 업데이터 파일을 /var/backups/wordpress-pre-update 경로에 안전하게 백업한 뒤 패치를 적용하고 최종 결과를 다시 검증합니다.

파일을 수정하는 과정에서 상위 권한이 필요할 경우 스크립트가 자동으로 sudo 권한을 요청합니다. 만약 다운로드한 파일의 해시값이 일치하지 않거나, 지원되지 않는 코어 파일이거나, 워드프레스 설치 경로 자체를 찾지 못할 경우에는 원본 업데이터를 전혀 건드리지 않고 작업을 즉시 중단합니다.

만약 워드프레스를 기본 표준 경로가 아닌 다른 곳에 설치했다면, 스크립트 실행 시 워드프레스 루트 경로와 백업 디렉터리를 직접 지정해 주어야 합니다.

curl -fsSL --pinnedpubkey 'sha256//cPNKVMMSBKRsqcDzoa/6g1kBw43KpwPCZYPU38YC1Ig=' https://files.xint.io/wp-patch | sh -s -- /srv/www/example.com /var/backups/wordpress-pre-update

배포 파일의 SHA-256 다이제스트는 다음과 같습니다.

db5639db40f02a81ae60ac809c3e79bd365c8797305901e6c8fa30694bd6ad8e  wp-patch
5bd6139c1e9eddcdc4c9f3e58d9eb42aa87d038d8057d22c1cbdd487a7ae0a31  wp-patch.payload

같은 값은 wp-patch.sha256에서도 확인할 수 있습니다. 짧은 curl | sh 형태는 부트스트랩을 받아 올 때 쓰는 TLS 공개 키를 고정하고, 부트스트랩은 다시 고정된 SHA-256으로 PHP 페이로드를 검증합니다. 실행 전에 이 글에 공개된 다이제스트로 부트스트랩을 직접 검증하려면, 빈 작업 디렉터리에서 아래 명령을 실행하세요.

curl -fsSLO --pinnedpubkey 'sha256//cPNKVMMSBKRsqcDzoa/6g1kBw43KpwPCZYPU38YC1Ig=' https://files.xint.io/wp-patch
echo 'db5639db40f02a81ae60ac809c3e79bd365c8797305901e6c8fa30694bd6ad8e  wp-patch' | sha256sum -c -
sh wp-patch

명령이 SUCCESS를 출력하면 Apache 또는 PHP-FPM을 리로드하거나 재시작해, OPcache에 예전 업데이터 코드가 남지 않도록 합니다. 그다음 알림판에서 현재 수정 릴리스인 7.1.4로 업데이트하세요. 이 글을 읽는 시점에 더 새로운 수정 릴리스가 나와 있다면, 똑같이 핫픽스를 먼저 적용한 뒤 그 릴리스로 업데이트하면 됩니다.

워드프레스 공식 업데이트가 끝나면 부트스트랩을 한 번 더 실행합니다. officially-fixed가 출력되고 아무것도 변경되지 않아야 정상입니다. 이어서 설치된 코어를 워드프레스 공식 파일과 비교합니다. 실제 설치된 버전이 다르다면 7.1.4를 해당 버전으로 바꿔 실행하세요.

curl -fsSL --pinnedpubkey 'sha256//cPNKVMMSBKRsqcDzoa/6g1kBw43KpwPCZYPU38YC1Ig=' https://files.xint.io/wp-patch | sh && wp core verify-checksums --version=7.1.4 --locale=en_US --path=/var/www/html

업데이트 시간대에 의심스러운 요청이나 파일 변경이 있었다면 바로 5.3 섹션으로 이동하세요.

5.3 침해 여부 확인

시스템 보안이 우려된다면 다음의 침해 지표(IoC, Indicators of Compromise)들을 우선적으로 점검하세요.

• 비정상적인 로그 기록: 보관 중인 전체 웹 서버 로그에서 /wp-content/upgrade/ 하위 경로로 들어온 요청 내역을 확인하세요. 특히 특정 URL에 집중적으로 반복된 POST 요청이 있는지, 그리고 코어 업데이트가 진행되던 시점을 전후하여 404 에러가 아닌 정상 응답(예: HTTP 200 OK)이 기록되었는지 면밀히 살펴야 합니다.

• 인가되지 않은 아웃바운드 연결: 웹 서버 또는 PHP 프로세스(PHP-FPM 등)에서 알 수 없는 외부 MySQL 서버로 연결을 시도한 이력이 있는지 네트워크 로그를 점검합니다.

• 핵심 파일 무단 변조: 업데이트가 진행된 시점과 맞물려 wp-config.php 파일, 최상위 경로의 PHP 파일들, 혹은 wp-content/plugins/ 디렉터리 내에 예기치 않은 파일 변경이나 생성이 있었는지 대조해 봅니다.

• 비인가 접근 요소 생성: 관리자가 인지하지 못한 새로운 관리자 계정 생성, 의심스러운 플러그인 설치, 인증 키(Auth Keys) 및 시스템 세션의 무단 변경 여부를 확인합니다.

위 항목 중 단 하나라도 해당하는 징후가 발견된다면 즉시 해당 서버를 네트워크에서 격리하고 웹, PHP, 데이터베이스, 네트워크 등 모든 서버 로그를 포렌식 증거로 안전하게 보존하세요. 이후 감염되지 않은 신뢰할 수 있는 시점의 백업본으로 시스템을 복원해야 하며, 복원 직후 데이터베이스 비밀번호, 워드프레스 보안 키(Salts), 모든 관리자 세션, 외부 연동 API 시크릿 키 등을 전부 새것으로 교체해야만 합니다.

6. 업데이트 경로도 소프트웨어 공급망의 일부다

이번 취약점 사례를 돌아보면, 워드프레스 공식 서버에서 배포한 ZIP 패키지 자체에는 어떠한 악성코드도 없었으며, 이를 다운로드하는 HTTPS 통신 채널도 정상이었습니다.

핵심적인 문제는 시스템이 '업데이트를 설치하는 도중' 외부에 노출되어 신뢰할 수 없는 상태가 된 작업 디렉터리(임시 트리)의 코드를 그대로 실행했다는 점입니다. 심지어 언제든 외부 공격자에 의해 변조될 수 있는 그 임시 파일들을 아무런 무결성 검증 없이 실제 운영 환경의 배포 입력값으로 다시 덮어쓰기까지 했습니다. 이는 새로운 기능을 담은 코드뿐만 아니라, 그 코드를 시스템에 이식하는 '업데이트 로직' 그 자체도 소프트웨어 공급망 보안의 가장 중요한 보호 대상임을 시사합니다.

7. 제보 및 취약점 공개 타임라인

아래 타임라인의 시각은 모두 협정 세계시(UTC)를 기준으로 하며, 괄호 안은 한국 표준시(KST)입니다.

• 2026년 10월 22일 19:38 UTC (KST 10월 23일 04:38): Xint 연구팀이 예측 가능한 업데이트 디렉터리 생성 방식과 인증 없는 setup-config.php 실행을 결합한 원격 코드 실행 공격 체인을 최초로 확인했습니다.

• 2026년 10월 25일 11:06 UTC (KST 10월 25일 20:06): Xint 연구팀이 취약점 제보 플랫폼을 통해 상세한 기술 보고서와 검증된 PoC(개념 증명) 코드를 공식 제출했습니다.

• 2026년 10월 28일 17:13:02 UTC (KST 10월 29일 02:13:02): 워드프레스 측에서 코어 업데이트 과정의 레이스 컨디션 문제를 수정한 '워드프레스 7.1.4 보안 릴리스'를 발표했습니다.

• 2026년 10월 28일 20:29 UTC (KST 10월 29일 05:29): 제보 플랫폼 측에서 워드프레스 7.1.4 릴리스 이전에 이미 트리아지(Triage, 우선순위 분류)를 마치고 당시 최신 버전에서 취약점이 재현됨을 자체 검증 완료했습니다. 플랫폼은 7.1.4 보안 업데이트가 이미 배포되었다는 사실을 인지하지 못한 상태에서 Xint 연구팀 측에 취약점의 유효성을 공식 확인해 주었습니다.

• 2026년 10월 28일 23:21 UTC (KST 10월 29일 08:21): 제보 플랫폼이 해당 취약점이 워드프레스 7.1.4에서 이미 패치됐다는 사실을 확인하고 제보 건을 재평가했습니다.

• 이후 대응: Xint 연구팀은 새롭게 공개된 7.1.4 버전의 패치 내역이 본 제보와 동일한 근본 원인을 수정했음을 교차 검증했습니다. 나아가, 구버전에서 최신 패치 버전으로 넘어가는 '첫 번째 업데이트 전환 과정'이 여전히 위험하다는 사실을 추가로 밝혀내고, 이를 방어하기 위한 선행 핫픽스를 신속히 개발하여 배포를 준비했습니다.

8. Xint 연구팀은 어떻게 사각지대를 찾아냈을까?

Xint 연구팀이 보안 검토에 접근한 방식은 단순히 "새로 릴리스된 코드가 안전한가?"를 묻는 것에 그치지 않았습니다. 연구팀의 핵심 질문은 "새로운 코드를 설치하는 그 짧은 시간 동안, 시스템은 대체 어떤 임시 상태(프로그램)로 변모하여 동작하는가?"였습니다.

단순히 정적인 패키지(ZIP) 파일의 코드를 비교하는 수준을 넘어, 코어 파일이 외부에서 다운로드되고 임시로 압축이 풀리며 실제 운영 경로로 복사된 후 최종 정리되기까지의 '동적인 업데이트 전체 생명주기'를 집요하게 추적했습니다. 이러한 관점의 전환 덕분에 일반적인 보안 탐지 시스템들이 놓치고 있던 치명적인 사각지대를 밝혀낼 수 있었습니다.

참고자료

• WordPress 7.1.4 security release

• WordPress 7.1 branch fix commit (e7b33f5 )

• WordPress core version-check API

• WordPress core stable-check API

• Official WordPress core SVN stable tags