PHP, 치명적 취약점 2건의 긴급 보안 패치 공개

브라우저가 페이지를 요청하면 PHP는 필요한 정보를 메모리에 올려 처리합니다. 메모리는 작업하는 동안 잠시 펼쳐 놓는 책상이고, 워커는 그 일을 처리하는 작업자라고 생각하면 됩니다. 한 작업자가 요청 A를 처리한 뒤 요청 B를 맡기도 하므로, 요청이 끝나면 A의 임시 정보는 치워야 합니다.

여기서 다루는 것은 저장된 글 파일이 아니라, PHP가 실행하는 동안 쓰는 임시 정보와 그 정보를 가리키는 참조, 즉 “어디를 읽을지 알려 주는 주소표”입니다. 주소표만 남고 그 자리가 이미 비워졌다면, 다음 작업은 잘못된 정보를 읽을 수 있습니다. 공식 원인 설명

사이트가 요청을 처리하려면 임시 작업 공간인 메모리가 필요합니다. PHP에는 한 요청이 메모리를 너무 많이 쓰지 않도록 한도가 있고, 한도에 이르러 일을 멈추는 것 자체는 보호 기능입니다. 그런데 멈추는 순간 내부 자료가 반쯤 만들어진 상태라면 어떻게 될까요?

첫 결함인 CVE-2026-109618에서는 메모리 부족으로 처리 중간에 갑자기 빠져나온 뒤, 종료 과정이 덜 만들어진 자료를 정상 자료처럼 다룰 수 있었습니다. 다 쓰지 않은 주문서를 완성본으로 알고 다음 담당자에게 넘기는 상황에 가깝습니다. 사이트가 조금 느려지는 문제와 달리, 프로그램이 잘못된 메모리를 다루면서 실행 흐름까지 영향을 받을 수 있습니다. PHP의 원인 설명

수정은 “멈춰야 한다”는 사실을 기록해 두고, 안전하게 멈출 수 있는 실행 지점에서 중단하도록 바꾼 것입니다. 그 전에 더 높은 최종 한도까지 넘으면 해당 작업 프로세스를 즉시 끝내는 비상 경로도 따로 있습니다. 아래 그림은 8.5 수정의 흐름을 단순화한 것으로, 메모리 제한을 없애거나 컴퓨터 전체를 끄는 수정은 아닙니다.

두 번째 결함인 CVE-2026-109619는 ‘자료’와 ‘자료의 위치를 적은 메모’의 수명이 어긋나는 문제입니다. PHP의 한 작업자가 방문자 A의 요청을 끝내고 임시 메모리를 비웠는데, 그 안의 자료를 가리키는 상태 일부가 남을 수 있었습니다. 같은 작업자가 다음 요청 B를 맡을 때, 새 초기화가 끝나기 전에 그 오래된 상태를 건드리는 경로가 있었습니다. 공식 설명

서류를 폐기했는데 ‘그 서류는 3번 칸에 있다’는 메모만 남아 있다고 생각해 보세요. 다음에 3번 칸을 열어도 같은 서류가 있다는 보장은 없습니다. 이 비유가 보여 주는 것은 이미 무효가 된 위치 정보를 계속 믿는다는 점입니다. 실제로는 PHP 내부 메모리의 결함이고, 이전 방문자의 글이 화면에 그대로 남는 식의 현상을 말하는 것은 아닙니다.

수정은 이전 요청이 끝날 때 남은 참조와 상태를 비우고, 종료 중에 다시 생기는 정보와 다음 초기화 전의 접근 경로도 함께 다룹니다. ‘다음 손님이 오면 알아서 치우겠지’에 맡기지 않고, 이번 일을 끝낼 때 다음 일이 잘못된 정보를 집어 들지 않게 하는 것이 핵심입니다.

PHP 7.4는 PHP 프로젝트의 일반 지원이 끝난 계열입니다. 이번에는 심각성을 고려해 오래된 계열에 옮겨 쓸 최소 수정 코드가 특별히 제공됐는데, 이를 백포트라고 합니다. 코드가 공개된 뒤에도 호스팅 업체가 그 코드를 패키지로 묶어 배포하고 내 서버에 적용하기까지는 단계가 더 남아 있습니다. PHP 공식 안내 · 지원 종료 기록

7.4 수정은 8.5와 따로 만든 최소 대응입니다. 위험한 메모리 오류가 나면 작업자를 끝내고, 해제된 위치 정보를 비우고, 확인된 세션 업로드 진행 처리 경로를 막습니다. 일반 파일 업로드 기능 전체를 막는 수정은 아닙니다. 실제 차이는 뒤의 코드 부록에 있습니다.

