PHP 원격 코드 실행 취약점 2건, 지금 바로 패치하세요

출처: PHP.net (The PHP Group)
원문: https://www.php.net/index.php
작성자: 팔복소프트-김팔복

한눈에 보기

• 2026년 10월 21일 PHP 팀이 인증 없이 원격 코드 실행(RCE)이 가능한 치명적 취약점 2건을 공개하고 패치를 내놨습니다.
• 고친 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35이고, PHP 팀은 모든 사용자에게 즉시 업데이트를 권고합니다.
• 웹 요청을 처리하는 PHP라면 PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed 구분 없이 모두 대상입니다.
• 가장 위험한 건 Apache mod_php로, 애플리케이션 코드가 실행되기도 전에 공격이 시작되는 익스플로잇이 이미 확인됐습니다.
• 설정으로 위험을 줄이는 방법도 안내됐지만 PHP 팀 스스로 "업데이트만이 안전한 선택"이라고 못 박았습니다.
• PHP 8.1 이하는 공식 업데이트가 없어 벤더 백포트를 찾거나 업그레이드해야 합니다.

배경

이번 두 취약점은 PHP 엔진이 요청을 받아 처리하고 정리하는 과정, 즉 우리가 작성한 코드 아래층에서 생겼습니다. 프레임워크나 CMS와 상관없이, 애플리케이션 코드가 아무리 깔끔해도 영향을 받습니다.

주요 내용

두 취약점은 무엇이 다른가

그림 1. 두 취약점의 원인과 임시 완화책 비교 (팔복소프트 작성)

CVE-2026-109618 (OOM 메모리 손상): 메모리 부족으로 PHP가 처리를 멈추는 시점이 내부 요청 데이터가 절반쯤 초기화됐을 때라면, 이후 정리 단계가 그 미완성 데이터를 정상으로 착각할 수 있습니다.

CVE-2026-109619 (남아 있는 전역 상태): 요청 하나가 쓰던 내부 상태가, 그 메모리가 해제된 뒤에도 남아 있을 수 있습니다. 같은 워커가 다음 요청을 받으면 정상 초기화가 끝나기 전에 그 낡은 상태를 쓰게 됩니다. 치운 줄 알았던 책상에 앞사람 짐이 남은 셈입니다.

어떤 버전으로 올려야 하나

리눅스 배포판과 LTS 벤더는 패치를 미리 받았기 때문에, 패키지로 PHP를 설치했다면 배포판의 보안 업데이트부터 확인하면 됩니다. PHP 7.4, 8.0, 8.1은 지원이 끝났지만, 사안이 심각해 PHP 보안팀이 최소한의 소스 백포트 브랜치를 따로 공개했습니다. LTS 벤더 없이 소스로 빌드하는 곳을 위한 조치입니다.

당장 업데이트할 수 없다면

PHP 팀이 안내한 임시 조치는 특정 공격 경로를 막을 뿐, 설치 환경을 안전하게 만들어 주지는 않는다고 분명히 적혀 있습니다.

• OOM 쪽: memory_limit=-1을 애플리케이션이 덮어쓸 수 없는 위치(FPM 풀의 php_admin_value, Apache 설정)에 지정합니다. post_max_size는 업로드가 없으면 8M, 있으면 32M으로 낮춥니다. 메모리 상한은 컨테이너나 cgroup으로 걸고, RLIMIT_AS·RLIMIT_DATA로 대신하면 오히려 취약한 경로를 부를 수 있습니다.
• 전역 상태 쪽: session.upload_progress.enabled=0을 php.ini나 FPM 풀 설정에 넣고 모든 워커를 재시작합니다. ini_set()이나 .user.ini로는 효과가 없습니다. PHP 8.5라면 fatal_error_backtraces=0도 같이 설정합니다.
• 진단 메시지를 error_reporting이나 @로 숨기는 건 도움이 되지 않습니다.

FPM 풀 설정이라면 대략 이런 모양이 됩니다.

; /etc/php/<버전>/fpm/pool.d/www.conf (임시 조치, 패치 전까지만)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[session.upload_progress.enabled] = 0

설정 후에는 systemctl restart php<버전>-fpm처럼 워커를 전부 다시 띄워야 반영됩니다.

팔복소프트 관점

• 국내에서 체감 범위가 넓은 사고입니다. 그누보드, 라이믹스, WordPress 사이트와 오래된 사내 관리 도구까지 국내 웹에는 PHP가 깊게 깔려 있고, 공유 호스팅이나 오래된 서버에는 하필 가장 위험하다고 지목된 mod_php 구성이 아직 흔합니다.
• 버전 숫자만 보고 판단하지 마세요. 배포판 패키지는 업스트림 버전 번호는 그대로 두고 패치만 얹는 경우가 많습니다. php -v만 보지 말고 배포판 보안 공지에서 해당 CVE가 반영됐는지 확인하세요.
• 컨테이너는 이미지 재빌드가 곧 패치입니다. 서버에서 apt upgrade를 해도 이미 배포된 컨테이너 안의 PHP는 그대로입니다. 베이스 이미지를 새로 받아 다시 빌드하고 배포하기 전까지는 패치되지 않은 상태라고 보는 게 안전합니다.
• 임시 완화책은 부작용을 따져야 합니다. memory_limit=-1은 상한을 컨테이너나 cgroup에 맡기라는 뜻이라, 그 경계가 없는 VM에서는 한 요청이 서버 메모리를 다 잡아먹을 수 있습니다. 완화책을 넣을 시간이면 대부분 패치가 더 쌉니다.
• PHP 8.1 이하, 8.2 사용 팀에게는 업그레이드 신호입니다. 이번엔 보안팀이 예외적으로 백포트를 내줬지만, 매번 그럴 거라 기대할 근거는 없습니다. 8.2도 올해 말이면 지원이 끝나니, 이번 패치 작업을 하는 김에 다음 버전 이전 일정을 같이 잡아 두길 권합니다.

그림 2. 운영 중인 PHP 서버의 대응 순서 (팔복소프트 작성)

정리

애플리케이션 코드로 막을 수 있는 문제가 아니니, 기억할 건 세 가지입니다. 지원 브랜치는 8.5.12, 8.4.27, 8.3.36, 8.2.35로 올리고, 배포판·컨테이너 환경은 각자의 경로로 패치가 실제 반영됐는지 확인하고, 임시 완화책은 패치까지 버티는 용도로만 씁니다.

• PHP
• 보안 패치
• 원격 코드 실행
• CVE-2026-109618
• PHP-FPM