워드프레스 플러그인 취약점 공개 직후 공격은 대응할 시간이 거의 없어서 위험해요. 이 글은 WP-CLI로 업데이트 대기 목록을 확인하고, 백업한 뒤 업데이트하고, 자동 업데이트를 켜고, 업로드 폴더에 낯선 PHP 파일이 없는지 살피는 순서를 정리했어요. 2026년 9월 기준 공개 자료를 바탕으로 썼고, SSH로 서버에 접속할 수 있다는 전제입니다.
플러그인 취약점 공개 후 악용까지 걸리는 시간은 얼마나 될까
Patchstack의 「State of WordPress Security in 2026」 보고서에 따르면 2025년 워드프레스 생태계에서 새 취약점 11,334건이 발견됐어요. 2024년의 7,966건보다 42% 늘어난 수치이고, 악용 가능성이 높은 취약점은 전년 대비 113% 늘었어요. 이 가운데 91%는 플러그인에서 나왔고 워드프레스 코어에서는 2건뿐이었습니다. 그래서 사이트 방어는 사실상 플러그인 관리에서 시작해요.
공개 후 6시간 20% · 24시간 45% · 7일 70%
집중적으로 악용된 취약점이 공개 후 공격당한 비율 · 최초 악용까지 가중 중앙값 5시간 · Patchstack, 2026
이 수치가 말해 주는 건 "주말에 몰아서 업데이트하자"는 방식이 이미 늦을 수 있다는 점이에요. 데일리시큐도 취약점이 공개된 지 수시간 만에 PHP 파일 생성을 노린 시도가 포착됐다고 보도했어요. 공개된 취약점 정보는 공격자에게도 그대로 설명서가 됩니다.
더 불편한 사실도 있어요. 지난해 취약점의 46%는 공개 시점에 패치가 아직 나오지 않은 상태였어요. 일반적인 호스팅·WAF 설정이 막아낸 비율도 워드프레스 특화 악용 공격의 12%, 더 넓은 취약점 테스트 세트의 26%에 그쳤습니다. 호스팅사가 알아서 막아 주겠거니 하고 기대기는 어렵다는 뜻이에요.
실제 사례로 WooCommerce Wholesale Lead Capture 플러그인의 CVE-2026-27540(CVSS 9.8)이 있어요. 인증 없이 파일을 올릴 수 있는 취약점이라 PHP 백도어 설치와 원격 코드 실행까지 가능했습니다. 2.0.3.1 이하가 영향을 받고, 2.0.3.2가 2월 20일에 나와 고쳐졌어요. 그런데 Wordfence는 2026년 6월 이후에만 10만 건이 넘는 악용 시도를 차단했고, 시도는 6~8월에 몰렸다고 해요. 패치가 나온 지 몇 달이 지나도 업데이트하지 않은 사이트를 찾아 공격이 이어진 거예요.
Wordfence 규칙 배포 시점에도 차이가 있었어요. 유료 사용자는 2월 27일, 무료 사용자는 30일 뒤인 3월 29일에 차단 규칙을 받았습니다. 보안 플러그인의 방화벽 규칙만 믿기보다 패치 자체를 빨리 적용하는 쪽이 확실하다는 이야기예요.

