PHP2Shell 수정 패치가 나왔지만, 패치가 필요한 웹사이트 대부분에는 누를 버튼이 없다. 취약점은 모든 워드프레스, Joomla, Drupal 페이지를 구동하는 엔진인 PHP 자체에 있다. CMS와 플러그인, 로그인 화면보다 아래 단계에 자리한 문제다. 워드프레스를 업데이트해도 해결되지 않는다. 패치된 인터프리터는 서버를 운영하는 곳, 즉 호스팅 업체나 리눅스 배포판의 패키지, 컨테이너 이미지에서 받아야 한다. 그때까지 사이트 운영자가 무엇을 하든 사이트는 기다릴 수밖에 없다.

‘지금 패치하라’는 제목의 기사들이 놓치는 대목이 바로 여기다. PHP 팀은 할 일을 마쳤다. 하지만 그 결과물을 각 서버에 적용하는 과정은 가장 느린 연결고리의 속도에 좌우되며, 첫날부터 각 연결고리 사이의 간극이 얼마나 큰지 드러났다. 자신의 PHP가 어디에서 제공되는지 모르는 사이트 운영자는 아직 얼마나 위험에 노출돼 있는지도 판단할 수 없다.

워드프레스 업데이트로 해결되지 않는 이유

버그가 인터프리터에 있기 때문에 PHP 보안 공지의 영향 범위에는 웹 요청을 처리하는 모든 설치 환경이 포함된다. PHP-FPM과 Apache의 mod_php부터 php-cgi, FrankenPHP, LiteSpeed까지 대상이다. The Hacker News에 따르면 취약한 버전에서 실행되는 기본적인 ‘Hello World’ 페이지도 공격받을 수 있다. 최악의 경우는 mod_php다. 계정이 없는 사용자의 요청 한 번으로 애플리케이션 코드가 실행되기 전에 공격이 시작될 수 있어, 보안 플러그인이나 로그인 화면이 이를 알아차리지 못한다.

워드프레스 보안 업체 Wordfence는 사이트 운영자들에게 자동 업데이트로는 패치를 받을 수 없으며 PHP를 누가 관리하는지 확인해야 한다고 안내했다고 The Verge가 보도했다. Laravel Forge도 자사 서버 이용자들에게 같은 내용을 알렸다. Forge의 자동 보안 업데이트는 PHP를 패치하지 않으며, 우분투의 무인 업그레이드는 우분투 자체 저장소에서만 업데이트를 가져온다. Forge가 PHP를 설치할 때 사용하는 서드파티 패키지는 대상에 포함되지 않는다.

패키지 저장소들의 대응 속도는 제각각이었다. 패치가 공개된 날, 사이트 관리 서비스 mySites.guru는 cPanel의 EasyApache 4에서 보안 공지 후 몇 분 만에 수정된 빌드를 제공했지만, Laravel Forge가 의존하는 우분투 패키지 저장소인 온드레이 수리(Ondřej Surý)의 PPA와 Remi 저장소에는 아직 패치가 없었다고 전했다. InMotion Hosting은 자사의 공유 서버와 워드프레스 서버가 CloudLinux의 빌드를 기다리고 있다고 밝혔다. mySites.guru가 모니터링하는 실제 사이트 가운데 수정된 PHP 버전을 사용한다고 보고한 곳은 UTC 기준 13시 52분 현재 0.08%에 그쳤다.

버전 번호만 보면 잘못 판단할 수 있다

패치 여부를 확인하는 일은 버전 번호를 읽는 것만큼 간단하지 않다. 우분투, 데비안, Red Hat은 상위 버전 번호를 바꾸지 않고 보안 수정 사항을 백포트하기 때문에, 패치가 적용된 우분투 24.04 서버도 여전히 8.3.6 패키지를 사용한다고 표시할 수 있다. The Hacker News는 데비안을 인용해 버전 문자열을 그대로 믿지 말고 패키지 변경 내역에서 CVE를 확인하라고 안내했다. mySites.guru는 또 다른 함정을 지적한다. 명령줄에서 php -v를 실행해 확인한 PHP 바이너리가 실제 페이지를 처리하는 바이너리와 다른 경우가 많으므로, 사이트 자체가 보고하는 버전을 확인해야 한다.

패치를 적용한 뒤에는 실제로 불러오도록 해야 한다. PHP의 보안 공지와 Forge는 Apache, PHP-FPM, 그리고 계속 실행 중인 모든 워커를 재시작해야 한다고 강조한다. 큐 워커와 그 밖의 백그라운드 프로세스는 재시작하지 않는 한 디스크의 파일이 패치됐더라도 이전 인터프리터를 계속 사용한다.

공식 패치를 받지 못하는 곳

