소스는 2026년 10월 22일 현재 확인되었습니다. 대상: PHP 애플리케이션 운영자, 보안 대응자 및 맞춤형 PHP 빌드를 유지 관리하는 엔지니어.

이 문서에는 PHP2Shell 취약점의 원인, 영향 범위, 공식적인 복구 프로세스, 임시 완화 조치 및 공식 패치 구현이 요약되어 있습니다. 본문은 S1와 같은 번호를 사용하여 인용됩니다. 모든 소스 링크는 텍스트 끝의 부록에 나열되어 있습니다. 구성 조각은 실제 버전, 비즈니스 용량 및 구성 상속 관계에 따라 조정되어야 하는 배포 템플릿입니다.

TL;DR: 수리 단계 및 제안

  1. PHP 런타임 업그레이드: 관련 분기를 최소한 8.2.35, 8.3.36, 8.4.27 또는 8.5.12로 업그레이드합니다. 배포 패키지의 경우 공급업체가 두 CVE를 모두 수정했다고 확인한 전체 패키지 버전을 사용하세요. S1S10
  2. 이전 프로세스를 모두 교체: 업그레이드 후 모든 PHP worker, 호스팅 서비스 및 컨테이너를 다시 시작하거나 롤오버하고 이전 인스턴스가 종료되었는지 확인합니다.
  3. 실제 Web 요청 경로를 통해 확인: Web SAPI, 전체 패키지 버전, 실행 중인 인스턴스를 확인합니다. php -v만 확인한다고 해서 라이브 서비스가 수정되었음을 확인할 수는 없습니다.
  4. 비즈니스 회귀 검사를 실행하고 정상적인 리소스 예산을 복원합니다.: 로그인, 세션 처리, 업로드, 가져오기 및 오류 처리를 테스트합니다. PHP 메모리 제한이 일시적으로 제거된 경우 패치 후 적절한 유한 예산을 복원하십시오.
  5. 즉시 업그레이드가 불가능한 경우: 신뢰할 수 없는 트래픽이 PHP에 도달하기 전에 제한합니다. 섹션 5에 설명된 대로 비활성화된 업로드 진행 및 PHP 8.5 치명적인 역추적을 평가합니다. 구성 완화 및 WAF 규칙은 적용 범위가 제한되어 있으며 업그레이드를 대체할 수 없습니다. S1S2S3

1. 취약점 개요 및 위험 판단

이 문서의 PHP2Shell는 2026년 10월 21일 PHP에서 공식적으로 공개한 두 가지 Critical 수준 취약점을 나타냅니다. 둘 다 PHP 엔진의 메모리 및 요청 수명주기 관리와 관련되어 인증되지 않은 원격 코드 실행의 위험을 초래합니다. S1S2S3

프로젝트CVE-2026-109618CVE-2026-109619
공식 명칭RCE via OOM corruptionRCE via stale global state
핵심 이슈메모리가 부족하면 비정상적인 점프가 발생하여 아직 초기화가 완료되지 않은 상태가 됩니다.작업자에 남아 있는 전역 상태는 해제된 요청 메모리를 가리킵니다.
일반적인 발생 시간현재 요청의 초기화, 실행 또는 정리 프로세스이전 요청은 상태를 벗어나고 후속 요청은 이를 미리 사용합니다.
OOM는 필요조건인가요?취약점의 핵심 트리거 메커니즘에 속합니다.아니요. 기타 치명적인 오류 및 진단 후 정리 작업도 포함될 수 있습니다.
근본적인 수리 방향할당 실패 및 종료 요청을 안전하게 처리상태 소유권, 정리 시기, 조기 초기화 수정
폐기 요구 사항수리해야합니다동시에 수리해야합니다

기반: 두 개의 공식 보안 게시판 및 수정 제출. S2S3S4

1.1 영향을 받는 배포 이해

PHP는 공식적으로 PHP-FPM, Apache mod_php, php-cgi, FrankenPHP를 포함하여 Web 요청를 처리하는모든 PHP 배포를 위험에 처한 것으로 간주합니다. LiteSpeed. 시연된 mod_php 공격은 애플리케이션 코드가 실행되기 전에 발생할 수 있으므로 로그인 확인, 프레임워크 미들웨어 및 애플리케이션 업로드 유효성 검사로는 해당 경로를 다룰 수 없습니다. S1

“배포를 수정해야 한다”와 “특정 공격 체인이 완전히 입증되었습니다”를 구별할 필요가 있습니다. CVE-2026-109618 발표: FPM는 요청 시작이 실패한 후 하위 프로세스를 종료하고 시작 실패 후 mod_php의 해당 정리 경로를 차단합니다. 그러나 성공적인 시작 후 OOM 경로는 여전히 위험합니다. 이 발표에서는 또한 이 CVE에 대한 전체 FPM 익스플로잇이 아직 시연되지 않았다고 언급했습니다. 이 제한 사항은 FPM가 안전하다고 추론하는 데 사용할 수 없으며, 특히 CVE-2026-109619는 ​​무시할 수 없습니다. S2S3

성공적인 악용을 위한 즉각적인 권한 경계는 PHP를 호스팅하는 프로세스의 ID와 액세스할 수 있는 리소스에 따라 달라집니다. 일반적으로 웹사이트 코드, 업로드 디렉터리, 데이터베이스 자격 증명, 서비스 토큰 및 내부 네트워크 액세스 기능에 주의를 기울여야 합니다. “원격 코드 실행”은 자연스럽게 루트 권한을 얻는 것을 의미하지 않습니다. 여기서 결과 판단은 프로세스 권한 모델을 기반으로 하며 실제 영향은 배포 권한과 함께 평가되어야 합니다.

일반 일회성 CLI 스크립트에는 동일한 HTTP 항목이 없습니다. 그러나 CLI 또는 임베디드 모드에서 오랫동안 외부 작업을 처리하는 프로세스는 여전히 런타임 및 수명 주기 목록에 포함되어야 합니다. CMS, 프레임워크 또는 Composer 종속성만 업데이트되고 기본 PHP 엔진은 자동으로 교체되지 않습니다.

2. 원인 분석

2.1 먼저 두 가지 수명주기를 이해합니다.

