PHP2Shell이란? PHP 긴급 업데이트와 서버 침해 대응

PHP2Shell은 PHP 웹셸 파일의 이름이 아니라 인증 없이 원격 코드를 실행할 수 있는 PHP 런타임 취약점 묶음입니다. 인터넷에 공개된 PHP 서버라면 PHP 버전을 먼저 확인하고 이미 노출된 기간이 있었다면 패치와 별도로 침해 흔적도 확인해야 합니다.

1. PHP2Shell이란 무엇인가

PHP2Shell은 2026년 10월 21일 공개된 CVE-2026-109618과 CVE-2026-109619을 묶어 부르는 이름입니다. 두 취약점이 악용되면 공격자는 로그인 없이 PHP 서버에서 임의의 코드를 실행할 수 있습니다.

이름에 shell이 들어가지만 서버에 이미 숨어 있는 .php 웹셸 파일 자체를 뜻하지는 않습니다. 취약점을 이용해 웹셸을 올릴 가능성이 있기 때문에 패치와 파일 점검을 함께 해야 한다는 의미로 이해하면 됩니다.

2. 내 서버가 확인할 대상

PHP 공식 공지에 따르면 웹 요청을 처리하는 PHP 설치본이 대상입니다. PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed 환경을 포함합니다.

우선 서버와 컨테이너, 호스팅 패널에 설치된 PHP를 모두 목록으로 만듭니다. 메인 사이트만 보지 말고 오래된 관리자 도구·테스트 도메인·별도 컨테이너도 확인해야 합니다.

위 표는 10월 21일 공개된 두 취약점의 수정 기준입니다. 공급사가 이전 버전 번호를 유지한 채 보안 패치를 적용하는 백포트 패키지는 버전 숫자만으로 결정하지 말고 공급사 공지를 확인하세요. 10월 23일 추가 공지는 아래 4번에서 별도로 다룹니다.

명령줄의 PHP와 실제 사이트를 처리하는 PHP-FPM·Apache 모듈·컨테이너 버전은 다를 수 있습니다. 운영 경로별로 패치 상태와 작업자 재시작을 확인하세요. 확인용 phpinfo 페이지를 외부에 공개하지 말고 컨테이너에서는 이미지 갱신 여부와 실행 중인 컨테이너를 함께 대조합니다.

3. 일반 패치와 침해 의심 시 대응 구분

취약한 버전이었다는 사실만으로 침해가 확인된 것은 아닙니다. 이상 징후가 없는 경우의 패치 절차와, 낯선 파일·계정·외부 연결이 발견된 경우의 대응을 구분합니다.

이상 징후가 없다면: 패치와 서비스 확인

현재 파일·데이터베이스와 설정을 백업하고 복구 경로를 확인합니다. 공급사의 수정 패키지 또는 컨테이너 이미지를 적용한 뒤 실제 웹 요청을 처리하는 PHP 작업자를 재시작합니다. 웹 경로의 버전·패치 상태와 홈페이지·관리자 로그인·업로드 등 사용하는 기능을 확인하고 결과를 기록하세요. 노출 기간의 로그·파일 점검도 이어서 진행합니다.

침해가 의심된다면: 보존·노출 축소·정상 복구

1단계: 변경 기록부터 보존

웹 서버 접근 로그·오류 로그·PHP-FPM 로그·호스팅 패널의 변경 기록을 먼저 별도 위치에 보관합니다. 발견 시각, 최근 플러그인·테마·서버 설정 변경도 함께 적어 두면 이후 원인 추적에 도움이 됩니다.

2단계: 서비스 노출을 줄이고 업데이트

서비스 침해가 의심된다면 호스팅사나 운영 담당자와 먼저 협의해 접근을 제한합니다. 이후 배포판 또는 호스팅사가 제공하는 수정 버전으로 올리고 PHP-FPM이나 웹 서버 작업자가 실제로 재시작됐는지 확인합니다.

3단계: 신뢰할 수 있는 환경에서 접근 정보 교체

침해 가능성이 있으면 서비스 노출을 줄이고 신뢰할 수 있는 관리 기기에서 접근 정보를 교체합니다. 공격자가 계속 접근하는 서버에 새 키를 그대로 저장하면 다시 노출될 수 있으므로 격리·정상 환경 복구와 함께 진행하세요. WordPress 관리자 비밀번호만 바꾸는 것으로 충분하지 않습니다. 호스팅 패널, SSH, SFTP, 데이터베이스, 배포 토큰, API 키처럼 사이트에 접근할 수 있는 계정을 범위에 넣습니다.

4. 10월 23일 추가 공지와 임시 완화 조치

10월 21일 두 취약점: 수정 패키지 적용이 우선

