PHP2Shell 보안 취약점의 PHP 5.2.17 영향 분석 및 대응 현황

2026년 10월 21일, PHP 실행 엔진의 메모리 관리와 요청 처리 과정에서 발생할 수 있는 두 건의 보안 취약점(CVE-2026-109618, CVE-2026-109619)이 공개되었습니다. 이번 취약점은 PHP2Shell이라는 명칭으로 알려졌으며, 특정 조건에서 메모리 손상이나 정보 노출, 원격 코드 실행(RCE) 등으로 이어질 가능성이 제기되면서 국내외 보안업계의 관심이 집중되고 있습니다.

리프아이티는 취약점 공개 직후 관련 보안 권고와 기술 분석 자료를 검토하고, 현재 운영 중인 e-Book 솔루션에 미치는 영향을 확인하기 위한 자체 분석에 착수하였습니다. 특히 PHP 버전이나 서버 설정값만으로 영향 여부를 판단하지 않고, PHP 5.2.17 원본 소스코드와 공식 수정 코드를 함수 및 행 단위로 직접 대조하여 취약점의 발생 조건과 내부 구현 차이를 분석하였습니다.

이번 글에서는 해당 분석을 통해 확인한 주요 내용과 현재 진행 중인 대응 방향을 안내드립니다.

PHP2Shell, 어떤 취약점인가?

CVE-2026-109618 : 메모리 부족 시 내부 자료구조 손상

PHP가 HTTP 요청을 처리하는 도중 메모리 부족(Out of Memory, OOM)이 발생하면 실행 흐름이 비정상적으로 중단될 수 있습니다. 이 과정에서 일부 내부 자료구조가 완전히 초기화되지 않은 상태로 남고, 이후 종료 처리 과정에서 해당 자료구조에 접근하면서 메모리 손상이 발생할 가능성이 있습니다.

CVE-2026-109619 : 요청 간 전역 상태 관리 문제

PHP는 동일한 서버 프로세스에서 여러 HTTP 요청을 처리할 수 있습니다. 이전 요청에서 사용한 메모리가 해제된 이후에도 관련 포인터가 남아 있고, 다음 요청에서 해당 포인터를 다시 참조하면 해제된 메모리에 접근하는 Use-After-Free(UAF) 문제가 발생할 수 있습니다. 두 취약점 모두 특정 요청이나 오류 발생 조건이 충족되어야 하며, 실제 악용 가능성은 PHP 버전별 내부 구현과 서버 운영 환경에 따라 달라질 수 있습니다.

이번 취약점은 인공지능(AI)을 활용한 보안 연구의 대표적인 사례이기도 합니다. Wiz Research와 Calif Research 등은 AI 기반 코드 분석과 검증을 활용하여 오랫동안 발견되지 않았던 PHP 실행 엔진의 취약점을 조사하고 실제 공격 가능성을 입증하였습니다. 이는 AI가 소프트웨어 개발뿐 아니라 복잡한 보안 취약점의 발견과 검증에도 중요한 역할을 할 수 있음을 보여줍니다.

PHP 5.2.17도 이번 취약점의 영향을 받을까?

이번 PHP2Shell 취약점과 관련하여 Google Cloud가 공개한 기술 분석에서는 PHP 5.4부터 PHP 8.5.11까지를 취약점 영향 버전(Vulnerable versions)으로 명시하고 있습니다.

다만 PHP 버전에 따라 내부 구현과 공격 경로에 차이가 있으며, 주요 취약 코드와 관련 기능의 도입 시점은 다음과 같습니다.

취약점	주요 분석 대상	관련 코드 · 기능 도입 시점
CVE-2026-109618	해시 테이블(HashTable) 처리 구조	PHP 7.3 이후
CVE-2026-109619	직렬화 관련 코드 경로	PHP 7.1 이후
CVE-2026-109619	세션 업로드 진행률 관리 기능	PHP 5.4 이후

이번 PHP2Shell 취약점에 대응하기 위해 PHP 개발팀은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 버전에 공식 보안 패치를 적용하여 배포하였습니다. 그러나 PHP 5.2.17을 비롯한 공식 지원이 종료된 구형 버전에는 보안 패치가 제공되지 않았으며 지원되는 최신 PHP 버전으로의 업그레이드가 권고되고 있습니다.

