WordPress 핵심 취약점 실제 공격에 악용…로그인 없이 사이트 장악 가능

유의사항

본 글은 2026년 7월 21일 기준으로 공개된 WordPress 보안 업데이트와 보안업체들의 분석, 관련 보도를 바탕으로 작성했습니다. 실제 공격 방식과 침해지표는 추가 조사에 따라 달라질 수 있습니다.

WordPress 핵심 소프트웨어에서 발견된 치명적인 취약점이 패치 공개 직후 실제 공격에 악용되기 시작했습니다.

이번 취약점은 특정 플러그인이나 테마에만 발생한 문제가 아닙니다. WordPress의 기본 기능인 REST API 요청 처리 과정과 데이터베이스 쿼리 처리 과정에서 발견된 결함으로, 두 취약점을 함께 악용하면 공격자가 로그인하지 않고도 서버에서 임의의 코드를 실행할 수 있습니다.

이는 취약한 사이트의 관리자 권한을 탈취하는 수준을 넘어, 공격자가 사이트가 설치된 서버를 사실상 장악할 수 있다는 의미입니다.

WordPress 코어에서 발견된 두 가지 취약점

이번 공격에는 서로 다른 두 가지 WordPress 취약점이 사용된 것으로 알려졌습니다.

이 가운데 핵심 취약점은 보안업체 Searchlight Cyber의 연구원 애덤 큐스(Adam Kues)가 발견해 신고했으며, 해당 취약점은 ‘WP2Shell’이라는 이름으로 공개됐습니다.

첫 번째 취약점인 CVE-2026-63030은 WordPress REST API가 요청을 처리하는 과정에서 발생하는 검증 문제입니다.

REST API는 외부 애플리케이션이나 WordPress 관리자 기능이 사이트의 게시물과 사용자 정보 등에 접근할 수 있도록 제공되는 인터페이스입니다. 그러나 취약한 버전에서는 일부 요청이 정상적으로 검증되지 않은 상태에서도 신뢰될 수 있었습니다.

두 번째 취약점인 CVE-2026-60137은 데이터베이스에 전달되는 명령을 조작할 수 있는 SQL 인젝션 취약점입니다.

SQL 인젝션은 공격자가 웹사이트에 전달하는 입력값에 데이터베이스 명령을 삽입해, 원래 허용되지 않은 데이터 조회나 변경을 수행하는 공격입니다.

SQL 인젝션 취약점만 놓고 보면 위험도가 상대적으로 낮을 수 있지만, REST API 취약점과 함께 사용하면 공격자가 로그인하지 않고 서버에서 코드를 실행하는 원격 코드 실행(RCE) 공격으로 이어질 수 있습니다.

로그인하지 않고도 사이트를 장악할 수 있다

일반적으로 WordPress 사이트를 장악하려면 관리자 계정의 비밀번호를 탈취하거나, 취약한 플러그인을 통해 관리자 권한을 획득해야 합니다.

그러나 이번 취약점은 공격자가 정상적인 관리자 계정을 확보하지 않은 상태에서도 악용할 수 있습니다.

두 취약점이 연결되면 공격자는 다음과 같은 행동을 수행할 수 있습니다.

1. 새로운 관리자 계정 생성
2. 악성 플러그인 또는 백도어 설치
3. 사이트 파일과 데이터베이스 변경
4. 방문자를 악성 사이트로 리디렉션
5. 피싱 페이지와 악성코드 배포
6. 서버를 추가 공격을 위한 중간 거점으로 이용

한 번 백도어가 설치되면 WordPress 버전을 업데이트한 뒤에도 공격자가 다시 접속할 수 있습니다.

따라서 취약한 버전을 사용했던 사이트는 단순히 업데이트만 진행하는 것으로 끝내지 않고, 이미 침해됐을 가능성까지 함께 점검해야 합니다.

영향을 받는 WordPress 버전

두 취약점의 영향을 모두 받는 주요 버전은 다음과 같습니다.

• WordPress 6.9.0~6.9.4
• WordPress 7.0.0~7.0.1

WordPress 6.9 버전은 6.9.5 이상, WordPress 7.0 버전은 7.0.2 이상으로 업데이트해야 합니다.

WordPress 6.8 계열은 REST API 취약점에는 영향을 받지 않지만 SQL 인젝션 취약점의 영향을 받을 수 있으므로, 6.8.6 이상으로 업데이트해야 합니다.

정리하면 다음과 같습니다.

1. WordPress 7.0.0~7.0.1: 7.0.2 이상으로 업데이트
2. WordPress 6.9.0~6.9.4: 6.9.5 이상으로 업데이트
3. WordPress 6.8.0~6.8.5: 6.8.6 이상으로 업데이트

WordPress는 취약점의 위험도가 높다고 판단해 가능한 사이트에는 강제 자동 업데이트도 적용했습니다. 보안 패치 공개 이후 실제 공격이 확인되면서, WordPress 프로젝트가 일반적인 업데이트 권고보다 적극적인 조치를 취한 것입니다.

패치 공개 하루 만에 실제 공격 시작

