워드프레스와 플러그인을 전부 최신으로 올려도 이번 PHP 취약점은 막히지 않는다. 사이트가 돌아가는 서버의 PHP가 패치됐는지 따로 확인해야 한다.
PHP 개발팀은 2026년 10월 21일 인증 없이 원격 코드 실행이 가능한 취약점 2건을 고친 긴급 보안 버전을 냈다. 같은 날 WordPress.org도 사이트 운영자에게 PHP 업데이트를 직접 권고했다. 할 일은 생각보다 단순하다. 다만 버전 숫자만 보고 판단하면 틀릴 수 있다.
한눈에 보기
📌 공개일 — 2026년 10월 21일
📌 취약점 — CVE-2026-109618, CVE-2026-109619 (통칭 PHP2Shell)
📌 심각도 — 각각 CVSS 4.0 기준 9.2, Critical
📌 수정 버전 — PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
📌 워드프레스 코어 업데이트 — 이번 건으로는 필요 없음, 예정도 없음
👉 할 일: 내 사이트가 쓰는 PHP에 두 CVE 패치가 적용됐는지 확인
PHP 보안 취약점 2건, 확인된 것만
이번 문제는 워드프레스 코드가 아니라 그 아래에서 돌아가는 PHP 엔진에 있다. PHP 공식 권고에 따르면 두 취약점 모두 로그인 없이 서버에서 임의 코드를 실행할 수 있다. 공격이 성공하면 웹 서버 프로세스 권한으로 코드가 돈다.
CVE-2026-109618은 메모리 부족 상황에서 생긴다. PHP가 요청을 처리하다 메모리가 바닥나면, 내부 데이터가 덜 정리된 채로 멈출 수 있다. 이후 정리 과정이 이 잘못된 데이터를 정상으로 다루면서 메모리가 망가진다.
CVE-2026-109619는 요청이 끝난 뒤에도 내부 상태가 남는 문제다. 같은 PHP 작업 프로세스가 다음 요청을 받을 때 이미 해제된 메모리를 다시 쓰게 된다. 앞 요청이 남긴 흔적이 뒤 요청에서 터지는 구조다.
PHP 개발팀은 웹 요청을 처리하는 모든 PHP 설치를 위험 범위로 봤다. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed가 명시됐다. 그중 mod_php가 가장 위험한 구성으로 평가됐다. 애플리케이션 코드가 실행되기도 전에 공격이 시작되는 경로가 확인됐기 때문이다.
PHP2Shell이라는 이름은 보안업계와 미국 CISA, Automattic 등이 함께 쓰는 통칭이다. PHP 공식 발표는 CVE 번호로 부른다.
워드프레스 업데이트로는 왜 안 막히나
방문자 요청은 워드프레스 코어나 플러그인에 닿기 전에 PHP를 먼저 거친다. 이번 구멍은 그 PHP 층에 있다. 그래서 대시보드의 업데이트 버튼으로는 손이 닿지 않는다.
WordPress.org는 이번 건이 워드프레스 전용 취약점이 아니라고 밝혔다. 이 두 CVE를 위한 코어 업데이트는 필요하지도, 예정되지도 않았다고 했다. Automattic도 같은 취지로 설명했다. 이번 수정은 런타임 수정이라 코어·테마·플러그인 업데이트만으로는 보호되지 않는다는 것이다.
헷갈리는 지점은 두 방향으로 생긴다. 아래 네 가지 경우를 보면 정리된다.
| 내 사이트 상태 | 이번 취약점 기준 |
|---|---|
| 워드프레스·플러그인 최신 + PHP 미패치 | 노출 가능 |
| PHP 버전 숫자가 수정 버전 이상 (공식 빌드) | 패치 적용 |
| 숫자는 낮아 보이지만 배포판이 보안 수정을 백포트 | 이미 보호됐을 수 있음 |
| 호스팅사가 “WAF 적용”만 안내 | PHP 패치 여부 추가 확인 필요 |
워드프레스 운영자가 지금 확인할 것
1. 관리자 화면에서 PHP 버전 보기
SSH를 열 필요는 없다. WordPress.org가 이번 공지에서 직접 안내한 경로가 있다.
도구 → 사이트 건강 → 정보 → 서버 → PHP 버전
2. 공식 PHP 빌드라면 이 숫자로 판단
| 현재 계열 | 수정 버전 | 판단 |
|---|---|---|
| PHP 8.5 | 8.5.12 이상 | 미만이면 업데이트 대상 |
| PHP 8.4 | 8.4.27 이상 | 미만이면 업데이트 대상 |
| PHP 8.3 | 8.3.36 이상 | 미만이면 업데이트 대상 |
| PHP 8.2 | 8.2.35 이상 | 미만이면 업데이트 대상. 12월 말 지원 종료 |
| PHP 8.1 이하 | 정규 릴리스 없음 | 배포판 백포트 또는 PHP 팀의 제한적 소스 수정 적용 여부 확인 + 지원 버전 이전 계획 |
3. 숫자가 낮다고 바로 미패치로 단정하지 않기
이 부분에서 판단이 가장 많이 틀린다. 리눅스 배포판은 버전 번호를 그대로 둔 채 보안 수정만 옮겨 넣는 경우가 많다. 이를 백포트라고 한다.
Ubuntu 24.04 LTS가 좋은 예다. 이번 두 CVE를 고친 PHP 패키지 버전이 8.3.6-0ubuntu0.24.04.13이다. 숫자만 보면 8.3.36보다 한참 낮다. 그런데 Ubuntu는 이 패키지에 두 CVE 수정이 들어갔다고 공식 명시했다. Ubuntu 22.04의 PHP 8.1도 8.1.2-1ubuntu2.28 패키지로 수정됐다.
반대로 PHP 8.1이 보인다고 무조건 뚫리는 상태도 아니다. 8.1 이하는 공식 정규 보안 릴리스가 없다. 하지만 배포판이 수정을 백포트했을 수 있다. PHP 보안팀도 이번 사안에 한해 7.4·8.0·8.1용 제한적 소스 수정을 따로 내놨다. 결국 확인해야 할 것은 숫자가 아니라 두 CVE 패치가 실제로 적용됐는지다.
하나 더 있다. 패키지를 업데이트해도 이미 돌고 있는 PHP 프로세스는 예전 코드를 쥐고 있을 수 있다. Ubuntu도 업데이트 후 웹 서버나 PHP 프로세스 재시작이 필요할 수 있다고 안내했다. 호스팅사가 패치를 적용했다고 답했다면, 실제 웹 요청을 처리하는 PHP 프로세스에도 반영됐는지까지 확인하는 게 좋다.
호스팅 방식별로 할 일이 다르다
| 운영 환경 | 지금 할 일 |
|---|---|
| WordPress.com·VIP·WP Cloud·Pressable·Tumblr | Automattic이 보호 완료를 발표. 별도 작업 불필요 |
| 일반 공유호스팅 | 호스팅사에 두 CVE의 PHP 패치·백포트 여부 문의 |
| 관리형 워드프레스 호스팅 | 업체 보안 공지 확인. WAF만인지, PHP 패치까지인지 구분 |
| 직접 운영하는 VPS·서버 | 배포판 공식 보안 패키지 업데이트 후 PHP-FPM 등 재시작 |
| PHP를 직접 빌드 | 수정 릴리스 또는 PHP 팀이 낸 소스 수정 적용 |
| Docker·쿠버네티스 등 컨테이너 | 패치된 PHP 베이스 이미지로 다시 빌드하고 재배포 |
Automattic의 “보호 완료” 발표는 자사 플랫폼에만 해당한다. 다른 관리형 호스팅까지 안전하다는 뜻으로 넓혀 읽으면 안 된다.
공유호스팅이라면 아래 문구를 그대로 문의 창에 붙여 넣으면 된다. “최신 PHP입니다” 같은 두루뭉술한 답을 피할 수 있다.
호스팅사 문의 문구 (복사용)
CVE-2026-109618 및 CVE-2026-109619와 관련해, 제 계정에서 웹 요청을 처리하는 PHP 환경에 패치가 적용됐는지 확인 부탁드립니다. 현재 표시되는 PHP 버전이 업스트림 수정 버전인지, 배포판 보안 백포트가 적용된 패키지인지도 알려주세요. WAF 완화 조치와 별개로 PHP 런타임 패치 적용 여부를 확인하고 싶습니다.
임시 설정과 WAF는 패치를 대신하지 못한다
PHP 개발팀은 당장 업데이트할 수 없는 환경을 위해 몇 가지 임시 설정을 제시했다. 예를 들면 session.upload_progress.enabled=0이나 memory_limit=-1 같은 값이다.
하지만 PHP 팀은 이 설정들이 확인된 공격 경로 일부만 줄인다고 분명히 했다. 설치 환경을 안전하게 만들지는 못한다는 뜻이다. 업로드·이미지 처리·백업 플러그인이 영향을 받을 수도 있다. 공유호스팅 운영자가 인터넷에 돌아다니는 php.ini 값을 따라 바꾸는 건 권하기 어렵다.
WAF도 같은 자리에 있다. WordPress.org와 Google Cloud 모두 WAF를 보조 방어선으로 봤다. PHP 패치의 대체재로 설명하지 않았다. 영국 NCSC는 패치나 완화 조치를 빨리 적용할 수 없는 중요 시스템이라면 오프라인 전환까지 고려하라고 권고했다.
공격은 실제로 일어나고 있나
📌 확정 — 두 취약점으로 원격 코드 실행이 가능하다는 점은 PHP 공식 권고가 확인했다. 보안 연구팀 Wiz는 취약한 PHP 위에서 최신 워드프레스를 대상으로 인증 없는 원격 코드 실행을 실제로 입증했다.
📢 보도·업체 발표 — 2026년 10월 22일 기준, 공격 시도는 실제로 관측됐다. 패치 전날 세부 내용이 유출됐고, 보안업체 watchTowr는 두 취약점을 노린 공격 시도를 관측하고 있다고 밝혔다. Cloudflare도 패치 공개 몇 시간 전 초기 공격을 보고한 것으로 알려졌다. 일부 공공기관은 서비스를 예방적으로 내렸다는 보도도 나왔다.
🔎 분석 — 다만 공격 시도가 관측됐다는 사실만으로 실제 서비스 침해나 대규모 피해가 확인됐다고 볼 수는 없다. 대규모 침해를 확인한 공식 발표는 아직 없고, Reuters 후속 보도도 많은 오프라인 조치가 예방 차원이었다고 전했다. 실제 공격 성공률은 PHP 버전, 실행 방식, 작업 프로세스 구성에 따라 달라진다. “모든 PHP 사이트가 요청 한 번에 뚫린다”는 과장이다. 그렇다고 기다릴 이유도 없다. 공격 코드가 현실적이고, 애플리케이션 버그가 없어도 경로가 열려 있기 때문이다.
PHP 8.2라면 한 가지 더
8.2.35로 올리면 이번 건은 해결된다. 하지만 PHP 8.2는 2026년 12월 31일 보안 지원이 끝난다. 두 달 뒤면 같은 고민을 다시 하게 된다.
공식 일정상 보안 지원은 8.3이 2027년 말, 8.4가 2028년 말, 8.5가 2029년 말까지다. 테마·플러그인 호환을 확인할 수 있다면 8.3 이상을 목표로 두는 편이 낫다. 오래된 사이트라면 7.x에서 8.5로 한 번에 건너뛰지 말고, 백업부터 하고 지원 범위를 확인하며 올린다.
🔎 Hoonyspot 판단
공유·관리형 호스팅을 쓰는 워드프레스 운영자에게 가장 중요한 일은 PHP를 직접 고치는 게 아니다. 호스팅사로부터 두 CVE 패치가 적용됐다는 답을 받아내는 것이다. 버전 숫자 한 줄로 안심하거나 겁먹기보다, CVE 번호를 들고 묻는 쪽이 빠르고 정확하다. 반면 VPS나 자체 서버를 운영한다면 확인으로 끝나지 않는다. 보안 업데이트 적용과 PHP 프로세스 재시작까지 직접 점검해야 한다.
자주 묻는 질문
Q. 워드프레스를 최신 버전으로 올렸는데 그걸로 충분한가요?
아닙니다. 이번 취약점은 PHP 자체의 문제라서 워드프레스 코어·테마·플러그인 업데이트로는 해결되지 않습니다. 서버 PHP의 패치 여부를 따로 확인하셔야 합니다.
Q. 사이트 건강 화면에 PHP 8.3.6이 보입니다. 위험한가요?
숫자만으로는 판단할 수 없습니다. Ubuntu 24.04처럼 8.3.6 기반 패키지에 이번 수정을 백포트한 사례가 있습니다. 호스팅사나 배포판 보안 공지에서 두 CVE 수정 여부를 확인해 보시기 바랍니다.
Q. 호스팅사가 WAF로 막았다고 합니다. 안심해도 되나요?
WAF는 보조 방어선입니다. PHP 개발팀은 패치를 유일한 완전한 해결책으로 안내했습니다. PHP 런타임 패치까지 적용됐는지 한 번 더 확인하시는 편이 안전합니다.
Q. PHP2Shell과 CVE-2026-109618·109619는 같은 건가요?
네. PHP2Shell은 두 취약점을 묶어 부르는 통칭입니다. PHP 공식 발표는 CVE 번호로 표기합니다.
확인 기준일: 2026년 10월 22일. PHP 개발팀·WordPress.org·호스팅사의 후속 발표에 따라 수정 버전과 권고 내용이 바뀔 수 있습니다. 실제 조치 전에는 이용 중인 호스팅사 또는 운영체제의 최신 보안 공지를 다시 확인해 주시기 바랍니다.
집에서 QNAP NAS를 쓰고 있다면 관리 화면 자체에 PHP가 들어 있어 대응 경로가 다릅니다. QNAP NAS PHP2Shell 패치 확인법에서 따로 정리했습니다.
참고 자료
- PHP 공식 사이트 — php.net
- WordPress.org — wordpress.org
- Automattic — automattic.com
- Ubuntu 보안 공지 — ubuntu.com
- 영국 NCSC — ncsc.gov.uk
- 미국 CISA — cisa.gov
- CERT-EU — cert.europa.eu
