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 실행 환경
침해 점검 | 점검한 로그 기간과 발견 사항
인증정보 | 교체 대상과 완료 여부
남은 작업 | 임시 조치만 적용된 서버와 후속 패치 계획
예를 들어 업체가 패키지 설치 완료만 알렸다고 가정합니다. 이때는 재시작과 웹 실행 환경의 확인 결과를 요청하세요. 로그 점검과 인증정보 교체는 별도 항목으로 확인하면 됩니다.
Injoys
