로그인 없이 서버가 뚫리는 PHP 취약점, 워드프레스 블로그를 4시간 꺼 뒀어요

10월 21일 밤 9시 50분쯤 스레드에서 “PHP 보안 초비상”이라는 글을 봤어요. PHP 보안팀이 심각도 9.2짜리 취약점 두 개를 고친 버전을 그날 밤 11시(한국 시간)에 낸다는 예고였어요. 제 블로그는 워드프레스고, 워드프레스는 PHP로 돌아요. 그래서 패치를 기다리다가 공개 직후 블로그를 꺼 두고, 고친 버전으로 바꾼 뒤 다시 켰어요. 그 과정과 워드프레스 운영자가 확인할 것을 PHP 공식 공지와 보안 권고 원문 기준으로 정리했어요.

어떤 취약점인가요?

PHP 공식 사이트(php.net)는 10월 20일 날짜로 먼저 예고를 올렸어요. 고칠 취약점이 두 개이고 둘 다 CVSS 4.0 기준 9.2점이라는 것까지만 적혀 있었어요. 자세한 내용과 해당 버전은 패치와 함께 공개한다고 했고요.

예정은 밤 11시였는데, GitHub에 보안 권고 두 건이 올라온 건 밤 10시 34분이었어요. 고친 버전도 그 무렵 함께 나왔어요. 공지 제목은 “치명적인 원격 코드 실행 취약점, 지금 업데이트하라”였어요. 원격 코드 실행은 밖에서 보낸 요청으로 서버에서 코드를 돌릴 수 있다는 뜻이에요. 권고에 적힌 영향은 로그인 없이, 웹 요청을 처리하는 작업자 계정 권한으로 코드를 실행하는 거예요.

두 취약점은 이래요.

1. CVE-2026-109618: PHP가 메모리가 모자라 요청 처리를 급히 멈출 때, 아직 준비가 덜 된 내부 데이터를 정리 단계에서 그대로 써 버리는 문제예요. 파일을 올릴 때 쓰는 멀티파트 요청으로 메모리를 바닥나게 하는 방법들이 적혀 있어요
2. CVE-2026-109619: 한 요청이 쓰던 내부 정보가 메모리를 반납한 뒤에도 남아 있다가, 같은 작업자가 처리하는 다음 요청에서 다시 쓰이는 문제예요

공지는 아파치에 PHP를 모듈로 붙여 쓰는 방식(mod_php)을 가장 위험하다고 꼽았어요. 이 방식에서는 로그인 없이 보낸 요청이 워드프레스 코드가 돌기도 전에 공격을 일으키는 시연까지 있었다고 해요. 작업자 수나 다른 접속에 따라 여러 번 시도해야 할 수는 있다고 적혀 있습니다.

내 워드프레스도 해당되나요?

PHP로 웹 요청을 처리하는 곳은 모두 업데이트 대상이에요. 공지가 꼽은 목록에는 PHP-FPM, 아파치 mod_php, php-cgi, FrankenPHP, LiteSpeed가 다 들어 있어요. 확인된 공격 경로는 방식마다 달라서 mod_php가 가장 급하지만, 다른 방식이라고 안전하다는 뜻은 아니에요. 워드프레스, 그누보드, 라라벨처럼 PHP로 만든 사이트라면 해당된다고 보면 돼요.

PHP 공식 릴리스 기준으로 고친 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35예요. 각 버전 줄에서 이 번호 이상으로 올려야 해요. 다만 리눅스 배포판이나 장기 지원 업체는 이번 수정만 기존 버전에 덧대서(백포트) 내기도 해요. 그래서 번호가 낮아도 고쳐져 있을 수 있으니, 업체 패키지를 쓴다면 업체 안내를 같이 봐야 해요.

8.1 이하는 PHP 쪽에서 더는 업데이트를 내지 않아요. 이번에는 사안이 심해서 7.4, 8.0, 8.1용 최소 수정 코드를 따로 공개했어요. 직접 빌드하거나 장기 지원 업체를 쓸 수 없는 사람을 위한 거예요. 8.2도 올해 12월 31일로 보안 지원이 끝나요.