그러나 PHP 5.2.17과 같은 오래된 레거시 환경에서는 최신 버전으로의 업그레이드가 단순히 프로그램 교체만으로 해결되지 않습니다. PHP 버전 간 문법과 함수, 내부 동작 방식이 크게 달라졌기 때문에 기존 애플리케이션의 상당 부분을 수정하거나 새로 개발 해야하며 이에 따른 호환성 검증과 서비스 안정성 확보에도 상당한 시간과 노력이 필요합니다.

이에 리프아이티는 공식 보안 패치의 변경 사항을 분석하고, 해당 수정 내용을 PHP 5.2.17 환경에 맞게 이식(Backport)할 수 있는지 검토하기 위한 소스코드 역분석(Reverse Engineering)을 진행하였습니다.

이를 위해 PHP 5.2.17 원본 소스코드와 공식 보안 패치의 변경 사항을 비교하고, 메모리 할당 및 해제, 해시 테이블 처리, 파일 업로드, 세션 관리, 요청 초기화 및 종료 과정 등 주요 실행 경로를 분석하였습니다.

이번 분석은 공개된 취약점의 발생 원인이 PHP 5.2.17에도 존재하는지 확인하고, 필요한 경우 레거시 환경에 적용할 수 있는 보완 방안을 마련하기 위한 사전 기술 검토입니다. 주요 분석 대상은 다음과 같습니다.

분석 영역	주요 확인 사항
해시 테이블	메모리 할당 및 내부 자료구조 등록 순서
메모리 관리자	메모리 부족 발생 시 오류 처리 및 실행 중단
파일 업로드	요청 데이터 처리와 임시 파일 관리
세션 관리	업로드 진행률 기능 및 세션 상태 초기화
요청 수명 관리	요청 종료 후 전역 포인터 해제 및 재초기화

1. 해시 테이블 처리 구조의 차이 확인

공개된 CVE-2026-109618의 대표적인 공격 경로 중 하나는 해시 테이블에서 새로운 항목을 등록하는 과정과 관련되어 있습니다. 일부 PHP 버전에서는 내부 항목 수를 먼저 증가시킨 이후 메모리를 할당하는 구조가 존재하며, 할당에 실패하면 실제 데이터와 관리 정보 사이에 불일치가 발생할 수 있습니다.

반면 PHP 5.2.17의 Zend/zend_hash.c를 분석한 결과, 새로운 버킷과 키 저장 공간을 먼저 할당하고 데이터를 초기화한 다음 해시 테이블에 연결하는 구조가 확인되었습니다. 또한 해시 테이블 확장과 재배치를 담당하는 zend_hash_do_resize(), zend_hash_rehash() 함수에서도 공개된 대표 공격 경로와 동일한 처리 순서상의 결함은 확인되지 않았습니다.

이는 PHP 5.2.17의 해시 테이블 구현이 공개된 특정 메모리 손상 경로와 구조적으로 다르다는 사실을 보여줍니다. 다만 다른 자료구조나 확장 모듈까지 포함한 모든 메모리 할당 경로의 안전성을 입증한 것은 아닙니다.

2. 세션 업로드 진행률 기능의 부재

공개된 공격 사례 중에는 파일 업로드 과정에서 세션 진행 상태를 관리하는 session.upload_progress 기능을 활용하는 경로가 포함되어 있습니다. 해당 기능은 PHP 5.4.0 소스에서 확인되지만, PHP 5.2.17 원본에는 내장되어 있지 않습니다. 실제 PHP 5.2.17의 ext/session/session.c와 main/rfc1867.c를 분석한 결과에서도 해당 기능을 세션 처리와 연결하는 내장 구현은 확인되지 않았습니다.

따라서 공개된 세션 업로드 진행률 기반의 공격 경로는 PHP 5.2.17에서 동일한 방식으로 성립하지 않습니다. 그러나 PHP 5.2.17에도 일반적인 파일 업로드 및 세션 처리 기능은 존재하므로, 다른 경로에서 발생할 수 있는 메모리 관리 문제는 별도로 검토해야 합니다.

3. 메모리 부족 및 요청 종료 과정의 추가 검증 필요

PHP 5.2.17에서도 메모리 부족 오류가 발생하면 zend_mm_safe_error()와 zend_bailout()을 통해 실행 흐름이 중단될 수 있습니다. 또한 파일 업로드 과정에서 생성한 일부 전역 상태는 요청 종료 시 해제되지만, 관련 포인터가 즉시 NULL로 초기화되지 않는 구간도 확인되었습니다. 정상적인 후속 요청에서는 해당 상태를 다시 초기화하는 처리가 존재합니다.

