블로그나 쇼핑몰, 동네 학원 홈페이지를 워드프레스(WordPress)로 운영하고 계신가요? 전 세계 웹사이트의 상당수가 워드프레스로 돌아가는데요, 10월 28일 워드프레스가 7.1.4 보안 업데이트를 내놓으면서 “지금 바로 업데이트하라”고 권고했어요. 그런데 이번에 고친 구멍 가운데 하나가 좀 특이합니다. 바로 업데이트를 설치하는 그 몇 초 동안 열리는 틈이었거든요.
오늘은 이 ‘업데이트 틈새’ 취약점이 무엇인지, 왜 패치가 나오자마자 공격 시도가 쏟아졌는지, 그리고 내 사이트는 무엇을 확인하면 되는지 차근차근 풀어 볼게요.
한눈에 보는 핵심 정리
| 항목 | 내용 |
|---|---|
| 무엇이 나왔나 | 워드프레스 7.1.4 보안 릴리스 (2026년 10월 28일, 미국 기준) |
| 가장 주목받는 구멍 | 코어 업데이트 중 생기는 레이스 컨디션(타이밍 싸움)으로 원격 코드 실행까지 갈 수 있는 문제 |
| 로그인 필요? | 필요 없음 (인증 없는 공격자도 시도 가능) |
| 위험도 | CVSS 8.1(높음). 아직 CVE 번호는 없고 깃허브 보안 권고(GHSA)로 공개 |
| 영향 범위 | 워드프레스 4.7 ~ 7.1.3 |
| 해결 | 7.1.4 또는 쓰는 브랜치의 최신 보안판(예: 7.0 계열은 7.0.8)으로 업데이트 |
| 현재 상황 | 패치 직후부터 공격 시도 급증. 다만 실제 침해 성공 사례는 아직 보고되지 않음 |
먼저, 워드프레스 업데이트는 어떻게 진행될까요?
우리가 ‘업데이트’ 버튼을 누르거나, 밤사이 자동 업데이트가 돌 때 워드프레스는 대략 이런 순서로 움직여요. 이사 갈 때 새 가구를 거실에 잠깐 풀어 놓았다가 방마다 옮기는 것과 비슷합니다.
| 단계 | 하는 일 | 이사에 비유하면 |
|---|---|---|
| ① 내려받기 | 새 버전 압축 파일을 받아요 | 새 가구 배송 |
| ② 임시로 풀기 | wp-content/upgrade/ 폴더 안에 새 워드프레스 전체를 풀어요 |
거실 한가운데 포장 풀기 |
| ③ 옮기기 | 풀어 둔 파일을 실제 자리로 복사해요 | 방마다 가구 배치 |
| ④ 정리 | 임시 폴더를 지워요 | 포장 박스 버리기 |
문제는 ②번이에요. 임시로 풀어 둔 곳이 인터넷에서 주소만 알면 열어 볼 수 있는 폴더였고, 그 안에는 새 워드프레스의 설치 마법사(setup-config.php)까지 그대로 들어 있었어요. 거실 문이 활짝 열린 채로 가구 포장을 풀고 있던 셈이죠.
‘레이스 컨디션’이 뭔가요?
레이스 컨디션(race condition)은 “누가 먼저 도착하느냐”에 따라 결과가 달라지는 상황을 말해요. 이번 경우엔 워드프레스가 임시 폴더를 정리하기 전에 공격자가 먼저 그 설치 마법사를 열면 이기는 게임이었습니다.
보안 업체들의 설명을 종합하면, 7.1.4 이전에는 이런 약점이 겹쳐 있었어요.
| 약점 | 쉽게 말하면 |
|---|---|
| 예측 가능한 폴더 이름 | 임시 폴더 이름이 업데이트 파일 이름에서 짐작 가능했어요 |
| 목록 보기 방지 파일이 사라질 수 있음 | 정리 과정에서 폴더 안 내용을 숨기는 index.php가 지워질 수 있었어요 |
| 설치 마법사가 그대로 노출 | 임시 복사본 속 설치 화면을 바깥에서 실행할 수 있었어요 |
| 설정 파일이 덮어써질 위험 | 공격자가 심은 설정(wp-config.php)이 업데이트 과정에서 진짜 설정 위로 복사될 수 있었다는 분석도 있어요 |
공격자가 자기 데이터베이스를 가리키는 설정으로 설치를 끝내 버리면, 결국 내 사이트 서버에서 공격자가 원하는 코드를 실행하는 단계까지 갈 수 있어요. 그래서 이름이 ‘원격 코드 실행(RCE)’입니다.
몇 초짜리 틈인데, 정말 위험한가요?
솔직히 말하면 쉬운 공격은 아니에요. 보안 업체 워드펜스(Wordfence)는 실험실에서 이 임시 폴더가 보통 몇 초만 존재했다고 했고, 패치스택(Patchstack)은 공격 난도가 높다고 평가했어요. 성공하려면 조건이 꽤 많이 맞아야 하거든요.
| 공격 성공에 필요한 조건 | 설명 |
|---|---|
| 전체 패키지 업데이트 | 설치 마법사 파일까지 들어 있는 ‘통째’ 업데이트가 진행 중이어야 해요 |
| 웹에서 접근 가능 | 임시 폴더를 인터넷에서 열 수 있고 PHP가 실행돼야 해요 |
| 폴더 위치 파악 | 임시 폴더 이름을 맞히거나 알아내야 해요 |
| 시간 안에 완료 | 워드프레스가 정리하기 전에 설치를 끝내야 해요 |
그런데 함정이 있어요. 이 틈은 업데이트할 때마다 다시 열립니다. 대부분 사이트가 쓰는 자동 업데이트도 마찬가지고, 심지어 7.1.4를 설치하는 바로 그 업데이트도 예외가 아니에요. 한 번은 어렵지만 로봇이 수천, 수만 번 두드리면 언젠가 맞을 수도 있다는 계산이죠.
패치 9분 만에 시작된 ‘자동 노크’
실제로 공격자들은 빨랐어요. 워드펜스는 이 취약점을 막는 방화벽 규칙을 배포한 지 9분 만에 첫 공격 요청을 잡았고, 처음 21시간 동안 1만 8,500건이 넘는 설치 마법사 경로 요청을 기록했다고 밝혔어요. 이후 보안 업계 일일 요약에서는 24시간 동안 막은 시도가 약 6만 3천 건으로 늘었다는 집계도 나왔습니다.
눈에 띄는 건 공격 패턴이에요. 일부 출처는 몇 개 사이트를 14시간 반가량 계속 두드리며 업데이트가 시작되기만을 기다리는 모습을 보였다고 해요. 낚싯대를 드리워 놓고 입질을 기다리는 것과 비슷하죠.
| 시점 | 무슨 일이 있었나 |
|---|---|
| 10월 28일 | 워드프레스 7.1.4 공개, 4.7까지 모든 브랜치에 보안 수정 백포트 |
| 같은 날 약 3시간 뒤 | 워드펜스 유료 고객용 방화벽 규칙 배포, 9분 만에 첫 적중 |
| 첫 21시간 | 공격 요청 1만 8,500건 이상 기록 |
| 10월 30~31일 | 하루 약 6만 3천 건 수준 시도 집계, 보안 업체들 “지금 바로 업데이트” 재강조 |
| 11월 1일 현재 | 확인된 침해 성공 보고는 아직 없음, CVE 번호도 아직 없음 |
7.1.4는 무엇을 고쳤나요?
7.1.4에는 모두 22개의 취약점 수정이 들어갔다고 알려졌는데요, 이번 ‘업데이트 틈새’ 문제에 대해서는 세 가지 방향으로 문을 잠갔어요.
| 바뀐 점 | 효과 |
|---|---|
| 임시 폴더 이름 무작위화 | 공격자가 위치를 짐작하기 어려워져요 |
| 목록 보기 방지 장치 추가 | 폴더 안 파일 목록이 바깥에 보이지 않게 해요 |
| 설정 파일 덮어쓰기 차단 | 임시 복사본의 설정이 진짜 설정 자리로 올라오지 못하게 막아요 |
“보안 플러그인 깔려 있으니 괜찮겠지?”는 위험해요
여기서 많이 놓치는 부분이 있어요. 공격자가 여는 건 임시 복사본 속 설치 파일을 직접 부르는 요청이라, 내 사이트의 워드프레스와 플러그인이 아예 실행되지 않아요. 그래서 일반적인 보안 플러그인 방화벽은 이 요청을 못 볼 수 있어요. 워드펜스도 자사 방화벽이 이 요청을 보려면 ‘확장 보호(Extended Protection)’ 설정이 필요하다고 했고, 무료 사용자에게는 규칙이 30일 늦게(11월 27일) 간다고 밝혔어요.
| 방어 수단 | 이번 공격에 효과 | 한마디 |
|---|---|---|
| 7.1.4(또는 브랜치 보안판) 업데이트 | 근본 해결 | 가장 먼저, 반드시 |
| 웹 서버에서 upgrade 폴더 차단 | 효과 큼 | 플러그인이 아니라 서버 설정에서 |
| 보안 플러그인 방화벽 | 제한적 | 설정에 따라 요청을 못 볼 수 있음 |
| 그냥 기다리기 | 효과 없음 | 틈은 업데이트마다 다시 열려요 |
내 워드프레스 10분 점검법
1. 버전부터 확인하기
관리자 화면의 알림판 → 업데이트에 들어가 “최신 버전의 워드프레스를 사용 중입니다”라는 문구가 보이는지 확인하세요. 도구 → 사이트 건강 → 정보 → WordPress에서도 버전을 볼 수 있어요. 자동 업데이트를 켜 뒀더라도 “됐겠지” 하지 말고 눈으로 확인하는 게 핵심이에요. 7.0처럼 옛 브랜치를 쓰고 있다면 7.1.4가 아니라 그 브랜치의 최신 보안판(예: 7.0.8)이 보이면 됩니다. 4.6 이하 버전은 더 이상 보안 업데이트를 받지 못하니 이번 기회에 올리는 걸 권해요.
| 내 사이트 버전 | 해야 할 일 |
|---|---|
| 7.1.4 이상 | 업데이트는 끝. 2번 폴더 차단만 추가로 확인 |
| 7.1.0 ~ 7.1.3 | 지금 바로 7.1.4로 업데이트 |
| 7.0 등 옛 브랜치 | 그 브랜치 최신 보안판으로 업데이트, 가능하면 7.1대로 이전 검토 |
| 4.6 이하 | 보안 지원 종료. 백업 후 최신 버전으로 올리기 |
2. upgrade 폴더를 웹에서 막기
서버 설정을 직접 만질 수 있다면, 웹 브라우저로는 wp-content/upgrade/를 아예 못 열게 막는 게 좋아요. 워드프레스는 이 폴더에 PHP로 직접 쓰기 때문에 막아도 업데이트는 정상 작동해요. 주의할 점은 이 규칙을 upgrade 폴더 안이 아니라 사이트 최상위 설정에 넣어야 한다는 거예요(업데이트 때 폴더 안이 정리되거든요).
아파치(Apache)라면 사이트 최상위 .htaccess의 # BEGIN WordPress 블록 바깥(위쪽)에:
RedirectMatch 403 ^/wp-content/upgrade/엔진엑스(Nginx)라면 server 블록 안에:
location ^~ /wp-content/upgrade/ { deny all; }설정 후 브라우저에서 https://내사이트주소/wp-content/upgrade/를 열어 403 Forbidden이 뜨면 성공이에요. 파일 목록이 보이면 아직 막히지 않은 거예요. 관리형 호스팅을 쓰고 있어 서버 설정을 못 바꾼다면 호스팅 업체에 “wp-content/upgrade 경로 웹 접근 차단”을 요청하세요.
3. 업데이트가 늦었다면 흔적 살펴보기
| 확인할 곳 | 이런 게 보이면 의심 |
|---|---|
| 사용자 → 모든 사용자 | 내가 만들지 않은 관리자 계정 |
| 플러그인 목록 | 설치한 적 없는 플러그인 |
| 웹 서버 접속 기록 | wp-content/upgrade 아래 PHP 파일(특히 setup-config.php) 요청 |
| 사이트 파일 | 내가 올리지 않은 PHP 파일, 바뀐 wp-config.php |
이상한 점이 보이면 혼자 고치기보다 백업을 확보하고 호스팅 업체나 전문가에게 점검을 맡기는 게 안전해요. 업데이트를 마친 뒤 보안 플러그인으로 전체 검사를 한 번 돌려 보는 것도 좋습니다.
이번 일에서 배울 점
보통 우리는 “업데이트하면 안전해진다”고만 생각하죠. 맞는 말이에요. 다만 이번 사례는 업데이트하는 과정 자체도 공격 대상이 될 수 있다는 걸 보여 줬어요. 그리고 패치가 나오면 공격자도 그 패치를 읽고 몇 시간 안에 움직인다는 것도요.
그러니 블로그 운영자가 기억할 건 딱 세 가지예요. 자동 업데이트는 켜 두되 버전은 눈으로 확인하기, 쓰지 않는 경로는 서버에서 닫아 두기, 보안 플러그인만 믿지 않기. 오늘 10분만 투자해서 내 사이트 버전부터 확인해 보세요.