PHP2Shell 취약점이 패치돼 PHP 런타임 업데이트가 필요하다

PHP 핵심 코드의 두 가지 취약점인 PHP2Shell이 수정됐다. 취약한 PHP 버전에서는 인증 없이 서버에서 코드를 실행하거나 PHP 프로세스 메모리의 민감한 정보를 노출할 수 있다. CVSS 심각도는 9.2이며, 운영자는 애플리케이션 업데이트만으로는 해결되지 않으므로 모든 PHP 런타임을 패치 버전으로 올려야 한다.

영향과 수정 버전

취약점은 메모리 부족 처리 과정의 손상(CVE-2026-109618)과 요청 사이에 남는 오래된 전역 상태(CVE-2026-109619) 두 종류다. 취약한 코드는 PHP 자체에 있어 WordPress, Drupal, Joomla뿐 아니라 영향을 받는 PHP 버전에서 실행되는 다른 애플리케이션도 대상이 될 수 있다. 시연된 원격 코드 실행과 메모리 노출에는 인증이나 애플리케이션 계정이 필요하지 않았다.

메모리에는 다른 요청이나 서버의 비밀번호, 인증 토큰, API 키, 인증서가 포함될 수 있다. 메모리 노출은 원격 코드 실행 없이도 민감한 정보를 드러낼 수 있다. Wiz Research는 PHP 5.4 이후의 릴리스에서 취약한 버전을 확인했으며, 수정 전에는 거의 모든 PHP 버전이 두 문제 중 하나 이상의 영향을 받았다고 밝혔다. 실제 노출 여부는 버전과 구성, 취약점별 조건에 따라 달라진다.

모든 실행 환경에 수정된 PHP 릴리스를 설치한 뒤 Apache, PHP-FPM 및 장시간 실행되는 PHP 작업자를 재시작해야 한다. 공식 릴리스는 php.net에서 확인할 수 있으며, 하위 배포판은 각자의 업데이트 경로로 패키지를 제공한다. 애플리케이션 코드만 업데이트하는 것은 PHP 런타임을 수정하지 않는다.

당장 업그레이드할 수 없다면

아래 설정은 일부 공격 경로의 노출을 줄일 수 있지만 모든 변형을 막지는 못하며, PHP 업데이트를 대신하지 않는다. 설정 변경은 애플리케이션 기능·성능·가용성에 영향을 줄 수 있으므로 요구사항에 맞춰 시험해야 한다.

• memory_limit = -1은 PHP 메모리 제한 처리에 의존하는 일부 경로를 막을 수 있지만, 메모리 고갈 처리를 운영체제로 넘긴다. 메모리 소진 시 작업자가 종료돼 요청이 중단되거나 서버 안정성과 가용성이 영향을 받을 수 있다. 적용한다면 Linux cgroup v2의 memory.max 또는 이에 준하는 운영체제 기능으로 자원 사용을 제한해야 한다. RLIMIT_AS와 RLIMIT_DATA는 같은 취약 경로를 유발할 수 있어 대체 메모리 제한으로 사용하지 말라는 것이 PHP 권고다.
• 애플리케이션의 업로드 요구사항을 고려해 post_max_size를 낮추고, 허용되는 경우 max_input_nesting_level도 낮출 수 있다. 업로드 진행 표시가 필요하지 않다면 session.upload_progress.enabled = 0으로 설정할 수 있다. 이 설정들은 특정 메모리 압박 요인만 제한하며 다른 경로는 남는다.
• 운영 환경에서 display_errors = 0으로 설정하면 PHP 오류가 원격 사용자에게 노출되는 경로를 줄일 수 있다. 지원되는 경우 fatal_error_backtraces = 0은 시연된 치명적 오류 역추적 경로를 제한할 수 있지만, 취약점의 다른 경로까지 막지는 않는다.
• PHP-FPM의 pm.max_requests를 낮추면 작업자를 더 자주 교체해 요청 사이에 손상된 상태가 남는 일을 줄일 수 있다. 다만 성능 비용이 들고 여러 요청에 의존하지 않는 경로는 해결하지 못한다.
• 애플리케이션과 호환된다면 SELinux 또는 AppArmor 정책으로 작업자의 권한과 다른 프로그램 실행을 제한할 수 있다. 이는 공격 영향을 제한하는 방어책이지 모든 악용이나 메모리 노출을 막는 수단은 아니다.

패치 후에는 PHP 권고에 새로 추가된 하드 메모리 제한의 운영상 영향을 검토해야 한다. 제한에 도달하면 프로세스가 종료되고 종료 처리기가 실행되지 않는다. memory_limit, 요청 크기 제한, 애플리케이션의 예상 메모리 사용량을 함께 점검하고, 임시로 memory_limit = -1을 적용했다면 재검토해야 한다. post_max_size는 메모리 예산보다 적절히 낮게 두되 정상 업로드를 지원해야 한다. expose_php = 0은 PHP 버전 노출을 줄이는 선택적 강화 설정이며 PHP2Shell을 해결하지는 않는다.

침해 확인과 참고 자료

비정상적으로 크거나 형식이 잘못된 PHPSESSID 응답 쿠키, 메모리 제한 오류나 반복적인 HTTP 500 응답을 동반한 이례적인 멀티파트 요청, 설명되지 않는 PHP 작업자 충돌·재시작은 조사 단서가 될 수 있다. 그러나 이런 징후만으로 악용을 확정할 수 없고, 징후가 없다고 영향이 없다고 단정할 수도 없다. 일부 공격은 악성 코드 실행 없이 메모리를 노출하며, 취약 경로가 애플리케이션 아래 계층에서 작동해 애플리케이션 로그에 정보가 적을 수 있다. 의심 활동이 관찰되지 않았더라도 업데이트를 적용해야 한다.

기술 분석과 패치 조정 경위는 Wiz Research, OpenAI, Calif, PHP Foundation의 자료에서 확인할 수 있다.