PHP2Shell 기업 서버 보안 대응 방법
========================

PHP2Shell 대응은 실제 웹 서비스의 PHP 업데이트와 재시작부터 진행합니다. 침해가 의심되면 증거 보존을 먼저 진행하고, 패치 이후에도 로그 점검과 인증정보 교체가 필요합니다.

- 운영 중인 서버와 내장 제품의 PHP 사용 현황을 확인하세요.
- 침해가 의심되면 서버를 격리하고 재시작 전에 증거를 보존하세요.
- 수정 버전을 적용하거나 업데이트 전까지 공식 임시 조치를 적용하세요.
- PHP 실행 서비스를 재시작한 뒤 실제 웹 서비스의 패치 반영을 확인하세요.
- 과거 로그를 점검하고 노출된 서버의 인증정보를 교체하세요.

PHP2Shell 대응은 PHP 사용 현황 확인과 수정 버전 적용부터 시작합니다. 업데이트 뒤에는 실행 서비스를 재시작하세요. 침해가 의심되면 재시작 전에 증거를 보존해야 합니다. 패치 후에도 로그 점검과 인증정보 교체가 필요합니다.
버전과 설정은 2026년 10월 22일 KISA 공지와 10월 23일 PHP 추가 공지를 기준으로 합니다.

PHP2Shell은 어떤 취약점인가요?
PHP2Shell은 인증 없이 서버 코드를 실행할 수 있는 PHP 취약점입니다. 웹 서버가 요청을 처리하는 과정의 메모리 관리 문제입니다. 공격 성공 여부는 실행 환경과 설정에 따라 달라집니다.

구분
식별 번호
문제의 성격

메모리 부족 처리 문제
CVE-2026-109618
메모리 부족 상황에서 불완전한 내부 데이터를 처리

요청 사이에 남은 상태 문제
CVE-2026-109619
해제된 메모리를 가리키는 상태를 이후 요청에서 사용

KISA는 두 취약점의 심각도를 CVSS 9.2점으로 안내합니다. 공격에 성공하면 웹셸 설치나 고객정보 유출이 가능합니다. 웹셸은 서버를 원격으로 조종하는 데 악용되는 파일입니다. 홈페이지 변조와 내부망 침투로 이어질 수도 있습니다.
KISA는 패치 배포 전 정보 유출과 공격 시도를 안내했습니다. 연구진은 AI를 활용한 취약점 발견 과정을 공개했습니다. 문제는 PHP 자체에 있어 특정 웹사이트 제품에만 한정되지 않습니다. KISA 기업 대응 수칙, 연구진의 PHP2Shell 설명

조건별 대응 순서
침해 의심 여부에 따라 업데이트와 증거 보존의 순서가 달라집니다. 평상시 패치 작업은 테스트 후 업데이트와 재시작을 진행합니다. 침해가 의심되는 서버는 먼저 격리하세요.

현재 상태
먼저 할 일
이어서 할 일

침해 징후가 없는 공개 서버
호환성 검토와 수정 버전 적용
재시작, 실제 버전 확인, 로그 점검

웹셸이나 의심스러운 연결 발견
네트워크 격리와 신고
증거 보존 후 복구 조치

즉시 업데이트가 어려운 서버
공식 임시 설정과 앞단 요청 제한
패치 일정 수립과 적용

임시 조치도 어려운 서버
외부 접속 차단 또는 일시 중단 검토
패치 후 재개 여부 판단

호스팅·제조사가 관리하는 환경
관리 업체에 적용 여부 확인
실행 환경의 반영 근거 확보

업데이트 후 재시작은 수정 코드를 실행하기 위한 절차입니다. 사고 대응 중 재시작을 미루는 이유는 증거 보존입니다. 같은 서버라도 침해 의심 상태라면 후자의 순서를 따르세요.

PHP 사용 현황 확인 방법
자산 목록과 실제 동작 중인 서버를 함께 확인하세요. 대표 홈페이지만 점검하면 관리에서 빠진 서버를 놓칠 수 있습니다. PHP가 포함된 장비와 컨테이너도 확인 대상입니다.

