PHP2Shell 점검 5단계, 업데이트 이후에도 로그와 인증정보까지 확인해야 하는 이유

핵심 POINT

PHP 프로젝트는 2026년 10월 21일 보안 공지를 내고, 치명적인 취약점 2건(CVE-2026-109618, CVE-2026-109619)을 고친 PHP 8.2부터 8.5까지의 보안 업데이트를 배포했습니다. 웹 요청을 처리하는 모든 PHP 설치 환경이 대상이며, 로그인 없이 외부에서 보낸 요청만으로 서버에서 원하는 명령을 실행할 수 있는 원격 코드 실행 취약점입니다. 두 건 모두 CVSS 4.0 기준 9.2점으로 평가됐습니다.

KISA도 10월 21일 보호나라에 'PHP 제품 보안 업데이트 권고'를 올린 데 이어, 22일에는 'PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙'을 공개했습니다. KISA는 보안 업데이트가 배포되기 전에 취약점 정보가 유출됐고 해외 보안업체를 중심으로 공격 시도가 보고되고 있다고 밝혔습니다. 이 글을 쓴 시점에 국내 피해 사례는 두 공지에 언급되지 않았습니다.

이 글에서는 취약점의 내용을 간단히 짚고, KISA 대응 수칙을 바탕으로 PHP 사용 현황 확인, 업데이트와 재시작, 임시 조치, 로그 점검, 인증정보 교체까지 5단계 점검 순서를 정리합니다.

■ PHP2Shell 취약점, 무엇이 문제일까요?

출처: AI(ChatGPT) 생성 이미지

PHP는 홈페이지와 쇼핑몰, 업무 시스템을 만드는 데 널리 쓰이는 서버 언어입니다. 이번 취약점 두 건은 PHP가 요청 하나를 처리하고 정리하는 과정에서 생기는 결함입니다. PHP 프로젝트와 PHP 개발 저장소의 보안 권고문은 두 취약점을 아래와 같이 설명합니다.

[표] PHP2Shell 취약점 요약 (PHP 프로젝트 보안 공지와 php-src 보안 권고문, 2026.10)

PHP 프로젝트는 아파치 웹 서버에 PHP를 붙여 쓰는 방식(mod_php)의 위험이 가장 높다고 평가했습니다. 이 환경에서는 로그인하지 않은 요청 하나가 애플리케이션 코드가 실행되기도 전에 공격을 일으키는 사례가 실제로 시연됐다고 밝혔습니다. PHP-FPM은 소스 분석상 영향을 받을 수 있지만 완전한 공격은 아직 시연되지 않았다는 것이 PHP 개발 저장소 권고문의 설명입니다. 다만 PHP 프로젝트는 PHP-FPM, php-cgi, FrankenPHP, LiteSpeed를 포함해 웹 요청을 처리하는 모든 환경이 위험하다고 안내했습니다.

KISA는 공격에 성공하면 원격조종 파일(웹셸) 설치, 고객정보 유출, 홈페이지 변조, 내부망 침투까지 이어질 수 있다고 설명했습니다. 이 취약점은 서버 메모리에 담긴 비밀번호나 접속 토큰, 외부 서비스 연동 키(API 키)도 유출시킬 수 있다고 덧붙였습니다.

■ 점검 1단계, 우리 회사의 PHP 사용 현황 확인

출처: AI(ChatGPT) 생성 이미지

가장 먼저 할 일은 어디에서 PHP가 돌아가고 있는지 찾는 것입니다. KISA는 자산 관리 목록에만 의존하지 말고 실제로 동작 중인 서버를 기준으로 확인하라고 당부했습니다.

❶ 놓치기 쉬운 곳부터 확인

KISA 대응 수칙은 인터넷에 공개된 모든 홈페이지와 시스템의 PHP 사용 여부와 버전을 확인하라고 안내합니다. 아래 대상을 빠뜨리지 않는 것이 중요합니다.

• 외주로 제작한 사이트

• 오래전에 만들어 두고 관리하지 않는 사이트

• 이벤트 사이트와 테스트 서버

• 관리자 페이지

❷ 장비와 컨테이너 이미지도 별도 확인

PHP는 눈에 보이는 홈페이지 서버에만 있지 않습니다. KISA는 네트워크 장비의 관리 화면, PHP가 포함된 윈도우용 설치 패키지, 도커 같은 외부 컨테이너 이미지도 따로 확인하라고 안내했습니다. 장비나 솔루션 제조사가 PHP를 관리하는 경우에는 관리자가 직접 업데이트하기 어려울 수 있으므로, 제조사에 조치 적용 여부를 확인하고 요청해야 합니다. 호스팅 업체가 PHP를 관리하는 경우도 마찬가지입니다.

■ 점검 2단계, 업데이트 설치와 웹 서비스 재시작

‍

두 번째는 해결 버전으로 올리고 웹 서비스를 다시 시작하는 단계입니다. 인터넷에 공개된 서버부터 먼저 조치하는 것이 KISA의 권고입니다.

❶ 업데이트 후 재시작은 필수

PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상으로 업데이트한 뒤에는 PHP를 실행하는 모든 웹 서비스(PHP-FPM, 아파치 mod_php, php-cgi, FrankenPHP, LiteSpeed 등)를 반드시 재시작해야 합니다. KISA는 재시작하지 않으면 메모리에 남은 이전 버전이 계속 동작해 여전히 취약하다고 설명했습니다. 컨테이너 환경이라면 새 이미지를 다시 배포해야 합니다.

❷ 바뀐 버전 확인 방법

재시작을 마친 뒤에는 웹 서비스가 실제로 사용하는 PHP 버전이 바뀌었는지 확인합니다. 아래 명령어로 보이는 버전과 웹 서비스가 사용하는 버전이 서로 다를 수 있기 때문입니다. 한 서버에 PHP가 여러 개 설치돼 있다면 각각 확인해야 합니다.

php -v

리눅스 배포판이나 제조사가 제공하는 패키지는 보안 패치를 적용해도 버전 번호가 그대로일 수 있습니다. 이 경우에는 패키지 변경 이력에서 두 CVE가 반영됐는지 확인하세요.

❸ PHP 8.1 이하는 지원 버전으로 전환

PHP 8.1 이하는 PHP 프로젝트의 공식 업데이트가 제공되지 않습니다. KISA는 PHP 8.2도 2026년 12월 31일에 보안 지원이 끝날 예정이어서 8.3 이상으로 전환하는 것을 권장했습니다. 전환에 시간이 걸린다면 리눅스 배포판이나 장기 지원(LTS) 업체의 보안 패치, 또는 PHP 보안팀이 PHP 7.4, 8.0, 8.1용으로 공개한 최소 소스 패치를 임시로 적용하고 전환 계획을 세우라는 안내입니다.

■ 점검 3단계, 바로 업데이트하기 어려울 때의 임시 조치

출처: AI(ChatGPT) 생성 이미지

서비스 중단이나 호환성 검토 때문에 당장 업데이트하기 어렵다면 임시 조치로 노출을 줄일 수 있습니다. 다만 PHP 프로젝트는 업데이트만이 완전한 해결책이라고 밝혔고, KISA도 임시 조치만으로는 공격을 완전히 막지 못한다며 업데이트를 권고했습니다.

❶ PHP 앞단에서 요청 제한

• 웹 방화벽, 웹 서버, 프록시에서 요청 크기를 제한합니다. 요청 크기 정보가 없는 요청도 제한 대상에 포함해야 합니다.

• 파일 업로드가 필요 없는 서비스는 파일 업로드(multipart) 요청을 차단합니다.

• 웹 방화벽을 쓰고 있다면 최신 차단 규칙이 적용됐는지 확인합니다.

❷ PHP 공식 임시 설정 적용

PHP 공식 안내의 설정을 php.ini, PHP-FPM 풀 설정 또는 웹 서버 설정에 적용한 뒤 모든 PHP 프로세스를 재시작합니다. KISA 수칙에 정리된 항목은 아래와 같습니다.

session.upload_progress.enabled = 0
memory_limit = -1
post_max_size = 8M
fatal_error_backtraces = 0

• session.upload_progress.enabled는 파일 업로드 진행률 표시 기능을 끄는 설정입니다.

• memory_limit는 프로그램이 바꿀 수 없도록 관리자 설정(예: PHP-FPM 풀의 php_admin_value)으로 지정합니다.

• post_max_size는 업로드가 필요 없으면 8M, 필요하면 32M 수준으로 낮게 두고, upload_max_filesize는 이보다 작게 유지합니다.

• fatal_error_backtraces는 PHP 8.5를 쓸 때만 추가합니다.

PHP 프로젝트는 session.upload_progress.enabled 설정을 요청 처리 전에 적용되는 php.ini, PHP-FPM 풀 설정, 서버 설정에 넣고 ini_set()이나 .user.ini에는 의존하지 말라고 당부했습니다.

❸ 임시 조치도 어렵다면

KISA는 임시 조치마저 적용하기 어렵다면 업데이트 전까지 외부 접속을 차단하거나 서비스를 일시 중단하는 방안을 검토하라고 권고했습니다.

■ 점검 4단계, 업데이트 이후 로그 확인

‍

KISA는 취약점 정보가 유출된 10월 20일 이후의 기록 전체를 점검하고, 가능하면 그 이전 기록까지 확인하라고 안내했습니다. 업데이트를 마쳤더라도 그 전에 공격을 받았는지는 따로 확인해야 하기 때문입니다. 주요 점검 항목은 아래와 같습니다.

• PHP 페이지로 들어온 비정상적으로 큰 요청과 그 뒤에 반복된 서버 오류(HTTP 500)

• 원인을 알 수 없는 PHP 프로그램 재시작, 비정상 종료(segfault), 메모리 부족 오류

• 웹 서버가 명령 실행 프로그램(sh, bash 등)이나 파일 다운로드 도구를 실행한 흔적

• 웹 폴더, 업로드 폴더, 임시 폴더에 새로 생기거나 바뀐 PHP 파일(웹셸)