PHP worker는 여러 요청을 연속적으로 처리하는 경우가 많습니다. 요청 중에 할당된 메모리는 요청이 끝날 때 균일하게 해제될 수 있지만 작업자 자체와 해당 전역 필드 중 일부는 계속 존재합니다.

따라서 엔진은 두 가지 제약 조건을 유지해야 합니다.

  • 초기화 제약: 다른 코드에 표시되는 데이터는 안전하게 읽고, 탐색하고, 파기할 수 있는 상태여야 합니다.
  • Lifecycle 제약 조건: 요청 메모리가 해제되면 수명이 긴 필드는 해당 메모리 내의 주소를 유효한 상태로 계속 처리해서는 안 됩니다.

이 두 가지 제약 조건은 두 가지 취약점 그룹의 주요 실패 모드에 해당합니다. 다음 프로세스는 공지 사항과 패치 컴파일을 결합한 메커니즘 설명입니다. 이는 모든 배포에 도달 가능한 경로가 정확히 동일하다는 의미는 아닙니다. S2S3S5

2.2 CVE-2026-109618: OOM가 완료되지 않은 상태 업데이트를 중단했습니다.

이전 구현에서는 longjmp() 유형의 비로컬 점프를 사용하여 OOM를 처리하고 관련 경로는 zend_bailout()를 통해 현재 실행 컨텍스트를 종료합니다. 위험은 C 코드 조각이 새로운 개체, 배열 또는 다른 코드에 대한 요청 상태를 게시했지만 아직 모든 필드 초기화를 완료하지 않았을 수 있다는 것입니다. 이때 해당 시점에 할당이 실패하면 정상적인 마감 단계를 건너뛸 수 있습니다. S2

실패 프로세스는 네 단계로 나눌 수 있습니다.

  1. 요청 내부 구조를 생성하거나 업데이트하고 액세스 가능하게 만듭니다.
  2. 후속 메모리 할당이 실패하고 OOM가 트리거됩니다.
  3. 실행 흐름은 현재 함수에서 벗어나며 원래 초기화를 완료하거나 상태를 복원하는 데 사용된 코드는 실행되지 않습니다.
  4. 요청 정리는 이러한 구조를 계속 처리하고 유효하지 않은 콘텐츠를 유효한 필드 또는 주소로 처리합니다.

문제는 메모리 부족으로 인해 항상 RCE가 발생한다는 것이 아닙니다. 오히려 메모리 고갈은 제어 흐름을 변경하고 유효한 구조에 대한 엔진의 가정을 위반합니다. 실패한 할당은 결국 잘못 읽히는 구조를 직접적으로 포함할 필요는 없습니다. S2

작은 요청에도 메모리가 부족할 수 있는 이유

요청 본문의 바이트 수와 구문 분석 후 힙 사용량은 동일하지 않습니다. A 필드는 PHP 내부의 여러 문자열, 배열 요소 및 메타데이터 개체에 해당할 수 있습니다. 입력 구조의 복잡성은 메모리 증폭 정도에 영향을 미칩니다.

공식 발표에 나열된 멀티파트 관련 문제에는 사용 가능한 선언 길이가 누락된 경우의 초기 크기 확인 간격, 단일 부분의 헤더 수가 충분히 제한되지 않았으며, 빈 파일 제어가 여전히 메타데이터를 생성하고 중첩된 이름이 배열 작업량을 더욱 증가시키는 문제가 포함됩니다. 애플리케이션 자체의 해제, 디코딩 또는 입력 재할당도 OOM의 소스일 수 있습니다. S2

이로부터 두 가지 보호적인 결론을 도출할 수 있습니다.

  • PHP를 입력하기 전에 요청 본문 제한을 최대한 구현해야 하며 실제 읽기 길이와 구조적 복잡성을 고려해야 합니다.
  • 파일 크기, 파일 수를 개별적으로 제한하거나 하나의 업로드 포털만 닫는 것만으로는 모든 OOM 소스를 다룰 수 없습니다.

애플리케이션 인증이 너무 늦을 수 있는 이유

mod_php에서는 요청 초기화 단계에서 요청 본문이 자동으로 구문 분석될 수 있습니다. 시작이 실패하더라도 관련 요청 정리는 계속 수행됩니다. 따라서 확인된 공격 경로는 애플리케이션 코드 이전에 발생할 수 있습니다. 이 단계에서 노출을 줄이려면 역방향 프록시, Web 서버 또는 PHP 요청 처리 이전의 기타 경계에 제한을 적용해야 합니다. S1S2

2.3 CVE-2026-109619: 요청 메모리가 해제되었으며 전역 참조는 아직 살아 있습니다.

이 문제는 오류, 세션, 개체 또는 확장 상태와 관련이 있습니다. 필드는 작업자 장기 액세스 위치에 저장되지만 필드에서 참조하는 데이터는 단일 요청에 속합니다. 요청 힙이 해제되기 전에 참조가 적절하게 정리되지 않는 한 후속 요청은 댕글링 상태에 직면하여 use-after-free를 형성할 수 있습니다. S3

공식 분석에서는 착취 조건을 ‘생산자’와 ‘소비자’로 구분합니다.

역할이나 조건의미보호에 대한 시사점
국가 생산자이 요청이 소유한 상태를 나중에 액세스할 수 있는 위치에 넣습니다.비정상 종료 후 해당 정리가 완료되었는지 확인하려면
상태는 그대로 유지됩니다지워지지 않았거나, 지워졌다가 늦은 작업으로 다시 채워졌습니다.초기 종료 단계에서 한 번만 클리어하는 것만으로는 충분하지 않을 수 있습니다.
작업자 재사용동일한 작업자가 후속 요청을 계속 처리합니다.다중 작업자는 메모리 안전 보장이 아니라 단지 스케줄링 차이일 뿐입니다.
사전 소비자해당 상태가 정상적으로 초기화되기 전에 잔존 값을 읽거나 해제하거나 결정하십시오.초기화 전 INI, 세션 및 기타 경로를 확인해야 합니다.

이러한 조건은 복합적으로 충족되어야 합니다. 오류 로그 자체로는 취약점이 성공적으로 악용되었음을 증명할 수 없습니다. S3

필수 전제 조건으로 OOM가 필요하지 않습니다.