내 워드프레스의 PHP 버전은 관리자 화면에서 볼 수 있어요.

1. 관리자 화면 왼쪽 메뉴에서 ‘도구’를 눌러요
2. ‘사이트 건강’에 들어가 ‘정보’ 탭을 열어요
3. ‘서버’ 항목을 펼쳐 ‘PHP 버전’을 봐요

블로그를 왜 꺼 뒀나요?

제 운영 환경에서는 새 PHP를 바로 올릴 수 없는 상태였거든요. 고친 버전이 제 쪽에 준비될 때까지 몇 시간은 내용이 다 공개된 취약점을 열어 둔 채로 있어야 했어요.

공지에 임시 대책도 있긴 했어요. 그런데 공지 스스로 특정 공격 경로의 노출을 줄일 뿐, 설치를 안전하게 만들지는 않는다고 적어 뒀어요. 블로그가 몇 시간 꺼지면 그동안 들어온 방문자를 놓치고 검색 로봇도 헛걸음을 해요. 대신 침입을 당하면 글을 다 옮기고 서버를 새로 꾸려야 할 수도 있어요. 둘을 비교하면 운영을 잠깐 멈추는 쪽의 손실이 더 작다고 판단했어요.

그래서 보안 권고가 올라오고 6분 뒤인 밤 10시 40분에 블로그의 외부 접속을 막았어요. 글 데이터는 그대로 두고 방문자용 화면만 내렸어요. 그동안 주소를 치고 들어오면 이런 화면이 떴어요.

침입 흔적은 어디까지 확인했나요?

끄기 전에 점검에 쓸 접속 기록을 따로 받아 뒀어요. 그다음 네 가지를 봤어요.

1. 최근에 바뀐 파일: 워드프레스 폴더에서 최근 3일 안에 바뀐 파일을 찾았어요. 0개였어요
2. 업로드 폴더 속 PHP 파일: 그림이 들어가는 폴더에 PHP 파일이 숨어 있으면 침입을 의심해야 해요. 없었어요
3. 관리자 계정과 설정: 모르는 관리자 계정이 생겼는지, 사이트 주소, 플러그인, 테마가 바뀌었는지 봤어요. 그대로였어요
4. 접속 기록: 받아 둔 기록은 10월 21일 새벽 4시 24분부터 밤 10시 39분까지 약 18시간치예요. 서버 오류 응답과 PHP 치명 오류는 0건이었어요. 로그인 비밀번호를 대입하는 요청은 반복해서 들어왔고, 상당수는 요청 제한에 걸려 막혔어요

호스팅을 쓰는 분도 2번과 3번은 관리자 화면과 파일 관리자에서 볼 수 있어요. ‘사용자’ 메뉴의 관리자 목록과 ‘플러그인’ 목록이 내가 아는 그대로인지부터 확인하면 돼요. 서버 기록을 볼 수 있다면 작업자가 비정상으로 끝난 기록, 실행 시간 초과, 치명 오류가 반복되는지도 보세요. 첫 번째 권고에는 작업자 수와 다른 접속에 따라 공격에 필요한 시도 횟수가 늘어날 수 있다고 적혀 있거든요.

다만 이 네 가지가 깨끗하다고 침입이 없었다고 단정할 수는 없어요. 제가 확인한 건 본 범위 안에서 뚜렷한 흔적이 없었다는 데까지예요.

바로 업데이트할 수 없으면 어떻게 하나요?

공지는 업데이트만이 완전한 해결책이라고 못 박았어요. 그래도 당장 못 올리는 곳을 위해 노출을 줄이는 방법을 적어 뒀어요. 하나씩 어느 취약점용인지와 한계가 같이 적혀 있습니다.

