CVE-2026-109618

CVE-2026-109618(RCE via Out-of-Memory Corruption)은 PHP 실행 엔진이 메모리 부족(OOM, Out of Memory) 오류를 처리하는 과정에서 초기화되지 않은 내부 데이터를 유효한 메모리로 취급하여 메모리 손상과 원격 코드 실행(RCE)을 유발할 수 있는 심각한 보안 취약점이다. 2026년 10월 21일 공개되었으며, CVE-2026-109619와 함께 PHP2Shell 원격 코드 실행 취약점으로 통칭된다.

개요

CVE-2026-109618은 PHP의 메모리 할당과 오류 처리 구조에 존재하는 취약점으로, 공격자가 특수하게 조작한 HTTP 요청을 통해 서버의 PHP 프로세스에서 인증 없이 임의의 코드를 실행할 수 있다.

핵심 원인은 PHP가 메모리 부족 오류를 만나면 longjmp()를 이용해 현재 실행 흐름을 즉시 중단한다는 점이다. 메모리 구조체가 완전히 초기화되기 전에 실행이 중단되면 내부 상태가 불완전하게 남을 수 있으며, 이후 정리 과정에서 이를 정상적인 메모리로 취급하면서 메모리 손상이 발생한다.

특히 Apache HTTP Server의 mod_php 환경에서는 PHP 애플리케이션의 코드가 실행되기 전에도 취약점이 발동할 수 있으며, 기본적인 PHP 입력 및 메모리 제한 설정에서 인증 없는 원격 코드 실행이 입증되었다.^[1]

항목	내용
CVE	CVE-2026-109618
공식 취약점 명칭	RCE via OOM corruption
관련 명칭	PHP2Shell
공개일	2026년 10월 21일
영향 대상	PHP 실행 엔진(Zend Engine)
취약점 유형	메모리 손상, 예외 처리 오류, 초기화되지 않은 메모리 참조
주요 결과	인증 없는 원격 코드 실행(RCE)
CVSS v4.0	9.2 (Critical)
공격 벡터	Network
공격 복잡도	High
공격 요구 조건	Present
필요 권한	None
사용자 상호작용	None
GitHub Advisory	GHSA-w8hw-w9fx-j79w
관련 취약점	CVE-2026-109619
수정 버전	PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12

PHP 공식 보안팀은 이 취약점에 CVSS v4.0 기준 9.2점을 부여했으며, 기밀성·무결성·가용성에 모두 높은 영향을 미칠 수 있다고 평가했다.^[1]

발견 및 공개 경과

2024년
- PHP 외부 보안 감사 이후 관련 수정 작업을 수행하던 개발자가 OOM 처리 구조의 잠재적인 문제를 발견했다.
- 당시에는 이 문제가 실제 원격 코드 실행으로 연결되는 공격 경로를 확인하지 못했다.
- 메모리 오류 처리 구조를 변경할 경우 호환성, 성능, 서드파티 확장 모듈 등에 미치는 영향이 커서 수정이 지연되었다.^[2]
2026년 8월 19일
- Wiz Research가 인공지능 모델을 활용한 분석 과정에서 PHP의 심각한 취약점을 발견했다.
2026년 8월 20~21일
- 연구진이 Drupal과 WordPress 환경에서 인증 없는 원격 코드 실행을 확인했다.
2026년 8월 24일
- Wiz Research가 PHP 보안팀에 취약점을 신고했다.^[3]
2026년 10월 20일
- PHP 보안팀이 두 건의 Critical 취약점에 대응하는 긴급 보안 업데이트를 예고했다.
2026년 10월 21일
- CVE-2026-109618이 공개되었다.
- PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 수정 버전이 배포되었다.
- 한국인터넷진흥원(KISA)도 보안 업데이트 권고를 발표했다.^[4]
2026년 10월 23일
- CERT-EU가 추가 기술정보와 취약점 대응 권고를 반영한 보안 공지를 갱신했다.^[5]

기술적 원인

PHP의 메모리 부족 처리 구조

PHP는 사용자별 스크립트 실행 과정에서 사용할 수 있는 메모리를 제한하기 위해 memory_limit 설정을 사용한다.

