워드프레스 보안 업데이트: 7.1.4 워드프레스 취약점 패치와 버전 확인

테스트 환경 RHEL 계열AlmaLinux 9.8Nginx + Apache · WordPress 7.1.42026-11-01 확인

2026년 10월 28일 워드프레스 보안 업데이트로 나온 7.1.4는 코어 업데이트 중 새 파일을 푸는 임시 폴더에서 원격 코드 실행으로 이어질 수 있는 경쟁 상태 결함을 고쳤습니다. 7.1.3과 7.1.4 패키지를 비교하고 Nginx + Apache 구성 테스트 사이트에서 임시 폴더 접근을 막아 본 결과, 폴더 안에 둔 차단 파일은 다음 설치 때 사라져 상위 폴더에서 막는 방식으로 정리했습니다.

TOC

3mn read

1️⃣ 워드프레스 취약점 원리와 영향 범위

이 결함은 코어를 전체 패키지로 업데이트하는 동안에만 열립니다. WordPress 보안 공지 GHSA-4w3m-c66w-69mg 기준으로 워드프레스는 새 파일을 웹으로 열리는 upgrade 폴더 안의 예측 가능한 자리에 풀었고, 로그인하지 않은 공격자가 파일이 풀리는 시점과의 경쟁에서 이기면 원격 코드 실행(RCE)에 닿을 수 있습니다.

CVE 기록은 영향 범위를 4.7부터 7.1.3까지로 적었고, 약점 유형은 검사 시점과 사용 시점이 어긋나는 경쟁 상태(CWE-367)입니다.

🧩 코어 업데이트 임시 폴더 흐름

설명 다이어그램

①전체 패키지 다운로드WordPress.org에서 코어 패키지를 받음

②upgrade 폴더에 풀기웹으로 열리는 폴더 · 7.1.3 이하는 자리를 예측 가능CVE-2026-119977

③코어 파일 교체풀린 파일이 폴더에 남아 있는 구간

④임시 폴더 삭제업데이트가 끝나면 풀린 파일 삭제

✅ 수정 버전은 폴더 이름을 무작위로 만들고 index.php를 유지7.1.47.0.86.9.116.8.12… 4.7.39

7.1.3과 7.1.4 공식 패키지를 내려받아 비교한 결과, 7.1.4는 임시 폴더 이름에 무작위 글자를 붙이고 upgrade 폴더의 [index.php]를 지우지 않으며, 파일이 없으면 새로 만듭니다.

같은 워드프레스 취약점을 두고 심각도는 출처마다 크게 다릅니다. WordPress 공지는 Low로 표기했고 판단 기준은 적지 않았습니다. CVE를 발급한 Wordfence는 CVSS 3.1 기준 8.1(High)을 매겼으며, 벡터를 보면 로그인이 필요 없고 영향이 높지만 공격 복잡도도 높습니다. Patchstack은 공격 복잡도를 High로 보고 실제 악용이 쉽지 않다고 판단했습니다.

출처	심각도	CVE 표기	수정 버전, 영향 범위
WordPress 보안 공지 GHSA-4w3m-c66w-69mg(2026-10-29)	Low	No known CVE	7.1.4, 7.0.8, 6.9.11, 6.8.12 … 4.7.39
cve.org 기록(CNA Wordfence · 2026-10-31)	CVSS 3.1 8.1 High · 공격 복잡도 High	CVE-2026-119977	영향 범위 4.7.0 ~ 7.1.3
NVD(2026-11-01 확인)	자체 점수 없음 · 상태 Received	CVE-2026-119977	영향 범위는 Wordfence 기록과 같음
Patchstack 글(2026-10-28)	공격 복잡도 High(AC:H)	표기 없음	7.1.4, 7.0.8, 6.9.11, 6.8.12 … 4.7.39

CVE 표기도 공지마다 다릅니다. GHSA의 CVE 칸은 2026년 11월 1일 확인 기준 [No known CVE]이고, Wordfence가 발급한 CVE-2026-119977은 10월 31일 cve.org에 올라갔습니다. NVD는 이 기록을 받은 상태이며 자체 점수는 아직 없습니다.