아래는 가상의 ‘호스팅 A’ 예시입니다. 업체명과 상황은 설명용이고, PHP 수정 버전은 실제 공개된 번호입니다. 호스팅 A의 화면에 PHP 8.3.35가 보인다면 “8.3 계열이니까 괜찮다”로 끝내지 말고, 8.3.36이나 두 수정이 백포트된 패키지가 제공·적용됐는지 묻습니다. 7.4.33이라면 새 공식 7.4 버전 번호를 기다리기보다, 해당 업체의 연장 지원 수정 여부와 지원 중인 계열로 옮기는 경로를 묻습니다.

WordPress는 PHP 위에서 동작하는 앱입니다. WordPress 본체·플러그인을 업데이트하는 일과 서버가 실행하는 PHP를 고치는 일은 서로 다른 층의 작업입니다. 공식 PHP 발표는 웹 요청을 처리하는 모든 PHP 환경에 업데이트를 권하면서, 그중 mod_php의 위험이 가장 높다고 봅니다. 앱 코드가 실행되기도 전에 비인증 요청으로 공격이 일어나는 사례를 입증했다는 이유입니다. PHP 발표 · WordPress의 PHP 업데이트 안내

mod_php는 Apache 웹서버 안에서 PHP를 실행하는 방식이고, PHP-FPM은 PHP 작업자들이 따로 요청을 받아 처리하는 방식입니다. 첫 번째 권고에 FPM의 특정 시작 단계 경로가 제한된다는 내용이 있어도, FPM 전체가 안전하다는 뜻으로 읽을 수는 없습니다. 두 번째 권고에는 조건을 만족한 FPM 경로도 검증됐다고 기록돼 있습니다. 첫 결함의 조건 · 두 번째 결함의 조건

10월 22일 아침, 제가 개인 WordPress 운영에 쓰는 Cloudways에서 운영 중인 앱 한 개의 PHP를 실제로 바꿨습니다. 별도 스테이징 복제본 없이 본 운영 앱에서 진행한 기록입니다. 사이트명·주소·계정·서버 식별자는 공개하지 않습니다.

먼저 파일·데이터베이스의 복원 지점을 10월 22일 06:57:52 JST로 확보했습니다. 이 앱의 Application Settings → PHP Settings에서 고를 수 있는 가장 새 계열은 8.4였습니다. 앱별 PHP 선택 기능을 썼으므로, 이 변경은 해당 앱 단위이고 서버 전체의 모든 PHP 환경을 바꾼 것은 아닙니다. Cloudways 앱별 변경 안내

Cloudways는 PHP 변경 성공 알림을 띄웠습니다. 이어 WordPress의 도구 → 사이트 건강 → 정보 → 서버를 새로 불러오니, 실제 웹 PHP는 7.4.33에서 8.4.26으로 바뀌어 있었고 실행 방식은 fpm-fcgi, 즉 PHP-FPM이었습니다. 아래는 같은 작업의 실제 화면이며, 제품 화면을 AI로 다시 그린 이미지가 아닙니다.

Cloudways는 10월 22일 07:19 JST에 PHP 공식 권고의 임시 설정 조치를 전체 서버에 적용했고 정식 패치는 순차 배포 중이라고 발표했습니다. 이어 10:02 JST 공지에서는 Autonomous의 모든 고객 앱에 패치를 적용했으며, Flexible은 계속 배포 중이라고 밝혔습니다. Autonomous와 Flexible은 Cloudways의 서로 다른 호스팅 상품이고, 이번에 작업한 앱은 Flexible입니다. Cloudways 공식 사건 공지

10월 22일 14:03 JST에 같은 앱의 WordPress 서버 정보를 새로 불러오자 웹 PHP는 8.4.27, 실행 방식은 fpm-fcgi로 표시됐습니다. PHP 공식 변경 기록의 8.4.27에는 이번 두 보안 권고에 대한 수정이 실려 있습니다. 따라서 이 앱에서 실제 웹 요청을 처리하는 PHP가 공식 수정 버전으로 바뀐 것을 확인했습니다. 이번 재조회에서는 버전 변경이나 설정 저장을 하지 않았으며, 패키지가 교체된 정확한 시각은 알 수 없습니다. 8.4.27 공식 변경 기록

