PHP2Shell 내 사이트도 위험할까 업데이트부터 침해 점검까지

홈페이지가 평소처럼 열리고 관리자 비밀번호도 바꾸었다면 안전할까요? PHP2Shell에서는 그것만으로 판단하기 어렵습니다. 일부 공격 경로가 로그인이나 애플리케이션의 정상 처리보다 앞선 PHP 실행 과정에 있기 때문입니다.

지금 할 일은 PHP 사용 위치를 찾고, 수정된 실행 환경을 배포한 뒤, 실제 적용 여부와 과거 침해 흔적을 함께 확인하는 것입니다. WAF의 차단 기록과 사이트의 정상 응답은 이 과정을 보조하는 자료입니다.

이 글은 PHP 프로젝트, 보안 기관, 공격 관측 업체의 공개 자료를 바탕으로 작성한 운영 점검 안내입니다. 특정 사이트를 공격하거나 독자의 서버를 직접 진단한 결과는 아닙니다.

그림 1. Cloudflare의 PHP 취약점 보호 안내에 실린 공식 대표 일러스트입니다. 공격 경로나 피해 규모를 표현한 도표가 아닙니다. 공식 원문 · 원본 확대

PHP2Shell은 무엇이며 왜 로그인이 필요 없을까요

PHP는 웹 서버에서 프로그램을 실행하는 언어이자 실행 환경입니다. WordPress 같은 CMS뿐 아니라 쇼핑몰, 예약 시스템, 사내 관리 화면에도 사용됩니다. 웹브라우저가 받은 HTML만으로 서버 안의 PHP 버전을 알아낼 수는 없습니다.

PHP2Shell은 공개 자료에서 함께 다루는 두 취약점의 이름입니다. 하나는 메모리 부족 처리 중 객체가 불완전하게 초기화되는 문제이고, 다른 하나는 요청 사이에 남은 전역 상태로 이미 해제된 메모리를 다시 사용하는 문제입니다. 조건이 맞으면 공격자가 서버에서 코드를 실행하는 RCE로 이어질 수 있습니다. RCE는 원격 코드 실행을 뜻합니다. PHP 메모리 부족 취약점 공지, 요청 사이 상태 취약점 공지

PHP 공식 공지는 FPM, Apache의 mod_php, CGI, FrankenPHP, LiteSpeed 등 여러 웹 실행 구성을 영향 범위에 포함합니다. 특히 mod_php의 심각한 경로에서는 애플리케이션 코드가 실행되기 전에도 문제가 생길 수 있습니다. 관리자 로그인 화면이 있다는 이유로 방어됐다고 볼 수 없고, FPM을 쓴다는 이유만으로 제외할 수도 없습니다. 실제 공격 조건과 영향은 실행 방식·설정에 따라 다릅니다. PHP 보안 공지

실행 권한은 보통 PHP 작업 프로세스가 가진 권한에서 시작합니다. 모든 서버에서 곧바로 최고 관리자 권한을 얻는다는 뜻은 아닙니다. 다만 그 계정이 소스 파일, 환경 설정, DB 접속 정보에 접근할 수 있다면 피해가 연결된 시스템으로 넓어질 수 있습니다.

공격 시도와 실제 침해를 구분해서 읽습니다

“많은 사이트가 공격받고 있다”는 표현에는 서로 다른 상황이 섞일 수 있습니다. 스캔이나 악성 요청이 도착한 것, 코드 실행에 성공한 것, 개인정보가 유출된 것은 각각 다른 근거가 필요합니다.

공개 자료에서 확인한 사실	그 사실만으로 단정할 수 없는 내용
AWS가 10월 17일 허니팟에서 관련 시도를 관측했고 공개 이후 추가 시도를 보고	그 요청을 받은 모든 실제 서버에서 공격이 성공했다는 주장
Cloudflare가 공격 트래픽과 변형되는 요청을 관측	차단 건수를 실제 침해 사이트 수로 환산한 수치
운영자가 예방 목적으로 서비스를 제한하거나 중단	해당 기관이 이미 침해되었다는 결론

