워드프레스 업데이트로는 못 막는 PHP 취약점
PHP 보안팀이 10월 21일 인증 없이 원격 코드 실행이 가능한 PHP2Shell 취약점(CVE-2026-109618·109619, 위험도 9.2)의 긴급 패치를 내놨다. 공격은 CMS가 실행되기 전에 일어나므로 워드프레스나 플러그인을 아무리 올려도 막히지 않고, 그 아래에서 도는 PHP 자체를 패치해야 한다. 내 PHP 버전과 운영 방식을 먼저 확인해 패치를 적용한 뒤, 패치 이전에 뚫렸을 가능성까지 역으로 점검하는 것이 순서다.
지금 상황부터
10월 21일 PHP 보안팀이 PHP2Shell로 불리는 두 취약점(CVE-2026-109618, CVE-2026-109619)의 긴급 패치를 내놨다. 둘 다 인증 없이 원격에서 코드를 실행할 수 있는 결함이고, 위험도는 10점 만점에 9.2다.
악용 시도는 이미 관측됐다. 아마존의 허니팟은 공개 나흘 전인 10월 17일에 공격 시도를 포착했고, 미국 CISA는 10월 26일 이 취약점을 '악용 확인' 목록에 올렸다. 국내에서도 취약한 PHP가 깔린 것으로 추정되는 자산이 약 11만 건으로 집계됐다.
다만 한 가지는 분명히 해두자. 공격 '시도'는 많지만, 성공한 침해가 공개적으로 확인된 사례는 10월 26일 기준 아직 없다. 서두르되 당황할 일은 아니다.
먼저, 내 서버가 영향권인가
Christina Morillo
흔한 오해부터 짚는다. 워드프레스나 그누보드, 플러그인과 테마를 최신으로 올려도 이 공격은 막히지 않는다. 공격이 CMS가 실행되기 전 단계에서 일어나기 때문이다. 막아야 할 대상은 그 아래에서 돌아가는 PHP 자체다.
확인 순서는 이렇다.
- PHP 버전을 본다. 서버에 접속할 수 있으면
php -v로, 아니면 phpinfo() 페이지나 호스팅 대시보드에서 확인한다. - 패치본과 비교한다. 수정된 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35다. 이보다 낮으면 영향권이다.
- 8.1 이하라면 공식 패치가 없다. 지원되는 버전으로 올리는 것이 유일한 해결책이고, 당장 어렵다면 보안 업체의 백포트 패치를 받아야 한다.
- 메인 사이트만 보지 말자. phpMyAdmin, 웹메일, 예전에 깔고 잊은 테스트 사이트까지 PHP로 도는 모든 것이 대상이다.
웹서버를 Apache의 mod_php 방식으로 돌린다면 사실상 모든 페이지가 공격 표면이 되므로 더 급하다.
패치 적용과 점검 순서
서버를 직접 관리하는 경우의 순서다.
- 패치된 버전 중 하나로 PHP를 업데이트한다.
- PHP를 재시작해 수정이 실제로 적용되게 한다. 재시작하지 않으면 옛 버전이 메모리에 그대로 떠 있다.
- 테마·플러그인·앱이 새 버전에서 정상 동작하는지 확인한다. 운영 사이트에 바로 올리기 전, 스테이징 사본에서 먼저 시험하는 편이 안전하다.
호스팅을 쓰는 경우는 다르다. 관리형 호스팅은 업체가 이미 패치했을 가능성이 높다. 빌드 날짜가 10월 21일 이후인지, 호스트 공지에 PHP2Shell 대응이 있는지 확인하고, 불확실하면 지원팀에 직접 묻는다. 단 cPanel이 깔린 VPS는 '호스팅'처럼 보여도 PHP 관리 책임이 본인에게 있다.
당장 패치가 어렵다면 Cloudflare 같은 WAF 규칙으로 시간을 벌 수 있다. 다만 WAF는 우회될 수 있고 서버로 직접 들어오는 트래픽은 못 막는다. 패치를 미루는 명분이 아니라 패치 전까지의 임시 방어로만 써야 한다. 세션 업로드 진행 기능과 얽힌 별도 취약점(CVE-2026-115560)은 설정에서 session.upload_progress.enabled를 끄고 워커를 재시작하는 것이 임시 조치다.
적용 후, 침해 흔적 점검
패치했다고 끝이 아니다. 패치 이전에 이미 당했을 수 있어서다. 공격이 성공하면 공격자는 페이지를 바꾸거나, 관리자 계정을 새로 만들거나, 데이터베이스를 읽거나, 사이트를 멈출 수 있다. 점검은 이 가능성들을 역으로 훑는 방식이 된다.
- 관리자 계정 목록을 열어 모르는 계정이 끼어 있지 않은지 본다.
- 최근 변경된 파일, 특히 업로드 폴더나 웹 루트에 낯선.php 파일이 생기지 않았는지 확인한다.
- 접속 로그를 10월 중순 이후 구간으로 되짚어 비정상적인 요청이 있었는지 살핀다. 허니팟 관측이 17일부터였으니 그 언저리가 기준점이다.
구체적인 침해 지표나 점검 스크립트는 PHP 공식 advisory와 이용 중인 호스팅 업체 공지에서 최신본을 확인하는 편이 정확하다. 확인된 침해가 없다는 건 다행이지만, 그건 지금까지 공개된 범위일 뿐 내 서버가 안전하다는 보증은 아니다.