Reddit

PHP2Shell: Google and Mandiant Warn That PHP Servers May Remain Vulnerable After Installing Patches

PHP2Shell: 패치를 설치해도 PHP 서버가 취약한 상태로 남을 수 있다고 Google과 Mandiant가 경고합니다

PHP 핵심 런타임의 두 취약점은 인증 없이 원격 코드 실행과 메모리 노출로 이어질 수 있으며, CVSS 점수는 각각 9.2입니다. 패치 설치만으로는 실행 중인 PHP 프로세스가 바뀌지 않을 수 있어, 영향을 받는 서비스 재시작과 취약 버전 업그레이드가 필요합니다.

에디터 노트

패키지 버전 확인과 실제 서비스 재시작을 별개로 다룬 점이 이 권고에서 가장 실무적인 대목입니다. Google은 실행 중인 worker가 취약한 라이브러리를 계속 메모리에 보유할 수 있다고 설명하고, php-fpm과 웹 서버 등 요청을 처리하는 프로세스를 직접 재시작하라고 구체적으로 적습니다. 컨테이너와 서버리스 서비스도 자동 업데이트 설정 여부에 따라 재배포가 필요하므로, 설치된 버전만 확인해서는 조치 완료 여부를 판단하기 어렵습니다. Reddit 댓글은 이 절차가 기본이라는 반응과 재시작이 운영 중단을 낳아 결정이 지연된다는 경험담을 함께 전합니다. 특히 고가용성 구성과 순차 재시작을 언급한 댓글은 보안 조치와 서비스 가용성 사이의 운영 책임을 짚지만, 각 조직의 구성이나 실제 공격 피해를 입증하지는 않습니다. Google의 권고도 모든 환경에 같은 재시작 절차를 제시하지 않고, 플랫폼별로 재배포와 자동 업데이트 조건을 나눕니다. 따라서 점검 대상은 패키지 버전뿐 아니라 실행 중인 프로세스와 이미지, 배포 경로까지 포함합니다. 침해가 의심되면 재시작 전에 메모리 증거를 보존하라는 조건도 함께 제시됩니다.

AI 요약

Google과 Mandiant는 PHP 핵심 런타임에서 발견된 CVE-2026-109618과 CVE-2026-109619에 대응하는 방법을 안내합니다. 두 취약점은 메모리 할당 오류와 해제된 메모리의 상태가 다음 요청까지 남는 문제에서 비롯됩니다. Google Cloud의 Cloud Armor와 탐지 도구는 노출을 줄이고 영향을 찾는 보완책이며, 근본 조치로는 패치 버전으로 업그레이드하고 실제 웹 서비스를 재시작해야 합니다.

취약점과 영향 범위

두 취약점 모두 CVSS 9.2의 Critical 등급입니다. CVE-2026-109618은 메모리 부족 상황에서 PHP가 요청 데이터를 완전히 초기화하기 전에 중단되고, 정리 과정이 잘못된 데이터를 유효한 것으로 다룰 수 있는 문제입니다. CVE-2026-109619는 요청에 속한 내부 상태가 메모리 해제 뒤에도 남아, 같은 작업자 프로세스가 다음 요청에서 초기화 전에 이를 참조할 수 있는 문제입니다. PHP 5.4부터 8.5.11까지가 취약 범위이며, PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12에서 수정됐습니다. 지원 종료된 PHP 8.1 이하에는 PHP 프로젝트가 수정 버전을 내놓지 않습니다.

업그레이드와 재시작

Google은 PHP 8.2 이상으로 올린 뒤 애플리케이션을 다시 배포하라고 안내합니다. App Engine standard의 지원 런타임과 자동 기본 이미지 업데이트를 켠 일부 서버리스 서비스는 업데이트가 자동으로 적용됩니다. 반면 App Engine flexible, 직접 만든 컨테이너 이미지, 자동 업데이트를 사용하지 않는 Cloud Run 서비스와 함수는 재빌드 또는 재배포가 필요합니다. PHP 8.1 이하의 미지원 런타임은 자동 패치 대상이 아닙니다.

패키지 파일을 업데이트해도 실행 중인 worker가 메모리에 올려 둔 취약한 libphp.so나 php-fpm 바이너리가 그대로 남을 수 있습니다. 따라서 php-fpm, Apache, FrankenPHP, OpenLiteSpeed 등 실제 요청을 처리하는 서비스와 supervisor가 관리하는 worker를 재시작해야 합니다. 의심스러운 활동이 있으면 재시작 전에 메모리 포렌식 자료를 확보하라고 권고합니다. 재시작하면 휘발성 힙 증거가 사라지기 때문입니다. 제3자 RPM 미러 대신 공식 배포판 보안 저장소나 공식 소스 빌드를 확인하라는 지침도 포함됐습니다.