PHP 실행 엔진인 Zend Engine은 메모리 할당 과정에서 이 제한을 초과하면 치명적 오류(Fatal Error)를 발생시키고 요청 처리를 중단한다.

취약한 버전에서는 이러한 중단 과정에서 zend_bailout() 및 longjmp() 방식이 사용된다.

longjmp()는 C 언어에서 이전에 저장한 실행 지점으로 제어 흐름을 이동시키는 기능이다. 일반적인 함수 반환 과정을 거치지 않고 중간 실행 단계를 건너뛸 수 있다.

문제는 메모리 할당이 여러 단계로 진행되는 도중 이러한 비지역적 제어 흐름 이동이 발생하면 일부 내부 상태가 초기화되지 않은 채 남을 수 있다는 점이다.

정상적인 처리와 취약한 처리의 차이는 다음과 같다.

[정상적인 처리]

메모리 할당
    ↓
내부 데이터 초기화
    ↓
자료구조에 등록
    ↓
요청 처리
    ↓
정상적인 메모리 정리


[취약한 처리]

메모리 할당 시작
    ↓
자료구조의 일부 상태 변경
    ↓
메모리 부족(OOM)
    ↓
longjmp()로 실행 흐름 중단
    ↓
초기화되지 않은 내부 상태 잔존
    ↓
요청 종료 및 메모리 정리
    ↓
유효하지 않은 데이터 참조
    ↓
메모리 손상
    ↓
원격 코드 실행 가능

메모리 할당에 실패한 위치와 내부 상태가 변경된 위치가 반드시 동일할 필요는 없다. 어떤 자료구조의 초기화가 끝나기 전에 다른 메모리 할당에서 오류가 발생해도 같은 문제가 발생할 수 있다.^[1]

Zend HashTable의 부분 초기화 문제

공개된 기술 분석에서는 PHP 내부의 HashTable 처리 과정에서 발생하는 구체적인 메모리 손상 경로도 확인되었다.

Zend Engine은 PHP 배열과 여러 내부 자료구조를 관리하기 위해 HashTable을 사용한다.

HashTable에는 실제로 사용 중인 항목 수를 추적하는 내부 필드가 있으며, 대표적으로 다음과 같은 항목이 있다.

nNumUsed: 사용된 Bucket 슬롯의 범위
nNumOfElements: HashTable의 논리적 원소 수
arData: Bucket 데이터 배열
p->key: Bucket의 문자열 키
p->val: Bucket에 저장되는 값

정상적인 경우에는 새로운 항목에 필요한 데이터를 생성하고 유효한 상태로 초기화한 뒤 자료구조에서 사용할 수 있어야 한다.

그러나 취약한 문자열 키 삽입 경로에서는 내부 원소 수를 먼저 증가시킨 뒤 문자열 키를 할당하는 순서가 사용되었다.

메모리 정리 과정의 문제

PHP는 요청이 종료되면 사용하던 배열, 문자열, 객체 등의 내부 자료구조를 정리한다.

이때 HashTable의 사용 범위에 포함된 Bucket을 순회하면서 각 항목이 보유한 자원을 해제한다.

앞서 설명한 불완전한 Bucket이 존재하면 다음과 같은 문제가 발생할 수 있다.

초기화되지 않은 값을 정상적인 PHP 값으로 해석
잘못된 포인터를 참조하거나 해제
이전 메모리 영역에 남아 있던 데이터를 유효한 구조체로 해석
실제로 다른 객체가 사용하는 메모리 영역을 손상
이후 메모리 재사용 과정에서 Use After Free 등의 취약 상태 발생

이러한 메모리 손상은 프로세스 비정상 종료뿐 아니라 공격자가 의도한 실행 흐름 변경으로 이어질 수 있다.^[6]

공격 경로

Multipart 요청을 이용한 메모리 소진

PHP는 파일 업로드와 HTML 폼 데이터를 처리할 때 multipart/form-data 형식의 HTTP 요청을 해석한다.