위 표의 수정 버전 또는 공급사 패치를 적용합니다. 업데이트 전 일부 공격 경로를 줄이는 임시 설정은 완전한 대체책이 아닙니다.

10월 23일 별도 공지: 세션 업로드 진행 기능 확인

PHP는 CVE-2026-115560 관련 추가 안내를 공개했습니다. 드문 설정·코드 조합에서 발생하는 별도 문제로, 10월 21일 두 취약점의 패치가 모두 무효라는 뜻은 아닙니다.

조건은 세션 업로드 진행 기능이 켜진 상태에서 설정의 session.serialize_handler가 php_binary 또는 php_serialize이고 앱이 실행 중 이를 php로 바꾼 뒤 session_start()를 호출하는 경우입니다. 실행 중 핸들러를 바꾸지 않는 앱은 해당 기능을 유지할 수 있다고 안내합니다.

PHP는 다음 정기 버그 수정 릴리스까지 session.upload_progress.enabled=0을 권고합니다. 이미 적용했다면 유지합니다. 담당자가 앱의 사용 여부·영향을 확인하고 요청 처리 전 적용되는 서버 설정에서 변경한 뒤 모든 관련 작업자를 재시작해 실제 웹 경로의 적용값을 확인하세요. 업로드 진행률 표시에 영향을 줄 수 있으므로 기능도 점검합니다.

추가 문제의 수정 릴리스와 최종 권고는 이후 PHP 공지를 확인합니다. 운영 앱에 새로운 세션 핸들러 변경 코드를 넣거나, 요청 중 ini_set() 호출만 추가하는 방식으로 대응하지 않습니다.

5. 침해 흔적은 무엇을 확인해야 하나

정상 업데이트 뒤에도 최근 생성·수정된 PHP 파일, 예상하지 못한 관리자 계정, PHP 또는 웹 서버 프로세스가 만든 낯선 명령과 외부 연결을 확인합니다. 로그에 흔적이 없다는 이유만으로 침해가 없었다고 결론 내리지는 않습니다. 보존 기간이나 수집 범위가 부족할 수 있으므로 파일·계정·예약 작업 등과 함께 확인합니다. 로그에서 비정상적인 대용량 multipart/form-data 요청이나 PHP 오류·작업자 재시작이 반복되는지도 봅니다.

파일 이름만 보고 삭제하지는 마십시오. 테마·플러그인 파일은 정상 파일과 섞일 수 있습니다. 조사 전 사본을 보관하고 신뢰 가능한 원본 패키지·버전 관리 기록과 비교해 확인하는 편이 안전합니다.

6. WordPress 사이트라면 추가로 할 일

WordPress 공식 문서는 침해가 의심될 때 증상을 기록하고 웹사이트와 관리 PC를 각각 검사하며 호스팅사와 함께 범위를 확인하라고 안내합니다. 관리자·SFTP·호스팅 패널·데이터베이스처럼 모든 접근 지점의 비밀번호를 교체해야 합니다.

코어 파일은 WordPress 공식 배포본으로 비교·재설치할 수 있지만 wp-content에는 테마·플러그인·업로드 파일이 있으므로 무작정 덮어쓰지 않습니다. 사용하지 않는 플러그인과 테마를 제거하고 업데이트 가능한 구성 요소는 최신 버전으로 유지합니다.

Cloudflare를 앞단에 쓰더라도 원본 서버 PHP는 별도 관리 대상입니다. 앞단 보호를 사용한다는 이유로 원본의 패치·파일·계정 확인을 생략하지 않습니다.

7. 피해야 할 대응

8. 마지막 정리

PHP2Shell 대응의 기준은 “패치했으니 끝”이 아니라 “패치와 침해 확인을 모두 마쳤는가”입니다. 10월 21일 두 취약점의 수정 패키지를 적용하고 10월 23일 세션 업로드 추가 공지의 조건과 권고를 별도로 확인합니다. 노출 기간이 있었다면 로그·파일·계정·외부 연결도 점검하세요.

웹셸이나 변조 흔적이 보이면 혼자 파일 몇 개를 지우기보다 서비스 노출을 줄이고 증거를 보존한 뒤 호스팅사 또는 보안 대응 인력과 복구 범위를 정하는 편이 안전합니다.

9. 출처와 자료 확인일

최초 자료 확인일: 2026년 10월 22일. PHP 추가 공지와 대응 범위 재확인일: 2026년 10월 23일. PHP 버전과 배포판의 백포트 적용 여부는 호스팅사·운영체제 공급사 문서를 함께 확인합니다.

• PHP: 10월 21일 긴급 패치 및 10월 23일 세션 업로드 추가 공지
• Canadian Centre for Cyber Security: PHP2Shell 경보
• Cloudflare: PHP2Shell WAF 보호 안내
• WordPress: 침해 의심 사이트 대응 안내