2026. 7. 18 (토) · 약 9분
사이트는 평소처럼 열리는데, 관리 화면의 업데이트 알림 하나가 늦은 밤에는 꽤 다른 의미가 된다. 7월 17일 공개된 WordPress 7.0.2는 보안 수정이 포함된 릴리스이고, Cloudflare는 공개 전 두 건의 고위험 취약점에 대응하는 WAF 규칙을 배포했다고 밝혔다. 여기서 흔한 오해는 ‘WAF가 있으니 업데이트를 미뤄도 된다’는 것이다. 앞단에서 공격 요청을 줄이는 일과 서버에 남은 취약한 코드를 바꾸는 일은 같은 작업이 아니다.
오늘의 핵심뉴스
심층 분석 · Cloudflare Blog / WordPress.org · 2026. 7. 18
Cloudflare, WordPress 고위험 취약점 두 건에 WAF 규칙 배포…WordPress 7.0.2 보안 릴리스
Cloudflare는 WordPress 보안팀과 협력해 두 건의 고위험 취약점에 대한 WAF 규칙을 배포했으며, WordPress 7.0.2는 7월 17일 공개된 보안 수정 릴리스다. WAF 보호 여부와 관계없이 영향받는 설치본은 패치 릴리스로 업데이트해야 한다.
WAF가 막아도 업데이트 알림은 사라지지 않는다
Cloudflare는 WordPress 보안팀이 공개한 두 건의 고위험 취약점에 대응해 WAF 규칙을 배포했다고 밝혔다. 이 규칙은 Cloudflare를 통과하는 HTTP 요청을 원본 서버에 닿기 전에 검사하는 방식이다. 같은 날 WordPress 7.0.2도 공개됐고, WordPress 공식 문서는 이 버전을 보안 수정이 포함된 릴리스로 안내한다. 즉 이번에는 ‘앞단 차단’과 ‘코어 수정’이 거의 동시에 제공됐다.
두 조치를 같은 의미로 보면 판단이 늦어진다. WAF 규칙은 알려진 공격 형태가 사이트에 도달하는 일을 줄일 수 있지만, 사이트 파일 안의 취약한 코드 자체를 바꾸지는 않는다. 원본 서버가 Cloudflare를 거치지 않고 직접 노출돼 있거나, 규칙이 다루지 않는 경로·변형·권한 있는 사용자의 동작이 문제라면 WAF만으로 안전을 보장할 수 없다. 패치는 영향받는 코드를 고친 버전으로 교체하는 조치다.
두 방어 층의 차이를 먼저 분리해 보자
| 확인할 점 | Cloudflare WAF | WordPress 7.0.2 업데이트 |
|---|---|---|
| 주된 위치 | 원본 서버 앞의 요청 검사 | 사이트의 WordPress 코어 파일 |
| 바로 하는 일 | 알려진 악성 요청 패턴을 차단하거나 완화 | 보안 수정이 들어간 코드로 교체 |
| 확인 신호 | WAF 이벤트·Security Analytics의 차단 기록 | 대시보드 버전, 업데이트 결과, 오류 로그 |
| 혼자 해결하지 못하는 부분 | 원본 직접 노출·모든 공격 변형·서버 안의 취약 코드 | 앞단 공격 트래픽 급증·플러그인·테마의 별도 취약점 |
Cloudflare의 지원 문서도 CMS 보안 기능이 정상 관리 작업을 방해할 수 있다고 설명한다. 예를 들어 로그인이나 이미지 업로드가 보안 규칙과 충돌할 수 있으므로, 규칙을 넓게 끄기보다 이벤트 로그에서 어떤 규칙이 어떤 URL을 막았는지 먼저 확인하는 편이 낫다. 차단 기록은 방어가 작동했다는 단서이지, 업데이트를 건너뛰어도 된다는 증명은 아니다.
반대로 업데이트도 모든 위험을 끝내지 않는다. WordPress 코어가 최신이어도 오래된 플러그인·테마, 재사용한 관리자 비밀번호, 외부에 열린 원본 IP는 별도의 공격면이다. 그래서 이번처럼 코어 보안 공지가 나왔을 때는 패치의 적용 범위와 WAF의 적용 범위를 나란히 확인하는 것이 현실적이다.
실제 업데이트는 백업과 확인 신호를 같이 준비한다
첫 단계는 현재 버전을 확인하는 것이다. WordPress 관리자 화면의 대시보드 또는 업데이트 화면에서 코어 버전과 자동 업데이트 상태를 기록한다. 여러 사이트를 운영한다면 목록과 시간을 남겨 두면, 나중에 WAF 이벤트·접속 오류와 같은 시간대를 비교하기 쉽다. 자동 업데이트가 켜져 있어도 적용 실패나 파일 권한 문제는 별도로 확인해야 한다.
업데이트 전 점검 순서
1. 데이터베이스와 wp-content를 포함한 복원 가능한 백업 생성
2. 현재 WordPress·PHP·활성 플러그인·테마 버전 기록
3. 가능하면 스테이징에서 7.0.2 적용 후 로그인·글쓰기·문의 폼 확인
4. 운영 사이트에서 업데이트 실행
5. 첫 15~30분은 오류 로그, 핵심 페이지, Cloudflare WAF 이벤트를 함께 확인
6. 치명적인 충돌이 생기면 원인을 기록한 뒤 검증한 백업으로 롤백여기서 ‘롤백 가능’은 백업 파일이 있다는 뜻보다 한 단계 더 구체적이어야 한다. 어느 백업 시점으로, 누가, 어떤 순서로 데이터베이스와 파일을 되돌릴지 정해 둬야 한다. 보안 패치를 적용한 직후 오류가 보인다고 즉시 오래된 취약 버전으로 되돌리는 판단도 위험할 수 있다. 먼저 플러그인·테마 충돌인지, 캐시나 WAF 규칙의 오탐인지 구분하고 복구 동안 노출을 최소화할 방법을 확인한다.
Cloudflare를 쓰는 사이트에서 함께 볼 로그
Cloudflare를 사용한다면 Security Events 또는 Security Analytics에서 이번 기간의 차단·관리됨·허용 이벤트를 확인한다. 특히 업데이트 직후 관리자 로그인, 글 저장, 미디어 업로드, 결제·문의 같은 핵심 흐름을 직접 실행해 보고 관련 요청이 차단됐는지 살핀다. 정상 요청이 막힌 흔적이 있다면 해당 이벤트의 규칙 ID, URI, 시간, 조치 값을 남긴다. 전체 WAF를 끄거나 광범위한 예외를 먼저 추가하는 것은 공격면을 넓힐 수 있다.
원본 서버의 직접 접근 경로도 점검할 가치가 있다. WAF는 Cloudflare 프록시를 지나는 트래픽에 적용된다. 원본 IP나 별도 호스트명이 공개돼 있고 방화벽이 Cloudflare IP만 허용하지 않는 구성이라면, 공격자는 프록시를 우회하려고 시도할 수 있다. 이 글의 범위에서 구체적 방화벽 설정을 단정할 수는 없지만, 호스팅·네트워크 환경별 공식 문서에 따라 원본 접근 정책을 검토해야 하는 이유다.
지금 바로 확인할 체크리스트
- 운영 중인 모든 사이트의 WordPress 코어 버전이 7.0.2 이상인지 확인했는가?
- 업데이트 전 복원 테스트가 가능한 백업 시점과 담당자를 정했는가?
- 로그인·글쓰기·미디어 업로드·폼 같은 핵심 흐름을 업데이트 뒤 다시 확인했는가?
- Cloudflare WAF 이벤트에서 정상 관리 요청이 차단되지 않았는지 같은 시간대로 확인했는가?
- 활성 플러그인·테마와 원본 서버 직접 노출 여부를 별도 점검 목록에 넣었는가?
보안 업데이트는 ‘문제가 생겼을 때만 하는 작업’이 아니라, 공개된 위험이 실제 공격으로 바뀌기 전에 노출 시간을 줄이는 운영 습관이다. 이번 공지처럼 WAF 보호가 함께 제공될 때도 순서는 바뀌지 않는다. 보호막이 시간을 벌어 주는 동안 패치를 적용하고, 적용 뒤에는 사이트 동작과 차단 로그를 함께 확인하는 것이 가장 짧고 재현 가능한 대응이다.
참고한 자료
이번 업데이트에서 기억할 한 줄은 간단하다. WAF는 시간을 벌고 공격면을 줄이는 보호막이며, 패치는 취약한 코드를 교체하는 해결책이다. 둘 중 하나를 골라 쓰는 일이 아니라 백업, 빠른 업데이트, 로그 확인, 롤백 준비를 한 흐름으로 묶어야 사이트가 실제로 회복력을 갖는다.
'최신 IT·개발 소식' 카테고리의 다른 글
| Windows 로그인에 FIDO2 보안 키를 더한 Google Workspace, 바뀌는 지점과 준비 순서 (0) | 2026.07.20 |
|---|---|
| Hugging Face 보안 공지 뒤 해야 할 일: 토큰 회전과 최소 권한 점검 순서 (1) | 2026.07.19 |
| Cloudflare 캐시가 대륙을 우회하는 이유: Smart Tiered Cache 리전 힌트 설정법 (0) | 2026.07.17 |
| Dependabot 3일 쿨다운: 일반 업데이트와 보안 업데이트 차이, 설정법까지 (0) | 2026.07.16 |
| 낮 3시간의 전기부터 패키지 업데이트까지, 자동화를 기다리게 하는 이유 (0) | 2026.07.16 |
