PHP2Shell을 완전히 막는 방법은 PHP 업데이트뿐입니다. 바로 업데이트할 수 없다면 PHP 앞단에서 요청 크기를 제한하고, php.net이 밝힌 임시 설정 네 가지를 넣은 뒤 PHP 프로세스를 모두 재시작합니다. php.net과 KISA 모두 이 조치가 공격을 완전히 막지는 못한다고 적었습니다.
2026년 11월 4일, php.net의 2026년 10월 21일 보안 권고와 KISA 보호나라 기업 보안 대응 수칙을 읽고 두 곳에 적힌 임시 조치만 옮겼습니다. 여기 없는 설정값은 넣지 않았습니다.
1. PHP2Shell, 패치 없이 막을 수 있나요?
아니요. php.net은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 발표문마다 완전한 완화책은 없고 업데이트만이 안전한 선택이라고 적었습니다.
임시 조치를 두고 php.net은 특정 공격 경로의 노출을 줄일 뿐 설치를 안전하게 만들지는 않는다고 설명합니다. KISA 수칙에도 같은 뜻의 문장이 있습니다.
※ 임시 조치는 공격을 완전히 막지 못하므로, 업데이트 권고
그래서 임시 조치는 업데이트를 마칠 때까지 노출을 줄이는 단계로 보고, 업데이트 일정을 함께 잡아야 합니다. 업데이트 순서는 PHP2Shell 조치 방법, 확인부터 패치까지에 있습니다.
2. PHP 앞단에서 요청 크기부터 제한하기
KISA 수칙 4번의 첫 항목은 웹 방화벽·웹 서버·프록시처럼 PHP 앞단에서 요청 크기를 제한하라는 것입니다. 요청 크기 정보가 없는 요청도 포함해야 합니다.
파일 업로드가 필요 없는 서비스라면 파일 업로드(multipart) 요청을 막으라고 적었습니다. 웹 방화벽을 쓰고 있다면 최신 차단 규칙이 적용됐는지도 확인합니다.
php.net은 웹 서버나 프록시에서 제한할 항목을 더 구체적으로 들었습니다. 풀어 쓴 요청 크기, 입력 칸 수, multipart 조각 수, 헤더 수, 중첩 깊이입니다. 크기 정보(Content-Length)가 없는 요청에도 이 제한이 걸려야 한다고 했습니다.
3. CVE-2026-109618 쪽 임시 설정 두 가지
첫 번째 취약점은 메모리 부족 처리 과정의 문제입니다. php.net이 밝힌 임시 설정은 이렇습니다.
memory_limit=-1— 프로그램이 바꿀 수 없게 FPM pool의php_admin_value같은 관리자 설정으로 넣고, 다른 설정이 한도를 되살리지 않는지 확인post_max_size를 낮게 — 업로드가 필요 없으면 8M, 필요하면 32M,upload_max_filesize는 그보다 작게
php.net은 memory_limit=-1을 넣어도 더 아래쪽의 메모리 할당 실패는 여전히 취약한 경로에 닿을 수 있다고 적었습니다. 컨테이너나 cgroup 한도를 쓰되 RLIMIT_AS·RLIMIT_DATA로 대신하지 말라는 주의도 있어, 서버 관리자와 함께 보는 것이 맞습니다.
4. CVE-2026-109619 쪽 임시 설정과 재시작
두 번째 취약점에는 session.upload_progress.enabled=0을 넣고 모든 작업 프로세스를 재시작합니다. php.ini, FPM pool, 서버 설정처럼 요청을 읽기 전에 적용되는 곳에 넣어야 하고, ini_set()이나 FPM .user.ini에 기대면 안 된다고 적었습니다.
PHP 8.5를 쓰면 fatal_error_backtraces=0도 넣고 재시작합니다. php.net은 두 설정이 확인된 경로만 막고 다른 변형까지 막지는 않는다고 밝혔습니다.
php.net은 10월 23일 추가 안내에서 업데이트한 뒤에도 다음 정기 버그 수정 배포 때까지 session.upload_progress.enabled=0으로 꺼 둔 상태를 유지하라고 권했습니다.
다만 실행 중에 세션 직렬화 방식(session.serialize_handler)을 바꾸는 드문 구성에서만 생기는 문제라, 그렇게 바꾸지 않는 프로그램은 기능을 켜 둬도 된다고 적었습니다.
php.net과 KISA 모두 설정을 넣은 뒤 모든 PHP 프로세스를 재시작하라고 적었으니, 재시작까지 한 번에 합니다.
5. 웹호스팅이라면 호스팅 회사에 먼저 묻기
KISA 수칙은 호스팅 업체나 장비·솔루션 제조사가 PHP를 관리하는 경우, 그 업체에 조치 적용 여부를 확인하고 요청하라고 적었습니다.
위 설정은 php.ini나 서버 설정 수준에서 넣어야 해서, 웹호스팅에서는 사용자가 직접 바꿀 수 없는 경우도 있습니다. 예를 들어 카페24는 2026년 10월 21일 PHP 8.x 이하 전체 서비스에 session.upload_progress.enabled Off를 적용했다고 공지했습니다.
내 호스팅에 어떤 조치가 들어갔는지는 회사마다 다르니 공지나 고객센터로 확인합니다. 카페24를 쓴다면 카페24 php 업데이트, 확인부터 변경까지에 조치 내역을 정리했습니다.
6. 임시 조치도 어렵다면 외부 접속 차단까지
KISA 수칙은 임시 조치도 적용하기 어렵다면 업데이트 전까지 외부 접속 차단이나 서비스 일시 중단을 검토하라고 권고했습니다.
PHP 8.1 이하처럼 공식 업데이트가 없는 버전은 지원 버전으로 전환하는 것이 KISA 수칙의 원칙입니다.
전환에 시간이 걸리는 경우에만 리눅스 배포판·장기지원(LTS) 업체의 보안 패치나, PHP 보안팀이 공개한 7.4·8.0·8.1용 소스 패치를 임시로 적용하고 전환 계획을 세우라고 했습니다. 적용할 패치가 없으면 위 임시 조치로 넘어갑니다.
패치를 적용할 때는 호환성 문제로 서비스 장애가 날 수 있어, 미리 영향을 검토하고 테스트한 뒤 적용하라는 권고도 수칙에 있습니다.
정리하면 패치 전 임시 조치는 이 순서입니다.
- php.net 기준으로 안전한 선택은 업데이트뿐이라는 전제를 두고 일정을 잡습니다
- 웹 방화벽·웹 서버·프록시에서 요청 크기를 제한하고, 업로드가 없으면 multipart 요청을 막습니다
- php.net이 밝힌 임시 설정을 관리자 설정 수준에 넣고 PHP 프로세스를 모두 재시작합니다
- 웹호스팅이면 호스팅 회사에 적용 여부를 확인하고 요청합니다
- 그것도 어렵다면 외부 접속 차단이나 서비스 일시 중단을 검토합니다
업데이트를 마친 뒤에는 이미 침입 흔적이 없는지 봐야 합니다. 점검 항목은 php 취약점 확인, 패치 뒤 해킹 흔적 점검에 정리했습니다.
참고자료 (모두 2026년 11월 4일 확인)
- PHP 뉴스 「Security advisory: Critical remote code execution vulnerabilities, update now」(2026-10-21)·「Informational advisory: Session upload progress」(2026-10-23) — php.net/archive/2026.php
- KISA 보호나라 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」(2026-10-22) — boho.or.kr 보안공지
- PHP 보안 권고 GHSA-w8hw-w9fx-j79w — github.com/php/php-src
- PHP 보안 권고 GHSA-6wmf-4rv5-p3rp — github.com/php/php-src
- 카페24 호스팅 고객센터 「2026년 10월 21일(수) PHP 긴급 보안 취약점 조치 작업 공지」 — help.cafe24.com
#PHP2Shell #PHP보안 #PHP취약점 #웹방화벽 #홈페이지보안