수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35이며, CVSS v4.0에서 각각 9.2점으로 평가된 CVE-2026-109618과 CVE-2026-109619를 해결한다. PHP 8.1 이하 버전에는 PHP 프로젝트가 별도의 공식 수정 버전을 제공하지 않는다. PHP를 직접 컴파일하는 사용자를 대상으로 7.4, 8.0, 8.1에 최소한의 소스 백포트만 제공한다. 일부 업체는 이 공백을 메우고 있다. InMotion에 따르면 cPanel은 7.4부터 8.1까지 자사 패키지에 수정 사항을 백포트했고, CloudLinux는 제공 중인 모든 버전에 패치를 적용하고 있다. 반면 CentOS 7에는 수정 사항이 전혀 제공되지 않는다.

지원이 끊긴 구형 버전을 쓰는 사이트는 적지 않다. 패치 공개 전날, mySites.guru가 모니터링하는 실제 Joomla 및 워드프레스 사이트 가운데 22.7%가 PHP 8.1 이하를 사용했고, 16.6%는 여전히 PHP 7 이하를 사용했다. 회사는 이 문제의 일부 원인으로 워드프레스 자체를 꼽는다. 워드프레스는 PHP 8.3을 권장하면서도 지원이 끝난 지 오래된 7.4를 여전히 호환 버전으로 표시하고 있다. PHP 8.2는 이번 패치를 받았지만, 보안 지원은 2026년 12월 31일 종료된다.

임시 설정으로 막을 수 있는 것

패치 공개 전에 돌았던 임시 조치인 session.upload_progress.enabled=0 설정은 실제로 효과가 있지만, 일부 경로만 차단한다. PHP에 따르면 이 설정은 CVE-2026-109619로 이어지는 것으로 확인된 세션 경로를 막을 뿐 다른 변형 공격까지 차단하지는 않는다. php.ini나 서버 또는 풀 설정에 적용한 뒤 모든 워커를 재시작해야 한다. PHP 8.5에서는 fatal_error_backtraces=0을 설정하면 확인된 공격 경로 하나를 더 차단할 수 있다. 하지만 어느 설정도 CVE-2026-109618에는 영향을 주지 않는다. PHP는 이 취약점에 대해 재정의할 수 없는 memory_limit=-1 설정과 낮은 post_max_size, 웹 서버나 프록시의 요청 크기 제한을 제안한다. PHP가 직접 밝힌 대로 완전한 완화책은 없다. InMotion은 워드프레스, Joomla, Drupal, Magento, PrestaShop이 업로드 진행률 기능을 사용하지 않으므로 이를 꺼도 해당 플랫폼에는 아무 문제가 없다고 설명했다.

Cloudflare는 모든 요금제에 방화벽 규칙을 적용했다. 최고기술책임자 데인 크네히트(Dane Knecht)는 이를 임시 방편이라고 설명했다. mySites.guru가 지적하듯, Cloudflare를 우회해 서버 IP 주소로 직접 향하는 트래픽을 서버가 거부해야만 이 규칙이 효과를 낸다.

현재까지 확인된 공격

watchTowr는 허니팟에서 패치 공개 당일 두 취약점을 겨냥한 공격 시도를 기록했다고 밝혔고, Cloudflare는 공격자들이 자사 규칙을 피하려고 페이로드를 바꾸는 모습을 포착했다. 특정 서버가 실제로 침해됐다는 사실을 확인한 출처는 아직 없다. 일부 운영자는 만일의 사태에 대비했다. The Hacker News에 따르면 BambooHR은 서비스를 오프라인으로 전환했고, DigiD를 포함한 네덜란드 공공 서비스도 예방 차원에서 중단됐다. EU의 CERT와 영국 국가사이버보안센터는 패치할 수 없는 조직에 노출된 앱을 격리하거나 서비스를 중단하라고 권고했다.

이번 취약점은 Wiz Research와 Calif, OpenAI의 Codex Security 팀이 발견했다. PHP Foundation에 따르면 메모리 취약점의 징후는 2024년 감사 과정에서 포착됐지만 수정 작업이 수개월 동안 지연됐으며, 재단은 이를 “구조적 실패”라고 불렀다. 연구진은 AI 모델의 도움으로 10년 묵은 버그를 작동하는 익스플로잇으로 만드는 데 약 일주일이 걸렸다고 밝혔다.

PHP가 이번 패치를 내놓기까지는 감사와 수개월의 교착 상태, 그리고 정보 유출이 필요했다. 공유 호스팅을 이용하는 사이트라면 마지막 단계는 고객 지원 티켓을 보내는 일이다.

태그: Cloudflare, PHP, PHP2Shell, WordPress, 취약점