다만 요청 초기화가 완료되기 전에 오류가 발생하는 예외적인 상황에서는 이전 요청의 상태가 어떻게 처리되는지 추가 검증이 필요합니다. 이는 공개된 공격 경로가 PHP 5.2.17에서 그대로 성립한다는 의미가 아니라, 동일 계열의 메모리 관리 문제가 다른 실행 경로에서도 발생할 수 있는지 확인해야 한다는 의미입니다.

소스코드 분석 결과와 현재 판단

이번 분석에서는 PHP 5.2.17의 핵심 소스 파일 7개를 공식 저장소의 관련 코드 및 보안 패치와 비교하고, 주요 함수의 호출 관계와 메모리 할당 실패 시 실행 흐름을 검토하였습니다. 그 결과, 현재 공개된 주요 공격 기법에서 이용하는 일부 코드와 기능이 PHP 5.2.17에는 존재하지 않거나, 내부 구현 방식이 구조적으로 다르다는 점을 확인하였습니다.

특히 해시 테이블의 메모리 할당 및 항목 등록 순서와 세션 업로드 진행률 기능을 이용하는 공격 경로는 PHP 5.2.17의 기본 구현에 동일하게 적용되지 않는 것으로 분석되었습니다.

취약점	PHP 5.2.17 분석 결과	판정
CVE-2026-109618	공개된 특정 해시 테이블 손상 경로와 구조적 차이 확인	판단 보류
CVE-2026-109619	세션 업로드 진행률 기반 공격 경로 부재 확인, 전역 상태 관리 추가 검증 필요	판단 보류

또한 PHP 5.2.17은 공식 지원이 종료된 버전으로, 이번 취약점에 대응하는 별도의 보안 패치가 제공되지 않았습니다. 최신 PHP에 적용된 보안 패치를 구형 버전에 이식하는 백포팅(Backporting)도 검토하였으나, 버전 간 내부 구조와 실행 방식의 차이로 인해 기존 패치를 그대로 적용하기 어려운 상황입니다.

특히 공개된 주요 공격 경로와 PHP 5.2.17의 구현이 서로 다른 부분을 확인하였기 때문에, 단순히 최신 버전의 수정 코드를 이식하기보다는 실제 취약점 발생 조건이 존재하는지 먼저 규명할 필요가 있다고 판단하였습니다.

현재까지 검토한 특정 공격 경로에서는 PHP 5.2.17의 구현상 차이가 확인되었으며, 해당 경로가 동일하게 성립한다는 근거는 확인되지 않았습니다. 다만 이번 검토는 정적 소스코드 분석에 기반한 것으로, 다른 실행 경로를 통한 영향 가능성까지 완전히 배제할 수는 없습니다.

이에 리프아이티는 확인된 분석 결과를 바탕으로 추가 검증과 레거시 환경에 적용 가능한 보안 보완 방안을 검토하고 있습니다.

운영 환경에 대한 보안 대응

이번 PHP2Shell 취약점과 관련하여 보안 연구기관에서는 PHP의 메모리 제한과 HTTP 요청 본문 크기의 관계를 메모리 부족 오류를 유발할 수 있는 주요 조건 중 하나로 설명하고 있습니다. 특히 memory_limit과 post_max_size 설정 및 요청 데이터의 처리 방식에 따라 메모리 부족(Out of Memory, OOM) 오류가 발생할 가능성이 있습니다.

다만, 관련 설정값을 즉시 축소할 경우 정상적인 콘텐츠 제작 기능에 영향을 주거나 서비스 장애를 유발할 수 있으며, 메모리 제한값을 변경하는 것만으로 PHP 실행 엔진의 근본적인 취약점이 해결되는 것도 아닙니다. 이에 리프아이티는 다음 사항을 중심으로 보안 대응을 검토하고 있습니다.

PHP 및 Apache 설정과 파일 업로드 처리 구조 점검
공개된 공격 조건과 현재 운영 환경의 차이 분석
대용량 파일 업로드, 콘텐츠 제작 및 동시 접속 환경에서 설정 변경에 따른 영향 검증
접근 제어 및 웹방화벽(WAF) 등 보완적 보안 조치 검토
공식 보안 권고와 추가 기술 분석 결과 지속 확인