치명적인 오류로 인해 쌍을 이루는 상태 게시 및 복원이 중단될 수 있습니다. 컴파일 또는 구문 분석 실패, 포착되지 않은 오류, require 실패 및 실행 시간 초과로 인해 특정 상태가 뒤처질 수 있습니다. 정리 후반에 치명적이지 않은 진단을 수행하면 이미 지워진 오류 정보를 다시 채울 수도 있습니다. S3

따라서 memory_limit를 무제한으로 변경해도 이 취약점은 해결되지 않습니다.

‘초기화 전’은 별도로 처리해야 합니다.

두 가지 유형의 소비자가 확인되는 시점이 다릅니다.

  • Early INI 진단: 요청 시 적용된 일부 구성은 일반 실행기 초기화 전에 경고, 공지 또는 사용 중단을 발행하며 진단 처리에서는 이전 오류 상태에 액세스할 수 있습니다.
  • 세션 업로드 진행: 요청 본문 구문 분석 프로세스 중에 세션이 미리 처리될 수 있지만 일반 모듈 RINIT는 아직 완료되지 않았습니다. it cannot be inferred that the path does not exist because the application does not explicitly call session_start(). S3

모든 INI 구성의 위험 타이밍이 동일한 것은 아닙니다. mod_php 및 FPM 프런트 엔드에서 전달된 PHP_VALUE/PHP_ADMIN_VALUE의 디렉터리 수준 구성은 일반 php.ini, FPM pool 시작 구성 및 FPM .user.ini와 구별되어야 합니다. The latter ones have different configuration timing and cannot be collectively called the same early consumers. S3

display_errors, log_errors를 끄거나 error_reporting를 줄이거나 @를 사용하면 진단 가시성에만 영향을 미칩니다. 로그 출력 여부를 결정하기 전에 해당 내부 상태에 액세스했을 수 있습니다. S3

3. 복구 버전 및 패치 선택

3.1 공식 업스트림 수정 기준선

현재 PHP 지점이 공식 수정 사항을 포함하는 첫 번째 버전제안
8.28.2.35이 버전이나 동일한 수정 사항이 포함된 후속 버전으로 업그레이드하세요.
8.38.3.36위와 동일
8.48.4.27위와 동일
8.58.5.12위와 동일
8.1 및 이전 버전업스트림 일반 지원이 종료되었습니다지원되는 분기로의 마이그레이션 우선순위를 지정합니다. short-term check release or LTS manufacturer backport

버전 및 지원 현황은 PHP의 공식 발표를 기준으로 하며, 기준일은 2026년 10월 22일입니다. S1

These are branch-specific fix thresholds. 8.5.12 아래의 모든 버전이 취약하다는 설명으로 대체할 수 없습니다. 다른 브랜치의 8.2.35 및 8.4.27와 같은 버전에는 이미 수정 사항이 포함되어 있습니다.

3.2 전체 배포 패키지 버전 확인

Distro는 종종 이전 업스트림 버전을 기반으로 보안 수정 사항을 추가합니다. 수락 시에는 릴리스 버전, 저장소 소스, 전체 패키지 버전 및 보안 게시판도 확인해야 합니다.

예를 들어, Ubuntu USN-8948-1에 대해 나열된 Ubuntu 24.04 LTS 수정 패키지 버전은 다음과 같습니다.

8.3.6-0ubuntu0.24.04.13

Its upstream part is still 8.3.6, but the full package version of that distribution is included in this fix announcement. 이 결론은 해당 배포 및 패키지 소스에만 적용되며 8.3.6도 표시하는 빌드로 일반화할 수 없습니다. S10

3.3 올바른 패치 선택

장면우선순위 계획합격의 핵심 포인트
배포판 PHP 패키지 사용제조업체에서 출시한 보안 업데이트 설치발표에는 두 가지가 모두 포함됩니다. CVE ; 전체 패키지 버전이 정확합니다
공식 PHP 컨테이너 또는 자체 구축 이미지를 사용하세요.기본 런타임 업데이트, 재구축 및 배포실행 중인 인스턴스는 새 이미지를 사용합니다. 이전 복사본이 모두 종료되었습니다.
자체 컴파일된 지원 브랜치이 브랜치의 공식 보안 버전 또는 전체 공식 패치 세트를 사용하세요.분기 일치, 종속성 완성, 확장 호환성 및 회귀 전달
7.4, 8.0, 8.1에 따라공급업체 백포트 우선순위를 지정합니다. 필요한 경우 공식 비상 소스 코드 분기를 평가합니다.동작 변경 사항을 식별하고 지원되는 버전으로 마이그레이션 예약

공식 패치가 릴리스되었으며 실제 수정은 이 패치부터 시작되어야 합니다. 섹션 6의 코드 조각은 설계 및 검토 하이라이트를 설명하기 위한 것이며 독립적으로 적용할 수 있는 완전한 패치를 구성하지 않습니다. S1S4S6

4. 정식 수리 과정

4.1 실제로 요청을 처리하는 런타임 인벤토리

최소한 다음 사항을 기록하기 위해 간략한 원장을 작성하는 것이 좋습니다.

  • 항목 도메인 이름 또는 서비스, 역방향 프록시 백엔드, PHP SAPI.
  • PHP 브랜치, 전체 패키지 버전 또는 이미지 다이제스트, 빌드 소스.
  • FPM pool, 실제 서비스 단위, 컨테이너 또는 Pod, 복제본 수입니다.
  • 확장, 기본 구성 및 추가 구성 파일이 로드되었습니다.
  • 직접 액세스할 수 있는 다른 PHP 버전, 이전 배포 복사본 또는 원본 포털이 있습니까?

이는 “업그레이드”가 각 실제 트래픽 항목에 해당할 수 있도록 구현 제안입니다. 특히 명령줄 PHP 및 Web PHP가 다른 버전을 사용하는지, 이미지가 빌드되었지만 이전 컨테이너가 여전히 실행 중인지, 풀의 일부 또는 복사본이 대체되지 않는지 등을 확인하세요.

4.2 올바른 업데이트를 선택하고 배포하세요.