AWS의 허니팟은 공격을 관찰하려고 만든 환경입니다. AWS도 초기 요청이 실제 운영 환경에서 성공했을지는 확정하지 않았습니다. 따라서 공개 전후의 시도를 경계하되, 별도의 피해 집계처럼 소개하지 않아야 합니다. AWS 위협 정보, Cloudflare 관측

첫 단계는 숨어 있는 PHP까지 찾는 것입니다

개발팀이 주력 서비스를 다른 언어로 만들었어도 PHP가 남아 있을 수 있습니다. 서버별 목록에 담당자와 외부 공개 여부를 함께 적으면 업데이트 대상을 놓치기 어렵습니다.

확인할 위치	담당자에게 물을 내용
홈페이지·CMS·쇼핑몰	CMS 버전과 별개로 PHP 실행 버전은 무엇인가요?
호스팅·외주 운영 시스템	공급자가 어느 수정 빌드를 언제 적용했나요?
컨테이너·배포 이미지	새 이미지 배포와 기존 인스턴스 교체가 모두 끝났나요?
관리 도구·오래된 서브도메인	phpMyAdmin이나 사용하지 않는 PHP 서비스가 외부에 열려 있나요?

ENISA는 자산 식별, 공급자와의 조율, 인터넷에 노출된 시스템의 우선 조치를 권고합니다. 즉시 패치할 수 없다면 노출된 애플리케이션을 격리하는 방안도 검토하도록 안내합니다. 개인정보보호위원회 역시 외주·수탁업체·호스팅 환경을 사각지대로 지목했습니다. ENISA 공동 성명, 개인정보위 예방조치

CMS 업데이트와 PHP 업데이트는 별개입니다

플러그인을 최신으로 바꿔도 그 아래에서 실행되는 PHP가 취약한 채로 남을 수 있습니다. 운영체제 패키지, 호스팅 설정, 컨테이너 이미지 등 PHP를 실제로 공급하는 경로에서 수정판을 적용해야 합니다.

다음은 2026년 10월 21일 공개된 각 지원 계열의 첫 수정 버전입니다. 앞으로도 계속 최신 버전이라는 의미는 아닙니다.

PHP 계열	첫 수정 버전	적용 판단
8.2	8.2.35	이 수정판 또는 이후 보안 수정판 확인
8.3	8.3.36	이 수정판 또는 이후 보안 수정판 확인
8.4	8.4.27	이 수정판 또는 이후 보안 수정판 확인
8.5	8.5.12	이 수정판 또는 이후 보안 수정판 확인

배포판 업체가 수정을 이전 버전에 이식한 패키지는 표시 숫자가 다를 수 있습니다. 버전 문자열만 비교하지 말고 공급자의 보안 공지와 설치된 패키지 빌드를 대조하세요. PHP 프로젝트는 지원이 끝난 7.4·8.0·8.1을 위한 최소 소스 백포트도 안내하지만, 일반 지원이 재개됐다는 뜻은 아닙니다. 해당 공급자의 수정 제공 여부를 확인하고 지원 계열로 이동할 계획을 세워야 합니다. PHP 공식 수정·백포트 안내

그림 2. PHP 공식 보안 공지의 실제 화면입니다. 2026년 10월 23일 확인 시점의 안내이며, 위 표의 버전은 이 취약점에 대한 첫 수정판입니다. 공식 공지 · 원본 확대

설치 완료 다음에는 실제 웹 실행 환경을 확인합니다

터미널에서 php -v를 실행하면 CLI용 PHP 버전을 볼 수 있고, php --ini로 그 실행 파일이 읽는 설정 경로를 확인할 수 있습니다. 하지만 웹 서버가 다른 PHP 실행 파일이나 다른 컨테이너를 사용하면 두 결과가 달라집니다.

업데이트 후에는 다음 순서로 확인 기록을 남기세요.