수정 버전은 4.7 브랜치까지 나왔습니다. 7.1.4 공지에는 백포트가 진행 중이라고 적혀 있지만, 11월 1일 확인한 WordPress 릴리스 보관소에는 4.7.39까지 모두 10월 28일 날짜로 올라와 있습니다. 공지는 옛 브랜치 수정을 호의로 제공한다고 밝혔으며, 적극 지원 대상은 최신 버전뿐입니다.

7.1.4에는 다른 보안 수정도 함께 들어갔습니다. WordPress 7.1.4 버전 문서 기준으로 보안 수정은 22건이며, 7.0 브랜치는 22건 모두에 해당합니다. Patchstack 표 기준으로 로그인 없이 닿는 항목은 이 결함과 미공개 사용자 정의 변경 노출 둘입니다. 나머지는 계정이 있어야 하며 저장형 XSS가 대부분입니다.

2️⃣ 워드프레스 RCE 공격 시도와 확인된 사실

공격 시도는 이미 보고되었습니다. Wordfence는 10월 29일 블로그에서 방화벽 규칙을 배포한 지 9분 뒤에 첫 일치 요청이 들어왔고, 처음 21시간 동안 임시 폴더의 설치 스크립트 경로로 온 요청이 18,500건을 넘었다고 밝혔습니다. 같은 글은 이 요청이 모두 정확한 취약 경로는 아니었다고 덧붙였습니다.

차단 건수는 숫자 하나로 적기 어렵습니다. Wordfence 취약점 페이지의 지난 24시간 차단 칸은 시각마다 값이 바뀌므로 기사마다 인용한 값이 달랐습니다. 차단 수는 막은 요청을 센 값이며 침해 수와는 별개입니다. 침해 건수는 Wordfence와 WordPress, The Hacker News 어디에도 숫자가 없으며, CISA의 알려진 악용 취약점 목록(KEV) 2026.10.30 버전에도 이 CVE는 없습니다(2026년 11월 1일 확인).

공격이 성공하려면 전체 패키지 업데이트가 도는 짧은 시간과 맞아야 합니다. Patchstack은 이 시간을 몇 초로 설명하면서, 자동 업데이트를 포함해 업데이트할 때마다 다시 열린다고 밝혔습니다.

3️⃣ 워드프레스 7.1.4 버전 확인

자동 업데이트를 켜 둔 사이트도 실제 버전은 직접 확인합니다. [알림판 › 업데이트]를 열면 맨 위 [현재 버전] 줄에 설치된 워드프레스 버전이 나옵니다.

워드프레스 업데이트 화면: 왼쪽 메뉴 알림판 › 업데이트, 현재 버전 7.1.4와 마지막 확인 시각, 다시 확인 링크, 자동 업데이트 상태, 최신 버전 안내, 재설치 버튼, 플러그인 구역(워드프레스 7.1.4)

그림은 7.1.4가 설치된 테스트 사이트의 11월 1일 화면으로, [현재 버전: 7.1.4]와 [최신 버전의 워드프레스입니다.]가 나옵니다. 7.1.3이 나오는 사이트에는 이 자리에 새 버전 안내와 업데이트 버튼이 나오며, 안내가 보이지 않으면 [다시 확인하세요] 링크로 바로 확인합니다.

서버에 접속할 수 있으면 WP-CLI로 확인합니다.

wp core version

7.1.4

WP-CLI가 없는 서버는 워드프레스 폴더의 [wp-includes/version.php]에서 같은 값을 읽습니다.

grep '^$wp_version' wp-includes/version.php

$wp_version = '7.1.4';

옛 브랜치를 유지하는 사이트는 그 브랜치의 수정 버전과 비교합니다. 7.0 브랜치는 7.0.8, 6.9 브랜치는 6.9.11, 6.8 브랜치는 6.8.12가 기준이고, 나머지 브랜치 값은 WordPress 7.1.4 버전 문서에 있습니다.

4️⃣ 워드프레스 보안 업데이트 적용