가급적 기존의 신뢰할 수 있는 패키지 소스나 제어된 빌드 체인을 사용하여 섹션 3에 따라 수정 버전을 확인하세요. 업데이트 범위에는 실제로 요청을 호스팅하는 구성 요소(예: FPM 패키지, Apache PHP 모듈, CGI 바이너리 또는 PHP가 포함된 서비스 빌드)가 포함되어야 합니다.

업그레이드하기 전에 구성 및 패키지 목록을 유지하고 프로덕션과 유사한 환경에서 시작 및 주요 서비스를 확인하십시오. 자체 유지 관리되는 확장의 경우 PHP 버전에 해당하는 빌드 및 실행 호환성을 확인하세요. 다른 브랜치에서 관련성이 있어 보이는 커밋을 선택한다고 해서 전체 수정 사항이 구현되었음을 보장할 수는 없습니다.

4.3 실행 중인 인스턴스 다시 시작 또는 롤오버

파일을 설치하는 것과 새 코드를 프로세스에 로드하는 것은 서로 다른 일입니다. 해당 서비스를 다시 시작하거나 롤링 교체를 완료하고 이전 작업자와 이전 컨테이너가 종료되었는지 확인해야 합니다.

mod_php의 경우 모듈을 호스팅하는 Apache 프로세스를 다시 시작합니다. PHP가 포함된 서비스에는 호스팅 프로세스를 교체해야 합니다. FPM의 경우 OPcache를 지워도 런타임 업데이트 및 이전 작업자 폐기가 대체되지 않습니다.

우아한 전환을 사용하는 경우 이전 세대 프로세스가 여전히 긴 연결이나 처리되지 않은 요청을 처리하고 있는지 확인해야 합니다. 수락 기록에는 실제 서비스, 배포 버전, 변경 완료 시간, 이전 인스턴스의 종료 결과가 포함되어야 합니다.

4.4 실제 Web 요청을 통해 확인

단일 버전 명령에만 의존하기보다는 다음 증거를 결합하는 것이 좋습니다.

증거증명할 수 있는 것혼자서는 아무것도 증명할 수 없어
패키지 관리자 또는 이미지 메타데이터설치 소스 및 전체 빌드트래픽이 이 인스턴스로 전환되었습니다.
프로세스 및 배포 상태작업자 또는 컨테이너 교체 완료외부 출입구가 그곳으로 연결되어야 합니다.
실제 포털을 통해 액세스되는 제한된 진단 결과실제 Web SAPI 및 실행 중인 구성릴리스 백포트에 CVE 2개가 포함되는지 여부
공급업체 발표 또는 전체 패치 기록이 버그 수정은 이 빌드에 포함되어 있습니다.모든 복제본이 배포되었습니다.

PHP_VERSION, PHP_SAPI, 로드된 구성 파일 및 비상 구성은 기존 내부 진단 기능 또는 임시 및 액세스 제어 진단 포털을 통해 확인할 수 있습니다. 요청이 CDN 또는 페이지 캐시에 의해 직접 반환되지 않는지 확인하세요. 완료되면 임시 진단 항목을 제거하십시오.

php -v는 일반적으로 현재 쉘에서 선택한 CLI 바이너리만 나타냅니다. php-fpm -i와 같은 명령은 트래픽을 수신하는 기존 작업자를 확인하는 것과 동일하지 않습니다. 전체 phpinfo() 페이지를 오랫동안 공용 네트워크에 노출하지 마십시오.

4.5 비즈니스 회귀 확인 및 긴급 설정 제거

이번 변경으로 영향을 받는 기능에 대한 정상적인 로그인, 세션 읽기 및 쓰기, 양식 및 업로드, 가져오기, 오류 처리 및 작업자 안정성을 확인하십시오. 오류율, 응답 지연, 메모리 피크, 프로세스 종료 및 재구축 빈도가 비정상인지 확인하십시오.

memory_limit=-1를 임시로 설정한 경우, 비즈니스 용량에 맞는 한정된 예산은 공식 패치 적용 후 복원됩니다. pm.max_requests=1가 설정된 경우 수리가 확인된 후 용량 평가 수명 주기 구성이 복원됩니다. 비즈니스 요구에 따라 입력 크기 제한과 소스 액세스 제어를 유지할 수 있습니다.

업그레이드 중에 호환성 문제가 발생하는 경우 영향을 받는 포털을 일시 중단하거나, 외부 액세스를 제한하거나, 롤백하기 전에 애플리케이션을 조정하는 데 우선 순위를 두어야 합니다. 복구되지 않은 런타임이 공용 네트워크에 다시 서비스를 제공하도록 직접 허용하면 원래 위험이 다시 발생합니다.

5. 즉시 업그레이드가 불가능한 경우 완화 조치

이 섹션은 단기적인 노출 감소 또는 가용성 향상을 위한 것입니다. 각 조치는 특정 경로에만 적용되며 여러 조치의 조합은 완전한 수리와 동일하지 않습니다. S1S2S3

5.1 PHP보다 먼저 교통 통제를 우선시합니다.

서비스에서 허용하는 경우 민감한 엔드포인트를 신뢰할 수 있는 소스로 일시적으로 제한하거나 PHP 이전에 액세스 제어를 시행하세요. 업로드 워크로드의 경우 요청 본문 크기, 필드 수, 부분 수, 부분당 헤더 및 중첩 깊이를 제한합니다. 멀티파트가 필요하지 않은 서비스는 프런트엔드에서 이를 거부할 수 있습니다. S2

이러한 제한 사항은 PHP의 모든 입구에 적용됩니다. “업로드”라는 URL를 가로채기만 하면 요청 본문에서 PHP에 의해 자동으로 구문 분석되는 다른 항목이 누락됩니다. 청크 전송, 사용 가능한 선언 길이 부족 등과 같은 경우 제한은 실제 읽기 크기를 기준으로 해야 합니다. 콘텐츠를 다시 압축 해제하거나 확장할 때 애플리케이션에는 자체 출력 크기 예산도 있어야 합니다.

5.2 FPM pool 구성 템플릿

php.ini에서 그대로 요청하는 것이 아니라 실제로 요청를 처리하는FPM pool 구성 섹션에 다음 설정을 지정합니다. 8M 및 4M 값은 워크로드에 맞게 조정하는 예입니다. 전체 POST 요청을 제한할 때 양식 필드 및 다중 부분 경계를 위한 공간을 남겨두십시오. S11S12