인터넷에 공개된 홈페이지와 시스템을 목록으로 만드세요.
외주 제작 사이트와 오래된 사이트를 확인하세요.
이벤트·테스트 서버와 관리자 페이지를 확인하세요.
장비 관리화면과 솔루션의 PHP 포함 여부를 확인하세요.
컨테이너 이미지와 실행 중인 컨테이너를 확인하세요.
각 환경의 PHP 버전과 관리 담당자를 기록하세요.

호스팅을 이용한다면 업체에 패치가 적용됐는지 확인을 요청하세요. 장비에 포함된 PHP는 제조사 업데이트를 확인하세요. 내부 시스템도 점검하되 인터넷 공개 서버부터 조치하세요.

PHP 수정 버전과 지원 종료 기준
PHP 공식 공지의 8.5 계열 수정 버전은 8.5.12입니다. KISA 원문도 같은 버전을 안내합니다. 8.5.13을 기다려야 패치할 수 있다는 뜻이 아닙니다.

사용 계열
두 취약점의 수정 버전
대응 기준

PHP 8.5
8.5.13 이상
해당 계열의 최신 보안 릴리스 확인

PHP 8.4
8.4.27 이상
해당 계열의 최신 보안 릴리스 확인

PHP 8.3
8.3.36 이상
해당 계열의 최신 보안 릴리스 확인

PHP 8.2
8.2.35 이상
패치와 함께 상위 계열 전환 준비

PHP 8.1 이하
정규 보안 지원 종료
지원 계열 전환 또는 공급업체 패치 확인

표는 2026년 10월 21일 발표된 수정 버전 기준입니다. 배포판 패키지는 표시 버전이 그대로일 수 있습니다. 이 경우 변경 이력에서 두 CVE의 수정 여부를 확인하세요. PHP 보안 릴리스 공지
PHP 8.2의 보안 지원 종료일은 2026년 12월 31일입니다. KISA는 PHP 8.3 이상으로 전환할 것을 권고합니다. 전환 전에는 애플리케이션 호환성을 테스트하세요. PHP 지원 일정
PHP 8.1 이하는 정규 보안 지원이 끝난 상태입니다. 배포판이나 장기지원 업체의 패치는 별도로 확인해야 합니다. 이번에 공개된 구버전용 소스 패치도 정규 지원 재개를 뜻하지 않습니다.

업데이트와 재시작 방법
설치 파일 교체 뒤에는 PHP 실행 서비스의 재시작이 필요합니다. 기존 프로세스가 메모리에 남은 코드를 계속 실행할 수 있습니다. 침해가 의심된다면 아래 작업보다 증거 보존을 먼저 진행하세요.

패치가 기존 기능에 미치는 영향을 검토하세요.
테스트 환경에서 서비스 호환성을 확인하세요.
인터넷 공개 서버부터 수정 패키지를 적용하세요.
PHP를 실행하는 모든 서비스를 재시작하세요.
컨테이너 환경은 수정된 이미지로 다시 배포하세요.
실제 웹 요청을 처리하는 PHP의 반영 상태를 확인하세요.

재시작 대상에는 PHP-FPM과 Apache mod_php가 포함됩니다. php-cgi, FrankenPHP, LiteSpeed도 확인하세요. 서버에 여러 PHP 환경이 있다면 각각 점검해야 합니다.
php -v는 명령줄에서 실행되는 PHP 버전을 보여줍니다. 웹 서비스가 사용하는 PHP와 다를 수 있습니다. 명령줄 출력만으로 업데이트 완료를 판단하지 마세요.

업데이트 전 임시 설정 기준
임시 조치는 일부 공격 경로를 줄이는 수단입니다. 전체 취약점을 해결하지는 못합니다. 설정 적용이 어렵다면 외부 접속 차단을 검토하세요.

memory_limit 설정은 어떻게 적용하나요?
이번 취약점의 공식 임시 권고는 memory_limit=-1입니다. 이 값은 PHP 자체의 메모리 사용 한도를 해제합니다. 일반적인 운영 설정으로 받아들이지 마세요.
한도를 해제하면 메모리 부족을 유발하는 특정 경로가 줄어듭니다. 실제 메모리 할당 실패까지 막는 설정은 아닙니다. 요청 크기 제한과 자원 관리 대책을 함께 검토해야 합니다. PHP 메모리 부족 취약점 권고

