워드프레스를 무너뜨린 건 코어가 아니라 플러그인 다섯 개였다

이미지 출처: The Hacker News

워드프레스 코어는 생각보다 단단하다. 보안팀도 있고, 자동 업데이트도 기본으로 돌고, 심각한 결함이 나오면 며칠 안에 패치가 배포된다. 그런데도 매달 "사이트가 통째로 넘어갔다"는 사고가 끊이지 않는 이유는 단순하다. 실제로 뚫리는 건 코어가 아니라 그 위에 얹은 플러그인과 테마이기 때문. 이번에도 플러그인·테마 다섯 곳에서 사이트 탈취나 원격 코드 실행으로 이어지는 결함이 한꺼번에 공개됐고, 하나같이 "인증 없이" 또는 "구독자 권한만으로" 시작할 수 있는 유형이었음.

핵심 요약

• 워드프레스 사고의 대부분은 코어가 아니라 서드파티 플러그인·테마의 권한 검사 누락에서 출발함
• 파일 업로드 검증 부재, 임의 옵션 변경, 파일 포함(LFI) 세 갈래가 결국 웹셸과 관리자 계정 생성으로 수렴함
• 방어는 패치가 1순위, 그다음이 uploads 디렉터리 PHP 실행 차단과 옵션·계정 변경 탐지

다섯 개의 결함이 공유하는 한 가지 패턴

제품 이름과 CVE 번호는 다르지만, 이런 류의 취약점은 놀랄 만큼 비슷한 자리에서 반복됨. 신뢰 경계를 잘못 그은 것.

• 권한 검사 누락 — 개발자가 nonce만 확인하고 끝내는 경우가 정말 많음. nonce는 CSRF 방어 수단이지 권한 검사가 아님. current_user_can()이 빠진 AJAX 핸들러 하나가 로그인만 하면 누구나 쓸 수 있는 관리 기능이 되어버림.
• 업로드 확장자 검증 부재 — 이미지 업로더인데 MIME 타입만 보거나, 아예 확장자 화이트리스트가 없는 경우. 웹셸 한 장이면 끝남.
• 임의 옵션 업데이트 — 얼핏 사소해 보이지만 가장 무서운 축. 공격자가 users_can_register를 켜고 default_role을 administrator로 바꾼 뒤, 회원가입 폼으로 관리자를 하나 만들어 들어옴. 파일 업로드 없이도 사이트가 넘어감.
• 파일 포함(LFI) — 템플릿 경로나 뷰 이름을 사용자 입력으로 받는 구조. 업로드 가능한 지점과 결합되면 곧바로 RCE가 됨.
• 인증 우회 — 사용자 ID나 이메일만 받아서 wp_set_auth_cookie()를 호출하는 소셜 로그인·원클릭 로그인 계열의 고전적 실수. 비밀번호를 몰라도 1번 계정으로 로그인됨.

왜 '사이트 탈취'와 'RCE'가 사실상 같은 말인가

워드프레스에서는 관리자 권한 획득과 코드 실행 사이의 거리가 굉장히 짧음. 관리자는 기본적으로 플러그인·테마 편집기를 쓸 수 있고, 플러그인 zip을 업로드해 설치할 수 있음. 즉 관리자 계정 하나 = 서버에서 PHP 임의 실행이라고 봐야 함. 그래서 "권한 상승 취약점"이라는 표현을 보고 방심하면 안 됨. 실제 결과는 웹셸이고, 그다음은 데이터베이스 덤프, 악성 리다이렉트 삽입, 스팸 페이지 대량 생성, 심하면 같은 호스팅 계정의 다른 사이트까지 번짐.

탐지: 로그에서 무엇을 보아야 하나

패치 전에 이미 당했는지를 확인하려면 로그를 봐야 하는데, 볼 곳이 의외로 정해져 있음.

• 비인증 요청이 몰리는 엔드포인트 — /wp-admin/admin-ajax.php와 /wp-json/ 하위로 들어오는 POST 중 로그인 쿠키가 없는 요청. 특정 action= 값이 짧은 시간에 반복되면 거의 자동화 스캔임.
• readme.txt 대량 조회 — 공격자는 먼저 /wp-content/plugins/*/readme.txt를 훑어 버전을 수집함. 404가 우수수 찍히는 패턴이 보이면 며칠 안에 실제 시도가 옴.
• uploads 아래의 .php 파일 — 정상 운영 중이라면 wp-content/uploads에 PHP 파일이 생길 이유가 없음. 파일 무결성 모니터링을 걸고 이 한 가지만 감시해도 체감 효과가 큼.
• wp_options 변경 — users_can_register, default_role, siteurl, home 네 값은 바뀌면 알림이 오게 해두는 걸 개인적으로 추천함.
• 신규 관리자 계정과 capabilities 변조 — 계정 목록만 보지 말고 wp_usermeta의 capabilities 값도 같이 봐야 함. 기존 구독자 계정의 권한만 슬쩍 올려두고 잠수하는 경우가 있음.

완화: 순서대로 하면 됨

• 패치가 1순위. 취약한 버전을 그대로 두고 나머지를 아무리 해도 시간벌기일 뿐. 사용 중인 플러그인 목록과 버전을 먼저 뽑고, 자동 업데이트를 켤 수 있는 것부터 켜기.
• uploads 디렉터리 PHP 실행 차단. 웹서버 설정에서 해당 경로의 .php 처리를 막아두면, 업로드 취약점이 터져도 웹셸이 실행되지 않음. 가성비가 가장 좋은 조치.
• wp-config.php에 DISALLOW_FILE_EDIT, 가능하면 DISALLOW_FILE_MODS. 관리자 계정을 뺏겨도 코드 실행까지 가는 길을 한 칸 늘려줌.
• 안 쓰는 플러그인·테마는 비활성화가 아니라 삭제. 비활성 상태여도 파일이 남아 있으면 직접 호출로 취약 코드가 실행되는 경우가 있음. 기본 테마 하나만 남기고 정리하기.
• WAF·가상 패치는 보조 수단. 패치까지 며칠이 걸릴 때 버티는 용도로는 충분히 값어치를 하지만, 그걸 최종 대책으로 삼으면 안 됨.
• 관리자 2FA와 최소 권한. 편집만 하는 사람에게 administrator를 주지 않기. 사고 대부분이 여기서 규모가 커짐.

이미 당한 것 같다면

플러그인만 업데이트하고 넘어가는 건 가장 흔한 실수. 이미 웹셸이 올라갔다면 패치는 문을 잠그는 것일 뿐, 안에 들어와 있는 사람을 내보내지는 못함. 낯선 관리자 계정 제거, 전 계정 비밀번호와 인증 키(SALT) 재발급, uploads와 테마 디렉터리 전수 점검, 그리고 감염 이전 시점 백업과의 파일 비교까지 해야 정리가 끝남. 복구보다 어디로 들어왔는지를 먼저 특정해야 같은 일이 반복되지 않음.

워드프레스를 쓰다 보면 플러그인이 스무 개, 서른 개까지 늘어나는 게 순식간이고, 그중 몇 개는 이미 개발이 멈춘 물건인 경우가 많다. 이번 주말에 딱 10분만 내서 플러그인 목록을 열어보고, 마지막 업데이트가 1년 넘게 없는 것부터 지워보는 걸 권함. 그것만으로도 공격 표면이 눈에 띄게 줄어드니까요. 다들 사이트 한 번씩 점검해보아요!