파일 업로드 처리 과정에서는 실제 파일 데이터 외에도 필드 이름, 헤더, 파일 메타데이터, 배열 등의 내부 정보가 생성된다.

PHP 공식 보안 권고는 메모리 부족 상태를 유발할 수 있는 여러 multipart 처리 문제를 설명하고 있다.

유형	기술적 원인
요청 본문 길이 제한 우회	유효한 Content-Length가 없는 일부 요청은 초기 `post_max_size` 검사를 통과한 뒤 실제 디코딩 과정에서 더 많은 데이터를 처리할 수 있음
Multipart 헤더 증가	개별 파트에 포함된 헤더를 내부 자료구조로 변환하는 과정에서 전송 크기보다 훨씬 많은 메모리가 필요할 수 있음
빈 파일 입력 처리	실제 파일 데이터가 없는 입력도 메타데이터 배열을 생성하며, 일부 경우 `max_file_uploads` 제한에 포함되지 않음
중첩된 필드 이름	배열 형태의 필드 이름을 처리하면서 다수의 내부 배열과 구조체가 생성될 수 있음
애플리케이션 입력 처리	애플리케이션에서 처리하는 외부 입력으로 인해 특정 실행 구간에서 반복적인 메모리 할당 또는 대규모 할당이 발생할 수 있음

이러한 경로는 PHP의 입력 크기 제한이 설정되어 있더라도 실제 메모리 사용량이 제한값을 초과할 수 있음을 보여준다.

단, 메모리 부족 오류가 발생한다는 사실만으로 원격 코드 실행에 성공하는 것은 아니다. 취약한 내부 상태가 형성되는 시점과 이후 해당 상태를 사용하는 과정이 결합해야 한다.^[1]

애플리케이션 실행 전 공격

CVE-2026-109618의 중요한 특징은 일부 실행 환경에서 웹 애플리케이션의 실제 PHP 코드가 실행되기 전에 공격이 가능하다는 점이다.

일반적인 요청 처리 과정은 다음과 같다.

클라이언트
    ↓
HTTP 요청
    ↓
웹 서버
    ↓
PHP 요청 초기화
    ↓
POST 및 파일 업로드 데이터 해석
    ↓
애플리케이션 PHP 코드 실행
    ↓
응답 생성
    ↓
요청 종료 및 자원 정리

취약한 mod_php 환경에서는 POST 및 파일 업로드 데이터 해석 단계에서 OOM이 발생할 수 있다.

이후 애플리케이션 코드에 도달하지 못했더라도 요청 종료 처리 과정이 수행되며, 앞서 남아 있던 유효하지 않은 내부 데이터를 참조할 수 있다.

따라서 다음과 같은 방어 대책만으로는 취약점을 해결할 수 없다.

애플리케이션 로그인 및 관리자 인증
애플리케이션 내부의 입력값 검증
PHP 코드에서 수행하는 파일 업로드 검사
PHP 코드에서 수행하는 요청 크기 검사

이들 방어 기능이 실행되기 전에 취약점이 발동하는 경로가 존재하기 때문이다.^[1]

메모리 정보 유출 및 후속 공격

Wiz Research는 PHP2Shell 연구 과정에서 원격 코드 실행뿐 아니라 PHP 프로세스의 메모리 정보가 외부에 노출될 수 있는 경로도 확인했다.

공개된 분석에 따르면 세션 업로드 진행률 처리 과정에서 사용되는 내부 포인터가 OOM 이후 해제된 메모리를 가리키는 상태로 남을 수 있다.

후속 요청에서 이 포인터가 정상적인 세션 문자열로 취급되면 해제된 메모리 영역의 내용이 세션 쿠키에 포함되어 외부로 전달될 가능성이 있다.

관련 내부 상태에는 다음과 같은 요소가 관여한다.

PS(id): 세션 식별자와 관련된 내부 상태
BG(unserialize): 역직렬화 관련 내부 상태
PHPSESSID: 기본 세션 쿠키 이름
RFC 1867 파일 업로드 처리 과정

Wiz Research는 이러한 메모리 정보 유출과 메모리 손상 경로를 분석하고, WordPress·Drupal·Joomla 환경에서 원격 코드 실행을 입증했다.^[3]