; Temporary mitigation: evaluate capacity before applying.
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M
php_admin_flag[session.upload_progress.enabled] = off

PHP 8.5만 해당, 추가:

php_admin_flag[fatal_error_backtraces] = off

각각의 기능과 경계는 다음과 같습니다.

구성기대효과유지해야 하는 제한 사항에 대한 설명
memory_limit=-1예측 가능한 PHP 요청 메모리 상한 트리거 조건을 제거합니다.기본 할당 실패를 방지하지는 않습니다. 원래 예산을 취소하면 메모리 고갈 및 서비스 중단 위험이 높아질 수 있습니다.
더 작은 post_max_size구문 분석 프로세스에 들어가는 데이터의 크기를 줄입니다.수정되지 않은 파서에는 알려진 간격이 있습니다. 메모리 증폭은 독립적으로 방지할 수 없습니다.
upload_max_filesize < post_max_size단일 파일 크기 제한 및 요청 오버헤드 공간 예약모든 필드, 메타데이터 또는 인앱 할당을 제한하지 않습니다.
업로드 진행 상황 닫기확인된 세션 관련 경로 차단다른 전역 상태 변형은 다루지 않습니다.
PHP 8.5 치명적인 역추적 닫기확인된 관련 상태 생성자 차단세션 등 다른 경로는 포함하지 않습니다.

측정 범위는 공식 발표에서 나옵니다. 풀 구문 및 관리 수준 구성 의미에 대해서는 PHP 매뉴얼을 참조하세요. S1S2S3S11

관리 수준 php_admin_* 설정은 ini_set()를 통해 애플리케이션으로 재정의될 수 없습니다. 모든 풀, 디렉터리 수준 및 프런트 엔드 수신 구성을 계속 검토하여 실제 요청의 값이 예상한 것과 같은지 확인해야 합니다. 수정 후에는 기존 프로세스가 이전 상태를 계속 유지하지 않도록 모든 작업자를 다시 빌드하세요.

php.ini를 직접 수정하도록 선택한 경우 구문을 다음과 같이 변경해야 합니다.

memory_limit = -1
post_max_size = 8M
upload_max_filesize = 4M
session.upload_progress.enabled = Off

풀의 php_admin_value와 달리 php.ini에 memory_limit=-1를 설정하는 것만으로는 앱이 다시 수정하는 것을 방지할 수 없습니다. 프레임워크, 애플리케이션 코드 및 기타 구성을 검사하여 제한된 값을 재설정했는지 확인해야 합니다. 적용이 필요한 경우 현재 SAPI에 적합한 관리 수준 설정을 사용하고 실제 유효 값을 확인하십시오. S11S12

PHP 8.5에만 fatal_error_backtraces = Off를 추가하세요. 업로드 진행을 비활성화하기 위한 해결 방법으로 애플리케이션 수준 ini_set()를 사용하지 말고 요청 구문 분석 전에 FPM .user.ini를 사용하여 이를 적용하지 마세요. S1S3

5.3 PHP 메모리 제한 제거 비용 관리

memory_limit=-1는 수정되지 않은 환경에 대한 임시 경로 완화이므로 장기 기본 구성으로 복사하면 안 됩니다. 애플리케이션이나 요청이 통제를 벗어나면 호스트 메모리를 더 많이 사용할 수 있습니다. 따라서 사용하기 전에 동시성 수, 최대 단일 작업자 및 총 서비스 용량을 평가하고 프런트엔드 입력 제한을 배포해야 합니다. S2

컨테이너 또는 cgroup 메모리 제한은 가용성 경계를 제공할 수 있지만 할당이 절대 실패하지 않을 것이라고 보장하지는 않습니다. 제한이 트리거되면 전체 컨테이너, 마스터 및 모든 작업자가 종료될 수도 있습니다. 격리 세분성 및 종료 전략은 배포와 함께 평가해야 하며 이 두 CVE에 대한 완전한 보호라고 할 수는 없습니다. S2

위의 전략을 RLIMIT_AS, RLIMIT_DATA 또는 해당 프로세스 주소 공간 제한으로 바꾸지 마십시오. 여전히 문제가 있는 OOM 경로에 기본 할당이 실패하도록 직접적으로 발생할 수 있습니다. S2

5.4 Nginx 구성 예

Nginx가 요청을 PHP-FPM로 전달하는 배포에 적용 가능합니다. 실제 호스팅 서비스의 구성 수준에서 설정할 수 있습니다.

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size는 요청 본문 크기를 제한합니다. fastcgi_request_buffering on를 사용하면 Nginx가 먼저 전체 요청 본문을 읽은 다음 이를 FastCGI 백엔드로 보낼 수 있습니다. 특정 server 또는 location에서 적용되는지 여부는 기존 상속 및 적용 범위 관계와 함께 확인해야 합니다. S13S14

비즈니스에 멀티파트가 필요하지 않은 경우에만 해당 서비스 입구에 거부 규칙을 추가할 수 있습니다.

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

이는 파서 취약점에 대한 일반적인 필터링 규칙이 아닌 if 및 return를 사용한 간단한 진입 제한 템플릿입니다. 배포하기 전에 구성 구문과 일반 요청을 확인하고, 사용자 지정 error_page가 403 요청을 PHP로 리디렉션하는지 확인하세요. 문자열 일치는 모든 구문 분석 차이점을 완벽하게 보장하지 않습니다. S15

또한 이러한 구성은 애플리케이션에서 압축을 풀 수 있는 데이터 양, 필드 수 또는 PHP 개체 수를 자동으로 제한하지 않습니다. 업로드해야 하는 기업은 요청 구조를 이해하는 추가 제한 사항을 사용해야 합니다.

5.5 선택적 완화: FPM 작업자당 요청 1개

오버헤드를 감당할 수 있는 FPM 배포의 경우 단기 설정을 평가할 수 있습니다.

pm.max_requests = 1

그리고 기존 작업자를 다시 빌드합니다. 작업자 재사용 수준에서 설명된 교차 요청 체인을 차단하지만 프로세스 생성 및 초기화 오버헤드가 증가합니다. 동시에 동일한 요청 OOM 및 CVE-2026-109618의 정리 문제를 복구할 수 없습니다. 값이 1보다 작지만 1보다 크면 여전히 요청 재사용 기간이 있습니다. S3S11

