PHP 핵심 엔진에서 발견된 두 취약점 PHP2Shell은 인증되지 않은 공격자가 취약한 서버에서 코드를 실행하게 할 수 있다. CVE-2026-109618과 CVE-2026-109619는 각각 CVSS 9.2로 평가됐으며, PHP를 사용하는 워드프레스·Drupal·Joomla와 자체 개발 애플리케이션이 영향을 받을 수 있다.
Wiz Research는 2026년 10월 21일 취약점을 공개하고 수정된 PHP 버전을 발표했다. 취약점은 PHP 런타임에 있으므로 CMS나 플러그인만 업데이트해서는 해결되지 않는다. PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 가운데 사용 중인 브랜치에 맞는 버전으로 업데이트한 뒤 PHP 작업자와 관련 서비스를 재시작하고, 운영 환경에서 실제 실행 중인 버전을 확인해야 한다.
취약점의 영향과 작동 방식
PHP2Shell은 PHP 핵심 엔진에 영향을 주는 두 취약점을 가리킨다. CVE-2026-109618은 업로드 진행 상황을 처리하는 과정에서 메모리 손상과 PHP 프로세스 메모리 노출을 일으킬 수 있다. CVE-2026-109619는 요청 사이에 남은 내부 상태와 OPcache의 객체 유형 혼동 문제를 포함한다.
두 취약점은 특정 CMS의 플러그인 결함이 아니다. PHP 런타임에 문제가 있으므로 애플리케이션 코드 자체가 안전하더라도 취약한 PHP를 사용하면 노출될 수 있다. Wiz Research는 워드프레스·Drupal·Joomla에서 인증 없는 원격 코드 실행(RCE)을 시연했다. 이는 영향을 받는 애플리케이션의 일부 사례이며 전체 목록은 아니다.
CVE-2026-109618은 PHP의 세션 업로드 진행 기능과 요청 처리 중 내부 상태 관리에 관련된다. 메모리 부족 오류로 요청 처리가 중단되면 정리 과정에서 초기화가 끝나지 않은 데이터나 이미 해제된 메모리를 가리키는 정보에 접근할 수 있다. 이후 요청이 남아 있는 상태와 상호작용하면 프로세스 메모리가 손상될 수 있다. Wiz는 이를 이용한 인증 없는 원격 코드 실행을 시연했고, PHP 작업자 메모리에 있는 민감한 정보를 노출하는 관련 경로도 확인했다. 노출 가능한 정보에는 다른 요청에서 사용한 자격 증명, 토큰, API 키 등이 포함될 수 있다.
CVE-2026-109619는 여러 요청에 걸쳐 유지되는 PHP 내부 상태와 바이트코드 캐시인 OPcache에 관련된다. 메모리가 해제된 뒤에도 참조가 남으면 이후 실행이 잘못된 상태에 접근할 수 있다. 별도로 OPcache가 런타임 객체를 추적하는 방식의 불일치 때문에 메모리 영역을 잘못된 유형의 객체로 해석할 수도 있다. 두 경로 모두 메모리 손상을 일으킬 기회를 만들며, Wiz는 관련 익스플로잇 경로를 이용해 Drupal과 워드프레스에서 인증 없는 원격 코드 실행을 시연했다.
메모리 노출은 코드 실행 외에도 위험을 키울 수 있다. 프로세스 메모리에서 주소나 자격 증명 같은 정보가 유출되면 뒤이은 공격이 쉬워질 수 있기 때문이다. PHP는 호스팅 사업자, 컨테이너, CMS, 자체 개발 애플리케이션 등 여러 환경에서 사용되므로 보안팀이 모든 PHP 런타임을 파악하지 못했을 가능성도 있다.
Wiz에 따르면 프런티어 AI 모델은 연구자들이 취약점을 발견하고 작동하는 익스플로잇을 개발하는 데 도움을 줬다. 여기에는 취약점 연결, 서로 다른 메모리 배치에 맞춘 조정, 테스트와 디버깅이 포함됐다. 해당 코드에는 취약점이 수년간 존재했다. 취약점이 오래 발견되지 않았다는 사실만으로 안전하다고 볼 수는 없으며, AI는 공격자뿐 아니라 방어자의 취약점 탐색과 탐지 개선에도 활용될 수 있다.
Wiz Research는 2026년 8월 19일 첫 취약점을 발견했다. 8월 20일에는 Drupal, 8월 21일에는 워드프레스에서 인증 없는 원격 코드 실행을 확인했고, 8월 24일 PHP 보안팀에 결과를 전달했다. PHP는 9월 21일 신고를 확인하고 조율된 수정을 시작했다. 10월 21일 수정 버전이 공개되면서 취약점도 공개됐다.
패치 버전과 지원 여부
공식 수정 버전은 보안 지원을 받는 PHP 네 개 브랜치에 제공됐다. 그보다 오래된 브랜치는 영향을 받지만 공식 수정 버전이 없을 수 있다.
| PHP 브랜치 | PHP2Shell 수정 상태 | 보안 지원 종료 |
|---|---|---|
| PHP 8.5 | 8.5.12에서 수정 | 2029년 12월 31일 |
| PHP 8.4 | 8.4.27에서 수정 | 2028년 12월 31일 |
| PHP 8.3 | 8.3.36에서 수정 | 2027년 12월 31일 |
| PHP 8.2 | 8.2.35에서 수정 | 2026년 12월 31일 |
| PHP 7.4, 8.0, 8.1 | 공식 릴리스 없음. 최소한의 소스 백포트만 제공 | 지원 종료 |
| PHP 5.4~7.3 | PHP 프로젝트의 수정 사항 없음 | 지원 종료 |
PHP 8.1 이하를 사용한다면 지원되는 브랜치로 업그레이드하거나, 리눅스 배포판 또는 장기 지원(LTS) 공급업체가 제공하는 백포트 패키지를 설치해야 한다. PHP 보안팀이 7.4, 8.0, 8.1용으로 제공한 백포트를 사용해 소스에서 빌드하는 방법도 있다. PHP 7.4보다 오래된 시스템은 업그레이드하거나 격리하거나 폐기해야 한다.
PHP 8.2를 사용한다면 8.2.35로 업데이트하되 8.3 이상으로 옮길 계획도 세워야 한다. PHP 8.2의 보안 지원은 2026년 12월 31일 끝난다. 운영체제나 호스팅 사업자가 제공하는 PHP는 버전 문자열을 바꾸지 않고 보안 수정을 백포트할 수 있으므로, 해당 공급업체의 보안 공지에서 수정된 패키지인지 확인해야 한다.
기술 세부 정보와 조치 안내는 CVE-2026-109618 PHP 보안 공지와 CVE-2026-109619 PHP 보안 공지에서 확인할 수 있다.
운영 환경에서 확인할 사항
먼저 웹 서버, 컨테이너, CMS 설치, 다른 팀이 관리하는 애플리케이션을 포함해 모든 PHP 런타임을 목록화한다. 주 운영 애플리케이션만 확인하지 말고 스테이징 시스템, 오래된 애플리케이션, 잊힌 CMS 설치와 외부 업체가 관리하는 서버도 살펴야 한다. 인터넷에 노출돼 있다면 이들 환경도 점검 대상이다.
사용 중인 환경에 맞는 수정 버전을 설치하고, 필요한 경우 PHP-FPM과 웹 서버, 장시간 실행되는 작업자를 재시작한다. 운영 환경에서 실제로 실행되는 버전도 확인한다. 워드프레스나 다른 애플리케이션을 업데이트해도 그 아래에서 실행되는 PHP 런타임은 업데이트되지 않는다.
WAF 공급자가 제공하는 보호 규칙은 추가 방어층으로 적용할 수 있지만 PHP 보안 업데이트를 대신하지는 않는다. 패치 후에는 웹 서버와 애플리케이션 로그에서 비정상 요청, 예상치 못한 PHP 작업자 오류, 설명되지 않는 프로세스 활동, 의심스러운 외부 연결을 확인한다. 이런 징후만으로 공격이 있었다고 단정할 수는 없지만 조사할 대상을 좁히는 데 도움이 된다. 의심스러운 활동이 발견되면 PHP 프로세스 메모리에서 다른 요청의 자격 증명이나 API 키가 노출됐을 가능성도 고려해 비밀 정보를 교체해야 한다.
PHP2Shell은 애플리케이션 코드만 안전하게 작성한다고 해서 런타임의 위험까지 없어지는 것은 아니라는 점을 보여준다. 우선 영향을 받는 런타임을 찾아 패치하고, 의심스러운 활동이 있었는지 조사해야 한다. AI가 취약점 발견과 익스플로잇 개발을 돕는 만큼 방어 측도 취약점을 더 일찍 찾고 공개와 수정 사이의 시간을 줄이는 데 이를 활용해야 한다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요