Cloudways는 10월 22일 19:11 JST에 PHP 보안 패치 배포가 완료됐고 모든 활성 서버가 업데이트됐다고 발표했습니다. 19:20 JST에도 같은 내용을 게시했으며, 추가 지원이 필요한 일부 고객에게는 지원팀이 개별 연락 중이라고 덧붙였습니다. 19:22 JST에는 후속 문제를 계속 관찰한다고 알렸고, 당시 사건 상태는 monitoring이었습니다. Cloudways 배포 완료 공지

이 앱에 대한 마지막 직접 관측은 14:03 JST의 웹 PHP 8.4.27 / fpm-fcgi입니다. 저녁에는 인증된 앱 세션에 접근하지 못해 추가 재조회는 하지 못했습니다. 공급자의 전체 배포 완료 발표와 오후에 직접 본 앱 상태를 각각의 시점으로 기록하며, CLI·예약 작업이나 모든 플러그인 기능까지 점검한 결과로 확대하지 않습니다.

위 표와 아래 경고 사진은 아침 07:08 JST의 기록입니다. 14:03 JST 재조회에서는 max_input_vars 10000, post_max_size 100M, 업로드 한도 30M, 메모리 한도 -1, 실행 시간 300초로 표시됐습니다. -1은 PHP의 해당 메모리 한도가 없는 설정을 뜻하며, 이번 점검에서 이 값들을 변경하지 않았습니다. 누가 언제 어떤 이유로 바꿨는지는 이 화면으로 알 수 없으므로, 당시의 10M 경고나 공급자의 임시 조치가 현재도 같은 상태라고 단정하지 않습니다.

버전을 바꾸면 설정도 함께 달라질 수 있고, 이번에도 입력 관련 한도 두 가지가 바뀌어 보였습니다. 입력 한도가 달라졌다고 곧바로 사이트가 고장 났다고 볼 수는 없지만, 항목이 많은 설정·메뉴를 저장하는 기능은 시험해 볼 대상입니다. 이번에 본 것은 위의 조회 기능까지이고, 모든 플러그인 기능·글 저장·파일 업로드·예약 작업은 아직 시험하지 않았습니다.

아침 점검에서는 이 경고만 보고 요청 크기를 예전 100M으로 되돌리지 않았습니다. PHP 공식 권고에는 요청 크기를 낮춰 일부 공격 경로의 노출을 줄이는 임시 조치도 있습니다. 아침의 10M과 입력 항목 한도가 그 조치에서 온 것인지는 미확인이었고, 오후에 달라진 값의 변경 이유도 확인되지 않았습니다. 이 기록을 한도를 높이거나 메모리 제한을 해제하는 권장 설정으로 사용해서는 안 됩니다. 이 추가 점검에서는 설정을 저장하지 않았습니다. PHP 공식 임시 조치와 한계

7.4를 당장 어떻게 다루든, 지원 중인 계열로 옮길 계획은 따로 세워야 합니다. Cloudways의 현재 Flexible 안내는 My Applications → 해당 앱 → Application Settings → PHP Settings → PHP Version에서 버전을 고르도록 설명합니다. 계정·운영체제·화면에 따라 경로와 제공 범위가 다를 수 있고, 예를 들어 공식 문서는 8.4에 Debian 11 또는 12가 필요하다고 안내합니다. Cloudways 버전 변경 안내

• 먼저 파일과 데이터베이스의 최신 백업과 복원 방법을 마련합니다.
• WordPress·테마·플러그인이 대상 PHP와 호환되는지 알아보고, 복제한 시험 환경에서 먼저 바꿔 봅니다.
• 해당 계열의 최종 수정 패키지가 제공되는지 공급자에게 물은 뒤 운영 환경에 적용합니다. 같은 서버의 다른 앱에 미치는 범위도 살핍니다.
• 적용 뒤에는 글 열람·관리자 로그인·검색·문의·예약·결제처럼 실제로 쓰는 기능을 점검합니다. WordPress의 도구 → 사이트 건강 → 정보 → 서버에서 웹 PHP 버전을 다시 보고, 백포트라면 공급자의 수정 이력과 함께 기록해 둡니다.

공식 안내에는 일부 설정으로 노출을 줄이는 임시 조치도 있지만, 완전한 해결은 업데이트뿐이라고 적혀 있습니다. 메모리 한도를 무작정 해제하는 식의 설정은 초보 운영자가 그대로 따라 할 해결책으로 권하지 않습니다. PHP 공식 조치와 한계 · WordPress 사이트 건강 안내