5.6 WAF 및 Cloudflare 적용 범위 제한

Cloudflare는 Free 계획을 포함하여 PHP2Shell에 대한 보호를 위한 배포 계획을 발표했습니다. 해당 서비스를 이용할 때 실제 트래픽이 프록시를 통과하는지, 보호 규칙이 적용되는지, 원본 사이트를 직접 우회할 수 있는지 여부를 확인해야 합니다. 유료 플랜의 경우 해당 관리 규칙의 구성 및 예외도 확인해야 합니다. S16

공급업체에서 설명하는 일부 탐지는 응답 신호를 활용하므로 모든 보호 기능을 “PHP에 도달하기 전에 모든 공격이 차단됩니다”라고 해석할 수는 없습니다. WAF는 노출을 줄이고 관찰 정보를 제공하는 데 도움이 될 수 있지만 PHP에 대한 지속적인 업그레이드가 여전히 필요합니다. S16

5.7 공통 조치가 부족한 이유

조치 또는 판단단점
file_uploads만 닫으세요.모든 멀티파트 처리를 처리할 수 없으며 자체 OOM 경로를 적용할 수 없습니다.
enable_post_data_reading=Off 설정POST/FILES를 자동으로 채우는 동작을 변경합니다. 요청 본문은 애플리케이션에서 계속 읽을 수 있으며 정상적인 비즈니스를 방해할 수 있습니다.
오류 표시를 끄고 기록하거나 @를 사용하세요.내부 진단 처리가 여전히 댕글링 상태에 액세스할 수 있습니다.
작업자 수를 늘려라안전한 상태 정리 메커니즘을 구축하거나 단일 작업자의 재사용을 제거하지 마세요.
disable_functions 또는 open_basedir만 구성이러한 제한 사항은 C 엔진 레이어 메모리 손상을 해결하지 못합니다.
버전이나 단일 복사본을 한 번만 확인하세요.모든 출입구와 실행 중인 인스턴스가 교체되었음을 입증할 수 없습니다.
예외 로그가 표시되지 않습니다.취약점이 존재하지 않거나 이전에 악용된 적이 없다는 것을 증명할 수는 없습니다.

그중 PHP의 구성 및 취약점 메커니즘 기반은 S2S3S12에서 확인할 수 있습니다. 적용 범위, 수용 및 허가 경계에 대한 판단은 이러한 메커니즘에서 제시된 구현 제안을 기반으로 합니다.

6. 정식 패치 구현 아이디어 및 검토 포인트

6.1 올바른 분기에 대한 완전한 수정 사항 사용

PHP 8.5의 대표적인 공식 제출물은 다음과 같습니다.

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

커밋은 두 개의 CVE를 명시적으로 연결하여 OOM 종료 메커니즘을 조정하고 초기화 단계에서 액세스할 수 있는 전역 상태를 수정합니다. 전체 차이점이 포함된 페이지를 제출하세요(S4S5 참조). 다른 지점에서는 자체 공식 보안 릴리스나 일치하는 패치를 사용해야 하며 8.5에 대한 변경 사항이 이전 버전에 직접 적용될 수 있다고 가정할 수 없습니다.

6.2 OOM 복구: 먼저 처리 가능한 상태를 복원한 후 요청을 종료합니다.

공식적인 구현에서는 소프트 및 하드 OOM 처리의 두 가지 수준을 도입합니다. 소프트 한계에 도달하면 보류 상태가 기록되고 VM와 같은 안전한 위치에서 제어된 종료가 수행됩니다. 실패 가능 할당 인터페이스를 사용하면 호출자가 명시적으로 실패를 처리할 수 있습니다. 실패를 직접 반환할 수 없는 할당의 경우 더 높은 하드 임계값을 초과할 것으로 예상되면 안전하지 않은 중간 상태에서 요청을 계속 처리하지 않도록 프로세스가 직접 종료됩니다. S2S5

다음은 보류 중인 OOM를 표시하는 데 사용되는 8.5 diff의 키 코드에서 발췌한 것입니다.

EG(delayed_oom).state = ZEND_OOM_STATE_PENDING;
zend_atomic_bool_store_ex(&EG(vm_interrupt), true);

VM 인터럽트 처리 및 기타 안전한 위치는 이후에 zend_handle_delayed_oom()를 호출합니다. 사용자 코드 실행 컨텍스트는 제어된 해제 경로를 사용합니다. 하드 OOM 경로는 _exit(137)를 호출합니다. S5

설계 관점에서 중요한 변경 사항은 다음과 같습니다. 구조가 중간 상태에 있을 때 C 호출 스택을 임의로 교차하는 것을 방지하고 상태 제약 조건을 유지할 수 있는 위치에 종료를 배치합니다. 소프트 제한이 트리거된 후 프로세스를 완료하려면 추가 메모리가 필요할 수 있으므로 새로운 소프트 임계값은 프로세스의 전체 메모리에 대한 절대적인 상한으로 이해될 수 없습니다.

또한 “PHP가 zend_bailout()를 모두 삭제했습니다”라고 요약할 수도 없습니다. 패치는 여전히 특정 상황에서 관련 메커니즘을 사용합니다. 수정된 것은 위험한 종료 시점과 이에 따른 상태 관리입니다. S5

6.3 할당 호출자와 멀티파트 구문 분석을 함께 업데이트합니다.

할당 함수를 “실패 시 NULL 반환”으로만 변경하고 원래 호출자가 여전히 유효한 포인터가 항상 반환된다고 가정하는 경우 새로운 null 포인터 액세스 또는 불완전한 정리가 발생합니다. 패치의 실패 가능한 할당 인터페이스는 호출자 확인 및 예외 전파와 함께 검토되어야 합니다. S5

멀티파트 관련 수정 사항에는 실제 읽기 볼륨을 기반으로 누적 검사 수행, 쓸모 없거나 중복된 헤더 처리 감소, OOM가 보류 중일 때 일관된 종료 및 정리 논리 채택도 포함됩니다. 이러한 변경 사항은 리소스 증폭을 줄이고 파서가 새로운 OOM 프로토콜을 준수하도록 만듭니다. S5