이러한 조치는 기존 서비스의 정상적인 운영과 안정성을 함께 고려하여 충분한 검증을 거친 후 적용할 계획입니다. 리프아이티는 이번 취약점 공개 이후 공식 보안 자료 검토와 PHP 5.2.17 소스코드 분석을 통해 실제 영향 가능성과 대응 방안을 검토해 왔으며, 향후 새로운 기술적 근거가 확인되는 경우 분석 결과를 재평가하고 필요한 보안 조치를 보완해 나갈 예정입니다.

PHP 업그레이드와 차세대 플랫폼 전환

이번 취약점에 대한 근본적인 대응은 보안 수정이 적용된 PHP 버전으로 업그레이드하는 것입니다. 그러나 앞서 설명한 것처럼 PHP 5.2에서 최신 버전으로의 전환은 기존 소스코드 전반에 대한 수정과 호환성 검증이 필요하며, 사실상 시스템을 재개발하는 수준의 작업이 요구될 수 있습니다.

리프아이티 역시 이러한 기술적 한계를 인지하고 있었으며, 이번 취약점이 공개되기 이전부터 기존 PHP 기반 시스템을 대체하기 위한 차세대 플랫폼 개발을 진행해 왔습니다.

PHP를 이어가며 버전을 높이는 방식보다는 최근 소프트웨어 산업에서 널리 활용되는 현대적인 개발 기술과 설계 방식을 도입하여, 기존 시스템의 구조적 한계를 개선하고 장기적인 유지보수성과 보안성을 확보하는 방향을 선택하였습니다.

현재 새로운 기술 기반의 차세대 e-Book 솔루션을 개발 중이며, 2027년 상반기 상품화를 목표로 하고 있습니다. 다만 기존 기능의 이관과 고객사별 운영 환경에 대한 호환성 검증, 서비스 안정성 확보 등이 필요한 만큼 실제 적용 일정은 개발 및 검증 결과에 따라 달라질 수 있습니다.

차세대 플랫폼 전환과 별개로, 기존 PHP 기반 시스템에 대해서도 필요한 보안 점검과 대응을 지속할 예정입니다.

향후 대응 방향

이번 PHP2Shell 취약점에 대한 소스코드 분석을 통해 PHP 5.2.17과 공개된 주요 공격 경로 사이의 구조적 차이를 확인하였습니다. 이는 실제 소스코드의 처리 방식과 실행 흐름을 비교하여 확보한 기술적 근거이지만, 두 취약점에 대한 최종적인 비영향 판정을 의미하지는 않습니다.

리프아이티는 충분한 검증 없이 안전성을 단정하거나, 반대로 실제 영향 여부가 확인되지 않은 상황에서 불필요한 조치로 서비스 안정성을 저해하는 것 모두 경계하고 있습니다. 앞으로도 공식 보안 권고와 추가 기술 분석 결과를 지속적으로 확인하고, 새로운 취약점 발생 조건이나 공격 경로가 확인될 경우 현재의 분석 결과를 재검토하여 필요한 보안 조치를 시행하겠습니다.

기존 시스템의 안정적인 운영을 유지하면서 확인된 기술적 근거에 따라 보안 대응을 지속하고, 장기적으로는 차세대 플랫폼으로의 전환을 추진하겠습니다.

Keywords
PHP2Shell PHP 보안 취약점 CVE-2026-109618 CVE-2026-109619 PHP 5.2.17 PHP 취약점 분석 PHP 소스코드 분석 PHP 보안 패치 PHP 업그레이드 PHP 레거시 시스템 백포팅 Backporting 원격 코드 실행 RCE 메모리 손상 Use-After-Free UAF Apache PHP 웹 서버 보안 e-Book 솔루션 전자책 시스템 리프아이티 dePaper Enterprise

PHP 공식 보안 권고 외

본 내용은 2026년 10월 22일 기준 공개된 보안 자료와 PHP 5.2.17 원본 소스코드에 대한 정적 분석을 바탕으로 작성되었습니다. 실제 운영 환경에서의 취약점 재현 시험이나 보안성 인증을 완료한 결과는 아니며, 향후 추가 분석 및 검증 결과에 따라 판단이 변경될 수 있습니다.

작성자 : (주)리프아이티 연구개발팀