• 홈페이지나 결제 페이지에 몰래 추가된 외부 스크립트

• 웹 서버에서 알 수 없는 외부 주소로 새로 연결한 흔적

KISA는 기록상 이상이 없더라도 안전이 보장되지 않는다고 설명했습니다. 그래서 다음 단계의 인증정보 교체를 업데이트와 함께 진행하라고 권고했습니다.

■ 점검 5단계, 중요 인증정보 교체

‍

이번 취약점은 서버 메모리에 담긴 비밀번호, 접속 인증값(토큰), 외부 서비스 연동 키를 유출시킬 수 있다는 것이 KISA의 설명입니다. 업데이트 전까지 인터넷에 노출돼 있던 서버라면 아래 정보를 교체하는 것이 권장됩니다.

• 데이터베이스(DB) 비밀번호

• 외부 서비스 연동 키(API 키)

• 관리자 계정 비밀번호

로그에서 침해 흔적이 발견된 서버는 선택이 아니라 반드시 교체해야 합니다.

■ 침해 흔적을 발견했다면

‍

KISA는 침해사고가 의심될 때 아래 순서로 대응하라고 안내했습니다. 순서가 중요한 이유는 서버를 재시작하면 메모리에 남은 공격 흔적이 사라지기 때문입니다.

❶ 격리

서버를 끄거나 재시작하지 말고, 네트워크에서 외부 접속만 차단합니다.

❷ 신고

보호나라(boho.or.kr)에서 침해사고 신고 메뉴를 통해 신고합니다.

❸ 증거 확보

서버 기록(로그), 실행 중인 프로그램 목록, 네트워크 연결 정보를 보존합니다.

❹ 조치

증거를 확보한 뒤에 업데이트와 재시작, 웹셸 제거, 인증정보 교체를 진행합니다.

한 가지 더 주의할 점이 있습니다. 인터넷에 떠도는 공격 코드(PoC) 중에는 악성코드가 숨겨진 가짜가 많다고 KISA가 경고했습니다. 내 서버가 취약한지는 PoC를 실행하지 말고 버전 확인과 기록 점검으로 판단하세요. 분석이 꼭 필요하다면 업무망과 분리된 환경에서만 수행해야 합니다.

SK쉴더스는 취약점 진단과 보안 관제 서비스를 통해 기업이 홈페이지와 웹 서버의 PHP 사용 현황을 파악하고 침해 징후를 점검하도록 지원하고 있습니다.

■ 자주 묻는 질문

‍

Q. 우리 홈페이지가 PHP로 만들어졌는지 모르겠는데 어떻게 확인하나요?

A. 개발사나 호스팅 업체, 서버 담당자에게 사용 중인 PHP 버전을 문의하는 것이 가장 확실합니다. KISA는 호스팅 업체나 장비·솔루션 제조사가 PHP를 관리하는 경우 해당 업체에 조치 적용 여부를 확인하고 요청하라고 안내했습니다.

Q. 업데이트를 설치했는데 재시작하지 않았다면 안전한가요?

A. 그렇지 않습니다. KISA는 재시작하지 않으면 메모리에 남은 이전 버전이 계속 동작해 여전히 취약하다고 설명했습니다. 모든 PHP 웹 서비스를 재시작하고 웹 서비스가 쓰는 버전이 바뀌었는지 확인하세요.

Q. 서버에서 확인한 PHP 버전이 최신인데도 다시 확인해야 하나요?

A. 네, 확인이 필요합니다. 명령어로 보이는 버전과 웹 서비스가 사용하는 버전이 다를 수 있고, 배포판 패키지는 패치를 적용해도 버전 번호가 그대로일 수 있습니다. 한 서버에 PHP가 여러 개라면 각각 확인하고, 패키지는 변경 이력에서 CVE 반영 여부를 보세요.

Q. PHP 8.1 이하를 쓰고 있다면 어떻게 하나요?

A. PHP 프로젝트의 공식 업데이트는 제공되지 않으므로 지원되는 버전으로 전환해야 합니다. 당장 어렵다면 배포판이나 LTS 업체의 보안 패치, 또는 PHP 보안팀이 공개한 7.4, 8.0, 8.1용 최소 소스 패치를 임시로 적용하고 전환 계획을 세우라는 것이 KISA의 안내입니다.

Q. 이미 국내에서도 실제 공격이 있었나요?

A. KISA는 취약점 정보가 사전에 유출됐고 해외 보안업체를 중심으로 공격 시도가 보고되고 있다고 밝혔습니다. 이 글을 쓴 시점에 국내 피해 사례는 KISA 공지에 언급되지 않았습니다. 상황이 바뀔 수 있으니 KISA 보호나라 공지를 계속 확인하세요.

[콘텐츠 출처]

PHP 프로젝트, Security advisory: Critical remote code execution vulnerabilities, update now (2026.10.21)

KISA 보호나라, PHP 제품 보안 업데이트 권고 (2026.10.21)

KISA 보호나라, PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙 (2026.10.22)

php-src 보안 권고문, RCE via OOM corruption (CVE-2026-109618)