워드프레스 7.1.4로 올릴 때 관리자 화면에서는 [알림판 › 업데이트]의 업데이트 버튼을 누르고, 코어를 올린 뒤에는 플러그인과 테마 순서대로 나머지를 처리합니다. 서버에서는 WP-CLI로 올립니다.

wp core update

Success: WordPress is up to date.

이미 최신이면 위처럼 끝나고, 새 버전이 있으면 패키지를 내려받아 설치합니다. 자동 업데이트 상태는 [알림판 › 업데이트]의 [현재 버전] 아래 문구로 확인합니다.

워드프레스 업데이트 화면 현재 버전 구역: 왼쪽 메뉴 알림판 › 업데이트, 현재 버전 7.1.4, 자동 업데이트 상태 문구와 유지 관리와 보안 릴리스 전환 링크(워드프레스 7.1.4)

그림은 모든 새 버전을 자동으로 올리는 상태이며, 아래 링크를 누르면 유지 관리와 보안 릴리스만 자동으로 올리는 상태로 바뀝니다. 공식 문서 기준으로 유지 관리와 보안 릴리스의 자동 업데이트는 기본으로 켜져 있습니다.

화면 문구와 별개로 [wp-config.php]의 상수도 확인합니다. [AUTOMATIC_UPDATER_DISABLED]를 true로 두면 모든 자동 업데이트가 꺼지고, [WP_AUTO_UPDATE_CORE]를 false로 두면 코어 자동 업데이트가 꺼집니다. 테스트 사이트에서는 아래 명령에 아무 줄도 나오지 않았습니다.

grep -n -E 'AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE' wp-config.php

7.1.3의 코어 업데이트 코드는 설치된 코드로 패키지를 먼저 풀고, 그다음에 새 파일을 복사합니다. 그래서 7.1.3 이하에서 전체 패키지로 올리는 마지막 한 번은 옛 코드가 패키지를 풀게 되며, 5️⃣의 차단 규칙을 먼저 넣고 올리면 그 구간의 PHP 요청까지 막을 수 있습니다.

5️⃣ wp-content/upgrade 폴더 차단

Patchstack은 [wp-content/upgrade/] 폴더의 웹 접근을 막고 폴더 목록이 보이지 않는지 확인하라고 권합니다. 같은 글은 업데이트가 없는 동안 이 폴더에 [index.php]만 있다고 설명합니다.

막기 전 상태를 보기 위해 글자 한 줄만 넣은 표시용 파일을 upgrade 폴더에 잠깐 두고 웹에서 요청했습니다. 주소와 표시용 파일 이름은 예시입니다.

for p in upgrade/ upgrade/index.php upgrade/check.txt upgrade/check.css; do
  printf '%s ' $p; curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/$p
done

upgrade/ 200
upgrade/index.php 200
upgrade/check.txt 200
upgrade/check.css 200

폴더 주소의 200은 [index.php]가 돌려준 0바이트 빈 페이지로, 파일 목록은 나오지 않았습니다. 표시용 파일은 웹에서 그대로 열렸습니다.

처음 시험한 자리는 upgrade 폴더 안의 [.htaccess]입니다. [Require all denied] 한 줄을 넣자 PHP와 텍스트 파일이 403으로 바뀌었지만, 플러그인 하나를 설치하자 이 파일이 사라지고 다시 200이 나왔습니다. 7.1.4 코드도 패키지를 풀기 전에 upgrade 폴더에서 [index.php]만 남기고 모두 지웁니다.

그래서 규칙은 한 단계 위인 [wp-content/.htaccess]에 둡니다. 파일이 없으면 새로 만들고, 있으면 맨 위에 한 줄을 더합니다.

RedirectMatch 403 ^/wp-content/upgrade(/|$)

이 한 줄은 주소가 /wp-content/upgrade로 시작하는 요청에 403을 응답합니다. 워드프레스를 하위 폴더에 설치한 사이트는 규칙이 주소 앞부분부터 비교하므로 맨 앞에 그 폴더 이름을 더하며, 하위 폴더 설치는 실측하지 않았습니다. 넣은 뒤 같은 반복문으로 다시 확인한 결과입니다.

