서론
2026년 10월 21일, PHP에 존재하는 두 가지 심각한 취약점이 공개되었습니다. 이들이 결합하여 'PHP2Shell'이라는 문제로 발생하며, 조건이 갖춰질 경우 외부에서 서버 상에 부정한 코드를 실행할 위험이 있습니다. 정보처리진흥기구(IPA) 역시 다음 날인 22일에 주의 환기를 발표했습니다. 이후에도 추가적인 발표가 있는 것으로 보이지만, 여기서는 PHP란 무엇이며 어떤 구조로 사용되는지에 초점을 맞춰 설명하겠습니다.
1. PHP란? ~ 웹사이트가 표시되기까지의 구조
PHP라는 이름을 들어본 적이 있어도 실제로 어떤 처리를 하는지 잘 모르는 분들도 있을 것입니다. PHP는 간단히 말해, 여러분이 자주 보는 HTML을 조합하는 메커니즘입니다.
예를 들어, 상품 번호를 지정하면 상품명과 재고가 표시되는 웹사이트를 생각해 봅시다. 이용자가 브라우저로 상품 페이지에 접속하면, 내부적으로 여러 처리 과정들이 연계됩니다.
商品ページが表示されるまでの仕組み
위는 브라우저로부터 요청을 받아 서버 측의 응답이 돌아와 브라우저에 결과가 표시되기까지의 동작 예시를 보여줍니다.
- 브라우저에서 웹 서버로 상품 페이지 표시를 요구합니다.
- 웹 서버는 PHP가 필요한 처리를 애플리케이션 서버로 전달합니다.
- PHP 프로그램이 데이터베이스(DB)에 상품 정보를 문의합니다.
- 데이터베이스로부터 상품 정보가 반환됩니다.
- PHP가 획득한 정보를 기반으로 표시용 HTML을 만들고, 웹 서버로 돌려줍니다.
- 웹 서버가 브라우저에 응답하고, 상품 페이지가 표시됩니다.
2. 웹 서버와 Apache의 역할
웹 서버는 브라우저로부터 HTTP 요청을 받아 HTML이나 이미지를 반환하는 소프트웨어 또는 그러한 기능을 수행하는 서버를 말합니다. 대표적인 웹 서버 소프트웨어로는 Apache HTTP Server(Apache)나 Nginx가 있습니다.
Apache는 브라우저의 요구를 받는 창구 역할을 합니다. 이미지 같은 정적 파일은 직접 반환할 뿐만 아니라, 상품 검색처럼 프로그램 처리가 필요한 경우에는 설정에 따라 PHP로 처리를 넘겨줍니다. PHP가 상품 정보를 이용해 HTML을 생성하면, Apache는 그 결과를 브라우저에게 돌려줍니다.
3. PHP의 역할과 실행 장소
PHP는 웹 애플리케이션의 서버 측 처리(Server-side processing)에 사용되는 프로그래밍 언어입니다. 폼으로 전송된 값 받기, 데이터베이스 검색, 로그인 처리, 주문 등록, HTML 생성 등에 활용할 수 있습니다. PHP로 작성한 프로그램을 실행하는 메커니즘을 PHP 런타임(실행 환경)이라고 부릅니다.
아래 그림과 같이, PHP가 동작하는 장소는 시스템에 따라 다릅니다.
PHPをWebサーバーと同居させる構成と分離する構成
PHP는 보안 정책에 따라 대략 구성 A처럼 웹 서버 위에 배치하거나, 구성 B처럼 웹 서버 뒤쪽의 애플리케이션 서버 위에 배치합니다.
구성 A는 Apache와 PHP를 같은 서버에서 구동하는 예시입니다. Apache에 PHP를 결합하는 mod_php 방식이나, 동일 호스트 상에서 PHP-FPM을 별도 프로세스로 구동하는 방식이 있습니다. 그림에서는 mod_php를 예시로 들었습니다.
구성 B는 DMZ(비무장지대)에 웹 서버를 두고, PHP의 실행 환경과 프로그램을 내부 애플리케이션 서버에 두는 예시입니다. 웹 서버에서 PHP-FPM으로 처리를 넘겨줍니다.
4. 간단한 PHP 프로그램으로 동작을 알아보기
예시로, 상품 번호로부터 재고를 표시하는 프로그램을 살펴보겠습니다. 실제 웹사이트에서는 데이터베이스를 참조하는 경우가 많지만, 여기서는 언어의 메커니즘이 잘 보이도록 상품 데이터를 프로그램 안에 준비했습니다.
product.php라는 파일에 다음 코드를 작성합니다.
<?php
$productId = $_GET['id'] ?? 'A001';
$products = [
...
브라우저에서 https://example.com/product.php?id=A001에 접속하면, PHP는 URL의 id를 받아 해당 상품을 찾고 「상품명: 노트북 PC」「재고수: 5개」를 표시하기 위한 HTML을 생성합니다. id=A002로 바꾸면 마우스 정보가 표시됩니다.
이 예시에서는 PHP 프로그램이 데이터를 선택하고 HTML을 만들었습니다. 웹 서버는 통신 접수와 응답을 담당합니다. 실제로 데이터베이스에 연결하는 경우에도, 마찬가지로 PHP 프로그램이 문의 처리를 담당하게 됩니다.
5. PHP2Shell에서 무슨 일이 일어났나
이번 취약점은 상기된 product.php와 같은 개별 업무 프로그램을 실행하는 PHP 런타임 내부에서 발생했습니다. 이번에 발표된 두 가지 문제는 다음과 같습니다.
CVE-2026-109618는 메모리 부족(Out of Memory)이 발생했을 때의 오류 처리 문제입니다. 특정 타이밍에 메모리 확보에 실패하면, 초기화가 불완전한 내부 데이터를 후속 처리가 다루게 되어 메모리 파괴로 이어질 가능성이 있었습니다.
CVE-2026-109619는 요청을 처리한 후의 내부 상태와 관련된 문제입니다. 오류로 인해 정리 작업이 중단되면, 해제된 메모리에 대한 참조가 남아있을 수 있습니다. 이후 처리가 이 참조를 사용하게 되면 문제가 발생합니다. (이는 'Use After Free(해제된 메모리 사용)'라고 불립니다.)
상품 재고 사이트의 예로 돌아가 봅시다. 일반적으로 웹 서버에서 PHP로 전달된 상품 표시 요청을 처리하고, 재고 정보를 반환합니다. 그러나 조작된 요청에 의해 PHP 런타임 내부 처리가 비정상적으로 발생하면, 조건에 따라 상품 표시와 관계없는 부적절한 코드가 실행될 위험이 있습니다.
예를 들어 구성 A에서 Apache에 mod_php를 사용하는 경우, PHP Foundation은 애플리케이션의 PHP 코드가 실행되기 전에 성립하는 공격도 실증되었다고 설명했습니다. 또한, 구성 B의 PHP-FPM에서도 애플리케이션 측 처리 경로를 통한 원격 코드 실행이 확인되었습니다.
따라서 일반적으로 위험도가 낮다고 여겨지는 구성 B조차 이번 취약점의 영향을 받게 됩니다. 수정 대상은 실제로 PHP를 실행하는 런타임입니다. 부적절한 코드가 실행되었을 경우 영향은 해당 PHP 프로세스에 부여된 권한이나 주변 접근 제어 등에 따라 다르지만, 정보 읽기나 변조, 서비스 중단 등으로 이어질 가능성이 있습니다.
6. 수정 버전 공개로 일단락되는가?
PHP 개발사에서는 2026년 10월 21일에 수정 버전을 공개했습니다.
패치가 공개되었다고 해서 패키지나 컨테이너 이미지가 즉시 사용 가능한 것은 아닙니다. 또한, 보안 문제를 수정한 업데이트 버전에도 다른 결함이 포함될 가능성이 있습니다.
(10/26 기준으로 이미 새로운 취약점이 확인되었습니다)
7. 현실적인 대응 ~ 패치를 적용하는 것만으로는 충분하지 않다
기업 시스템에서는 PHP를 업데이트할 때 여러 가지 확인 과정이 필요합니다.
단지 예시일 뿐이지만, 적어도 다음과 같은 확인이 필요합니다.
| 작업 | 확인할 내용 |
|---|
| 영향 조사 | PHP가 어떤 호스트, 컨테이너, 애플리케이션, 제품에서 구동되고 있는지 |
| ... | |
게다가 동일 계열 내의 보안 업데이트와 대규모 버전 업그레이드를 나누어 생각해야 합니다. 예를 들어 PHP 8.4.26에서 8.4.27로 업데이트하는 경우라면 일반적으로 호환성이 고려되므로 반드시 프로그램을 다시 작성할 필요는 없습니다. 그럼에도 불구하고, 환경 차이나 회귀 결함(regression bug)에 대비한 테스트가 필요합니다.
PHP 7 계열 등 오래된 환경에서 지원되는 계열로 이전하는 경우에는 폐기된 함수나 동작 사양, 라이브러리/확장 모듈의 대응 상황을 확인해야 합니다. 경우에 따라서는 PHP 코드나 주변 인터페이스의 개修(개수), 그리고 더 넓은 범위의 테스트가 필요합니다.
이번 재고 표시 예시라면 상품 검색과 HTML 표시만 확인하는 것으로 충분할 수도 있습니다. 하지만 실제 업무 시스템에서는 주문 등록이나 결제, 외부 시스템과의 연결, 야간 배치 등이 연동됩니다. 프로그램에 수정 사항을 가하지 않았더라도 실행 환경을 변경하면 영향이 없는지 확인할 필요가 있습니다.
중대한 취약점이 공개된 상황에서 일반적인 시스템 개수와 동일한 기간을 들여 검증을 계속하는 것 역시 위험합니다. 업데이트까지의 임시 대책이나 접근 제한을 검토하고, 필요한 경우 외부 공개 중단도 필요합니다. 대응 우선순위와 테스트 범위를 가늠하는 것이 현장에서 어려운 판단이 됩니다.
요약
이번 PHP2Shell은 웹 애플리케이션의 기반이 되는 PHP 런타임 내부에서 발견된 중대한 취약점이었습니다. 상품 재고 표시와 같은 PHP 프로그램이 올바르게 작성되었더라도, 그 실행 환경의 결함으로 인해 시스템에 위험이 미칠 수 있습니다.
패치 적용에는 확보 및 배포 메커니즘, 다른 소프트웨어와의 호환성, 업무 테스트, 롤백 준비 등이 관련됩니다. 안전한 상태로 서비스를 제공하기까지는 많은 공정이 필요합니다.
AI의 악용으로 인해 이러한 대응이 빈번하게 발생하지 않기를 바랄 뿐입니다.