이번 사건에서 특히 주목해야 할 부분은 취약점 패치가 공개된 이후 실제 공격이 시작되기까지 걸린 시간입니다.

보안업체 WatchTowr는 WordPress가 패치를 배포한 다음 날 새벽부터 실제 공격이 진행되고 있었다고 밝혔습니다.

WatchTowr의 허니팟에서는 수만 건의 공격 시도와 100개가 넘는 백도어 관리자 계정 생성이 관찰됐으며, 일부 공격자는 감염된 서버에 원격제어 악성코드를 설치하려 한 것으로 전해졌습니다.

Patchstack과 Hexastrike, WatchTowr 등 복수의 보안업체도 취약점이 실제 환경에서 악용되고 있다고 경고했습니다. 이는 단순히 공격 가능성을 설명하는 개념증명 코드가 공개된 단계가 아니라, 업데이트되지 않은 WordPress 사이트를 대상으로 실제 침입이 시도되고 있다는 의미입니다.

취약점이 공개되면 공격자는 패치 전후의 코드를 비교해 어떤 부분이 수정됐는지 분석합니다.

이 과정을 통해 취약점의 위치와 공격 방식을 역으로 찾아낼 수 있기 때문에, 보안 패치가 공개되는 순간 공격자에게도 취약점에 대한 단서가 제공됩니다.

최근에는 자동화 도구와 AI 기반 코드 분석 기술까지 활용되면서, 공개된 패치를 분석하고 공격 코드를 제작하는 시간이 더욱 짧아지고 있습니다.

실제로 얼마나 많은 사이트가 위험한가

WordPress는 전 세계에서 가장 널리 사용되는 웹사이트 관리 시스템 중 하나입니다.

개인 블로그뿐 아니라 기업 홈페이지, 언론사, 온라인 쇼핑몰, 공공기관 사이트 등 다양한 웹사이트가 WordPress를 기반으로 운영됩니다.

공식 버전 통계를 단순 적용하면 취약 버전을 사용했을 가능성이 있는 사이트가 매우 많을 수 있습니다.

보안 컨설턴트 대니얼 카드(Daniel Card)는 약 3,500개의 WordPress 사이트를 표본 조사한 결과를 바탕으로 전체 사이트 중 15% 미만이 취약한 상태일 것으로 추정했으며, 이를 전체 WordPress 사이트에 적용하면 약 9,000만 개에 이를 수 있다고 분석했습니다.

그러나 이 숫자를 실제 취약 사이트 수로 단정하기는 어렵습니다.

WordPress 버전 통계에는 이미 자동 업데이트나 수동 업데이트를 완료한 사이트도 포함될 수 있습니다. Cloudflare나 웹 방화벽이 공격 요청을 차단한 경우도 있으며, 관리형 호스팅업체가 고객 사이트에 패치를 자동 적용했을 가능성도 있습니다.

따라서 이번 사건에서 중요한 것은 정확한 숫자보다, 공격 가능한 WordPress 사이트의 범위가 매우 넓을 수 있다는 사실입니다.

플러그인 취약점과 다른 이유

WordPress 보안 사고의 상당수는 오래된 플러그인이나 테마에서 발생합니다.

이 경우 취약한 플러그인을 사용하지 않는 사이트는 직접적인 영향을 받지 않습니다.

하지만 이번 취약점은 WordPress의 핵심 코드에서 발견됐습니다.

WordPress 코어는 WordPress 사이트라면 공통으로 사용하는 기본 소프트웨어입니다. 따라서 영향을 받는 버전을 사용하는 사이트는 설치된 플러그인의 종류와 관계없이 취약할 수 있습니다.

특정 플러그인 사용자를 대상으로 한 제한적인 문제가 아니라, WordPress 생태계 전체에 공통으로 적용되는 위험인 것입니다.

WordPress 핵심 취약점이 위험한 이유는 하나의 소프트웨어 결함이 수많은 독립적인 웹사이트에 동시에 영향을 줄 수 있기 때문입니다.

취약한 사이트가 악성코드 배포, 피싱, 검색 결과 조작, 다른 서버 공격에 이용되기 시작하면 개별 사이트의 보안 문제를 넘어 웹 생태계 전체의 시스템적 위험으로 확산될 수 있습니다.

이미 업데이트했어도 확인이 필요하다

관리자 화면에 최신 버전이 표시된다고 해서 사이트가 반드시 안전한 것은 아닙니다.

공격자가 업데이트 전에 이미 관리자 계정이나 백도어를 만들어 놓았다면, WordPress 코어를 업데이트한 뒤에도 사이트 내부에 공격 흔적이 남아 있을 수 있습니다.

WordPress 운영자는 다음 사항을 우선 확인할 필요가 있습니다.

