워드프레스 보안 패치가 여는 최후의 침투 창구: CVE-2026-119977 임시 폴더 취약점 분석
워드프레스 최신 보안 패치 적용 과정에서 구버전 업데이터 코드가 유발하는 임시 설치기 노출 결함과 웹 루트 차단 중심의 실무 방어 수칙을 정리한다.
발행일: 2026.11.09
Wordfence 산정 기준 (CISA KEV 등재)
임시 디렉터리 생성부터 교체 완료 시점
WordPress 5.9 이상에서 디렉터리명 예측 가능
워드프레스 코어의 보안 업데이트를 내려받는 바로 그 순간 서버 침투가 발생하는 기이한 결함이 발견됐다. 피커스 시큐리티(Picus Security)의 우무트 바이람(Umut Bayram) 연구원이 보고한 CVE-2026-119977 취약점은 보안 패치를 적용하는 업데이트 프로세스 자체가 공격자의 실행 창구로 전락하는 구조적 한계를 노린다. 미국 사이버보안 및 인프라 보안국(CISA)은 이 취약점을 이미 야생에서 악용 중인 ‘알려진 악용 취약점 목록(KEV)‘에 즉각 추가했다.
문제의 핵심은 패치를 설치하는 주체가 아직 패치되지 않은 기존 시스템 내부의 구형 업데이터 코드라는 점이다. 보안 패치 자체는 임시 폴더의 이름을 난수화하도록 설계됐지만, 정작 이 패치를 담은 압축 파일을 해제하는 작업은 여전히 구버전 로직으로 실행된다. 이로 인해 완전한 패치가 서버 디스크에 덮어씌워지기 직전 수 초의 공백 동안 공격자가 악의적 코드를 밀어 넣을 수 있는 단 한 번의 기회가 열린다.
구버전 업데이터가 새 패치를 압축 해제할 때 발생하는 권한 탈취 경로
wp-content/upgrade 경로에 새 버전 압축이 풀리며 웹에서 접근 가능한 설치기가 생성된다.
버전 5.9 이상에서는 다운로드 파일명을 기반으로 임시 폴더가 생성되어 공격자가 경로를 특정할 수 있다.
Nginx 또는 Apache 설정에서 해당 폴더의 외부 HTTP 요청을 완전 차단한 뒤 업데이트를 실행한다.
구버전 코드가 새 패치를 푸는 아키텍처 결함의 작동 메커니즘
워드프레스 코어가 전체 업데이트 패키지를 내려받으면 내부적으로 임시 압축 해제 프로세스가 가동된다. 시스템은 wp-content/upgrade 하위 디렉터리에 새 버전의 파일 복사본을 생성한다. 이 복사본에는 워드프레스 초기 구성을 지원하는 웹 설치기 파일들이 고스란히 포함되어 있으며, 기본 설정 상태의 웹 서버는 이 경로에 대한 직접적인 HTTP 요청을 거부하지 않는다.
워드프레스 개발진은 최신 브랜치인 7.1.4 버전과 이전 하위 브랜치(4.7 버전까지 백포트)에 임시 폴더 이름을 완전 무작위 문자열로 치환하는 패치를 배포했다. 그러나 웹 기반 자동 업데이트나 대시보드 업데이트를 누르는 순간, 실제 디스크에 파일 압축을 푸는 엔진은 현재 서버에서 구동 중인 ‘패치 전 구버전 업데이터’다. 워드프레스 5.9 버전 이후 환경에서는 이 구버전 코드가 다운로드된 패키지 파일명을 기반으로 임시 디렉터리 이름을 고정 생성한다.
임시 파일 생성부터 원격 코드 실행(RCE)까지의 단계
구버전 업데이터가 wp-content/upgrade 내 예측 가능한 폴더에 패키지 압축 해제
공격자가 웹 브라우저로 해당 임시 인스톨러에 접근해 외부 원격 DB 연결 정보 입력
임시 폴더 내에 공격자 소유의 wp-config.php가 생성되고 서버 권한 획득
업데이터가 임시 파일들을 운영 루트로 복사하면서 실서버 권한이 완전히 탈취됨
공격자는 이 예측 가능한 디렉터리 경로를 지속적으로 조회하다가, 압축 해제가 완료되는 즉시 임시 워드프레스 설치기 인터페이스를 호출한다. 계정이 없는 외부 공격자라 할지라도 이 설치기를 통해 본인의 외부 데이터베이스를 연결하고 새로운 wp-config.php 파일을 임시 폴더 내에 강제로 써넣을 수 있다.
이후 워드프레스 업데이터가 새 파일들을 실서버 경로로 복사하는 마지막 단계를 수행할 때, 공격자가 변조해 둔 설정 파일이 실운영 파일로 덮어씌워지거나 임시 환경에서 획득한 PHP 실행 권한을 통해 운영 서버 내부 데이터를 자유롭게 읽고 쓸 수 있는 상태가 된다. 실험 환경 기준으로 이 작업이 성립하는 시간적 여유는 수 초에 불과하지만, 이미 자동화된 정찰 스크립트가 전 세계 웹사이트를 대상으로 대량 조회를 시도하고 있다.
부분 업데이트와 전체 패키지 간 위험도 차이
모든 워드프레스 업데이트가 이 공격에 노출되는 것은 아니다. 워드프레스는 업데이트 방식에 따라 두 가지 형태의 배포 패키지를 사용한다. 변경된 파일만 최소한으로 묶은 ‘부분 패키지(Partial Package)‘와 코어 파일 전체를 포함하는 ‘전체 패키지(Complete Package)‘다.
임시 폴더 공격이 성립하려면 압축이 풀린 임시 디렉터리 내에 독립적으로 작동 가능한 설치기 파일이 존재해야 한다. 동일 메이저 브랜치 내에서의 단순 마이너 업데이트(예: 7.1.3에서 7.1.4로 전환)는 통상 변경점만 담긴 부분 패키지가 제공되므로 설치기가 임시 폴더에 풀리지 않아 익스플로잇이 작동하지 않는다. 반면 오래된 브랜치에서 건너뛰는 업그레이드(예: 7.0.7에서 7.1.4로 전환)나 코어 파일 해시값이 공식 체크섬과 일치하지 않아 전체 재설치가 트리거되는 경우에는 반드시 전체 패키지가 다운로드되어 위험에 노출된다.
| 구분 항목 | 부분 패키지 (Partial Update) | 전체 패키지 (Complete Package) | 수동 파일 교체 (Manual CLI) |
|---|---|---|---|
| 적용 시점 | 동일 마이너 브랜치 내 자동/수동 패치 | 메이저 버전 도약, 파일 변조 감지 시 | 인프라 엔지니어 수동 파일 배포 |
| 설치기 파일 포함 여부 | 미포함 (변경된 단일 파일만 전송) | 포함 (전체 워드프레스 코어 포함) | 비웹 경로에서 압축 해제 후 복사 |
| 임시 폴더 노출 위험 | 매우 낮음 (인스톨러 미동작) | 매우 높음 (수 초간 RCE 노출) | 없음 (웹 접근 경로 차단) |
| 디렉터리명 예측 가능성 | 5.9 이상에서 고정 명칭 생성 | 5.9 이상에서 고정 명칭 생성 | 해당 없음 (임시 웹 폴더 미사용) |
| 운영 리스크 수준 | 통상 자동 백그라운드 적용 가능 | 즉각적인 웹 방화벽 사전 개입 필수 | 수동 다운타임 및 무중단 배포 검증 필요 |
보안 기업 워드펜스(Wordfence)는 방화벽 규칙을 배포한 지 9분 만에 공격 징후가 감지됐다고 밝혔다. 일부 공격 IP는 약 14.5시간 동안 특정 사이트 그룹을 주기적으로 조회하며 업데이트가 시작되는 찰나의 순간을 탐색했다. 깃허브 등 공개 저장소에는 이미 디렉터리 구조를 노리는 익스플로잇 코드가 등록되고 있다.
버전 5.9를 기점으로 갈라진 디렉터리 노출 메커니즘
- • 임시 폴더명 뒤에 무작위 문자열이 자동으로 추가됨
- • 별도의 에러 로그 누출이 없는 한 외부 경로 예측 불가
- • 공격자의 무차별 대입(Brute-force) 성공 확률 극히 희박
- • 다운로드 패키지 파일명을 그대로 폴더 이름으로 사용
- • 버전 번호만 알면 임시 디렉터리 경로를 확정적으로 특정
- • 패치 설치 중 구버전 로직이 실행되어 1회성 침투 허용
인프라 엔지니어를 위한 3단계 즉각 방어 절차
워드프레스 내부의 패치 메커니즘 자체에 결함이 있으므로, 관리자 콘솔에서 단순히 ‘지금 업데이트’를 클릭하는 행위는 위험을 동반한다. 심지어 터미널 환경의 wp core update 명령어(WP-CLI) 역시 동일한 코어 업데이터 함수를 호출하여 wp-content/upgrade 경로를 사용하므로 안전하지 않다. 시스템 침투 창구를 완전히 차단하기 위해서는 웹 서버 단에서 물리적 격리를 선행해야 한다.
웹 서버 접근 차단부터 수동 파일 배치까지 3단계 대응
wp-content/upgrade 디렉터리에 대한 외부 HTTP 요청을 403 Forbidden으로 차단
웹 서버가 서빙하지 않는 별도 폴더에서 새 7.1.4 패키지를 내려받아 압축 해제
wp-config.php와 wp-content를 제외한 순수 코어만 복사한 뒤 DB 스키마 갱신
1. 웹 서버 수준의 임시 디렉터리 HTTP 접근 완전 차단
워드프레스 코어 업데이터는 로컬 디스크 상에서 디렉터리를 직접 읽고 쓰기 때문에, 외부 웹 브라우저가 해당 경로에 접근할 필요가 전혀 없다. 웹 서버 설정 파일에서 upgrade 폴더에 대한 외부 요청을 차단해도 정상적인 업데이트 동작에는 아무런 지장이 없다.
Nginx 환경에서는 설정 블록에 아래 지시자를 추가하여 외부 HTTP 접근을 차단한다.
location ^~ /wp-content/upgrade/ {
deny all;
return 403;
}Apache 환경을 운용 중이라면 가상 호스트 설정이나 최상위 접근 제어 지시문에서 해당 디렉터리의 라우팅을 거부하도록 구성한다.
<Directory "/var/www/html/wp-content/upgrade">
Require all denied
</Directory>2. 비웹(Non-Web) 루트 기반 수동 업데이트 체계 적용
대규모 트래픽을 처리하는 엔터프라이즈 환경이거나 다수의 사이트를 호스팅하는 클러스터라면 웹 기반 자동 업데이트 기능을 비활성화하고, 웹 문서 루트(Document Root) 바깥에서 수동으로 패키지를 교체하는 방식이 권장된다.
- 운영 데이터베이스와 파일 시스템의 최신 스냅샷 백업을 생성한다.
- 웹 서버가 서빙하지 않는 임시 경로(예:
/tmp/wp-core-7.1.4)에 최신 정식 릴리스 압축을 해제한다. - 압축을 해제한 디렉터리에서
wp-config-sample.php및wp-content폴더를 제외한 모든 순수 코어 파일만 실제 서비스 루트(/var/www/html/)로 복사한다. - 파일 배치가 완료된 후 관리자 화면 또는 터미널에서
wp core update-db명령을 실행해 데이터베이스 스키마를 최신 상태로 마이그레이션한다.
3. 단종된 레거시 브랜치 폐기 및 침해 흔적 점검
워드프레스 4.6 이하 버전은 보안 패치 지원이 공식적으로 완전히 중단된 상태다. 이 결함은 2008년 발표된 워드프레스 2.7 버전부터 거슬러 올라가는 레거시 코드에 뿌리를 두고 있다. 공식 지원이 끊긴 인프라를 운영 중인 조직은 이번 기회에 지원 대상 브랜치(7.1.x)로 코어를 전면 재구축해야 한다.
패치 이전 시점에 장시간 가동되었던 서버라면 wp-content/upgrade 하위 디렉터리에 비정상적인 .php 파일이 남아 있는지, 그리고 웹 서버 접근 로그 중 해당 경로에 대한 외부 POST 또는 GET 요청 성공 기록(HTTP 200)이 존재하는지 즉각 전수 조사를 실시해야 한다.