항목
공식 임시 조치
적용 시 확인할 내용

memory_limit

-1로 지정
애플리케이션이 바꾸지 못하도록 관리자 설정 적용

session.upload_progress.enabled

0으로 지정
요청 처리 전에 적용되는 설정 위치 사용

post_max_size
업로드 불필요 시 8M 예시
실제 서비스 요구와 앞단 제한을 함께 검토

upload_max_filesize

post_max_size보다 작게 지정
파일 업로드 기능의 영향 확인

fatal_error_backtraces
PHP 8.5에서 0으로 지정
다른 계열에 일괄 적용하지 않음

표의 설정값은 2026년 10월 공식 대응 공지 기준입니다. 8M은 업로드가 불필요한 서비스에 제시된 예시입니다. 모든 서비스에 같은 크기를 적용하는 기준은 아닙니다.

웹방화벽·웹 서버·프록시에서 요청 크기를 제한하세요.
크기 정보가 없는 요청에도 제한이 적용되는지 확인하세요.
업로드가 불필요하면 multipart 요청을 앞단에서 차단하세요.
웹방화벽의 최신 차단 규칙을 확인하세요.

php.ini나 PHP-FPM pool 등에서 설정을 적용하세요.
증거 보존이 필요한지 확인한 뒤 PHP 프로세스를 재시작하세요.

ini_set()만으로 임시 설정을 적용하지 마세요. 요청 처리 전에 필요한 설정이 늦게 적용될 수 있습니다. PHP-FPM의 .user.ini에도 같은 역할을 기대하지 마세요. PHP 공식 임시 조치

10월 23일 추가 공지에서 확인할 내용
PHP는 추가 공지에서 업로드 진행률 기능을 끄도록 권고했습니다. 일부 설정 조합에 남은 별도 실행 경로에 대한 안내입니다. 이미 기능을 껐다면 다음 정기 수정 릴리스까지 유지하도록 안내합니다.
해당 조건에는 실행 중 세션 직렬화 방식 변경이 포함됩니다. 모든 PHP 설치에서 같은 조건이 성립하는 것은 아닙니다. 패치 뒤 설정 복원 여부는 추가 공지를 확인해 결정하세요. (확인값 session.upload_progress.enabled=0을 다음 정기 버그 수정 릴리스까지 유지하도록 권고 · 출처 php.net · 2026-10-23 확인) PHP Session upload progress 추가 공지

로그 점검과 인증정보 교체 방법
KISA는 최소 2026년 10월 20일 이후 기록 점검을 권고합니다. 가능하면 그 이전 기록도 확인하세요. 패치는 이미 발생한 침해나 정보 유출을 되돌리지 못합니다.

점검 대상
확인할 흔적

웹 서버 로그
반복되는 HTTP 500 오류

PHP 실행 기록
비정상 종료와 segfault

웹·업로드·임시 폴더
새로 생기거나 바뀐 PHP 파일

프로세스 실행 기록
웹 서버의 sh·bash·다운로드 도구 실행

네트워크 연결
낯선 외부 주소로 새로 연결한 흔적

홈페이지·관리 페이지
몰래 추가된 외부 스크립트

오류가 있다는 사실만으로 침해를 확정할 수는 없습니다. 반대로 이상 기록이 없다고 안전을 확정할 수도 없습니다. KISA는 다음과 같이 안내합니다.

기록상 이상이 없더라도 안전이 보장되지 않으므로, 업데이트와 인증정보 교체를 함께 진행
KISA 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」

패치 전 인터넷에 노출된 서버는 인증정보 교체가 권고됩니다. 침해 흔적이 발견된 서버는 반드시 교체하세요. 대상에는 DB 비밀번호와 관리자 비밀번호가 포함됩니다. API 키와 접속 토큰도 노출 가능성을 점검하세요.
개인정보 DB를 연결한 서비스는 DB 기록도 확인하세요. 대량 조회와 반출 흔적을 점검할 필요가 있습니다. phpMyAdmin의 인터넷 직접 접근도 제한하세요. 웹서비스 계정의 DB 권한은 필요한 범위로 줄이세요. 개인정보보호위원회 예방조치 안내