자체 브랜치를 유지 관리하는 팀의 경우 다음 문제에 코드 검토의 초점을 두는 것이 좋습니다.

  • 상태가 완전히 초기화되기 전에 외부 세계에 표시됩니까?
  • 할당 실패 또는 콜백 예외 후에도 소유권이 여전히 고유하고 모호하지 않습니까?
  • 중간에 실패하면 통합 정리 출구에 도달할 수 있나요?
  • 정리 기능이 초기화되지 않았거나 해제된 필드를 인식할 수 있습니까?
  • 파싱 예산은 단순히 신뢰 요청 청구가 아닌 실제 처리량을 기준으로 책정되나요?
  • 모든 호출자가 새로운 실패 반환 값을 처리했습니까?

이는 수정 메커니즘을 기반으로 요약된 검토 질문이며, 제공되지 않은 코드 베이스에 대해 완료된 감사의 결론이 아닙니다.

6.4 교차 요청 수정: 초기 초기화, 나중에 최종 정리

CVE-2026-109619에 해당하는 패치는 여러 수명 주기 경계를 동시에 조정합니다. 아래 나열된 파일 및 작업은 PHP 8.5 공식 diff를 예로 사용합니다. S5

위치방향을 바꾸다문제 해결
Zend/zend_execute_API.c 등오류, 예외, 핸들러, 객체 등과 같은 실행자 상태를 재설정합니다.요청이 종료된 후에도 다음 요청에서 액세스할 수 있는 이전 참조가 여전히 남아 있습니다.
main/main.c의 시작 경로SAPI가 활성화되기 전에 php_basic_early_rinit()를 호출하세요.초기 소비자가 발생하면 관련 기본 상태가 아직 초기화되지 않은 것입니다.
main/main.c의 경로 닫기HTTP globals를 삭제하고 정의되지 않음으로 표시릴리스된 값은 여전히 유효한 개체로 간주됩니다.
요청 힙이 최종적으로 해제되기 전에마지막 오류 메시지를 다시 정리하세요.늦은 정리 진단으로 오류 상태가 다시 채워집니다.
ext/session/session.c업로드 진행 초기 경로가 초기화되었습니다. 첫 번째 세션 전역일반 모듈 RINIT는 이전에 이전 상태에 액세스했습니다.
직렬화 관련 코드초기 처리에서 클래스 구문 분석 및 사용자 콜백을 제한합니다.초기화가 완료되지 않은 경우 추가 사용자 코드 실행

예를 들어 시작 순서에는 다음이 포함됩니다.

zend_activate();
php_basic_early_rinit();
sapi_activate();

HTTP globals가 파괴된 후 상태 실패 표시를 추가합니다.

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

이 발췌문에서는 가능한 가장 빠른 소비자 이전에 초기화하고 상태를 다시 생성할 수 있는 마지막 작업 후에 최종 정리를 수행한다는 두 가지 원칙을 설명합니다. 일반적인 RINIT 또는 이전 종료 단계에서만 포인터를 재설정하면 이전 또는 이후 액세스가 누락될 수 있습니다. S5

6.5 왜 자신만의 “단선 수리”를 권장하지 않습니까?

모든 zend_bailout()를 _exit()로 바꾸거나 특정 항목에 널 포인터 검사를 추가하면 다양한 실행 컨텍스트가 확장됩니다. 다른 상태 필드를 생략하거나 소멸, 확장 콜백, 프로세스 호스팅 및 요청 최종 의미 체계를 변경할 수 있습니다.

지원되는 버전의 경우 이미 릴리스된 전체 수정 사항이 우선적으로 적용됩니다. 자체 지점의 마이그레이션에서는 패치 소스, 적용 가능한 기준, 충돌 처리 및 동작 변경 사항을 기록하고 해당 업스트림 회귀 사용 사례와 이 비즈니스 프로세스의 검증을 사용해야 합니다. 여기의 제안은 할당자, VM, 세션 및 요청 수명주기 변경 전반에 걸친 패치 범위 분석에서 나온 것입니다. S4S5

7. PHP 7.4, 8.0, 8.1의 비상 백포트

PHP는 심각도에 따라 세 가지 이전 분기의 최소 소스 코드 백포트를 공식적으로 제공합니다. 지점 이름은 다음과 같습니다.

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

분기 링크는 S7S8S9를 참조하세요. 이는 이 취약점에 대한 긴급 전달이며 이전 분기에 대한 정기적인 업스트림 지원으로의 복귀를 의미하지 않으며 다른 보안 업데이트를 대체하지도 않습니다. S1

7.1 PHP 8.1 백포트를 예로 들어 보겠습니다.

PHP 8.1에 대한 관련 제출물은 다음과 같습니다.

1d7dec178a094e6e75b229ce22754045f8c6070a

해당 전략은 빠른 실패를 선호합니다. 해당 OOM 경로에서 진단을 출력하고 전역 상태 및 기타 관련 수정 사항을 포함하여 _exit(1)를 호출합니다. 내부적으로 세션 업로드 진행의 해당 처리를 비활성화합니다. 관련 소스 코드 제출은 S6를 참조하세요.

이는 지원되는 분기에서 보다 완전한 지연된 OOM 설계와의 동작 차이입니다. 구성에 여전히 업로드 진행 상태가 표시된다고 해서 이 백포트 이후의 내부 처리 동작이 변경되지 않은 상태로 유지된다는 의미는 아닙니다.

7.2 배포 시 수용해야 하는 가격

프로세스를 직접 종료하면 현재 요청이 실패하고 일반적인 PHP 종료 콜백을 건너뛰고 애플리케이션 일부가 닫힐 수 있습니다. 호스트가 스레드 모델을 채택하는 경우 전체 호스트 프로세스 종료가 다른 동시 작업에 미치는 영향도 평가해야 합니다. 프로세스 관리자가 적시에 교체 프로세스를 시작할 수 있는지 여부도 검증에 포함되어야 합니다.

