피드

PHP 코어에 인증 없는 원격 코드 실행 취약점 2건… 전 세계 웹 서버 긴급 패치

4℃

PHP 코어 보안 패치 안내.png

‘PHP2Shell’(CVE-2026-109618·CVE-2026-109619), CVSS 9.2 — 엠바고 유출로 하루 앞당겨 패치 공개

PHP 개발팀이 2026년 10월 21일 14시(UTC, 한국시간 22일 23시) 긴급 보안 릴리스를 공개했습니다. 수정된 취약점은 두 건으로, 모두 인증 없이 원격에서 코드를 실행할 수 있고 CVSS 4.0 기준 9.2점을 받았습니다. 취약점이 애플리케이션이 아니라 PHP 엔진 자체에 있어, 워드프레스·드루팔·라라벨·마젠토 등 PHP로 돌아가는 사실상 모든 사이트가 영향권입니다. KISA도 10월 22일 보안 업데이트를 권고했습니다.

 

무슨 취약점인가

CVE-2026-109618 — 메모리 부족(OOM) 처리 중 메모리 손상
이 오류는 프로세스의 메모리 할당이 실패해 요청 처리가 중단될 때, 아직 초기화가 끝나지 않은 요청 데이터를 종료 과정에서 정상 데이터로 취급하면서 발생합니다. 이점을 이용해 조작된 multipart 요청으로 오류를 유발할 수 있습니다.

PHP 개발팀은 아파치 mod_php의 일반적인 구성에서 인증되지 않은 HTTP 요청만으로 코드 실행을 검증했으며, 웹 애플리케이션 코드가 실행되기 전 단계에서 공격 경로가 작동한다고 밝혔습니다.

따라서 애플리케이션 코드를 아무리 안전하게 작성해도 막을 수 없다는 뜻입니다.

 

CVE-2026-109619 — 요청 간 잔존 상태로 인한 Use-After-Free
이전 요청에서 해제된 메모리를 내부 상태가 계속 가리키고 있어, 같은 워커 프로세스가 처리하는 이후 요청이 그 오래된 상태를 참조하면서 코드 실행으로 이어집니다. 확인된 경로는 세션 업로드 진행률(session upload progress) 기능과, PHP 8.5의 치명적 오류 백트레이스(fatal_error_backtraces) 기능입니다. PHP 공식 권고문은 메모리 정보 노출도 확정 영향으로 함께 적었습니다.

 

두 건 모두 PHP-FPM, 아파치 mod_php, php-cgi, FrankenPHP, LiteSpeed 환경이 영향을 받으며, PHP 개발팀은 mod_php의 위험을 가장 높게 평가했습니다.

 

이 취약점이 영향 받는 버전과 수정 버전

PHP 계열 취약 버전 수정 버전
8.5 8.5.12 미만 8.5.12
8.4 8.4.27 미만 8.4.27
8.3 8.3.36 미만 8.3.36
8.2 8.2.35 미만 8.2.35
7.4 ~ 8.1 전 버전 공식 릴리스 없음 — 소스 백포트만 제공
5.4 ~ 7.3 전 버전 지원 종료, 수정 없음

주의할 점은 배포판 패키지는 버전 문자열이 다르다는 것입니다. 예컨대 우분투 24.04 LTS의 수정 패키지는 8.3.6-0ubuntu0.24.04.13으로, 앞자리만 보면 8.3.36보다 낮아 보입니다. 리눅스 배포판과 LTS 벤더는 사전에 패치를 받았으므로, 버전 번호가 아니라 패키지 체인지로그의 CVE 번호를 확인해야 합니다.

 

타임라인 — 엠바고가 깨졌습니다

이번 건의 특이점은 공개 과정입니다. (모두 2026년, UTC 기준)

  • 10/20 저녁 — Hacker News에 “10월 22일 공개 예정”이라며 CVE 번호가 유출됩니다. 유출본에 적힌 CVSS 10.0은 PHP 측 평가가 아닌 오류였습니다(실제 9.2). PHP는 같은 날 저녁 사전 공지를 내고 릴리스를 10월 21일로 하루 앞당깁니다.
  • 10/20 20:00경 — Calif가 작동하는 PoC 영상을 실수로 공개합니다.
  • 10/21 03:02 — 클라우드플레어가 패치 공개 전에 WAF 규칙을 기본 활성화합니다.
  • 10/21 07:41 — Chainguard가 패치 적용 이미지를 릴리스 약 6시간 전에 공개합니다.
  • 10/21 14:00 — PHP가 예정대로 수정 버전을 배포합니다.
  • 10/22 — KISA가 국내 보안 업데이트를 권고합니다.

 

