안녕하세요,
그로메트릭 입니다. 🐸
PHP 기반 웹사이트나 사내 포털, 또는 PHP 런타임을 내장한 제품을 운영하는 조직이라면 절대 가볍게 넘겨서는 안 될 소식입니다.
PHP2Shell은 PHP 런타임에서 확인된 두 건의 치명적 취약점(CVE-2026-109618, CVE-2026-109619)을 묶어 부르는 명칭입니다.
두 취약점 모두 인증 없이 원격 코드를 실행할 수 있는 상태로 이어질 수 있습니다.
PHP 프로젝트는 웹 요청을 처리하는 모든 PHP 설치 환경이 영향 범위에 있으며, 특히 Apache의 mod_php 구성에서 위험이 가장 높다고 밝혔습니다.
소프트웨어 공급망 보안 관점에서, 패치 자체보다 어느 시스템에 PHP가 있고 누가 책임지는지 모르는 상태가 실질적인 비즈니스 리스크로 이어질 수 있는 사안입니다.
*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 작성되었습니다.
PHP2Shell: PHP 인벤토리와 패치 책임 소재 정립이 우선인 이유
요약
- PHP2Shell은 CVE-2026-109618과 CVE-2026-109619 두 건의 PHP 치명적 취약점을 가리키며, 둘 다 인증 없는 원격 코드 실행을 허용할 수 있습니다.
- 수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. 웹 요청을 처리하는 모든 PHP 설치 환경이 위험 대상이며, Apache mod_php 구성이 가장 위험합니다.
- 대응의 출발점은 PHP 인벤토리 작성, 인터넷 노출 시스템 우선 순위 지정, 이상 징후 모니터링, 벤더 경로를 포함한 패치 적용입니다. 즉시 조치가 어려운 시스템은 완전히 완화될 때까지 오프라인 전환을 검토해야 합니다.
- 현재 대응 가이드는 소나타입 가이드의 PHP2Shell 보안 이벤트 페이지에서 추적됩니다.
PHP2Shell은 어떤 취약점이며, 무엇이 문제일까?
PHP2Shell은 PHP 내부 요청 처리 과정에서 발견된 두 취약점(CVE-2026-109618, CVE-2026-109619 )을 가리킵니다.
PHP는 웹사이트, 애플리케이션, 제품 전반에서 쓰이기 때문에 사내 여러 팀이 사용 중이거나 다른 벤더사에서도 사용 중일 수 있습니다. 따라서 가장 시급한 작업은 PHP가 쓰이는 시스템을 모두 찾아내고, 각 시스템의 책임 소재를 분명히 하는 것입니다. 이후 모든 시스템에 패치가 적용됐는지 확인해, 취약한 상태로 남은 PHP가 없도록 해야 합니다.
| 구분 | 취약점 성격 |
| CVE-2026-109618 | 메모리 부족(out-of-memory) 처리와 관련됨. PHP가 내부 데이터가 일부만 초기화된 상태에서 요청을 중단하고, 이후 정리 과정에서 해당 데이터를 잘못 처리할 수 있음 |
| CVE-2026-109619 | 기반 메모리가 해제된 이후에도 오래된 전역 상태(stale global state)가 남아 있는 문제 |
조건이 충족되면 원격 공격자가 인증 없이 코드를 실행할 수 있습니다. 소나타입의 필드 CTO인 일카 투루넨(Ilkka Turunen)은 PHP 사용 위치, 수정 책임 소재, 수정 배포 속도를 언급했습니다.
왜 모든 PHP 설치 위치를 찾는 것이 가장 어려울까?
공개 웹사이트가 PHP를 쓴다는 점은 알고 있어도, 내부 포털, 오래된 서비스, 어플라이언스, 자체 런타임을 번들한 소프트웨어까지는 확인하기 어려운 경우가 많습니다. 운영체제 배포판, 호스팅 업체, 서드파티 벤더 등 설치와 유지보수 경로도 제각각입니다.
투루넨은 조치 범위가 눈에 보이는 웹사이트와 서비스를 넘어설 것으로 예상했습니다. PHP가 다른 제품에 번들되고 구형 환경에 남아 있기 때문에, 패치를 적용해야 하는 환경이 꼬리에 꼬리를 무는 것처럼 이어진다는 설명입니다.
완전한 대응은 각 런타임을 책임 소재와 패치 경로에 연결하는 인벤토리에서 시작됩니다. 다음 항목을 확인해야 합니다.
- PHP를 실행하는 인터넷 노출 시스템과 내부 시스템
- PHP 버전과 공급·유지보수 방식
- PHP 런타임을 포함하는 애플리케이션, 컨테이너, 이미지, 어플라이언스, 제품
- 수정을 책임지는 비즈니스 또는 서비스 책임 소재
- PHP 프로젝트, OS 배포판, 호스팅 업체, 기타 벤더 중 수정 패키지를 제공하는 주체
트래픽이 적은 오래된 애플리케이션, 여전히 접근 가능한 테스트 환경, 중앙 플랫폼 팀 밖에서 관리되는 배포처럼 놓치기 쉬운 시스템도 포함해야 합니다. 불완전한 인벤토리는 조치가 끝났다는 착각을 만들면서 취약한 설치 환경을 온라인에 남겨 둘 수 있습니다.
PHP 8.1 이하는 PHP 프로젝트의 업데이트 대상에서 제외된 상태입니다. 일부 배포판과 장기 지원(LTS) 벤더는 백포트 수정을 제공하고, PHP 프로젝트도 일부 구형 브랜치용 소스 백포트를 공개했습니다. 해당 버전을 쓰는 조직은 배포판이나 벤더에 수정 여부를 확인하거나 지원되는 릴리스로 업그레이드를 계획해야 합니다. 업스트림 버전 번호만으로 벤더가 유지보수하는 패키지의 수정 여부를 판단해서는 안 됩니다.
패치 이후에는 무엇을 검증하고 모니터링해야 할까?
PHP 프로젝트는 수정 릴리스로 업데이트하는 것만이 완전한 해결책이라고 밝혔습니다.
| PHP 브랜치 | 수정 버전 |
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
임시 보호 조치는 특정 공격 경로에 대한 노출을 줄일 수 있습니다. 웹 애플리케이션 방화벽(WAF) 같은 경우는 해당 방화벽을 거치는 트래픽에 추가 보호를 제공할 수 있습니다. 또한, Cloudflare는 보호 기능을 배포했으며 자사 고객을 겨냥한 공격 트래픽을 관측했다고 보고하면서 패치를 권고했습니다.
영국 NCSC(National Cyber Security Centre)는 즉시 수정이 어려운 시스템에 한해 완화될 때까지 오프라인 전환을 검토하라고 권고합니다. 서비스를 유지해야 한다면 책임 소재를 정하고, 임시 보호 조치와 다시 검토할 날짜를 기록해 두어야 합니다.
이번 발견과 대응은 취약점 연구에서 AI가 맡는 역할도 보여줍니다. 월스트리트저널 보도에 따르면 Calif와 Wiz 연구진이 PHP 소스 코드 감사에 AI 도구를 사용했고, 패치가 나올 시점보다 관련 정보가 온라인에 유출되면서 개발자, 연구자, 배포판 관계자가 긴급 보안 패치를 앞당겨 배포했습니다.
투루넨은 AI 시대에 공격 속도도 빨라져 인터넷 전반에서 대규모 공격이 임박했을 가능성이 높다고 경고했습니다.
결론: PHP2Shell 대응은 가시성과 책임 소재 정립에서 시작됩니다
PHP2Shell은 조직이 자신의 환경에서 실행되는 소프트웨어를 찾고, 책임지고, 업데이트할 수 있는지를 테스트하는 도구입니다. PHP는 수정 패치를 공개했지만, 릴리스는 업데이트가 다른 벤더가 유지하는 제품 및 서비스 내 모든 런타임에 도달할 때만 위험을 줄여줍니다.
조직이 취해야 할 조치는 다음과 같습니다.
- PHP를 실행하는 인벤토리 시스템(우선순위는 인터넷에 연결된 시스템)
- 인터넷에 연결된 PHP 시스템을 대상으로 하는 의심스러운 활동 모니터링
- PHP(8.5.12, 8.4.27, 8.3.36, 8.2.35)로 업데이트 또는 해당 벤더의 백포트 적용
- PHP 8.1 이하 버전 실행 시, PHP, 배포판, 서드파티 벤더 권고 확인
- 오프라인 전환 고려
최신 내용과 어드바이저리 링크는 PHP 공식 보안 어드바이저리에서 확인할 수 있습니다.
출처
소나타입 블로그 : PHP2Shell Makes PHP Inventory and Patch Ownership Urgent
'Security Insights & Trends' 카테고리의 다른 글
| AI 코딩 시대의 개발 생산성, 릴리즈 뒤 의존성 정리 작업의 효율성 (0) | 2026.10.21 |
|---|---|
| 2026 3분기 오픈소스 악성코드 인덱스, 침해가 연쇄/확산되는 구조 (0) | 2026.10.16 |
| TensorLake 악성 릴리즈 npm 공급망 공격 - 설치 한 번에 자격증명 위협까지 (0) | 2026.10.14 |
| AI 코딩 에이전트가 바꾸는 SDLC: 오픈소스 의존성 거버넌스 전략 (0) | 2026.10.02 |
| CI/CD 자격증명 탈취: 악성 오픈소스 패키지가 설치 시점에 노리는 권한 (0) | 2026.09.30 |