워드프레스 업데이트 순간 뚫린다 — 점검 3단계

경남 창원에서 수제 가구 공방을 하는 D씨(가상의 사례예요)는 워드프레스 관리자 화면에 업데이트 알림이 뜨면 바로 누르는 편이에요. 보안 패치라고 하는데 미룰 이유가 없으니까요.

그런데 10월 28일에 나온 워드프레스 7.1.4는 사정이 달랐어요. 이번 결함은 업데이트를 하는 바로 그 몇 초를 노렸거든요. 워드프레스 보안 업데이트가 오히려 공격 통로가 된 셈이에요.

내 사이트가 걸리는지는 3단계로 점검할 수 있어요. 먼저 무슨 일이 있었는지 볼게요.

업데이트하는 몇 초, 현관문이 열려 있었어요

워드프레스는 업데이트할 때 새 파일을 wp-content/upgrade/ 폴더에 먼저 풀어 놓아요. 이삿짐을 현관 앞에 내려놓고 하나씩 들여놓는 것과 비슷해요. 그런데 웹 서버가 이 폴더를 다른 폴더처럼 그대로 내보내는 설정이면, 인터넷 주소만 알아도 그 안의 파일에 접속할 수 있어요. 7.1.4 이전에는 풀리는 폴더 이름도 업데이트 패키지 이름에서 따와서 짐작하기 쉬웠고요.

이 틈에 붙은 이름이 CVE-2026-119977이에요. CVE는 보안 결함마다 붙는 고유 번호고요. 업데이트 도중 임시 폴더에는 새 워드프레스 사본이 통째로 풀려 있고, 그 안에는 설치 프로그램(wp-admin/setup-config.php)도 들어 있어요. 로그인하지 않은 사람이 이 틈에 설치 프로그램에 접속하면 그 서버에서 코드를 실행할 수 있어요. 영향을 받는 버전은 4.7부터 7.1.3까지입니다.

다만 조건이 있어요. 업데이트가 도는 몇 초 사이에 맞춰 접속해야 하고, upgrade 폴더가 웹에서 열려 있어야 해요. 그래서 Patchstack은 공격 난이도를 높음(AC:H)으로 매기고, 실전에서 쓰기엔 현실적이지 않다고 평가했어요. 그래도 로그인이 필요 없고, 업데이트할 때마다 같은 틈이 다시 열려요.

▲ 업데이트 창을 노린 공격 흐름 · 출처: Patchstack 분석, WordPress.org 7.1.4 공지

속도가 빨랐다는 점도 눈여겨볼 만해요. 보안 업체 워드펜스는 7.1.4가 나온 날 방화벽 규칙을 넣었어요. 그 시각이 20시 30분(UTC)인데, 9분 뒤 첫 공격 요청이 들어왔다고 해요. 21시간 동안 업데이트용 설치 파일 경로를 노린 요청이 1만 8,500건을 넘었고요. 이 수치는 internetsecure.org가 워드펜스 자료를 인용한 거예요. 그 글이 나온 시점에 워드펜스는 확인된 침해 사례를 보고하지 않았어요. 그런데 11월 3일에는 미국 CISA가 이 취약점을 악용 확인 취약점 목록(KEV)에 올렸습니다.

▲ 7.1.4 관련 핵심 수치 · 출처: Patchstack, internetsecure.org(워드펜스 자료 인용)

자동 업데이트를 켜 놨는데도 안심 못 하는 이유

"저는 자동 업데이트 켜 놨는데요?" 이렇게 생각하셨죠. 맞아요, 켜 둔 사이트는 7.1.4를 알아서 받아요. 7.1.4부터는 작업 폴더 이름 뒤에 무작위 16자가 붙고, 작업 폴더의 wp-config.php는 사이트로 복사하지 않는 파일 목록에 들어갔어요.

걸리는 건 두 가지예요. 업데이트 창은 수동이든 자동이든 매번 열려요. 또 자동 업데이트는 쓰기 권한이나 플러그인 문제로 실패할 수 있어요. 실패한 줄 모르고 7.1.3에 머무는 사이트가 생길 수 있는 거예요. 4.6 이하 버전은 아예 패치가 나오지 않았고요.

워드프레스 공식 공지도 간단해요.

"it is recommended that you update your sites immediately" (사이트를 즉시 업데이트할 것을 권장합니다 — WordPress.org 7.1.4 공지)

무료 도구 3개로 막고 확인하기

따로 설치할 프로그램은 거의 없어요. 서버 설정 몇 줄과 명령어 몇 개면 돼요. 내 컴퓨터 사양도 상관없어요. 명령은 사이트가 돌아가는 서버에서 실행하고 몇 초면 끝나요.

업데이트만 해도 핵심 구멍은 막혀요. 그래도 internetsecure.org는 차단 규칙을 "패치한 뒤에도 유지할 가치가 있다"고 권해요. Patchstack은 워드프레스 안에서 도는 PHP 방화벽으로는 이 요청을 못 막는다고 설명해서, 웹 서버에서 막으라고 해요. 호스팅 업체에 맡기면 편하지만 제대로 걸렸는지는 내가 확인해야 하고요. 직접 하면 빠른 대신 설정 실수 부담이 따라와요. WP-CLI는 상태를 보여 주는 도구라서 규칙 차단과 같이 써야 의미가 있어요.

차단 규칙은 서버 종류에 따라 이렇게 써요. 규칙은 업데이트 때마다 지워지지 않는 곳에 두는 게 핵심이에요. 워드프레스는 업데이트 때 wp-content/upgrade/ 안의 내용을 지우기 때문에, 그 폴더 안에 .htaccess를 넣어 두는 방식은 지속적인 방어책이 되지 못해요.

# Apache — 사이트 가상호스트 설정 파일(예: /etc/apache2/sites-available/내사이트.conf)의 <VirtualHost> 안
<Location "/wp-content/upgrade/">
    Require all denied
</Location>

# 적용: 문법 검사 후 다시 읽기
apachectl configtest && systemctl reload apache2

워드프레스를 하위 폴더(예: /blog)에 설치했다면 경로를 /blog/wp-content/upgrade/로 바꿔 주세요. 서버 설정 파일에 접근할 수 없는 공유 호스팅이라면 호스팅 업체나 CDN(방화벽) 설정에 같은 규칙을 요청하세요.

# nginx — 사이트 설정 파일의 server { } 안
location ^~ /wp-content/upgrade/ { return 403; }

# 적용: 문법 검사 후 다시 읽기
nginx -t && systemctl reload nginx

공방 D씨가 한 일

D씨는 먼저 관리자 화면에서 버전을 봤어요. 7.1.3이었어요. 업데이트 알림이 떠 있었는데 자동 업데이트가 실패했던 거예요. 호스팅 업체에 upgrade 폴더 접근 차단을 먼저 요청하고, 규칙이 들어간 걸 확인한 뒤 백업을 받고 7.1.4로 올렸습니다.

다음은 흔적 확인이에요. 워드펜스는 접속 기록에서 wp-content/upgrade/ 아래 PHP 파일을 찾는 요청, 낯선 관리자 계정, 설치한 적 없는 플러그인, 내가 올린 적 없는 PHP 파일을 살펴보라고 안내해요. D씨는 서버 접속 기록에서 이렇게 찾아봤어요(로그 경로는 호스팅마다 달라요).

grep "wp-content/upgrade" /var/log/nginx/access.log | grep "\.php"

점검을 매번 손으로 하기 번거로우면 자동으로 돌려 두세요. 아래 파일을 서버에 만들어 두면 주 1회 버전과 관리자 목록이 기록으로 남아요. 지난주와 관리자 명단이 다르면 바로 눈에 띄고요.

