이 글은 Sonatype 공식 블로그의 PHP2Shell Makes PHP Inventory and Patch Ownership Urgent을 에스코어가 공식 파트너로서 한국어로 번역한 콘텐츠입니다.
에스코어 인사이트
PHP2Shell 대응에서는 외부에 노출된 웹서버뿐 아니라 제품과 컨테이너에 포함된 PHP 런타임까지 조사해야 합니다. 설치 버전 확인만으로 끝내지 말고 각 시스템의 담당자, 공급업체별 패치 제공 여부, 적용 결과를 함께 관리하는 것이 중요합니다. 추가로 공개된 CVE-2026-115560의 임시 설정 조치와 공급업체의 완전한 수정 릴리스 적용 계획도 별도로 확인해야 합니다.
•
서비스·컨테이너 이미지·어플라이언스에 포함된 PHP 런타임과 공급 경로를 조사해 자산 목록에 연결합니다.
•
인터넷에 노출된 시스템부터 우선순위를 정하고, 제품·배포판 공급업체의 백포트 적용 여부도 확인합니다.
•
시스템별 조치 책임자와 패치 검증 결과를 기록하며, 즉시 수정하기 어려운 시스템은 임시 보호 조치와 재평가 시점을 관리합니다.
Sonatype 원문 번역
PHP2Shell 대응에는 PHP 설치 현황 파악과 패치 책임자 지정이 시급하다
2026년 10월 23일 업데이트: PHP는 일반적이지 않은 세션 설정에서 발생할 가능성이 낮은 원격 코드 실행(RCE) 경로와 관련된 후속 취약점 CVE-2026-115560을 공개했습니다. PHP는 다음 정기 버그 수정 릴리스가 나올 때까지 session.upload_progress.enabled를 비활성화하도록 권고합니다. 자세한 내용은 Sonatype Guide의 연구 결과 및 권고를 참고하십시오.
핵심 요약
•
PHP2Shell은 PHP의 심각도 '치명적(Critical)' 취약점 두 건인 CVE-2026-109618과 CVE-2026-109619를 가리키는 명칭입니다. 두 취약점 모두 인증되지 않은 원격 코드 실행을 허용할 수 있습니다.
•
PHP 프로젝트는 웹 요청을 처리하는 모든 PHP 설치 환경이 위험에 노출돼 있으며, 특히 mod_php를 사용하는 Apache 구성에서 위험이 가장 크다고 설명합니다. 수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다.
•
조직은 전체 환경에서 PHP 설치 현황을 조사하고, 인터넷에 노출된 시스템을 우선 처리하며, 의심스러운 활동을 모니터링해야 합니다. 패치는 PHP 프로젝트 또는 관련 배포판·제품 공급업체가 제공하는 경로로 적용해야 합니다. 신속히 조치할 수 없는 시스템은 취약점이 완전히 완화될 때까지 오프라인 전환을 고려해야 합니다.
•
2026년 10월 23일 PHP는 별도의 후속 RCE 취약점인 CVE-2026-115560을 공개했습니다. PHP의 권고에 따라 session.upload_progress.enabled를 임시로 비활성화하고, 완전한 수정 사항이 제공되면 해당 PHP 패치를 적용해야 합니다.
PHP2Shell은 PHP 런타임의 치명적 취약점 두 건이다
PHP2Shell은 PHP 내부의 요청 처리 과정에 존재하는 취약점 두 건을 가리킵니다. PHP는 웹사이트와 애플리케이션, 다양한 제품에 사용되므로 영향을 받는 설치 환경을 서로 다른 팀이 관리하거나 각기 다른 공급업체가 제공할 수 있습니다. 지금 시급한 일은 해당 시스템을 모두 찾아 담당자를 지정하고 모든 배포 환경에 수정 사항이 적용됐는지 확인하는 것입니다.
•
CVE-2026-109618은 메모리 부족(out-of-memory) 처리와 관련된 취약점입니다. 내부 데이터가 일부만 초기화된 상태에서 PHP가 요청 처리를 중단한 뒤, 정리 과정에서 해당 데이터를 잘못 처리할 수 있습니다.
•
CVE-2026-109619는 기반 메모리가 해제된 뒤에도 오래된 전역 상태(stale global state)가 남을 수 있는 문제입니다.
•
PHP에 따르면 CVE-2026-115560은 애플리케이션에서 session.serialize_handler를 php_binary 또는 php_serialize로 설정했다가 실행 중 session_start() 호출 전에 php로 변경하고, 세션 업로드 진행 상황 기능을 활성화한 상태에서 발생할 수 있습니다. PHP는 앞서 CVE-2026-109619의 완화책으로 업로드 진행 상황 기능 비활성화를 안내했습니다. 그러나 이 설정만으로 영향을 받는 모든 경로를 차단할 수는 없으며, 상태 초기화 패치가 완전히 포함된 PHP 릴리스를 적용하는 것이 신뢰할 수 있는 해결책입니다.
영향받는 조건에서는 공격자가 인증 없이 원격으로 코드를 실행할 수 있습니다.
Sonatype의 Field CTO인 Ilkka Turunen은 운영 측면에서 무엇을 우선해야 하는지 강조합니다. 핵심은 책임 소재를 명확히 하는 것입니다. 서비스와 제품 어디에 PHP가 사용되는지, 누가 문제 해결을 책임지는지, 수정 사항을 얼마나 빨리 배포할 수 있는지 파악해야 합니다.
어려운 점은 모든 PHP 설치 환경을 찾아내는 일이다
조직은 대외 웹사이트에서 PHP를 사용한다는 사실은 알더라도 내부 포털, 오래된 서비스, 어플라이언스, 런타임이 내장된 소프트웨어의 현황은 충분히 파악하지 못할 수 있습니다. 팀별로 서로 다른 운영체제 배포판, 호스팅 공급업체 또는 서드파티 공급업체를 이용해 PHP를 설치하고 유지보수하기도 합니다.
Turunen은 눈에 보이는 웹사이트와 서비스 바깥까지 조치 범위가 넓어질 것으로 봅니다. PHP는 여러 제품에 내장돼 있으며 기존 환경에도 남아 있습니다. 이처럼 패치를 적용해야 하는 환경이 길게 이어진다는 점을 강조한 것입니다.
완전한 대응을 위해서는 각 런타임을 관리 담당자 및 패치 적용 경로와 연결한 자산 목록부터 작성해야 합니다. 확인 항목은 다음과 같습니다.
•
인터넷에 노출된 시스템과 내부 시스템 중 PHP를 실행하는 곳
•
PHP 버전과 해당 버전의 제공·유지보수 주체
•
PHP 런타임을 포함하는 애플리케이션, 컨테이너, 이미지, 어플라이언스 및 제품
•
조치를 책임지는 사업 또는 서비스 담당자
•
PHP 프로젝트, 운영체제 배포판, 호스팅 공급업체, 기타 공급업체 중 어디에서 수정 패키지를 제공하는지
트래픽이 적은 오래된 애플리케이션, 여전히 접근 가능한 테스트 환경, 중앙 플랫폼 팀 밖에서 유지보수하는 배포 환경처럼 놓치기 쉬운 시스템도 포함해야 합니다. 자산 목록이 불완전하면 취약한 설치 환경이 온라인에 남아 있는데도 조직은 모든 조치를 마쳤다고 잘못 판단할 수 있습니다.
PHP 8.1 이하 버전은 PHP 프로젝트에서 더 이상 업데이트를 제공하지 않습니다. PHP 프로젝트에 따르면 일부 배포판과 장기 지원 공급업체는 수정 사항을 백포트하며, 프로젝트 자체도 일부 오래된 브랜치에 대해 소스 백포트를 공개했습니다. 이러한 버전을 사용하는 조직은 배포판 또는 공급업체에 실제 수정 적용 상태를 확인하거나 지원되는 릴리스로 업그레이드할 계획을 수립해야 합니다. 업스트림 버전 번호만 보고 공급업체가 관리하는 패키지에 수정 사항이 포함됐는지를 단정해서는 안 됩니다.
전체 시스템에 패치를 적용하고 검증하며 모니터링해야 한다
PHP 프로젝트는 수정된 릴리스로 업데이트하는 것만이 문제를 완전히 해결하는 방법이라고 설명합니다. 임시 통제는 특정 공격 경로에 대한 노출을 줄일 수 있고, 웹 애플리케이션 방화벽(WAF)은 해당 장비를 경유하는 트래픽에 추가 보호 기능을 제공할 수 있습니다. Cloudflare는 보호 조치를 배포했으며 고객을 겨냥한 공격 트래픽을 관측했다고 밝히면서 패치 적용을 촉구했습니다.
시스템을 신속하게 수정할 수 없다면 영국 국가사이버보안센터(NCSC)는 취약점이 완전히 완화될 때까지 해당 시스템을 오프라인으로 전환하는 방안을 고려하라고 권고합니다. 반드시 운영을 유지해야 한다면 담당자를 지정하고 임시 보호 조치와 재평가 날짜를 문서화해야 합니다.
Turunen은 AI 시대에 취약점 악용의 속도 역시 빨라졌다며, 인터넷 전반에서 공격이 곧 대규모로 증가할 가능성이 있다고 경고했습니다.
조직이 지금 해야 할 일
PHP2Shell은 조직이 각 환경에서 실행 중인 소프트웨어를 찾아내고, 담당자를 지정하며, 실제로 업데이트할 수 있는지를 시험하는 사건입니다. PHP 프로젝트가 수정 사항을 공개했더라도 다른 공급업체가 관리하는 제품과 서비스에 내장된 런타임까지 업데이트가 전달돼야 위험이 줄어듭니다.
조직은 다음 조치를 수행해야 합니다.
•
PHP가 실행 중인 시스템 목록을 작성하고 인터넷에 노출된 시스템부터 우선 처리합니다.
•
인터넷에 노출된 PHP 시스템에서 의심스러운 활동을 모니터링합니다.
•
PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35로 업데이트하거나 해당 공급업체의 백포트 수정 사항을 적용합니다. PHP를 내장한 제품과 서비스도 포함합니다.
•
특히 PHP 8.1 이하를 사용하는 경우 PHP 프로젝트, 배포판 및 서드파티 공급업체의 보안 권고를 확인합니다.
•
시스템을 신속히 수정할 수 없다면 취약점이 완전히 완화될 때까지 오프라인으로 전환하는 방안을 고려합니다.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide