2026년 10월 21일 PHP 프로젝트는 치명적 취약점 두 건에 대한 수정 버전을 공개했고, CERT-EU도 같은 날 보안 권고 2026-018을 발표했습니다. 두 취약점 모두 심각도 9.2로 평가되었으며, 인증 없는 원격 코드 실행으로 설명됩니다. WordPress 사이트, 쇼핑몰 또는 다른 PHP 애플리케이션을 운영하신다면 해당되는 이야기이며, 해결책은 설정 변경이 아니라 업데이트입니다. 이 글에서는 알려진 내용, 공격이 들어오는 경로, 그리고 해야 할 일을 설명합니다. 기준 시점은 2026년 10월 22일이며, CERT-EU 권고 1.1판을 바탕으로 합니다.
무슨 일이 있었는가
- 보안 릴리스 예고PHP가 보안 버전을 미리 예고함
- 수정 버전 공개8.5.12, 8.4.27, 8.3.36, 8.2.35
- CERT-EU 권고 2026-018두 취약점 모두 9.2로 평가
- 개념 증명 코드 유포공격은 확인되지 않았지만 가능성은 높아짐
PHP는 10월 20일에 보안 릴리스를 예고했고, 10월 21일 13:30 UTC에 수정 버전을 공개했습니다. CERT-EU는 권고문 제목을 「Critical Vulnerabilities in PHP」로 정하고 두 건의 CVE, 즉 CVE-2026-109618과 CVE-2026-109619를 나열했으며, 각각 9.2점으로 평가했습니다. CERT-EU는 또한 기술적 세부 사항이 이미 공개적으로 논의되고 있고 최초의 개념 증명(Proof of Concept) 코드가 돌기 시작했다고 적고 있습니다. 권고문은 실제 공격을 확인한 것은 아니지만, 이로 인해 공격자가 이미 취약점을 악용하고 있을 가능성이 높아졌다고 말합니다. 긴급한 사안으로 다루십시오.
누가 영향을 받는가
영향을 받는 것은 지원 중인 브랜치에서 수정 버전보다 낮은 모든 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 보안팀이 7.4, 8.0, 8.1용 최소한의 소스 코드 백포트를 공개함 |
CERT-EU는 PHP-FPM, mod_php를 사용하는 Apache, php-cgi, FrankenPHP, LiteSpeed를 언급합니다. PHP 팀에 따르면 mod_php의 위험이 가장 높습니다. PHP를 내장한 제품도 영향을 받을 수 있으며, CERT-EU는 이 글 끝에 있는 네덜란드 NCSC의 목록을 참고하라고 안내합니다. 업로드 양식이 있든 없든, 웹 요청을 처리하는 설치는 모두 해당됩니다.
공격자가 첫 번째 취약점에 도달하는 방법
로그인할 필요가 있는 사람은 아무도 없습니다. CERT-EU에 따르면, 시연된 공격 코드는 인증 없는 요청 한 번만으로 애플리케이션 코드가 실행되기 전에 공격을 일으킬 수 있음을 보여 줍니다. 대부분이 놓치는 부분이 바로 이것입니다. WordPress가 최신인지, 플러그인에 패치가 적용되었는지, 문의 양식이 보호되고 있는지는 중요하지 않습니다. 요청은 먼저 PHP 엔진에 도달합니다.
첫 번째 취약점인 CVE-2026-109618은 다음과 같이 동작합니다.
- PHP가 처리하는 주소로 요청이 들어옵니다. 로그인도 계정도 필요 없습니다.
- PHP가 요청 본문을 읽기 시작합니다. CERT-EU는 예로 양식 기반 파일 업로드의 파싱을 듭니다.
- PHP는
longjmp()로memory_limit를 강제합니다. 한도를 넘으면 하던 작업에서 곧바로 빠져나와 요청을 끝냅니다. - 이것이 내부 요청 데이터를 구성하는 도중에 일어나면, 그 데이터는 절반만 만들어진 상태가 됩니다.
- 이어지는 정리 단계는 유효하지 않은 데이터를 유효한 것으로 취급하여, 한 번도 초기화되지 않은 메모리를 해제합니다. 그 메모리에는 공격자가 조작할 수 있었던 이전 할당의 데이터가 남아 있을 수 있습니다.
- 그 지점부터 권고문은 서버에서의 코드 실행을 설명합니다.
공격자가 마지막 단계를 어떻게 조종하는지는 의도적으로 설명하지 않습니다. 진입점이 귀하의 애플리케이션이 아니라는 것만 알면 충분하며, 그렇기 때문에 애플리케이션 내부의 어떤 것도 이를 막을 수 없습니다.
두 번째 취약점: 메모리보다 오래 남는 상태
CVE-2026-109619는 메커니즘은 다르지만 결과는 같습니다. PHP는 요청마다 내부 상태를 유지합니다. 치명적 오류(Fatal Error) 같은 특정 실패 뒤에는 그 아래의 메모리는 해제되었는데도 상태가 그대로 남을 수 있습니다. 같은 워커가 다음에 처리하는 요청은 이 낡은 상태가 정상적으로 초기화되기 전에 그것을 사용할 수 있습니다. 공격자에게는 같은 워커에 도달하는 요청 두 건이 필요하며, CERT-EU는 그 결과를 첫 번째 취약점과 같은 원격 코드 실행으로 평가합니다.
오늘 해야 할 일
서버의 PHP가 8.5.12, 8.4.27, 8.3.36, 8.2.35보다 낮습니까, 또는 8.1 이하입니까?
- 예두 취약점 모두의 영향을 받습니다. 다음 질문으로 넘어가십시오.
- 아니요웹 서버가 실제로 실행하는 버전이 이것이 맞다면 두 취약점 모두 수정되었습니다.
오늘 업데이트할 수 있습니까?
- 예업데이트하고, 모든 PHP 워커를 재시작하고, 실행 중인 버전을 확인하십시오.
- 아니요수정될 때까지 서버를 공용 네트워크에서 분리하십시오. 제한은 위험을 낮출 뿐입니다.
- 실제로 사이트를 구동하는 PHP 버전을 확인하십시오. 명령줄에서
php -v를 실행하면 명령줄용 버전이 표시되는데, 이는 웹 서버가 사용하는 버전과 다를 수 있습니다.php-fpm -v, 호스팅 관리 패널, 또는phpinfo()를 호출하는 페이지에서 확인하십시오. 공유 호스팅이라면 제공업체에 문의하십시오. - 수정된 버전으로 업데이트하십시오: 8.5.12, 8.4.27, 8.3.36 또는 8.2.35입니다. 배포판은 버전 번호를 바꾸지 않고 수정만 백포트하는 경우가 많으므로, 공급업체의 보안 공지에서 CVE 번호를 찾아보십시오. 컨테이너에서는 업데이트된 기본 이미지로 다시 빌드하십시오. PHP 팀은 릴리스 당일 rpms.remirepo.net에 업데이트가 없었다고 밝히며, 배포판 패키지나 소스 코드 빌드를 권장합니다.
- 모든 PHP 워커를 재시작하십시오. 디스크의 업데이트는 이미 실행 중인 프로세스를 바꾸지 못합니다. PHP-FPM 또는 웹 서버를 재시작한 뒤, 실행 중인 버전을 다시 확인하십시오.
- 오늘 업데이트할 수 없다면 서버를 공용 네트워크에서 분리하십시오. 수정이 적용되고 확인될 때까지입니다. CERT-EU는 오직 업데이트만이 이 취약점을 완전히 해결한다고 분명히 말합니다.
- PHP 8.1 이하를 사용 중이라면, 공급업체에 백포트를 요청하거나 지원되는 브랜치로 옮기십시오. 이 버전들에는 정기 업데이트가 제공되지 않습니다.
위험은 줄이지만 해결하지는 못하는 우회책
CERT-EU는 공격을 어렵게 만드는 조치를 나열합니다. 이 조치들로 설치가 안전해지는 것은 아니라고 분명히 밝힙니다. 업데이트를 준비하는 동안 사용하시고, 업데이트를 대신하는 용도로 쓰지 마십시오.
- CVE-2026-109618 대응: 애플리케이션이 덮어쓸 수 없는 방식으로
memory_limit=-1을 설정하십시오. 예를 들어 FPM 풀의php_admin_value를 사용하고, 어떤 풀, 디렉터리, 애플리케이션 항목도 유한한 한도를 다시 설정하지 않는지 확인하십시오.post_max_size는 낮게 설정하고(업로드가 없으면 8M, 있으면 32M),upload_max_filesize는 그보다 작게 유지하십시오. 요청 크기, 필드 수, multipart 파트 수, 헤더 수, 중첩 깊이는 웹 서버나 프록시에서 제한하십시오. 컨테이너나 cgroup의 메모리 제한은 가용성의 경계로 사용할 수 있지만, 취약한 할당 실패를 일으킬 수 있는RLIMIT_AS나RLIMIT_DATA는 사용하지 마십시오. - CVE-2026-109619 대응:
php.ini, FPM 풀, 또는 요청 파싱 이전에 적용되는 서버 설정에서session.upload_progress.enabled=0을 설정하고(ini_set()이나.user.ini로는 안 됩니다), 모든 워커를 재시작하십시오. PHP 8.5에서는fatal_error_backtraces=0도 함께 설정하십시오. 초기화 이전에 진단 메시지를 출력하는, 요청별의 잘못되었거나 오래된 설정은 제거하고, 공격자가 도달할 수 있는 치명적 오류와 실행 시간 초과는 고치십시오.
SilentShield가 할 수 있는 일과 할 수 없는 일
이것은 봇 문제가 아닙니다. 제품 페이지가 다른 인상을 주도록 두기보다는 이렇게 분명히 말씀드립니다. 이 공격은 저희 제품이든 CAPTCHA든, 애플리케이션 안의 플러그인이나 방화벽 규칙이든 어느 것이 요청을 보기도 전에 PHP 엔진을 직접 공격합니다. 양식에 설치한 봇 방어로는 막을 수 없으며, 막을 수 있다고 말하는 사람이 있어서는 안 됩니다. 유일하게 완전한 해결책은 PHP 업데이트입니다.
SilentShield API와 대시보드는 PHP로 작성되지 않았습니다. WordPress 플러그인과 PHP SDK는 귀하의 PHP 안에서 실행되므로, 이들에 대해서는 귀하의 서버에서 업데이트해야 합니다. 업데이트한 뒤에도 봇과 양식 스팸에 대한 기존 보호는 이전처럼 유용합니다. 다만 그것은 이 문제에 대한 답이 아니었을 뿐입니다.