for p in upgrade/ upgrade/index.php upgrade/check.txt upgrade/check.css; do
  printf '%s ' $p; curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/$p
done

upgrade/ 403
upgrade/index.php 403
upgrade/check.txt 403
upgrade/check.css 200

[.css] 파일만 200인 까닭은 구성에 있습니다. 테스트한 Nginx + Apache 구성은 [.css] 같은 정적 파일을 Nginx가 직접 응답하고 나머지 요청을 Apache로 넘기므로, [.htaccess] 규칙은 Apache까지 온 요청에만 적용됩니다. PHP 요청은 Apache를 거치므로 403으로 막혔고, 폴더 밖의 [wp-content/index.php]와 메인 페이지는 200 그대로였습니다.

규칙을 둔 채 업데이트가 되는지도 시험했습니다. 먼저 플러그인 하나를 같은 버전으로 다시 설치했습니다.

wp plugin install two-factor --version=0.17.0 --force

Success: Installed 1 of 1 plugins.

이어서 코어 7.1.4를 다시 설치했습니다.

wp core update --force --version=7.1.4

Success: WordPress updated successfully.

설치된 코어 파일이 공식 체크섬과 맞는지도 확인했습니다.

wp core verify-checksums

Success: WordPress installation verifies against checksums.

두 번의 설치 뒤에도 규칙은 남아 upgrade 폴더 요청은 403이었고, 메인 페이지는 200이었습니다. 시험은 WP-CLI로 실행했으며, 관리자 화면 업데이트는 실측하지 않았습니다.

Nginx만 쓰는 서버는 [.htaccess]를 읽지 않습니다. 공식 Nginx 문서에는 uploads 폴더의 PHP 요청을 location과 deny all로 막는 예시가 있으며, upgrade 폴더는 서버 설정에서 같은 지시어로 막게 됩니다. 이 구성은 실측하지 않았고, 서버 설정을 고칠 수 없는 호스팅은 업체에 문의합니다.

6️⃣ 워드프레스 접근 기록 확인

패치 전에 코어 업데이트가 돌았던 사이트는 웹 서버 접근 기록에서 upgrade 폴더 요청을 찾아봅니다. Patchstack 기준으로 임시 폴더의 사본은 사이트의 PHP 방화벽을 거치지 않으므로, 워드프레스 안의 기록보다 웹 서버 기록을 봅니다.

grep '/wp-content/upgrade/' /var/log/nginx/example.com_access.log | awk '{print $4, $7, $9}'

