10 월 21 일 PHP 에 두 가지 중대한 취약점이 발견되어 수정 버전이 긴급하게 공개되었습니다. 저는 고객사의 웹사이트 및 서버를 관리하는 직분으로, 공개 직전 밤부터 주말까지 여러 서버의 대응에 몰두했습니다. 밤을 새우며 휴일에도 출근하는 바쁜 일상이지만, 대응하지 않으면 큰 문제가 발생합니다.
이 글에서는 WordPress 사이트를 운영 중인 분들을 위해 실제로 수행한 작업, 겪은 어려움, 그리고 유용하게 여긴 점을 정리합니다. 실제 작업 내용을 바탕으로 특정되지 않도록 세부 사항은 변경하였습니다. 확인된 정보는 10 월 24 일 기준입니다.
무슨 일이 일어난지
이번 취약점은 CVE-2026-109618 과 CVE-2026-109619 의 두 가지입니다. 언론 보도에서는 공식 명칭이 아닌 'PHP2Shell'이라는 이름으로 불리기도 합니다. 두 취약점 모두 CVSS v4.0 기준으로 심각도 점수가 9.2 로 평가되었으며, 로그인하지 않은 외부 사용자가 서버상에서 임의의 프로그램을 실행할 수 있는 위험이 있습니다.
중심 내용을 살펴보면 다음 두 가지가 있습니다. ① CVE-2026-109618 은 PHP 가 메모리 부족 상태일 때의 처리 문제입니다. 완성되지 않은 불완전한 데이터를 후속 정리 처리가 정상적인 데이터로 잘못 인식하게 만듭니다. ② CVE-2026-109619 은 이전 요청에서 사용된 내부 상태가 메모리 해제 후에도 남아있는 문제입니다. 동일한 프로세스가 다음으로 처리하는 요청에서 그 오래된 상태가 잘못 사용되어 버립니다.
PHP 공식은 10 월 20 일 긴급 릴리스를 예고한 후, 일본 시간 10 월 21 일 23 시경에 수정 버전을 공개했습니다. 이번 수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 입니다. 8.2~8.5 시리즈에서 이보다 더 오래된 버전은 영향을 받습니다.
PHP-FPM, Apache 의 mod_php 등 웹 요청을 처리하는 PHP 는 모두 대상입니다. PHP 공식은 특히 mod_php 의 위험도가 가장 높다고 지적하고 있으며, 이는 실제 공격이 애플리케이션 코드가 실행되기 전에 시작되기 때문입니다. PHP-FPM 은 CVE-2026-109619 에서 세션 업로드 진행률 경로에 의한 조건부 공격이 증명되었고, CVE-2026-109618 의 경우 완전한 공격이 증명되지 않았다고 합니다. 그럼에도 불구하고 FPM 도 영향을 받을 수 있으므로 업데이트가 필요합니다.
PHP 8.1 이전에는 PHP 개발자로부터의 일반적인 업데이트가 제공되지 않았습니다. 개발자는 7.4, 8.0, 8.1 에 대한 최소한의 소스 수정만 공개하고 있으며, 업데이트 패키지가 제공될지는 운영체제나 서버 제공업체에 달려 있습니다.
악용 사례는 정보원에 따라 표현이 다릅니다. PHP 공식 자문위원회에는 실제 환경에서 악용이 확인되었다는 기록은 찾을 수 없었습니다. 제 3 자 보고서에 따르면, Amazon 이 공표한 4 일 전인 10 월 17 일에 악용 시도가 관측되었다는 보도가 있었습니다. Sophos 는 스캔과 일부 실패한 시도를 확인했지만, 10 월 23 일 아침의 수정時点で 성공한 침해의 증거는 없다고 밝혔습니다. 반면, 실증 코드 (PoC) 는 공개되었습니다.
2. 먼저「본 사이트가 대상인지」확인합니다.
WordPress 의 경우 관리 화면만으로도 PHP 버전을 확인할 수 있습니다. 「도구 → 사이트 헬스」를 열고「정보」탭의「서버」를 보면 다음 항목이 표시됩니다.
① PHP 버전: 위 수정 버전보다 오래된 경우 업데이트가 필요합니다. ② PHP SAPI: 'fpm-fcgi'라면 PHP-FPM, 'apache2handler'라면 mod_php로 작동합니다.
제공자가 수정 사항만 백포팅하는 경우 버전 번호가 변경되지 않을 수 있습니다. 이 경우 제공자의 공지사항을 통해 수정 여부를 확인하세요.
이 문제의 핵심은 PHP 자체의 취약점이므로, WordPress 자체나 플러그인을 업데이트해도 해결되지 않는다는 점입니다. PHP 자체를 업데이트해야 하며, 누가 업데이트할지는 사이트가 어디에서 실행되고 있는지에 따라 달라집니다.
서버 종류에 따라 대응 방식이 달라집니다.
이번에 가장 실감하게 된 점은, 동일한 PHP 취약점이라도 서버 종류에 따라 '잠시 기다리는 것이냐, 직접 해결하는 것이냐'가 완전히 다르다는 사실입니다.
3-1. 렌탈 서버의 경우
PHP 본체의 업데이트는 서버 사업자의 작업이며, 이용자는 사업자의 공지사항을 확인하는 것이 기본입니다. 예를 들어, 사쿠라 렌탈 서버는 10 월 22 일에 선택 가능한 모든 PHP 버전의 업데이트가 완료되었다고 발표했습니다. 아울러, 지원 기간 중에도 새로운 버전으로의 마이그레이션을 권장하고 있습니다.
3-2. AWS EC2(Amazon Linux 2023)의 경우
자신들이 직접 업데이트합니다. Amazon Linux 2023 에서 10 월 22 일에 php 8.2~8.5 의 수정 패키지가 공개되었습니다. ALAS2023-2026-3301 은 php 8.2, 3302 은 php 8.3, 3303 은 php 8.4, 3304 은 php 8.5 를 의미합니다.
Amazon Linux 2023 은 리포지토리 버전을 고정하는 구조를 가지므로 일반적인 `dnf update` 명령으로 새로운 수정이 적용되지 않을 수 있습니다. 업데이트 명령어는 각 ALAS 의「Issue Correction」에 명시된 대로 그대로 사용해야 합니다. php8.5(ALAS2023-2026-3304)의 예시는 다음과 같습니다.
실행에는 sudo 가 필요합니다. 설치된 버전과 일치하는 ALAS 명령어를 선택합니다. 업데이트 후에는 PHP-FPM 을 재시작해야 합니다.
한편, Amazon Linux 2023 의 PHP 8.1 과 Amazon Linux 2 표준 (Core) PHP 는 "수정 계획 없음 (대응 예정 없음)"으로 알려졌습니다. 또한, Amazon Linux 2 자체도 2026 년 6 월 30 일까지의 지원만 유지됩니다.
3-3. Elastic Beanstalk 의 경우
플랫폼 업데이트를 기다리는 것이 기본입니다. 10 월 21 일에는 두 차례의 릴리스가 있었습니다. 첫 번째 릴리스에서는 일부 설정만 비활성화하면 되며, PHP 자체는 수정되지 않았습니다. 두 번째 릴리스에서는 PHP 8.4 와 8.5 의 수정 버전 (8.4.27, 8.5.12) 을 탑재한 플랫폼이 출시되었습니다. 8.3 과 8.2 는 별도의 릴리스 (10 월 22 일 안내) 에서 대응될 예정입니다. 릴리스 노트에는 새 버전이 모든 리전에서 사용 가능해질 때까지 수 시간이 걸릴 수 있다고 명시되어 있습니다. 최신 상황은 릴리스 노트를 확인하시기 바랍니다.
주의해야 할 점은 두 번째 릴리스에서 첫 번째 릴리스에서 비활성화했던 설정 (예: session.upload_progress.enabled) 이 기본값으로 복원된 점입니다. 별도로 비활성화하고 싶은 설정이 있다면, 스스로 ini 파일을 배치해야 합니다.
Beanstalk 의 공식 문서에서는 .ebextensions 의 files 블록을 통해 /etc/php.d/ 디렉토리에 ini 파일을 추가할 수 있다고 설명하고 있습니다. php.ini 는 이 폴더의 파일을 이름 순서대로 로드하며, 설정을 덮어쓰려면 Beanstalk 가 배치한 aws.ini 보다 나중에 로드되는 이름 (예: zz 로 시작하는 이름) 으로 설정합니다.
내 환경에서는 .ebextensions 의 option_settings 에서 memory_limit 에 -1 을 지정했으나 배포가 실패했습니다. 이에 따라 다음과 같이 ini 파일을 추가하는 방식으로 변경했습니다.
이것은 수정 버전이 아직 게시되지 않은 플랫폼을 위한 임시 조치입니다. 수정 버전 플랫폼에 업데이트가 완료되면 memory_limit 행을 삭제합니다.
지원이 종료된 오래된 PHP 버전의 경우
PHP 8.1 이전에는 일반적인 수정 버전이 없습니다. 개발자가 최소한의 소스 코드를 수정하여 제공한 것은 PHP 7.4, 8.0, 8.1 전용이며, 그 이전의 PHP 5 시리즈 등은 제외됩니다. 운영체제 제공업체의 수정 버전이나 유료 연장 지원을 사용할 수는 있지만, 기본적으로 접근 가능한 사용자를 제한하거나, 서비스를 종료할 시기를 결정하거나, 새로운 버전으로 전환할지 여부를 판단해야 합니다.
4. 패치 전 임시 조치 및 패치 후 설정
수정 버전을 확인할 수 있는 기간 동안 PHP 공식은 다음과 같은 임시 대응책을 제시했습니다. 다만, 이는 모두 특정 공격 경로를 줄이는 데 그치며 안전성을 보장하지는 않는다는 점을 명시하고 있습니다.
① memory_limit = -1 (CVE-2026-109618 대응용) ② post_max_size 축소 (업로드가 없으면 8M, 있으면 약 32M 정도) ③ session.upload_progress.enabled = 0 (CVE-2026-109619 대응용) ④ fatal_error_backtraces = 0 (PHP 8.5 전용)
설정 시 주의할 점은 세 가지입니다. ① php.ini 나 PHP-FPM 풀 설정에 명시하고, .user.ini 나 애플리케이션 측의 ini_set() 에 의존하지 않는 것. ② 설정 후에는 모든 워커를 재시작하는 것. ③ memory_limit = -1 은 상한선이 없어 하나의 요청이 서버 메모리를 모두 사용하게 할 위험이 있어 고부하 환경에서 취약해질 수 있다는 점. OS 측의 RLIMIT_AS 나 RLIMIT_DATA 로 제한을 두는 것은 오히려 취약한 경로를 열어줄 수 있으므로 사용하지 않도록 안내됩니다.
수정 버전을 적용한 후에는 사고방식이 달라집니다. memory_limit = -1 은 원래 값이나 충분히 큰 유한한 값으로 되돌릴 것을 고려하십시오. 또한 session.upload_progress.enabled = 0 은 파일 업로드 진행 바를 사용하지 않는다면 그대로 두어도 큰 문제가 없으므로, 사용하는 사이트는 업데이트 후 이를 되돌릴지 여부를 판단하시기 바랍니다.
5. 실제 작업 흐름 (AWS 상의 WordPress 사이트 예시)
이후는 AWS 에서 실행 중인 WordPress 사이트의 작업 흐름을 예시로서 소개합니다. 휴일 대응이었기 때문에 작업은 PHP 업데이트에만 집중했습니다.
5-1. 업데이트 전 기록
사이트 헬스의 '서버' 화면을 업데이트 전 스크린샷으로 저장했습니다. PHP 버전, PHP SAPI, 메모리 상한을 기록해 두면 업데이트 후 이를 비교하여 확인하기만 하면 됩니다.
5-2. 업데이트 전 '기준' 확인
문의하기 양식과 이메일이 현재 어떻게 작동하는지 먼저 확인했습니다. 고객에게 보내지는 알림 이메일이 수신자에게 도달하지 않으므로, 다음 세 가지 방법으로 확인했습니다.
① 폼을 전송한 후 전송 완료 메시지가 표시되는지, ② 문의 내용을 저장하는 플러그인을 사용했을 경우 건수가 1 개 더 증가하는지, ③ WP Mail SMTP 의 테스트 메일 기능을 통해 본인宛 메일이 도착하는지
테스트 전송 본문에는 "작동 확인용 테스트 전송이며, 답변 불필요"라고 적어 고객에게 놀라움을 주지 않도록 했습니다.
5-3. 서버 업데이트
스냅샷을 찍은 후 PHP 를 업데이트하고 재시작했습니다. 사이트가 멈춘 시간은 재시작 후 수 초 정도였습니다.
STG 환경에서 먼저 테스트해보고 싶지만, STG 와 본산이 같은 서버에 구성되어 있으면 한 번의 업데이트로 두 환경이 동시에 전환되므로, 이 경우 스냅샷이 유일한 복귀 수단이 됩니다.
5-4. 업데이트 후 확인
사이트 헬스를 통해 PHP 가 수정 버전으로 업데이트되었음을 확인한 후, 업데이트 전과 동일한 절차로 표시, 로그인, 폼, 이메일 기능을 검증했습니다. 본番이 CDN 을 통해 배포되는 경우, 표시 검증 시 URL 에 '?test=1'과 같은 파라미터를 추가하여 캐시를 우회하고 최신 상태를 확인하도록 했습니다. CDN 설정에 따라 해당 파라미터를 무시하고 캐시된 내용이 반환될 수 있으므로, 표시가 변경되지 않을 때는 설정을 다시 확인해야 합니다.
6. 시도해 보니 깨달은 점
6-1. 사전 기준 확인이 효과를 발휘했습니다.
업데이트 전 관리 화면을 확인한 결과, 기존에 존재하던 경고 표시를 발견했습니다. 미리 확인하지 않았다면 업데이트 후 이 표시를 보고 "업데이트로 망쳤다"며 당황했을 것입니다. 업데이트 전 상태를 기록하는 것은 지루할 수 있지만 가장 효과적이었습니다.
6-2. WordPress 자체 업데이트도 함께 확인합니다.
일부 사이트에서는 업데이트 화면을 열면 WordPress 본체의 자동 업데이트가 중단될 수 있습니다. "사이트는 버전 관리 중입니다. 자동 업데이트가 비활성화되었습니다."라는 메시지가 표시되는 경우, WordPress 폴더에 Git 등의 관리 도구가 설치되어 있기 때문입니다. 이 상태에서는 보안 관련 작은 업데이트조차 자동으로 적용되지 않습니다.
사쿠라 인터넷은 9 월 25 일, 인증 없이 조건에 따라 원격에서 코드를 실행할 수 있는 취약점 (CVE-2026-87902) 이 WordPress 4.7.0~7.1.1 에 존재한다고 경고했습니다. 사쿠라 인터넷은 자동 업데이트가 활성화되어도 업데이트가 완료되지 않은 경우가 있으므로 관리 화면에서 업데이트 상태를 확인하도록 안내했습니다. PHP 지원과 함께 WordPress 본체의 버전도 반드시 확인하시기 바랍니다.
6-3. FTP 연결 정보를 요청받으면 중단
관리 화면에서 WordPress 를 업데이트하려 하면 FTP 연결 정보를 요구할 수 있습니다. 이는 웹 서버 권한으로 파일 수정이 불가능하도록 설정되어 있음을 의미하며, Git 으로 관리되는 사이트에서는 흔한 구성입니다. 이때 강제로 정보를 입력하거나 파일 권한을 완화하지 말고, 개발 담당자와 상담하여 Git 측에서 업데이트를 진행하는 방식으로 전환하는 것이 안전합니다.
6-4. STG 는 공격의 시작점이 된다
STG 는 종종 간과되지만, 실제 서비스와 동일한 서버에 존재한다면 STG 가 침해당할 경우 실제 서비스까지 위험에 처할 수 있습니다. 따라서 접근 가능한 사용자를 기본 인증 또는 IP 제한으로 엄격히 제한하는 것을 권장합니다.
6-5. 「PoC」라 불리는 것은 실행하지 않는다
이번에는 수정 버전의 공개 전후로 공격 코드 (PoC) 가 공개되었습니다. Sophos 는 일부 PoC 는 실험 환경에서만 작동한다고 지적했습니다. 일반적으로, 해당 취약점의 PoC 를 가짜로 만들어 말웨어를 숨기는 수법이 있습니다. 출처가 불분명한 파일은 다운로드도 실행도 하지 않는 것이 안전합니다. 대응을 위해 PoC 는 필요 없습니다.
서버 목록 유무에 따라 결과가 달라집니다.
결국 이번에는 가장 시간이 많이 걸린 것은 '어떤 서버가 어떤 OS 와 PHP 로, 누구의 관리 하에 운영되고 있는지'를 확인하는 작업이었습니다. 서버 목록 (장부) 을 평소부터 잘 정리해 두는 것이 다음 긴급 대응의 가장 중요한 준비가 될 것이라고 느꼈습니다.
7. 맺음말
이번 PHP2Shell 에서 대응의 핵심은 '수정된 PHP 로 업데이트하는 것'뿐입니다. 이를 바탕으로 아래 순서로 진행하면, 처음 작업이라 해도 차분하게 처리할 수 있습니다. ① 자신의 사이트가 어디에서 실행되고 누가 업데이트할지 확인하기 ② 업데이트 전 상태를 기록하여 기준을 세우기 ③ 업데이트 후 동일한 절차로 확인하기
WordPress 를 운영 중인 분들은 이번 기회에 '사이트 헬스' 기능을 통해 PHP 와 WordPress 의 버전을 한 번 확인해 보시기 바랍니다.
관련 글:
8. 출처
- PHP 공식 2026 년 10 월 21 일 보안 릴리스 공지 (php.net)
- OOM 오류를 통한 RCE (GHSA-w8hw-w9fx-j79w / CVE-2026-109618)
- 오래된 전역 상태를 이용한 원격 코드 실행 (GHSA-6wmf-4rv5-p3rp / CVE-2026-109619)
- CVE-2026-109618(아마존 리눅스 보안 센터)
- ALAS2023-2026-3304（php8.5）
- 2026 년 10 월 21 일 Elastic Beanstalk AL2023 PHP 8.5 및 PHP 8.4 플랫폼 업데이트
- 2026 년 10 월 21 일 Elastic Beanstalk AL2023 PHP 플랫폼 업데이트
- Elastic Beanstalk PHP 플랫폼을 사용하여 (AWS 공식 문서)
- 사쿠라 인터넷의 PHP 취약점 (CVE-2026-109618, CVE-2026-109619) 대응 현황에 대해
- WordPress 7.1.3 유지보수 및 보안 업데이트
- WordPress 의 취약점 (CVE-2026-87902) 에 유의하시기 바랍니다 (사쿠라 인터넷).
- PHP 취약점 (CVE-2026-109618, CVE-2026-109619) 을 위한 프로토타입 악용 코드 공개 (소포스)
- PHP2Shell 취약점 공격 시도: 공개 4 일 전
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 36청크
원문 보기 | 출처: note.com