1. 업로드 진행 표시 기능(session.upload_progress.enabled)을 0으로 끄고 PHP 작업자를 모두 다시 시작해요. CVE-2026-109619의 확인된 세션 경로만 막고 다른 변형은 못 막아요. php.ini나 서버 설정에 넣어야 하고, 코드 안의 ini_set()이나 FPM의 .user.ini에 기대면 안 된다고 해요
2. 파일 업로드가 없으면 요청 크기 한도(post_max_size)를 8M으로, 업로드가 있으면 32M으로 낮춰요. 업로드 한도(upload_max_filesize)는 그보다 작게 둬요. CVE-2026-109618용인데 이것만으로는 모든 요청이 막히지 않아요. 크기를 밝히지 않은 요청도 있어서 웹 서버나 프록시 쪽에서도 요청 크기, 입력 칸 수, 멀티파트 조각 수를 제한하라고 해요. 멀티파트 요청을 안 쓰는 사이트라면 PHP에 닿기 전에 막는 방법도 적혀 있어요
3. 메모리 한도(memory_limit)를 -1로 둬서 PHP 자체 메모리 한도를 없애요. 앱이 다시 바꾸지 못하게 서버 설정(php_admin_value 등)으로 고정하고 PHP 작업자를 모두 다시 시작해요. 다른 설정이 유한한 한도를 다시 넣지 않는지도 확인해야 해요. 이것도 CVE-2026-109618용이고, 실제 메모리 할당이 실패하면 여전히 취약한 경로에 닿을 수 있어요. RLIMIT_AS나 RLIMIT_DATA 같은 운영체제 메모리 제한으로 대신하면 오히려 그 경로를 부른다고 경고해요
4. PHP 8.5라면 fatal_error_backtraces를 0으로 두고 작업자를 모두 다시 시작해요. 확인된 치명 오류 추적 경로만 막아요

하나 더 있어요. 요청마다 적용되는 설정 가운데 잘못됐거나 더는 안 쓰는 설정이 경고를 내면 그게 공격 경로가 될 수 있대요. 아파치 mod_php에서는 .htaccess에 넣은 php_value 같은 설정이 여기에 해당해요. 워드프레스 .htaccess에 예전에 넣어 둔 PHP 설정이 있다면 정리하는 게 좋아요. error_reporting이나 display_errors로 경고를 숨겨도 이 취약점은 막히지 않는다고 적혀 있어요.

웹호스팅을 쓴다면 PHP는 호스팅 업체가 올려요. 업체 공지에서 CVE-2026-109618과 CVE-2026-109619 두 건이 모두 고쳐졌는지 확인하고, 위의 ‘사이트 건강’ 화면에서 버전도 같이 보면 돼요. 업체가 백포트를 했다면 번호가 낮게 나올 수 있으니 업체 안내가 기준이에요. PHP 버전을 고를 수 있는 호스팅이라면 8.1 이하는 이번 기회에 올리는 게 맞아요.

다시 켜기까지 얼마나 걸렸나요?

고친 버전은 10월 22일 새벽 2시 40분대에 제 쪽에 준비됐어요. 받자마자 보안 수정이 들어간 버전인지부터 확인했어요. 그다음 새벽 2시 49분에 블로그를 다시 켰어요. 켠 뒤에는 PHP 버전이 고친 번호로 바뀌었는지, 첫 화면과 글 주소가 정상으로 열리는지, 예약해 둔 글이 그대로인지 차례로 봤어요. 셋 다 문제없었어요.

블로그가 꺼져 있던 시간은 밤 10시 40분부터 새벽 2시 49분까지 4시간 9분이었어요. 이번에 배운 건 예고가 나왔을 때 미리 정해 둘 게 있다는 거예요. 패치가 나오자마자 바로 올릴 수 있는지, 못 올리면 꺼 둘지 임시 설정을 넣을지요. 저는 패치를 기다리기만 하다가 권고가 공개된 뒤에야 끄기로 정했어요.

참고한 곳

• PHP 공지 (2026.10.20 예고, 10.21 보안 안내): https://www.php.net/archive/2026.php
• CVE-2026-109618 보안 권고: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• CVE-2026-109619 보안 권고: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp