로그인 없이 외부에서 서버에 명령을 실행할 수 있는 PHP2Shell, 누리집 운영자 대응 순서
2026년 10월 21일 PHP2Shell 보안 업데이트가 배포되어, PHP로 누리집을 운영하는 기업·기관이 확인할 영향 버전과 해결 버전, 재시작과 임시 조치, 로그 점검과 침해사고 신고를 조치 순서대로 정리했습니다.
결론부터 말씀드리면, 운영 중인 PHP를 해결 버전으로 업데이트한 뒤 PHP를 실행하는 모든 웹 서비스를 재시작해야 보안 조치가 적용돼요. PHP 8.1 이하는 공식 업데이트가 제공되지 않으므로 지원 버전으로 전환해야 합니다. 당장 업데이트가 어렵다면 임시 조치를 적용하되, 임시 조치는 공격을 완전히 차단하지 못한다는 사실도 함께 알아 두셔야 해요.
PHP2Shell 취약점 2건과 영향 버전
이번 취약점은 PHP에서 발견된 원격 코드 실행 취약점 2건(CVE-2026-109618, CVE-2026-109619)이며, 두 건을 함께 ‘PHP2Shell’이라고 부릅니다. 공격자가 아이디·비밀번호 없이 인터넷을 통해 특수하게 조작된 요청을 보내는 것만으로 서버에 원하는 명령을 실행할 수 있고, CVSS 점수는 9.2입니다. 공격에 성공하면 원격조종 파일(웹셸) 설치, 고객정보 유출, 홈페이지 변조, 내부망 침투로 이어질 수 있어요.
개별 홈페이지의 프로그램이 아니라 PHP 자체의 취약점이므로, 홈페이지 프로그램을 안전하게 만들었더라도 영향을 받을 수 있죠. 워드프레스·그누보드처럼 국내에서 많이 사용하는 누리집 제작 도구도 PHP를 기반으로 동작합니다. 취약점 정보는 보안 업데이트 배포 전인 10월 20일에 유출되었고, 해외 보안업체를 중심으로 공격 시도가 보고되고 있습니다. 과학기술정보통신부는 10월 22일 12시부로 민간 분야 사이버 위기 경보를 ‘관심’에서 ‘주의’로 상향했어요.
주의할 것은 PHP 8.1 이하입니다. 8.1 이하는 영향을 받지 않는 버전이 아니라, PHP 프로젝트의 공식 업데이트가 더 이상 제공되지 않는 버전이에요.
실제 동작 중인 PHP 버전 확인
인터넷에 공개된 모든 홈페이지와 시스템의 PHP 사용 여부와 버전은 자산 관리 목록에만 의존하지 말고 실제 동작 중인 서버를 기준으로 확인해야 합니다. 누리집 주소가 ‘.php’로 끝나지 않아도 PHP를 사용하고 있을 수 있어요. 다음 대상도 빠뜨리지 않고 확인해야 합니다.
- 외주 제작 사이트, 오래전에 만들어 두고 관리하지 않는 사이트
- 이벤트·테스트 서버와 관리자 페이지
- PHP가 내장된 장비·솔루션(네트워크 장비 관리 화면, PHP가 포함된 윈도우용 설치 패키지 등)
- 외부에서 받아 사용하는 컨테이너 이미지(도커 등)
- 대표 누리집이 PHP를 사용하지 않더라도 웹 서버에 설치된 외부 애플리케이션·구성요소
관리 페이지에서 PHP 버전을 확인했다면, 다음은 그 서버의 PHP를 누가 관리하는지 확인할 차례입니다. 호스팅 업체나 장비·솔루션 제조사가 PHP를 관리하는 경우에는 해당 업체에 아래 조치의 적용 여부를 확인하고 요청해야 해요.
PHP 업데이트 방법, 해결 버전 적용 후 웹 서비스 재시작
업데이트는 인터넷에 공개된 서버부터 우선 적용합니다. 리눅스 배포판과 LTS 업체는 패치를 미리 받았으므로, 사용 중인 배포판·제조사의 업데이트 패키지를 확인하면 돼요. 다만 패치 적용 시 기존 시스템과의 호환성 및 안정성 문제로 서비스 장애가 발생할 수 있으므로, 사전 영향도 검토와 테스트 후 적용해야 합니다.
업데이트 후 PHP를 실행하는 모든 웹 서비스(PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed 등)를 반드시 재시작해야 합니다. 재시작하지 않으면 메모리에 남은 이전 버전이 계속 동작해 여전히 취약해요. 컨테이너 환경은 신규 이미지를 재배포합니다.
재시작 뒤에는 웹 서비스가 실제로 사용하는 PHP의 버전이 바뀌었는지 확인합니다. 명령어(php -v)로 확인되는 버전과 웹 서비스가 사용하는 버전이 다를 수 있으므로, 한 서버에 PHP가 여러 개 설치되어 있다면 각각 확인해야 하죠. 리눅스 배포판·제조사 제공 패키지는 보안 패치를 적용해도 버전 번호가 바뀌지 않을 수 있어요. 이때는 패키지 변경 이력에서 CVE 반영 여부를 확인합니다.
PHP 8.1 이하는 지원 버전으로 전환
PHP 8.1 이하는 공식 업데이트가 제공되지 않으므로 지원 버전으로 전환해야 합니다. 8.2도 2026년 12월 31일 보안 지원이 종료될 예정이므로 8.3 이상 버전으로 전환하시기를 권장합니다.
전환에 시간이 필요하다면 리눅스 배포판·장기지원(LTS) 업체가 제공하는 보안 패치 또는 PHP 보안팀이 공개한 7.4·8.0·8.1용 소스 패치를 임시로 적용하고 전환 계획을 수립합니다. 적용할 패치가 없다면 다음 절의 임시 조치를 적용해야 해요.
당장 업데이트가 어려울 때의 임시 조치
임시 조치는 확인된 일부 공격 방식에만 효과가 있고 공격을 완전히 차단하지 못하므로, 업데이트를 적용해야 합니다. 먼저 웹 방화벽·웹 서버·프록시 등 PHP 앞단에서 요청 크기를 제한하고(요청 크기 정보가 없는 요청 포함), 파일 업로드가 필요 없는 서비스는 파일 업로드(multipart) 요청을 차단합니다. 웹 방화벽을 이용 중이라면 최신 차단 규칙이 적용되었는지도 확인해야 하죠.
PHP 공식 임시 설정은 다음과 같습니다.
설정은 모든 PHP 프로세스를 재시작해야 반영됩니다. 임시 조치도 적용하기 어렵다면 업데이트 전까지 외부 접속 차단 또는 서비스 일시 중단을 검토해야 해요.
CVE-2026-115560은 10월 21일 업데이트로 해결되지 않음
10월 23일에는 PHP 세션 처리 과정에서 발생하는 원격 코드 실행 취약점(CVE-2026-115560)이 추가로 공개되었어요. CVE-2026-115560은 보안 업데이트가 아직 배포되지 않았고 차기 정기 업데이트에서 해결될 예정이며, 10월 21일 배포된 보안 업데이트로는 해결되지 않습니다. 다만 다음 조건을 모두 충족하는 경우에만 영향을 받습니다.
PHP2Shell 임시 조치로 session.upload_progress.enabled=0 설정을 이미 적용했다면 추가 조치는 필요하지 않습니다. 실행 중에 serialize handler를 바꾸지 않는 애플리케이션은 업로드 진행률 기능을 켜 둔 채로 사용해도 돼요.
업데이트 후 로그 점검과 인증정보 교체
취약점 정보가 이미 유출된 만큼, 업데이트를 마친 서버라도 침해 흔적을 점검해야 합니다. 최소 10월 20일(취약점 정보 유출일) 이후의 기록 전체를 점검하고, 가능하면 10월 17일부터 해결 버전을 적용하기 전까지의 기록을 확인해요. 침해 흔적이 발견되면 점검 기간을 더 넓혀야 합니다. 점검할 흔적은 다음과 같습니다.
- PHP 페이지로 들어온 비정상적으로 큰 요청과 그 뒤에 반복된 서버 오류(HTTP 500)
- 원인을 알 수 없는 PHP 프로그램 재시작·비정상 종료(segfault)나 메모리 부족 오류
- 웹 서버가 명령 실행 프로그램(sh, bash 등)이나 파일 다운로드 도구를 실행한 흔적
- 웹 폴더, 업로드 폴더, 임시 폴더에 새로 생성되거나 변경된 PHP 파일(웹셸)
- 홈페이지나 결제 페이지에 몰래 추가된 외부 스크립트
- 웹 서버에서 알 수 없는 외부 주소로 새로 연결한 흔적
기록상 이상이 없더라도 안전이 보장되지 않으므로, 업데이트와 인증정보 교체를 함께 진행해야 합니다.
이번 취약점은 서버 메모리에 담긴 비밀번호, 접속 인증값(토큰), 외부 서비스 연동 키(API 키) 등을 유출시킬 수 있어요. 업데이트 전까지 인터넷에 노출되었던 서버는 DB 비밀번호, 외부 서비스 연동 키, 관리자 계정 비밀번호를 교체하시기를 권장하며, 침해 흔적이 발견된 서버는 반드시 교체해야 합니다.
침해사고 발생 시 대응 순서와 신고
침해 흔적이 발견되면 아래 순서대로 대응합니다. 순서에서 중요한 것은 증거 확보를 업데이트·재시작보다 먼저 하는 것이에요. 서버를 재시작하면 메모리에 남은 공격 흔적이 사라지기 때문입니다.
인터넷에 ‘공격 시험 코드(PoC)’라며 유포되는 파일 중에는 악성코드가 숨겨진 가짜가 많으므로, 출처가 불분명한 코드는 내려받거나 실행하지 않습니다. 취약 여부는 PoC 실행 대신 버전 확인과 기록 점검으로 판단해야 해요. 분석이 꼭 필요한 경우에는 업무망과 분리된 환경에서만 수행합니다.
운영 형태별로 자주 묻는 질문
Q1. 호스팅 업체를 이용해 누리집을 운영하면 무엇을 해야 하나요?
A1. 이용 중인 호스팅 업체에 보안 업데이트 적용 여부를 확인하면 됩니다. CMS나 플러그인을 업데이트해도 PHP 취약점은 해결되지 않으므로, PHP 자체의 업데이트와 재시작이 적용되었는지를 확인해야 해요.
Q2. PHP를 어떤 방식으로 실행할 때 위험이 가장 높나요?
A2. 웹 요청을 처리하는 모든 PHP 설치 환경이 위험하고, 그중 위험이 가장 높은 것은 Apache mod_php입니다. mod_php에서는 로그인하지 않은 요청만으로 애플리케이션 코드가 실행되기도 전에 공격이 이루어지는 것이 확인되었기 때문이에요.
Q3. 누리집을 운영하지 않는 일반 이용자도 조치해야 하나요?
A3. 일반 이용자가 직접 조치할 사항은 없어요. 평소와 같이 백신 설치, 최신 보안 업데이트 등 기본적인 보안 수칙을 지키는 것이 좋습니다.
PHP를 사용하는 기업·기관은 운영 중인 모든 누리집과 시스템의 PHP 버전을 확인하고, 인터넷에 공개된 서버부터 업데이트와 재시작을 마쳐야 합니다. 피해가 의심되면 즉시 한국인터넷진흥원(KISA)에 신고해야 하죠.
출처·참고자료
- 한국인터넷진흥원 보호나라, 「PHP 제품 보안 업데이트 권고」 (2026.10.21.)
- 한국인터넷진흥원 보호나라, 「PHP 보안취약점(PHP2Shell) 관련 기업 보안 대응 수칙」 (2026.10.22.)
- 한국인터넷진흥원 보호나라, 「PHP 신규 취약점(CVE-2026-115560) 임시 조치 권고」 (2026.10.24.)
- 과학기술정보통신부, 「과기정통부, 웹사이트 개발 언어 ‘PHP’ 보안 취약점 관련 긴급 보안 최신화(업데이트) 및 기술적 조치 당부」
- The PHP Group, ‘Security advisory: Critical remote code execution vulnerabilities, update now’ (2026.10.21.)
- The PHP Group, ‘Informational advisory: Session upload progress’ (2026.10.23.)
- The PHP Group, ‘Supported Versions’
- php-src Security Advisory, ‘RCE via OOM corruption’ (GHSA-w8hw-w9fx-j79w)
- php-src Security Advisory, ‘RCE via stale global state’ (GHSA-6wmf-4rv5-p3rp)
- Cyber Security Agency of Singapore, ‘AL-2026-151 Critical Vulnerabilities in PHP (PHP2Shell)’
- Victor Grigas, ‘Wikimedia Foundation Servers-8055 35’, Wikimedia Commons (CC BY-SA 3.0)
- David Monniaux, ‘Paris servers DSC00190’, Wikimedia Commons (CC BY-SA 3.0)
- Abigor, ‘Servers in a Rack’, Wikimedia Commons (CC BY-SA 3.0)
위 자료를 수집·분석하여 본문 작성에 참고하였으며 2026년 10월 24일 확인 기준입니다. CVE-2026-115560은 보안 업데이트가 아직 배포되지 않았으므로, 차기 정기 업데이트가 배포되는 시점에 PHP 공식 누리집과 보호나라 공지를 다시 확인하시기 바랍니다.
본 글은 개별 서버의 보안 진단이나 침해사고 분석을 대신하지 않습니다.
답글 남기기