따라서 이전 버전 사용자는 다음 사항을 순서대로 고려해야 합니다.

  1. 지원되는 PHP 분기 및 해당 수정 버전으로 마이그레이션합니다.
  2. CVE 또는 LTS 제조업체 업데이트를 모두 명시적으로 포함하는 릴리스를 사용하십시오.
  3. 실제로 이전 버전의 소스 코드가 적용되는 경우 일치하는 버전의 공식 긴급 백포트를 사용하여 전체 변경 사항과 호환성을 확인하고 후속 마이그레이션을 준비합니다.

여기서 “최소 백포트”는 공식적으로 선택한 호환성 및 구현 범위를 설명하며 “알려진 불완전한 취약점 수정”으로 자동 해석되어서는 안 됩니다. 해당 브랜치의 소스코드와 제조사의 공지사항을 토대로 판단하시고, 지원되는 변경사항을 임의로 삭제하지 마세요. S1S6

8. 합격기준 및 사후검사

이 수리를 완료하기 위한 기초로 다음 결과를 사용하는 것이 좋습니다.

접수항목완성기준
취약점 적용 범위빌드 또는 공급업체 발표로 CVE-2026-109618 및 CVE-2026-109619가 명시적으로 수정되었습니다.
배포 범위모든 포털, 풀, 서비스 및 복제본은 복구된 런타임을 사용합니다.
프로세스가 적용됩니다.이전 작업자, 이전 호스트 프로세스 및 이전 컨테이너가 모두 종료됩니다.
실제 요청 확인캐시 잘못된 방향을 제거하기 위해 실제 Web 링크로 구축 및 구성된 SAPI 확인
비즈니스 가용성세션, 업로드, 가져오기, 오류 처리 등 주요 기능이 정상적으로 반환되었습니다.
임시조치 종료무제한 메모리 및 극한의 작업자 재활용 구성이 용량 계획에 따라 복원되었거나 보존 이유가 명확함
변화의 증거패키지 버전 또는 이미지 다이제스트, 업데이트 범위, 완료 시간 및 확인 결과를 기록합니다.

위 내용은 구현을 위한 제안 사항입니다. OOM 동작, 비정상적인 종료 또는 사용자 정의 패치를 확인해야 하는 경우 격리된 환경에서 업스트림 회귀 테스트 또는 제어된 결함 주입을 사용하여 수용 방법으로 프로덕션 환경에서 반복적으로 메모리 소모가 발생하지 않도록 해야 합니다.

또한 업데이트 전후의 PHP 치명적, 작업자 충돌, 비정상적인 재시작, 요청 오류율 및 WAF 이벤트를 확인하세요. 로그는 조사 단서를 제공할 수만 있습니다. OOM가 발생했다고 해서 악용되었다는 의미는 아니며, 경보가 없다고 해서 악용이 발생하지 않았다는 의미는 아닙니다. 업그레이드는 향후 도달할 수 있는 취약성 경로를 수정합니다. 파일 변조나 자격 증명 유출 등의 이상이 발견되면 별도의 사고 조사가 수행되어야 합니다.

부록: 인용 출처 및 링크

모든 소스 링크는 아래에 수집되어 있습니다. 권고, 패치 및 공급업체 지침에는 2026년 10월 22일 기준 점검 사항이 반영됩니다. 후속 배포에서는 공급업체 업데이트를 확인해야 합니다. 본문에서 번호가 매겨진 인용은 이러한 항목을 나타냅니다.

S1 — PHP 공식 보안 게시판 및 복구 버전

  • 출처: 프로젝트 PHP, 2026년 10월 21일.
  • 목적: 위험 범위, 4가지 공식 수리 버전, 공식적인 임시 조치 및 이전 지점에 대한 긴급 백포트 지침.
  • 참고 자료: PHP 2026 This security bulletin는 연간 게시판 아카이브에 있습니다.

S2 — CVE-2026-109618 공식 기술 게시판

  • 출처: php/php-src GitHub Security Advisory, 2026년 10월 21일.
  • 식별번호: GHSA-w8hw-w9fx-j79w.
  • 목적: OOM에 대한 적용 범위 경계, 다중 부분 증폭, SAPI 차이 및 완화.
  • 참고 자료: RCE via OOM corruption

S3 — CVE-2026-109619 공식 기술 게시판

  • 출처: php/php-src GitHub Security Advisory, 2026년 10월 21일.
  • 식별번호: GHSA-6wmf-4rv5-p3rp.
  • 목적: 교차 요청 매달려 상태, 생산자와 소비자, 조기 초기화, 구성 완화.
  • 참고 자료: RCE via stale global state

S4 — PHP 8.5 공식 수정 사항 제출

  • 출처: php/php-src.
  • 제출: 31c0ea7d7ff1d1fccb6492e52dab544011628065.
  • 목적: 두 가지 취약점을 동시에 수정하기 위해 정식 제출을 확인하고 전반적인 변경 방향을 설명합니다.
  • 참고 자료: Avoid state corruption via bailout

S5 — PHP 8.5 공식적으로 복원되고 완전한 차이점

  • 출처: 동일한 공식 제출물과 다릅니다.
  • 목적: 할당자 VM, HTTP globals, 세션, 직렬화 및 요청 수명 주기의 구체적인 구현을 확인합니다.
  • 참고 자료: official complete diff

S6 — PHP 8.1 공식 긴급 백포트 제출

S7 — PHP 7.4 공식 비상 백포트 지점

S8 — PHP 8.0 공식 비상 백포트 지점

S9 — PHP 8.1 공식 비상 백포트 지점

S10 — Ubuntu 보안 게시판 USN-8948-1

  • 출처: Canonical / Ubuntu, 2026년 10월 21일.
  • 목적: 백포트 및 전체 패키지 버전 예제를 릴리스합니다.
  • 참고 자료: USN-8948-1: PHP vulnerabilities

S11 — PHP-FPM Configuration 매뉴얼

  • 출처: PHP 공식 문서.
  • 목적: php_admin_value, php_admin_flag, pm.max_requests 등과 같은 구성 의미.
  • 참고 자료: PHP-FPM Configuration

S12 — PHP 코어 INI 구성 매뉴얼

S13 — Nginx 요청 본문 크기 제한

S14 — Nginx FastCGI 요청 버퍼

S15 — Nginx 조건 및 반환 지침

S16 — Cloudflare PHP2Shell 보호 지침