메모리 정보가 유출되면 인증정보나 API 키 등의 민감한 데이터가 노출될 수 있으며, 메모리 주소 정보가 유출되는 경우 ASLR 등 메모리 배치 무작위화 기법의 효과를 약화시키는 데 이용될 수도 있다.

다만 PHP2Shell 연구에서는 여러 결함을 조합한 공격 경로가 존재하며, 각각의 메모리 정보 유출과 코드 실행 경로를 모두 CVE-2026-109618 단독의 필수 동작으로 해석해서는 안 된다.

실행 환경별 영향

PHP 실행 방식에 따라 취약점의 실제 발생 조건과 공격 가능성이 다르다.

실행 환경	공개된 영향 분석
Apache mod_php	기본적인 PHP 입력 및 메모리 제한 환경에서 인증 없는 원격 코드 실행 입증
PHP-FPM	요청 초기화 실패 시 워커가 종료되므로 mod_php와 동일한 초기화 단계 공격 경로는 성립하지 않음. 정상 초기화 이후 애플리케이션 실행 과정에서 발생하는 OOM 경로는 영향 가능
FrankenPHP	mod_php와 유사하게 요청 종료 처리가 수행되는 구조로 인해 애플리케이션에 독립적인 공격에 취약할 가능성이 있음
LiteSpeed LSAPI	PHP-FPM과 유사한 구조로 분석되며, 애플리케이션별 공격 가능성이 있으나 공식 권고 시점에 완전한 공격 실증은 확인되지 않음
php-cgi	PHP 공식 보안 공지에서 잠재적인 영향 대상으로 포함

PHP 보안 권고는 mod_php 환경에서의 원격 코드 실행을 확인했으며, PHP-FPM에 대해서는 애플리케이션 실행 이후의 취약 경로가 존재한다고 설명했다.

한편 PHP 재단은 별도 발표에서 애플리케이션 수준의 경로를 통한 PHP-FPM 원격 코드 실행도 확인되었다고 밝혔다. 다만 개별 CVE 권고문에서는 PHP-FPM에 대한 완전한 공격 실증 여부를 보다 제한적으로 기술하고 있어, 특정 PHP-FPM 구성의 실제 공격 가능성을 판단할 때에는 구체적인 공격 경로와 조건을 구분할 필요가 있다.^[1]^[2]

취약점 분류 및 심각도

CWE 분류

PHP 공식 GitHub 보안 권고에는 다음 CWE 유형이 연결되어 있다.

CWE	명칭	관련 내용
CWE-416	Use After Free	이미 해제된 메모리를 다시 참조하거나 사용
CWE-755	Improper Handling of Exceptional Conditions	OOM과 같은 예외 상황의 부적절한 처리
CWE-824	Access of Uninitialized Pointer	초기화되지 않은 포인터에 대한 접근
CWE-1325	Improperly Controlled Sequential Memory Allocation	연속적인 메모리 할당에 대한 부적절한 통제
CWE-1419	Incorrect Initialization of Resource	자원이 불완전하거나 잘못된 상태로 초기화됨

이 중 핵심적인 원인은 OOM 예외 처리 과정에서 내부 상태의 일관성이 유지되지 않는 것이며, 그 결과가 초기화되지 않은 메모리 참조나 Use After Free 등으로 나타날 수 있다.^[1]

CVSS 평가

CVSS v4.0: 9.2 (Critical)

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

AV:N: 네트워크를 통해 공격 가능
AC:H: 높은 공격 복잡도
AT:P: 특정 공격 요구 조건 존재
PR:N: 사전 권한 불필요
UI:N: 다른 사용자의 상호작용 불필요
VC:H: 취약한 시스템의 기밀성에 높은 영향
VI:H: 취약한 시스템의 무결성에 높은 영향
VA:H: 취약한 시스템의 가용성에 높은 영향
SC:N, SI:N, SA:N: 후속 시스템에 대한 직접적인 영향은 기본 평가에서 없음

공격 복잡도가 높게 평가된 것은 메모리 배치와 내부 상태를 정밀하게 제어해야 하기 때문이다. 그러나 높은 공격 복잡도가 실제 악용 불가능을 의미하지는 않는다.