1단계: WP-CLI로 업데이트 대기 중인 플러그인 확인하고 백업하기
먼저 워드프레스가 설치된 디렉터리(wp-config.php가 있는 위치)로 이동해서 아래 명령을 실행해요. 다른 위치에서 실행한다면 --path=/사이트/경로를 붙이면 됩니다.
wp plugin list --update=available
이 명령은 업데이트가 대기 중인 플러그인만 골라서 이름, 상태, 업데이트 여부, 현재 버전을 보여 줘요. 목록이 비어 있다면 지금은 처리할 게 없다는 뜻이에요. 목록이 있다면 보안 공지에 오른 플러그인이 섞여 있는지 이름부터 확인해 보세요.
특정 플러그인이 취약 버전 범위인지 볼 때는 버전만 따로 뽑으면 편해요. 예를 들어 위에서 소개한 플러그인이라면 아래처럼 확인해요.
wp plugin get woocommerce-wholesale-lead-capture --field=version
출력이 2.0.3.1 이하라면 영향권이에요. 2.0.3.2 이상이면 해당 취약점은 고쳐진 버전입니다.
업데이트 전에는 되돌릴 수단을 만들어 두는 게 좋아요. 업데이트가 사이트를 깨뜨리는 일이 취약점 공격보다 자주 일어나기 때문에, 백업은 보안 절차이면서 운영 절차이기도 합니다. 데이터베이스와 wp-content를 각각 저장해 두면 돼요.
wp db export ~/backup/db-$(date +%F).sql
tar -czf ~/backup/wp-content-$(date +%F).tar.gz wp-content
백업 파일은 웹에서 접근 가능한 디렉터리 밖에 두세요. SQL 덤프가 공개 경로에 남으면 그 자체로 또 다른 사고가 됩니다.
2단계: wp plugin update로 전체 또는 일부만 업데이트하는 방법
백업이 끝났으면 업데이트를 실행해요. 전체를 한 번에 올리는 명령은 다음과 같아요.
wp plugin update --all
결제나 회원 기능을 쥔 플러그인은 먼저 시험해 보고 올리고 싶을 때가 있어요. 그럴 땐 --exclude로 특정 플러그인만 빼고 나머지를 올릴 수 있습니다.
wp plugin update --all --exclude=woocommerce
단, 제외한 플러그인에 심각한 취약점이 걸려 있다면 미룰수록 위험해요. 위 통계처럼 공개 후 24시간 안에 45%가 공격당했으니까요. 제외는 "취약점 공지가 없는 플러그인을 시험 후 올리는 경우"에만 쓰는 게 안전해요. 공지가 붙은 플러그인은 백업을 확인한 뒤 바로 올리는 쪽이 낫습니다.
업데이트가 끝나면 wp plugin list --update=available을 한 번 더 실행해서 목록이 비었는지 확인하세요. 남은 항목이 있다면 호환성 문제나 라이선스 만료로 막혔을 가능성이 커요. 유료 플러그인은 라이선스가 끝나면 업데이트가 조용히 멈추는 경우가 있어서, 이런 항목이 남는 건 그 자체로 점검 신호예요.
WP-CLI 공식 문서의 플러그인 명령어 옵션 자세히 보기
3단계: 자동 업데이트 설정, 어떤 플러그인부터 켜야 할까
수동 업데이트는 결국 사람이 잊는 순간 구멍이 돼요. 그래서 자동 업데이트를 켜 두는 게 좋은데, WP-CLI에서는 플러그인 하나씩 지정해요.
wp plugin auto-updates enable 플러그인명
wp plugin auto-updates status 플러그인명
WP-CLI 공식 문서와 관련 글을 보면 이 설정은 플러그인마다 개별로 해야 하고, 일괄로 처리하는 방식은 안내되지 않아요. 여러 개를 켜야 한다면 아래처럼 목록을 셸 반복문으로 돌리는 방법이 있어요. 이건 WP-CLI 기능이 아니라 셸 문법이라, 대상 이름을 직접 골라서 넣는 편이 안전합니다.
for p in 플러그인A 플러그인B 플러그인C; do
wp plugin auto-updates enable "$p"
done
그렇다면 어떤 플러그인부터 자동으로 돌려야 할까요? 정해진 정답은 없지만, 아래 기준으로 나누면 판단이 빨라져요.
| 플러그인 유형 | 자동 업데이트 | 이유 |
|---|---|---|
| 파일 업로드·양식·회원가입 기능 | 켜기 우선 | 외부 입력을 받는 기능이라 공격 표면이 넓고, 위 사례처럼 파일 업로드 취약점이 치명적이에요. |
| 보안·캐시·SEO 보조 | 켜도 무난 | 화면 구성과 무관한 편이라 업데이트로 깨질 위험이 상대적으로 낮아요. |
| 결제·쇼핑몰 핵심 플러그인 | 시험 후 수동 | 오류가 매출로 직결되므로 백업 후 시점을 정해 직접 올리는 게 나아요. |
| 페이지 빌더·직접 수정한 테마 연동 | 신중히 | 레이아웃이 깨질 수 있어서 업데이트 후 화면 확인이 필요해요. |
| 더 이상 쓰지 않는 플러그인 | 삭제 | 비활성 상태여도 파일이 남아 있으면 공격 대상이 될 수 있어요. |
마지막 줄은 특히 챙기세요. 쓰지 않는 플러그인은 wp plugin delete 플러그인명으로 지울 수 있어요. 91%가 플러그인에서 나온다는 통계를 떠올리면, 플러그인 수 자체를 줄이는 것도 좋은 방어예요.
워드프레스 관리자 화면의 플러그인 목록에서도 각 플러그인 옆의 자동 업데이트 활성화 링크로 같은 설정을 할 수 있어요. SSH가 없는 환경이라면 이 화면이 대안입니다. WP-CLI의 장점은 status 명령으로 설정 상태를 한꺼번에 기록하고 점검하기 쉽다는 점이에요.
4단계: 업로드 폴더에 낯선 PHP 파일이 생겼는지 점검하기
업데이트를 했더라도 공개 직후에 이미 뚫렸을 가능성은 남아 있어요. 위 사례의 취약점은 PHP 백도어 설치로 이어질 수 있었고, 패치를 적용해도 이미 심어진 파일은 지워지지 않아요. 그래서 마지막 단계는 "지금 깨끗한가"를 확인하는 일입니다.
업로드 폴더(wp-content/uploads)에는 보통 이미지와 문서가 들어 있어요. 여기에 PHP 파일이 있다면 일단 의심해 볼 만합니다.
find wp-content/uploads -type f -name "*.php"
find wp-content/uploads -type f -name "*.php" -mtime -7
첫 줄은 전체 PHP 파일, 둘째 줄은 최근 7일 안에 바뀐 PHP 파일만 찾아요. 일부 플러그인은 디렉터리 목록 노출을 막으려고 내용이 거의 비어 있는 index.php를 만들어 두기도 해서, 파일이 나왔다고 곧바로 감염은 아니에요. 파일 이름이 무작위 문자열이거나, 내용에 eval·base64_decode 같은 코드가 있거나, 설치한 적 없는 시점에 생겼다면 그때 의심하면 됩니다.
코어와 플러그인 파일이 공식 배포본과 같은지는 WP-CLI가 체크섬으로 검증해 줘요.
wp core verify-checksums
wp plugin verify-checksums --all
수정되거나 낯선 파일이 보고되면 해당 플러그인을 다시 설치하는 것으로 정리될 때가 많아요. 다만 wordpress.org에 등록되지 않은 유료 플러그인은 검증 대상에서 빠질 수 있어서, 그런 것들은 위의 find 결과로 보완해야 합니다. 의심 파일이 실제로 발견됐다면 파일만 지우고 끝내지 말고 백업 시점을 되짚어 복원하고, 관리자 비밀번호와 DB 접속 정보를 바꾸는 것까지 함께 진행하세요.
한눈에 보는 점검 순서와 운영 습관
앞에서 다룬 명령을 순서대로 정리하면 아래와 같아요. 한 번 메모해 두고 보안 공지가 나올 때마다 그대로 따라 하면 됩니다.
| 순서 | 목적 | 명령 |
|---|---|---|
| 1 | 대기 목록 확인 | wp plugin list --update=available |
| 2 | 백업 | wp db export + wp-content 압축 |
| 3 | 업데이트 | wp plugin update --all (필요 시 --exclude) |
| 4 | 자동 업데이트 | wp plugin auto-updates enable 후 status 확인 |
| 5 | 침해 점검 | uploads의 PHP 검색, verify-checksums |
운영 습관으로는 두 가지만 권해요. 하나는 자동 업데이트를 켜 두더라도 주 1회쯤 wp plugin list --update=available로 남은 항목을 확인하는 거예요. 자동 업데이트는 개별 설정이라, 새로 설치한 플러그인이 빠져 있는 일이 흔합니다. 다른 하나는 설치한 플러그인의 개발이 멈추지 않았는지 가끔 보는 거예요. 패치가 나오지 않는 플러그인은 자동 업데이트로 지킬 수 없으니까요.
공개 후 6시간 안에 20%가 공격당하는 환경에서는 "발견하면 고친다"보다 "미리 자동으로 고쳐지게 해 둔다"가 더 현실적이에요. 대기 목록 확인, 백업, 업데이트, 자동 업데이트 대상 선정, 업로드 폴더 PHP 점검까지 다섯 단계를 한 번 돌려 두면, 다음 취약점 공지가 나와도 훨씬 빠르게 대응할 수 있습니다.