공급자 수정 확인: 사용한 패키지·이미지와 보안 공지의 수정 내역을 대조합니다.
실행 중인 서비스 확인: 실제 웹 요청을 처리하는 FPM·Apache 등의 버전과 프로세스 교체 여부를 관리 환경에서 확인합니다.
모든 인스턴스 확인: 여러 서버와 컨테이너가 있다면 오래된 인스턴스가 남았는지 확인합니다.
업무 기능 확인: 로그인·업로드·검색·결제 등 서비스에 필요한 정상 기능과 오류 로그를 확인합니다.

공개된 phpinfo() 페이지를 새로 만들어 서버 정보를 노출하기보다는 호스팅 관리 화면이나 접근이 제한된 관리 수단으로 확인하세요. 담당자가 “업데이트 완료”라고 답했다면 적용한 빌드, 완료 시각, 실제 실행 환경을 확인한 방법까지 받는 것이 좋습니다. 이는 공급자의 패치를 운영 현장에 적용했는지 확인하기 위한 점검 순서입니다.

WAF는 패치 전후의 추가 방어입니다

WAF는 웹 요청을 검사하는 웹 애플리케이션 방화벽입니다. Cloudflare는 해당 취약점에 대한 기본 보호를 제공하고, 유료 환경에서는 규칙의 차단 동작을 확인하도록 안내합니다. 아래는 공식 글에 실린 보호 설정 예시입니다. Cloudflare 보호 안내

그림 3. Cloudflare 공식 보호 설정 화면 예시입니다. 이 사이트나 독자의 계정에 보호가 적용됐다는 증거는 아닙니다. 작은 글자는 원본을 열어 확대할 수 있습니다. 공식 원문 · 원본 확대

화면에 보호 표시가 있어도 PHP 업데이트를 생략해서는 안 됩니다. PHP 공식 공지는 공격 경로가 여러 가지이므로 특정 설정 변경만으로 전체 문제를 해결할 수 없다고 설명합니다. 메모리 제한이나 세션 설정 하나를 바꾸는 방법을 모든 서버에 통하는 해결책으로 적용하지 마세요. 수정판 적용을 우선하고, WAF와 접근 제한은 그 사이와 이후에 더하는 방어로 운영합니다. PHP 대응 지침

패치가 끝나도 과거 침해 흔적은 따로 확인합니다

패치는 앞으로 같은 취약점이 악용되는 것을 막기 위한 조치입니다. 이미 바뀐 파일이나 노출된 접속 정보까지 원래 상태로 되돌려 주지는 않습니다.

JPCERT는 비정상적으로 길거나 손상된 세션 쿠키, 메모리 부족 오류와 연관된 요청, 작업 프로세스의 비정상 종료 등 조사에 참고할 지표를 제시합니다. 아래 항목은 그 안내와 개인정보위 권고를 운영 점검표로 정리한 것입니다. JPCERT 주의 환기, 개인정보위 점검 권고

점검 영역	함께 확인할 자료
웹·PHP 로그	이상 요청 시각, 세션 관련 이상, 메모리 부족·500 오류의 연관성
실행 기록	웹 작업 프로세스의 예기치 않은 종료·재시작과 의심스러운 하위 프로세스
파일·통신	새 실행 파일이나 웹셸 의심 파일, 변경된 설정, 예상 밖 외부 연결
개인정보 DB	서비스 계정의 과도한 권한, 대량조회·반출과 접속 기록
관리 도구	외부에 직접 노출된 phpMyAdmin, 불필요한 서비스와 설정 파일

500 오류 하나나 메모리 부족 하나만으로 침해를 확정할 수는 없습니다. 반대로 특정 문자열이 검색되지 않았다는 사실만으로 정상이라고 판단해서도 안 됩니다. 요청·오류·프로세스·파일·DB 기록의 시간 관계를 함께 살펴야 합니다.