영향받는 버전

2026년 10월 21일 배포된 보안 업데이트 기준 영향 버전은 다음과 같다.

PHP 계열	취약한 버전	수정 버전
PHP 8.5	8.5.12 미만	8.5.12 이상
PHP 8.4	8.4.27 미만	8.4.27 이상
PHP 8.3	8.3.36 미만	8.3.36 이상
PHP 8.2	8.2.35 미만	8.2.35 이상
PHP 8.1 이하	공식 지원 종료 버전	공식 정식 릴리스 없음

PHP 8.1 이하 버전은 공식 보안 지원이 종료되었지만, PHP 보안팀은 취약점의 심각성을 고려하여 PHP 7.4, 8.0, 8.1에 대한 최소한의 소스 코드 백포트도 공개했다.

PHP 8.6 개발 버전 역시 보안 수정이 이루어졌으며, PHP 8.6.0 RC4에는 관련 패치가 포함되어 있다. 다만 RC 버전은 운영 환경용 정식 릴리스가 아니다.^[7]

오래된 PHP 버전에서도 관련 메모리 처리 문제가 보고되었지만, 개별 결함의 최초 도입 시점은 다를 수 있다.

또한 리눅스 배포판은 기존 PHP 버전 번호를 유지하면서 수정 코드를 백포트할 수 있으므로 버전 문자열만으로 보안 패치 여부를 단정해서는 안 된다.

보안 패치의 기술적 변경

OOM 처리 방식 변경

PHP 개발팀은 단순히 개별 메모리 손상 지점에 검사를 추가하는 대신 OOM 발생 시의 실행 흐름을 변경하는 방향으로 문제를 수정했다.

기존 방식에서는 메모리 제한 초과 시 zend_bailout()을 통해 즉시 현재 실행 흐름을 벗어날 수 있었다.

수정된 방식에서는 OOM 상황을 다음 두 단계로 구분한다.

Soft OOM
- 메모리 제한에 도달하면 즉시 실행 흐름을 중단하는 대신 OOM 상태를 기록한다.
- 가상 머신이 안전하게 중단할 수 있는 시점(VM safe point)에 도달했을 때 제어된 종료 처리를 수행한다.
Hard OOM
- 추가적인 메모리 사용으로 더 높은 임계값에 도달하면 안전하지 않은 정리 과정을 진행하지 않고 _exit()를 통해 프로세스를 종료한다.

이를 통해 내부 자료구조가 불완전한 상태에서 요청 종료 처리가 수행되는 문제를 방지한다.^[1]

소스 코드 수정

PHP 보안팀의 주요 수정 커밋은 다음과 같다.

커밋: 31c0ea7d7ff1d1fccb6492e52dab544011628065
제목: Avoid state corruption via bailout
수정 내용: OOM 상황에서 기존의 즉시 중단 방식 대신 제어된 종료 처리 도입 및 전역 상태 초기화 보강
관련 취약점: CVE-2026-109618, CVE-2026-109619

해당 수정은 Zend Engine의 메모리 관리 및 실행 흐름뿐 아니라 요청 처리와 확장 모듈의 다양한 오류 처리 경로에 걸쳐 이루어졌다.^[8]

수정의 의미

핵심적인 변경은 메모리 부족 자체를 방지하는 것이 아니다.

메모리 부족이 발생하더라도 내부 자료구조가 잘못된 상태로 남은 채 이후 정리 과정에 전달되지 않도록 하는 것이다.

따라서 보안 패치 이후에도 메모리 부족에 따른 정상적인 오류나 서비스 중단은 발생할 수 있지만, 동일한 오류가 취약한 메모리 손상 경로로 이어지는 문제를 방지하도록 설계되었다.

보안 대응

정식 대응

취약점이 수정된 PHP 버전으로 업데이트하는 것이 유일한 완전한 대응 방법이다.

PHP 보안팀은 설정 변경이나 웹 방화벽 차단만으로 모든 공격 경로를 제거할 수 없다고 명시했다.^[1]