침해가 의심될 때 대응 순서
침해가 의심되면 서버를 끄거나 바로 재시작하지 마세요. 재시작으로 메모리에 남은 공격 흔적이 사라질 수 있습니다. 네트워크 격리 뒤 증거 확보를 진행하세요.

서버의 외부 접속을 네트워크에서 차단하세요.
국내 기업은 보호나라의 침해사고 신고 메뉴로 신고하세요.
로그와 실행 중인 프로그램 목록을 보존하세요.
현재 네트워크 연결 정보도 보존하세요.
증거 확보 뒤 업데이트와 재시작을 진행하세요.
웹셸 제거와 인증정보 교체를 진행하세요.

국내 상담 창구는 KISA 118입니다. 신고 메뉴는 보호나라 > 침해사고 신고 > 신고하기입니다. 해외에서 운영한다면 해당 지역의 신고 창구를 확인하세요.

흔한 실수 비교
패치 적용 여부는 실행 상태와 변경 이력까지 확인해야 합니다. 설치 완료 메시지만으로는 확인이 끝나지 않습니다. 다음 판단을 점검표에 넣어두세요.

흔한 판단
확인해야 할 내용

php -v가 바뀌면 완료
웹 서비스가 실제 사용하는 PHP 확인

패키지만 설치하면 완료
PHP 실행 서비스 재시작 확인

버전 숫자가 그대로면 미조치
배포판 변경 이력의 CVE 수정 여부 확인

웹방화벽이 있으면 패치 생략 가능
최신 규칙 확인과 PHP 업데이트 병행

로그가 깨끗하면 유출 없음
인증정보의 노출 가능성까지 검토

외주 사이트는 업체가 알아서 처리
서비스별 적용 근거 요청

인터넷에서 찾은 검증 코드를 운영 서버에 실행하지 마세요. KISA는 악성코드가 포함된 가짜 PoC를 경고합니다. PoC는 취약점 악용 가능성을 보여주는 검증 코드입니다. 취약 여부는 버전과 패치 이력부터 확인하세요.

외주·호스팅 환경의 조치 완료 확인표
조치 완료 보고에는 서비스별 확인 근거를 남기는 편이 좋습니다. 아래 표는 KISA 대응 수칙을 업무 확인 항목으로 묶은 것입니다. 별도의 공식 제출 서식은 아닙니다.

확인 항목
업체나 담당자에게 요청할 내용

대상 누락 여부
홈페이지·관리 페이지·테스트 서버의 점검 목록

취약점 수정
적용 버전 또는 두 CVE가 적힌 패키지 변경 이력

실행 상태
서비스 재시작 또는 컨테이너 재배포 기록

실제 반영
웹 서비스에서 확인한 PHP 실행 환경

침해 점검
점검한 로그 기간과 발견 사항

인증정보
교체 대상과 완료 여부

남은 작업
임시 조치만 적용된 서버와 후속 패치 계획

예를 들어 업체가 패키지 설치 완료만 알렸다고 가정합니다. 이때는 재시작과 웹 실행 환경의 확인 결과를 요청하세요. 로그 점검과 인증정보 교체는 별도 항목으로 확인하면 됩니다.

