WordPress 7.0.4 보안 업데이트, 7.0.3에서 다시 올려야 하는 이유

WordPress 7.0.3을 설치했는데 다시 업데이트 알림이 떴다면 오류로 넘길 일이 아니다. WordPress는 2026년 8월 12일 새 보안 문제를 고친 7.0.4를 공개했다. 7.0.3을 쓰는 사이트도 다시 업데이트해야 한다.

7.0.4에서 고친 취약점은 조건부 원격 코드 실행이다

CVE-2026-65640은 서버에서 Imagick과 Ghostscript를 사용하고, 파일 업로드 권한이 있는 글쓴이급 이상 사용자가 악성 PostScript 파일을 올릴 수 있을 때 원격 코드 실행으로 이어질 수 있는 취약점이다. 모든 사이트가 조건 없이 즉시 공격받는다는 뜻은 아니지만, WordPress의 공식 권고는 패치 버전 적용이다.

낯선 글쓴이·편집자 계정이나 기억나지 않는 업로드가 함께 보인다면 업데이트만 하고 끝내지 않는다. 계정 생성 시각과 서버 로그를 보존하고 호스팅 업체에 침해 여부 확인을 요청한다.

현재 계열에 맞는 패치 버전을 고른다

반드시 7.0 계열로 건너뛰어야 하는 것은 아니다. 이번 수정은 4.7 계열까지 백포트됐다. 위 표보다 오래된 계열은 WordPress 공식 보안 권고의 패치 목록과 대조한다.

업데이트 전후 확인 순서 5단계

1. 같은 시점의 백업을 확보한다. 데이터베이스와 wp-content를 포함한 파일을 한 세트로 준비하고 복원 방법도 확인한다.
2. 현재 버전을 기록한다. 관리자 화면의 알림판 → 업데이트에서 버전과 설치 가능한 패치를 확인한다.
3. 권한 계정을 살핀다. 사용자 → 모든 사용자에서 기억나지 않는 관리자·편집자·글쓴이 계정과 공유 계정을 찾는다.
4. 공식 경로로 업데이트한다. 관리자 화면이나 WordPress.org 공식 배포본을 사용한다. 관리형 호스팅은 자동 업데이트 정책과 완료 시각을 확인한다.
5. 공개·관리자 화면을 시험한다. 메인 화면, 로그인, 글과 이미지 업로드를 확인하고 캐시를 비운 뒤 버전 번호를 다시 본다.

메일의 긴급 패치 ZIP은 내려받지 않는다

메일이나 검색 광고가 건넨 ‘긴급 패치’ ZIP을 서버에 덮어쓰지 않는다. 플러그인만 업데이트하거나 7.0.3에서 멈춰도 이번 코어 문제가 해결된다고 볼 수 없다.

업데이트 도중 브라우저를 반복해서 새로고침하거나 .maintenance 파일부터 지우는 것도 피한다. Imagick이나 Ghostscript를 무작정 삭제하면 이미지 처리 기능과 다른 서비스가 깨질 수 있다. 우선 패치를 적용하고 서버 구성 변경은 호스팅 업체와 상의한다.

업데이트가 실패했을 때 복구 순서

화면이 ‘점검 중’에서 오래 멈췄다면 업데이트 작업이 끝났는지 호스팅 로그나 제어판에서 먼저 확인한다. 실패가 확정된 뒤에도 점검 화면이 남으면 WordPress 공식 문서에 따라 FTP나 파일 관리자로 설치 루트의 .maintenance 파일을 제거하고 관리자 화면에 다시 접속한다.

사이트가 깨졌다면 파일과 데이터베이스를 서로 다른 시점으로 섞어 복원하지 않는다. 같은 시점의 백업 세트로 되돌린 뒤 수동 업데이트나 호스팅 지원을 이용한다.

FAQ

7.0.3이면 최신 보안 버전 아닌가요?
아니다. CVE-2026-65640을 고친 7.0 계열 패치 버전은 7.0.4다.

WordPress 6.x도 7.0.4로 올려야 하나요?
반드시 7.0으로 건너뛸 필요는 없다. 6.9.7, 6.8.8처럼 각 계열에 패치 버전이 배포됐다.

자동 업데이트 완료 메일을 받았으면 끝인가요?
관리자 화면에서 실제 버전 번호를 확인하고, 공개 화면과 로그인·업로드가 정상인지까지 시험한다.

공식 출처

• WordPress.org: WordPress 7.0.4 Release
• WordPress 공식 GitHub 보안 권고: CVE-2026-65640
• WordPress 문서: 업데이트와 실패 복구
• WordPress 개발자 문서: 파일·데이터베이스 백업

가짜 보안 파일을 구분하는 방법은 AI 개발도구 위장 ZIP 악성코드 대응, PC 쪽 랜섬웨어 보호는 Windows 제어된 폴더 액세스 확인 순서에서 이어볼 수 있다.