#!/bin/bash
cd /var/www/mysite   # 워드프레스가 설치된 폴더로 바꾸세요
echo "== $(date +%F) =="
wp core version
wp core check-update
wp user list --role=administrator --fields=ID,user_login,user_registered

# crontab -e 에 추가: 매주 월요일 9시 실행
0 9 * * 1 /home/deploy/wp-weekly-check.sh >> /home/deploy/wp-check.log 2>&1

여기까지는 직접 하셔도 충분해요. 낯선 관리자나 PHP 파일이 나왔다면 얘기가 달라져요. 지우기 전에 어떻게 들어왔는지부터 봐야 해서, 이 단계부터는 전문가와 함께 보시길 권해요.

(주)비젼솔루션은 "업데이트하면 안전하다"는 등식을 의심해요. 패치도 결국 코드고, 적용하는 순간은 시스템이 가장 열려 있는 순간이에요. 안전은 버튼 한 번에서 나오지 않고, 누른 뒤에 확인하는 습관에서 나온다고 봐요. 이번 사건은 그 확인이 필요한 이유를 잘 보여 줬어요.

지금 따라 해 보세요

▲ 점검 3단계 순서 · 출처: WordPress.org, Patchstack, internetsecure.org 권고 종합

1. 버전 확인 + 서버 차단 — 관리자 화면의 대시보드에서 워드프레스 버전을 확인해요. SSH가 되면 wp core version을 입력해도 돼요. 7.1.4 미만이거나 업데이트 알림이 남아 있다면, 업데이트를 누르기 전에 위의 Apache 또는 nginx 규칙부터 서버 설정에 넣어요. 업데이트 창은 업데이트할 때마다 열리니까요. 직접 못 하면 호스팅 업체에 "wp-content/upgrade 폴더 웹 접근 차단"을 요청하세요.
2. 백업 후 업데이트 — 규칙이 들어간 걸 확인한 뒤 백업을 받고 업데이트를 눌러요. 7.1.4 이상(또는 내 버전대의 패치판)이 되어야 해요.
3. 403 확인 + 흔적 점검 — 규칙을 넣고 서버를 다시 읽은 뒤, 실제 서비스 중인 도메인에서 curl -I https://내도메인/wp-content/upgrade/를 실행해요. 403이 나오면 막힌 거예요. 200이나 301이 나오면 아직 열려 있거나 다른 가상호스트에 넣은 거예요. 설정 파일에 써 놓았다는 것만으로는 확인이 안 되니, 꼭 실제 호스트에서 실행하세요. 이어서 wp user list --role=administrator로 관리자 명단에 모르는 계정이 있는지 보고, 플러그인 목록도 같이 훑어보세요.

자주 묻는 질문

Q. 워드프레스를 안 쓰는데 해당하나요?

이 결함은 워드프레스 코어의 업데이트 과정에서 생긴 거라, 다른 방식으로 만든 홈페이지에는 해당하지 않아요.

Q. 7.1.4로 올렸으면 끝인가요?

핵심 구멍은 막혀요. 다만 패치 전에 이미 공격 시도가 있었으니 흔적 확인은 한 번 해 두세요.

Q. 4.6 이하 버전이에요.

이 버전들은 패치가 나오지 않았어요. 최신 버전으로 올리는 계획부터 세워야 해요.

혼자 점검하기 어렵거나 우리 사이트가 외부에서 어떻게 보이는지 확인하고 싶다면, 실전 모의해킹 진단이 있어요. 29만 원 단일가이고 1~2일 안에 한글 분석 보고서로 결과를 드려요.

워드프레스를 쓰는 지인이 있다면 이 글을 공유해 주세요. 댓글로 질문하시면 답변드릴게요.

함께 보면 좋은 글

• UpdraftPlus 보안 사고, 워드프레스 관리자가 확인해야 할 것
• PHP 치명적 RCE 'PHP2Shell' 터졌다 — 워드프레스 포함, 지금 할 일 (CVE-2026-109618·109619)
• AI 도구가 파일 몰래 업로드 — 5분 안전 점검법