공격 관측이 10월 17일로 거슬러 올라간다는 AWS 자료를 참고해 조사 기간을 정하고, 보관 중인 이전 기록도 함께 확인하세요. 의심 정황이 있으면 로그와 시스템 증거를 보존하면서 접근을 제한하고 보안 담당자·호스팅 공급자와 대응해야 합니다. 조사 전에 의심 파일과 로그부터 지우면 원인과 영향 범위를 확인하기 어려워집니다. AWS 조사 안내

AI 시대에 달라지는 것은 발견 이후의 대응 시간입니다

PHP Foundation의 설명에는 2024년의 메모리 부족 관련 단서와 2026년 여러 연구자의 보고가 함께 등장합니다. 후속 분석이 원격 코드 실행의 심각성을 구체화했다는 맥락입니다. 이를 “AI가 모든 문제를 처음 발견했다”거나 특정 모델의 보안 성능 순위로 바꿔 소개할 근거는 부족합니다. PHP Foundation의 경위 설명

운영자가 가져갈 교훈은 공개된 단서의 분석과 공격 검증이 빨라질수록 자산 확인·수정판 배포·실행 확인의 지연도 위험해진다는 점입니다. AI가 로그를 분류하거나 점검표 초안을 만들 수는 있어도, 실제 실행 버전과 접근 권한을 확인하는 책임까지 대신하지는 않습니다.

AI 도구의 보안 주장을 근거별로 읽는 방법은 REA 후속 글의 실험과 방어 검토에서, 에이전트가 “완료”라고 말한 작업을 확인하는 기준은 AI 결과물 품질 점검에서 이어 볼 수 있습니다.

운영자가 남겨야 할 결론은 네 가지입니다

어디에서 PHP를 쓰는지, 어떤 수정 빌드를 적용했는지, 실제 웹 요청도 그 빌드가 처리하는지, 침해 흔적은 어디까지 확인했는지를 기록하세요. 이 네 가지가 있어야 담당자가 바뀌어도 조치 상황을 이어서 판단할 수 있습니다.

관리형 호스팅 사용자라면 직접 서버를 수정하기보다 공급자에게 이 네 항목을 요청하면 됩니다. 즉시 수정이 어려운 서비스는 외부 노출을 줄이는 방안을 함께 검토하세요. PHP2Shell 방어의 완료 기준은 공지를 읽었다는 사실보다, 수정된 실행 환경과 점검 근거를 갖췄는지에 있습니다.

자주 묻는 질문

Q1. WordPress와 플러그인을 모두 업데이트했는데 충분한가요?

PHP 런타임은 별도입니다. 호스팅이나 서버에서 실제 사용 중인 PHP에 수정이 적용됐는지 확인해야 합니다. CMS 업데이트만으로 이번 PHP 취약점이 해결됐다고 판단할 수 없습니다.

Q2. 정적 사이트나 Node.js 서비스도 PHP를 업데이트해야 하나요?

해당 서비스에 PHP가 없다면 그 실행 환경에는 이 PHP 취약점이 적용되지 않습니다. 다만 별도 관리자 도구, 과거 사이트, 호스팅 계정에 PHP가 남아 있는지 함께 확인하세요.

Q3. WAF에서 차단 기록이 보이면 이미 해킹된 것인가요?

차단 기록은 요청이 관측·처리됐다는 자료입니다. 코드 실행 성공이나 개인정보 유출을 뜻하지 않습니다. 반대로 WAF 기록만으로 서버의 전체 상태를 증명할 수도 없습니다.

Q4. 터미널의 PHP 버전이 수정판이면 점검이 끝나나요?

웹 서버가 다른 실행 파일이나 컨테이너를 사용할 수 있습니다. 실제 요청 처리 환경과 모든 인스턴스의 교체 여부를 확인하고, 과거 침해 흔적 점검도 별도로 기록해야 합니다.

공식 자료와 확인 기준일

확인 기준일: 2026-10-23 · 보안 공지와 공급자별 수정 상태는 이후 갱신될 수 있습니다. 적용 직전 공식 공지를 다시 확인하세요. 이 글의 버전 표는 최초 수정판 기준이며, 직접 실행한 취약점 재현 결과나 피해 사이트 집계가 아닙니다.