운영 환경에서는 다음 사항을 확인해야 한다.

실제 웹 요청을 처리하는 PHP 버전
PHP 실행 방식(mod_php, PHP-FPM 등)
운영체제 및 패키지 공급업체의 보안 패치 반영 여부
별도 저장소에서 설치한 PHP의 업데이트 여부
컨테이너 이미지와 실제 실행 중인 PHP의 일치 여부
패치 적용 후 모든 PHP 워커의 재시작 여부

임시 완화 조치

즉시 업데이트할 수 없는 경우 PHP 공식 보안팀은 다음 조치를 안내하고 있다.

조치	설명	한계
`memory_limit=-1`	PHP 자체의 메모리 제한으로 발생하는 예측 가능한 OOM 경로 축소	실제 메모리 할당 실패는 여전히 발생 가능
`post_max_size` 축소	HTTP 요청 본문으로 인한 메모리 사용량 감소	모든 multipart 처리 문제를 해결하지는 못함
`upload_max_filesize` 제한	파일 업로드 크기 제한	메타데이터나 다수 필드에 의한 메모리 소진 가능
입력 필드·헤더·중첩 수준 제한	요청 처리 과정에서 생성되는 내부 자료구조의 크기 제한	정상적인 서비스 입력과의 호환성 검토 필요
프록시 및 웹 서버 요청 크기 제한	비정상적으로 큰 요청이 PHP에 전달되는 것을 제한	PHP 내부의 모든 메모리 할당 경로를 차단할 수 없음
컨테이너 또는 cgroup 메모리 제한	비정상적인 메모리 사용으로 인한 시스템 전체의 가용성 피해 축소	메모리 할당 실패 자체를 방지하지는 못함

PHP 공식 권고에서는 파일 업로드가 필요하지 않은 애플리케이션의 post_max_size를 8M, 업로드가 필요한 환경에서는 32M 정도로 제한하는 방안을 제시했다. 이는 보편적인 적정값이 아니라 긴급 완화를 위한 예시이므로 정상 업무의 업로드 요구량과 비교해야 한다.^[7]

또한 memory_limit=-1 설정은 PHP 내부의 메모리 사용 제한을 해제하는 것이므로 자원 고갈로 인한 서비스 장애가 발생할 수 있다. 운영체제 또는 컨테이너 수준의 자원 통제와 함께 검토해야 한다.

PHP 보안팀은 RLIMIT_AS 또는 RLIMIT_DATA를 대체 메모리 제한 수단으로 사용하는 것도 권고하지 않는다. 이러한 제한으로 메모리 할당 함수가 실패하면 취약한 OOM 경로가 다시 실행될 수 있기 때문이다.^[1]

보안 로그 및 침해 흔적 점검

취약점 악용 여부를 조사할 때 다음과 같은 징후를 참고할 수 있다.

평소보다 빈번한 PHP 메모리 부족 오류
PHP 애플리케이션 코드 실행 전 단계에서 발생하는 오류
비정상적으로 큰 multipart 요청 또는 비정상적인 필드 구성
특정 클라이언트에서 반복적으로 발생하는 HTTP 500 응답
PHP 워커의 비정상적인 종료 및 재시작
PHP 또는 웹 서버 프로세스가 평소 실행하지 않던 셸이나 외부 프로그램을 실행한 흔적
웹 서버 프로세스가 생성한 의심스러운 파일이나 외부 통신

PHP 애플리케이션 코드 실행 전에 발생하는 오류는 애플리케이션 로그에 충분한 정보가 남지 않을 수도 있다.

따라서 웹 서버 접근 로그, PHP 오류 로그, 시스템 프로세스 실행 기록, 네트워크 통신 기록 등을 함께 확인할 필요가 있다.

다만 메모리 부족 오류나 HTTP 500 응답 자체는 정상적인 장애 상황에서도 발생할 수 있으므로 단일 징후만으로 공격을 확정할 수 없다.^[9]

실제 악용 및 검증 현황

2026년 10월 24일 기준 공개 자료에서 확인되는 주요 사항은 다음과 같다.