1. WordPress 버전 확인 관리자 화면의 업데이트 메뉴에서 현재 WordPress 버전을 확인하고, 7.0.2·6.9.5·6.8.6 이상의 보안 버전이 적용됐는지 점검해야 합니다.
2. 자동 업데이트 상태 확인 WordPress 코어 보안 업데이트가 비활성화돼 있지 않은지 확인해야 합니다. 관리형 호스팅을 이용한다면 호스팅업체가 이번 패치를 자동 적용했는지도 확인할 필요가 있습니다.
3. 낯선 관리자 계정 확인 사용자 목록에서 직접 생성하지 않은 관리자 계정이나 알 수 없는 이메일 주소가 등록돼 있는지 살펴봐야 합니다.
4. 플러그인과 테마 점검 설치한 기억이 없는 플러그인, 최근 갑자기 활성화된 플러그인, 출처를 알 수 없는 테마가 있는지 확인해야 합니다.
5. 관리자 비밀번호 변경 침해 가능성이 의심된다면 WordPress 관리자와 호스팅 계정, 데이터베이스, FTP 또는 SSH 계정의 비밀번호를 모두 변경하는 것이 안전합니다.
6. 접속 기록과 파일 변경 내역 확인 알 수 없는 관리자 로그인, 비정상적인 REST API 요청, 최근 수정된 PHP 파일, 외부 서버와의 수상한 통신 기록이 있는지 확인해야 합니다.

관련 보도 역시 업데이트 이후에도 낯선 관리자 계정과 처음 보는 플러그인이 있는지 추가로 점검할 것을 권고하고 있습니다.

자동 업데이트가 더 중요해지는 이유

과거에는 웹사이트 운영자가 일정한 주기로 관리자 화면에 접속해 업데이트를 확인하는 방식으로도 대응할 수 있었습니다.

하지만 이번 사건처럼 패치 공개 후 하루 안에 실제 공격이 시작된다면, 일주일이나 한 달 단위의 정기 점검만으로는 대응하기 어렵습니다.

취약점 공개와 실제 공격 사이의 간격이 짧아질수록 다음과 같은 보안 체계의 중요성이 커집니다.

• WordPress 코어 보안 업데이트 자동 적용
• 플러그인과 테마의 자동 업데이트 또는 신속한 수동 검토
• 웹 방화벽을 통한 공격 요청 차단
• 관리자 계정 로그인 알림
• 파일 변경 탐지
• 정기적인 외부 백업
• 호스팅업체의 긴급 보안 패치

특히 개인 운영 사이트는 전담 보안 인력이 없는 경우가 많기 때문에, 관리자가 직접 취약점 정보를 확인한 뒤 대응하는 방식보다 자동 업데이트와 호스팅업체의 관리 기능을 적극적으로 활용하는 편이 현실적입니다.

앞으로 주목해야 할 점

현재까지는 WordPress 취약점이 실제 공격에 악용되고 있다는 사실이 확인된 단계입니다.

앞으로는 다음 내용이 추가로 공개되는지 살펴볼 필요가 있습니다.

1. 침해된 사이트를 이용한 악성코드와 피싱 페이지 배포 여부
2. 검색 결과를 조작하는 SEO 스팸 공격 확산 여부
3. 공격에 사용된 IP 주소와 파일명 등 구체적인 침해지표
4. 특정 국가나 산업을 겨냥한 공격 캠페인 존재 여부
5. 호스팅업체의 취약 버전 차단 또는 강제 업데이트 적용 범위
6. 이미 침해된 사이트를 진단하고 복구하기 위한 보안 도구 공개 여부

공격자가 어떤 악성코드를 설치했고, 감염된 사이트를 어떤 목적으로 사용했는지가 확인되면 이번 사건의 실제 피해 범위도 보다 명확해질 것으로 보입니다.

DANA NOTES 해설

이번 WordPress 취약점의 핵심은 단순히 위험도가 높은 보안 결함이 발견됐다는 사실에만 있지 않습니다.

더 중요한 점은 패치가 공개된 뒤 실제 공격이 시작되기까지 걸린 시간이 하루도 되지 않았다는 것입니다.

소프트웨어 기업이 취약점을 수정해 패치를 배포하더라도, 사용자가 업데이트하지 않으면 기존 버전의 취약점은 그대로 남아 있습니다.

공격자는 패치 내용을 분석해 취약점을 빠르게 재현하고, 인터넷에서 해당 버전을 사용하는 사이트를 자동으로 검색할 수 있습니다.

결국 보안의 중심도 취약점을 발견한 뒤 정기적으로 수정하는 방식에서, 패치가 공개되는 즉시 자동으로 적용하고 침해 흔적을 실시간으로 탐지하는 방식으로 이동하고 있습니다.

WordPress 운영자가 가장 먼저 해야 할 일은 관리자 화면에서 버전을 확인하는 것입니다.

그러나 이번처럼 실제 공격이 이미 시작된 사건에서는 업데이트 여부만 확인해서는 충분하지 않습니다.

낯선 관리자 계정과 플러그인, 파일 변경 기록까지 함께 살펴봐야 하며, 침해가 의심된다면 깨끗한 백업을 이용한 복구와 계정 비밀번호 변경도 검토해야 합니다.

WordPress의 편리함은 다양한 웹사이트가 동일한 플랫폼을 사용할 수 있다는 데서 나옵니다.

하지만 그만큼 WordPress 핵심 코드에 발생한 하나의 취약점이 수많은 사이트에 동시에 영향을 줄 수 있다는 점도 함께 기억해야 합니다.