현재까지 이 취약점을 이용한  실제 침해 성공 사례를 보고하지 않았습니다. 공개된 익스플로잇 코드가 돌아다니지만 작동 여부는 검증되지 않았고, PHP 재단은 "공개 시점에 작동하는 익스플로잇을 확인하지 못했다"는 입장입니다. 다만 예방 차원의 서비스 중단은 실제로 나왔습니다 — BambooHR이 미국·캐나다·아일랜드 서비스를 내렸고, 네덜란드·핀란드 일부 공공·교육 기관 사이트도 중단됐습니다. 네덜란드 국가사이버보안센터는 악용 사례를 보지 못했다고 밝혔습니다.

 

노출 규모 추정치는 130만~190만 대로, 실라스 커틀러가 취약 가능 호스트 130만 대 이상, Shodan 검색 기준 PHP 구동 호스트 190만 대 이상으로 집계했습니다.

 

PHP로 운영되는 시스템이 있다면 지금 해야 할 일

1. 즉시 업데이트가 유일한 완전 해결책입니다. 

2. php -v 결과만 믿지 마세요. 실제 웹 요청을 처리하는 환경이 전부 패치됐는지 따로 확인해야 합니다.

  • 가상호스트별 실행 환경
  • 컨테이너 이미지 (재빌드·재배포 필요)
  • 호스팅 사업자가 제공하는 PHP
  • 상용 제품에 내장된 PHP

3. 업데이트 후 워커를 반드시 재시작하세요. 기존 워커 프로세스가 계속 살아 있으면 패치가 적용되지 않습니다. 컨테이너는 재배포까지 검증해야 합니다.

4. 로그에 흔적이 없다고 안전한 것은 아닙니다. 진단 정보를 숨기는 것으로는 잔존 상태 접근을 막을 수 없습니다.

5. PHP 8.1 이하는 업그레이드가 답입니다. 공식 릴리스가 없어 소스 백포트를 직접 빌드하거나, 지원 버전으로 올리거나, 배포판·LTS 벤더 패치를 받아야 합니다.

 

임시 완화책 — 노출을 줄일 뿐, 안전해지지 않습니다

패치를 즉시 적용할 수 없는 경우에 한한 조치이고 아래의 조치를 하면 임시로는 방어가 됩니다.

  • CVE-2026-109618: memory_limit=-1을 애플리케이션이 덮어쓸 수 없도록 관리자 레벨에서 강제. 유한한 값으로 되돌리는 설정이 없는지 확인
  • CVE-2026-109619: session.upload_progress.enabled=0을 php.ini·FPM 풀·서버 설정에 적용. 애플리케이션의 ini_set()이나 FPM .user.ini는 시점이 너무 늦어 무효
  • PHP 8.5: fatal_error_backtraces=0을 관리자 레벨에서 설정
  • post_max_size를 8M(업로드 필요 시 32M)로, upload_max_filesize를 그보다 낮게
  • 프론트엔드에서 요청 크기·multipart 개수·파트별 헤더 수·중첩 깊이 제한
  • 애플리케이션이 multipart를 쓰지 않으면 PHP에 닿기 전에 차단
  • RLIMIT_AS·RLIMIT_DATA는 사용하지 마세요 — 오히려 취약 경로를 유발할 수 있습니다

클라우드플레어는 무료 요금제까지 포함해 전 고객에게 WAF 규칙을 배포했지만, 자체적으로 ”임시방편"이라고 밝혔습니다. 클라우드플레어를 경유하는 트래픽만 보호되고, 공격자가 페이로드를 바꿔 우회를 시도한 사례도 이미 보고됐습니다. CERT-EU는 패치 적용·검증 전까지 인터넷 노출 애플리케이션을 공용망에서 분리할 것을 권고했습니다(권고문 2026-018).

 

KISA는 10월 22일 보안 업데이트를 권고하며 두 취약점을 각각 '부적절한 예외 상황 처리'(109618), '해제 후 사용'(109619)으로 분류했습니다. PHP 8.1 이하는 공식 보안 지원이 종료됐으므로 지원 버전으로 업그레이드할 것을 함께 권고했습니다. 미 NSA도 기관·기업에 업데이트 준비를 권고했고, CISA는 10월 21일 “Critical Vulnerabilities in PHP Require Immediate Patching” 경보를 발행했습니다.

W3Techs 기준 언어 식별이 가능한 웹사이트의 약 75%가 PHP를 사용하고, 워드프레스 하나만으로도 전체 웹사이트의 약 43%를 차지합니다. 국내 사정은 더 직접적입니다 — 그누보드·XE·라이밍스 등 국내 커뮤니티 CMS가 모두 PHP 기반이고, 상당수가 공유 호스팅에서 돌아갑니다.

공유 호스팅은 PHP 버전 선택권이 사업자에게 있어 운영자가 직접 패치할 수 없는 경우가 많습니다.

사용 중인 호스팅의 PHP 패치 적용 여부를 사업자에 직접 확인하는 것이 현실적인 첫 조치입니다. 오래된 그누보드 사이트가 PHP 7.x대에 묶여 있다면 공식 수정 버전이 없는 구간이라 더 시급합니다.

 

참고링크

0 0