임시 완화와 탐지

Cloud Armor 관리 규칙은 인터넷에 노출된 PHP 애플리케이션의 방어를 보완합니다. 파일 업로드와 RFI 규칙을 적용하고, 검사 한도를 넘는 큰 요청 본문이 백엔드에 전달되지 않도록 별도 정책을 설정하라고 안내합니다. 다만 WAF 규칙은 패치와 재배포를 대신하지 않습니다.

업그레이드가 늦어지면 전역 php.ini에 설정을 두고 모든 worker를 재시작하며, php-fpm의 pm.max_requests를 1로 설정해 요청마다 worker를 교체하는 방안이 제시됩니다. display_errors를 끄는 것만으로 메모리 노출을 막을 수는 없습니다. 프록시와 WAF에서는 업로드가 필요 없는 경로의 multipart 요청, chunked 전송, 지나치게 큰 본문과 복잡한 폼 필드를 제한하고, PHPSESSID 형식도 검증하라고 권합니다.

PHP worker를 비특권 계정으로 실행하고 웹 루트를 읽기 전용으로 설정하며, cgroup으로 메모리를 제한하는 운영체제 수준의 격리도 안내합니다. PHP 서버의 외부 통신과 셸 실행을 제한하는 방안도 포함됩니다. Google Cloud의 Security Command Center, Artifact Analysis, Threat Detection과 Google Security Operations의 Mandiant 탐지 규칙은 취약한 자산과 침입 흔적을 찾는 데 활용할 수 있습니다.

Reddit 반응

  • @T_Thriller_T — 반복해서 말하는 것보다 낫긴 합니다. 하지만 패치한 뒤에는 최소한 관련 서비스를 재시작해야 합니다. 많은 경우에는 머신도 재시작해야 합니다. 사이버 보안 전문가라면 기본적으로 알아야 합니다.
  • @BTC-brother2018 — 맞습니다. 실행 중인 프로세스가 메모리에 올린 소프트웨어는 패키지 업데이트만으로 바뀌지 않을 수 있다는 점을 경험 많은 시스템 관리자라면 알아야 합니다. 다만 모든 소프트웨어 업데이트가 서비스 재시작을 요구하는 것은 아닙니다. 일부 패키지는 재시작 없이 업데이트할 수 있지만, 다른 패키지는 패치 코드를 불러오려면 프로세스를 재시작해야 합니다. 운영 환경에서는 서비스 중단을 피하려고 관리자가 재시작을 미루기도 합니다.
  • @DMmeYourMCbuilds — 운영팀과 보안팀이 서비스와 서버 재시작의 위험을 두고 부딪히는 오래된 문제입니다. 사이버 보험사나 FBI에 연락해야 할 상황이 생길 수 있는데도 IT 관리자나 임원 중 재시작 결정을 책임지려는 사람을 아직 만나지 못했습니다. 다들 매출 이야기를 합니다. 랜섬웨어 피해를 입으면 매출을 얼마나 올릴 수 있겠습니까?
  • @beren0073 — 고가용성 구조를 승인하지 않았을 때 매출 손실을 감수하기로 선택한 셈입니다. 당사자들은 그렇게 받아들이지 않겠지만요. 테스트 후 노드를 순차 재부팅하는 방법은 새롭지 않습니다. 다만 최소한의 여유만 두고 운영하는 회사가 많습니다.
  • @faultypacket — Debian, Ubuntu, cPanel, HestiaCP 관리자들이 놓치기 쉬운 점이 하나 있습니다. apt upgrade로 php8.x-fpm을 업데이트해도 master PHP-FPM worker pool을 정상적으로 다시 불러오지 않거나, 컨테이너나 chroot 안의 프로세스가 메모리에서 이전 inode를 계속 참조하면 dpkg -l에 패치 버전이 표시돼도 엔드포인트는 취약할 수 있습니다. 실행 중인 master 프로세스 시작 시각을 apt 기록과 대조하고, 웹에서 쓸 수 있는 캐시나 업로드 디렉터리에 패치 전 웹셸이 남지 않았는지도 확인하세요.
  • @ramriot — 요약하면 문제를 완전히 해결하려면 껐다가 다시 켜야 합니다.

원문: Google Cloud / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