FAQ
Q. PHP2Shell은 로그인 비밀번호를 바꾸면 막을 수 있나요?
A. 로그인 없이 악용될 수 있어 비밀번호 변경만으로 해결되지 않습니다. PHP 보안 업데이트가 필요합니다. 인증정보 교체는 유출 가능성에 대응하는 별도 조치입니다.
Q. PHP 8.5는 8.5.13까지 기다려야 하나요?
A. PHP와 KISA 원문은 두 취약점의 수정 버전을 8.5.13로 안내합니다. 8.5.13을 기다려야 한다는 뜻이 아닙니다. 적용할 때는 해당 계열의 최신 공식 릴리스도 확인하세요.
Q. PHP-FPM을 사용하면 점검하지 않아도 되나요?
A. PHP-FPM도 점검 대상입니다. 실행 방식에 따라 공격 조건은 달라질 수 있습니다. 환경 이름만으로 안전을 판단하지 마세요.
Q. php -v 결과가 수정 버전이면 조치가 끝난 것인가요?
A. 명령줄 PHP와 웹 서비스의 PHP가 다를 수 있습니다. 실제 웹 요청을 처리하는 환경을 확인하세요. 실행 서비스의 재시작 여부도 확인해야 합니다.
Q. 패치 후 버전 번호가 그대로면 실패한 것인가요?
A. 배포판이나 제조사 패키지는 기존 버전에 수정 사항을 반영할 수 있습니다. 패키지 변경 이력에서 두 CVE의 반영 여부를 확인하세요.
Q. memory_limit=-1은 이번 대응에서 금지되는 설정인가요?
A. 이번 취약점의 공식 임시 권고에는 해당 설정이 포함됩니다. 일반적인 운영 권고와 구분해야 합니다. 요청 제한과 자원 관리 대책을 함께 검토하세요.
Q. 파일 업로드가 없는 사이트도 대상인가요?
A. 업로드 기능이 없다는 이유만으로 대상에서 제외할 수 없습니다. PHP 자체의 취약점이므로 사용 버전과 패치 상태를 확인하세요. 불필요한 multipart 요청 차단은 임시 조치입니다.
Q. PHP 8.1 이하에 업체 패치가 있으면 계속 사용해도 되나요?
A. 업체 패치는 정규 지원 종료와 별도로 확인해야 합니다. 해당 패치를 임시 적용하더라도 지원 버전 전환 계획을 세우세요.
Q. 로그에서 이상이 없으면 인증정보를 유지해도 되나요?
A. 로그만으로 정보 유출이 없었다고 판단할 수 없습니다. KISA는 패치 전 인터넷에 노출된 서버의 인증정보 교체를 권고합니다. 침해 흔적이 있으면 반드시 교체하세요.
Q. 침해가 의심되는데 업데이트를 먼저 해야 하나요?
A. 먼저 네트워크에서 격리하세요. 신고와 증거 확보 후 업데이트를 진행하세요. 재시작하면 메모리에 남은 공격 흔적이 사라질 수 있습니다.
Q. 호스팅 이용자는 무엇을 확인해야 하나요?
A. 업체에 서비스별 패치 적용 근거를 요청하세요. 재시작과 실제 웹 실행 환경의 확인 결과도 요청하세요. 로그 점검과 인증정보 교체 여부는 별도로 확인하세요.
Q. 패치 후 업로드 진행률 설정을 다시 켜도 되나요?
A. PHP의 2026년 10월 23일 추가 공지를 확인하세요. 일부 설정 조합의 추가 문제 때문에 기능 비활성화 유지가 권고됩니다. 설정 복원은 후속 수정 사항을 확인한 뒤 판단하세요.

Sources
- KISA 보호나라: PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙, 2026년 10월 22일: https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230
- PHP 2026년 공지: 10월 21일 보안 업데이트와 10월 23일 Session upload progress 추가 안내: https://www.php.net/archive/2026.php
- PHP 보안 권고: RCE via OOM corruption: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- PHP 보안 권고: RCE via stale global state: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- PHP Supported Versions: 공식 지원 기간: https://www.php.net/supported-versions.php
- PHP2Shell: 연구진의 취약점 설명과 영향 범위: https://www.php2shell.com/
- 개인정보보호위원회: PHP 보안 취약점 관련 개인정보 유출 예방조치 당부, 2026년 10월 22일: https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588

Images
- 서버실에서 여성이 랙 서버의 네트워크 포트 앞에 파란 랜 케이블 커넥터를 들고 있다.: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp
- 공장에서 중년 기술자가 열린 네트워크 장비함 옆 태블릿의 상태 화면을 확인하는 모습: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp
- 서버 사용 현황 확인부터 침해 여부별 대응, 패치, 서비스 재시작, 로그 점검과 인증정보 교체까지 정리한 흐름도: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzOTUsInB1ciI6ImJsb2JfaWQifX0=--dacb7fe617f3f237c4c74b415c08756ecf82ee8b/ai-bd9f0440.webp

---
Category: 하우투
Source: https://injoys.com/ko/articles/php2shell-enterprise-security-patch-response-guide
License: cc_by
Translation-Status: original