PHP 공식 보안팀이 인증 없는 원격 코드 실행 가능성을 확인했다.
Apache mod_php 환경에서 기본 PHP 입력 및 메모리 제한을 이용한 원격 코드 실행 실증이 이루어졌다.
Wiz Research가 WordPress, Drupal, Joomla 환경에서 관련 공격 경로를 검증했다.
공개된 보안 연구와 실습 환경을 통해 취약점 재현 및 공격 연구가 진행되고 있다.
다만 공개된 실증 자료만으로 실제 운영 서버에서 발생한 대규모 침해 규모나 피해 건수를 확정할 수는 없다.

특히 취약점의 심각성과 공격 코드의 존재 여부, 실제 악용 여부, 피해 규모는 서로 구분해서 판단해야 한다.

같이 보기

각주

↑ ^1.00 ^1.01 ^1.02 ^1.03 ^1.04 ^1.05 ^1.06 ^1.07 ^1.08 ^1.09 PHP Security Team, RCE via OOM corruption (GHSA-w8hw-w9fx-j79w), 2026-10-21.
↑ ^2.0 ^2.1 The PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security, 2026-10-21.
↑ ^3.0 ^3.1 Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, 2026-10-21.
↑ 한국인터넷진흥원, PHP 제품 보안 업데이트 권고, 2026-10-21.
↑ CERT-EU, Critical Vulnerabilities in PHP, Security Advisory 2026-018, 최종 갱신: 2026-10-23.
↑ ^6.0 ^6.1 Red Hat Bugzilla, Bug 2553995: PHP Zend HashTable raw-key partial-insertion memory corruption, 확인: 2026-10-24.
↑ ^7.0 ^7.1 PHP Development Team, Security advisory: Critical remote code execution vulnerabilities, update now, 2026-10-21.
↑ PHP Development Team, Avoid state corruption via bailout, 2026-10-21.
↑ Elastic Security Labs, php2shell: Assessing Elastic detection coverage relevant to CVE-2026-109618 and CVE-2026-109619, 2026-10-21.

[ghsa-1] 1.00 ^1.01 ^1.02 ^1.03 ^1.04 ^1.05 ^1.06 ^1.07 ^1.08 ^1.09 PHP Security Team, RCE via OOM corruption (GHSA-w8hw-w9fx-j79w), 2026-10-21.

[foundation-2] 2.0 ^2.1 The PHP Foundation, Today's PHP Security Release, and How We're Strengthening PHP Security, 2026-10-21.

[wiz-3] 3.0 ^3.1 Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, 2026-10-21.

[kisa-4] 한국인터넷진흥원, PHP 제품 보안 업데이트 권고, 2026-10-21.

[certeu-5] CERT-EU, Critical Vulnerabilities in PHP, Security Advisory 2026-018, 최종 갱신: 2026-10-23.

[redhatbug-6] 6.0 ^6.1 Red Hat Bugzilla, Bug 2553995: PHP Zend HashTable raw-key partial-insertion memory corruption, 확인: 2026-10-24.

[php-7] 7.0 ^7.1 PHP Development Team, Security advisory: Critical remote code execution vulnerabilities, update now, 2026-10-21.

[8] PHP Development Team, Avoid state corruption via bailout, 2026-10-21.

[9] Elastic Security Labs, php2shell: Assessing Elastic detection coverage relevant to CVE-2026-109618 and CVE-2026-109619, 2026-10-21.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

항목	CVE-2026-109618	CVE-2026-109619
핵심 원인	메모리 부족으로 초기화 도중 실행이 중단되어 불완전한 내부 데이터가 남음	요청 종료 이후에도 해제된 메모리를 가리키는 내부 전역 상태가 남음
주요 취약 상태	부분 초기화 및 잘못된 메모리 정리	이전 요청의 메모리를 후속 요청이 참조
대표적인 오류 유형	초기화되지 않은 데이터 참조, 메모리 손상	Use After Free, 전역 상태 관리 오류
공격 결과	원격 코드 실행	원격 코드 실행 및 메모리 정보 노출
CVSS v4.0	9.2	9.2
수정일	2026년 10월 21일	2026년 10월 21일

개요