[01/Nov/2026:08:25:12 /wp-content/upgrade/check.txt 200
[01/Nov/2026:08:25:12 /wp-content/upgrade/check.css 200
[01/Nov/2026:08:25:23 /wp-content/upgrade/check.txt 403
[01/Nov/2026:08:25:23 /wp-content/upgrade/check.css 200

결과는 테스트 사이트 기록이고, 칸은 요청 시각과 주소, 응답 코드입니다. 200은 웹 서버가 응답한 요청이고 403은 막힌 요청이며, 404는 파일이 없는 요청입니다. Nginx + Apache 구성은 앞단 Nginx 기록을 보며, 위 [check.css]처럼 Nginx가 직접 응답한 요청까지 남습니다.

날짜별로 나뉜 기록은 [zgrep]이 압축 파일까지 함께 읽습니다. 10월 28일 이후 기록이 남아 있는지 먼저 보고, 지워진 기간은 호스팅 업체에 문의합니다.

zgrep -h '/wp-content/upgrade/' /var/log/nginx/example.com_access.log-*

눈여겨볼 줄은 upgrade 경로 아래 [index.php]가 아닌 PHP 파일, 특히 [setup-config.php] 요청에 200이 찍힌 줄입니다. Wordfence가 밝힌 요청이 이 설치 스크립트 경로로 왔기 때문입니다. 이런 줄이 있으면 시각을 코어 업데이트 시각과 맞춰 보고, 침해가 의심되면 공식 문서 [FAQ My site was hacked] 순서를 따릅니다. 이 문서는 증상과 시각을 기록하고 사이트와 내 컴퓨터를 검사한 뒤, 호스팅 업체 확인과 접속 정보 변경, 백업, 감염 파일 제거, 업데이트로 이어지는 순서를 안내합니다.

🔢 FAQ & 추천 콘텐츠

WordPress 버전 문서 기준으로 4.6 이하는 보안 업데이트를 받지 못합니다. 이번 경쟁 상태 결함의 CVE 영향 범위는 4.7부터지만, 수정이 나오지 않는 버전이므로 지원 브랜치로 올리는 계획을 세우게 됩니다.

출처마다 범위가 다릅니다. GHSA와 CVE 기록이 말하는 조건은 전체 패키지를 쓰는 코어 업데이트이고, Patchstack은 설치와 업데이트 모두 이 폴더에 패키지가 풀린다고 설명합니다. 7.1.4의 폴더 이름 수정도 플러그인과 테마가 함께 쓰는 공용 코드 [class-wp-upgrader.php]에 들어갔습니다. 폴더 차단은 upgrade 경로 전체에 적용되므로 플러그인과 테마를 위해 따로 손볼 설정은 없습니다.

출처마다 설명이 다릅니다. Patchstack은 풀린 코어 사본이 자기 파일로 워드프레스를 불러와 사이트의 PHP 방화벽이 실행되지 않는다고 설명하며 웹 서버에서 막으라고 권합니다. Wordfence는 새 방화벽 규칙으로 공격 요청을 잡았다고 밝혔으며, 이 규칙은 유료 사용자에게 바로 배포되었고 무료 사용자는 30일 뒤인 2026년 11월 27일에 받습니다. 그래서 어느 쪽이든 버전 업데이트와 웹 서버 차단을 먼저 챙기게 됩니다.

보안 Node.js 취약점: Node2Shell 패치와 Node.js 버전 확인 Node.js와 libbrotli 버전을 확인하고 패치 버전으로 올리는 과정입니다.

보안 WP 보안: wp-admin 보안 로그인 주소 변경과 로그인 제한, XML-RPC 차단으로 관리자 화면을 지키는 설정입니다.

보안 wp-config.php 보안 취약점: 워드프레스 보안 강화 wp-config.php 파일을 보호하는 설정을 확인합니다.

🪐참조WordPress 7.1.4 15

📡WordPress 7.1.4 (2026-10-28) — Release announcement 📡WordPress Documentation: Version 7.1.4 📡GitHub Security Advisory: GHSA-4w3m-c66w-69mg 📡CVE Record: CVE-2026-119977 (CNA Wordfence) 📡NVD: CVE-2026-119977 Detail 📡WordPress Releases: Release archive 📡CISA: Known Exploited Vulnerabilities Catalog 📡WordPress: Configuring Automatic Background Updates 📡WordPress: Nginx 📡WordPress: FAQ My site was hacked 📡Apache HTTP Server: mod_alias RedirectMatch 🛰️Patchstack: WordPress 7.1.4 Security Release 🛰️Wordfence: WordPress 7.1.4 Security Release (2026-10-29) 🛰️Wordfence Intelligence: WordPress Core 4.7.0 – 7.1.3 Upgrade-Window RCE 🛰️The Hacker News: WordPress RCE Flaw (2026-10)

ℹ️ 제휴 안내
본 사이트의 콘텐츠에는 제휴 링크가 포함되어 있습니다. 방문자가 이 링크를 통해 상품 또는 서비스를 구매하면 본 사이트는 판매처로부터 수수료를 지급받습니다. 이 과정에서 구매자가 지불하는 금액^{(이벤트 할인 시 금액이 내려갑니다↓)}은 오르지 않습니다. 게시된 가격·할인·재고 정보는 작성 시점 기준이며 실제와 다를 수 있으므로, 구매 전 판매처에서 최종 확인하시기 바랍니다. 상품 선정과 평가는 자체 기준에 따라 작성되며, 수수료 지급 여부가 소개 순서나 평가 내용에 영향을 주지 않습니다.