PHP2Shell 대응, IP 화이트리스트와 백포트의 효과와 한계

2026년 10월 31일

PHP2Shell 공지를 읽다 보면 원격 코드 실행, 백포트, PHP-FPM 같은 낯선 말이 나온다. 서버를 맡긴 입장에서는 “업데이트했다”거나 “접속 IP를 제한했다”는 설명이 충분한 대응인지 판단하기 어렵다. 나도 이 문제를 어느 한 조치가 소용있느냐 없느냐로 보기보다는 무엇을 막아 주고 어떤 확인이 남는지 나눠서 정리해 보고 싶었다.

먼저 IP 화이트리스트는 무작위 스캐너와 공격 봇의 접근을 막는 데 효과가 크다. 허용되지 않은 요청을 PHP 실행 전에 차단한다면 인터넷 전체에 서비스를 공개한 상태와는 노출 범위가 크게 다르다. 검증된 백포트 역시 오래된 버전의 알려진 결함을 고치는 정식 유지보수 방법이다. 두 조치의 효과를 인정하되 적용 범위와 실제 실행 상태까지 확인하는 것이 이 글의 출발점이다.

PHP2Shell은 왜 로그인만으로 막기 어려울까

PHP는 서버에서 프로그램을 실행해 웹페이지를 만드는 데 쓰인다. 워드프레스가 글과 댓글을 관리하는 애플리케이션이라면 PHP는 그 코드를 실행하는 환경이고 데이터베이스는 글과 설정을 보관한다. 워드프레스나 플러그인을 업데이트했다고 PHP까지 자동으로 바뀌지는 않는다.

PHP 개발팀은 2026년 10월 21일 CVE-2026-109618과 CVE-2026-109619를 수정한 업데이트를 발표했다. CVE는 취약점을 구분하는 번호이며 PHP2Shell은 이 두 결함을 함께 부르는 이름이다. 공식 공지는 인증 없이 원격 코드 실행이 가능할 수 있다고 설명했다. 특히 mod_php에서는 애플리케이션 코드가 실행되기 전 공격 사례를 명시했다. ^[1]

원격 코드 실행은 외부 요청 때문에 서버가 공격자가 의도한 코드를 실행하는 상황이다. PHP는 로그인 검사에 앞서 입력값과 파일 전송 형식을 해석하는 등의 준비 작업을 한다. 그 과정에서 문제가 생긴다면 복잡한 비밀번호나 로그인 실패 횟수 제한만으로는 막기 어렵다.

두 결함은 메모리를 다루는 과정과 관련돼 있다. 메모리 할당 실패나 치명적인 오류로 처리가 끊긴 뒤 내부 상태가 제대로 정리되지 않아 준비되지 않은 데이터나 이미 해제한 메모리를 사용하면서 위험한 동작이 발생할 수 있다. ^[2] 다만 모든 PHP 서버가 같은 요청 한 번에 장악된다는 뜻은 아니다. 실행 구성과 메모리 배치 등 조건이 영향을 주며 CrowdStrike도 공격을 안정적으로 구현하고 널리 적용하는 데 제약이 있다고 분석했다. 이런 어려움만을 방어 수단으로 기대하기는 힘들다. ^[3]

공격에 성공해도 곧바로 최고 관리자 권한을 얻는다고 단정할 수는 없다. 보통은 공격받은 프로세스의 권한부터 영향을 받는다. 그 권한으로 데이터베이스 접속 정보나 설정을 읽고 파일을 수정할 수 있다면 자료 노출과 변조로 이어질 수 있다.

백포트는 무엇을 고치고, 무엇을 확인해야 할까

새 버전에는 보안 수정과 기능 변화가 함께 들어가기도 한다. 기존 서비스의 호환성을 유지하기 위해 필요한 보안 수정만 이전 버전에 옮겨 적용하는 것이 백포트다. 검증된 수정이 들어갔다면 해당 취약점을 고칠 수 있으므로 오래된 기본 버전 숫자만으로 취약하다고 판단해서는 안 된다. ^[4]

확인할 것은 공급자와 패키지의 실제 상태다. 누가 어느 패키지를 언제까지 지원하는지, 해당 CVE 수정이 포함된 세부 릴리스가 설치됐는지 살펴야 한다. 운영체제가 제공하는 PHP, 별도 저장소의 PHP, 직접 빌드한 실행 파일은 업데이트 경로가 다를 수 있다. 장기 지원 대상이라는 설명만으로 내 서버에 수정본이 적용됐다고 볼 수는 없다.

설치한 파일과 웹 요청을 처리하는 프로그램도 일치해야 한다. 터미널에서는 새 PHP가 실행돼도 사이트는 별도의 PHP-FPM 환경을 사용할 수 있고 오래 실행된 프로세스가 교체 전 코드를 유지할 수도 있다. 공급자가 안내하는 재시작이나 워커 교체까지 마친 뒤 실제 웹 실행 환경을 확인해야 한다.

지원 기간은 별도로 확인할 항목이다. PHP 8.2의 공식 보안 지원 종료일은 2026년 12월 31일로, 이 글을 쓰는 10월 31일에는 두 달 남짓 남았다. 배포판이나 업체의 장기 지원 일정은 다를 수 있다. ^[5] 지원 종료일에 프로그램이 멈추지는 않지만 다음 결함이 발견됐을 때 수정본을 받을 경로가 없을 수 있다. 당장의 문제는 검증된 백포트로 고치고 호환성을 확인하면서 지원 기간이 남은 환경으로 옮기는 계획을 세울 수 있다.

화이트리스트가 무작위 공격을 막는 방식

IP 제한은 요청이 어디에서 왔는지를 접근 조건으로 삼는다. 알려진 악성 주소만 막는 블랙리스트와 달리, 화이트리스트는 등록한 IP만 허용하고 나머지는 거절한다. 처음 보는 공격자의 주소라도 목록에 없으면 차단되므로 인터넷의 여러 주소를 훑는 스캐너와 자동 공격 봇을 막는 데 실질적인 효과가 있다.

이 효과를 얻으려면 방화벽이나 웹서버가 PHP에 요청을 넘기기 전에 차단해야 한다. PHP 코드가 실행된 뒤 IP를 검사하면 이미 취약한 요청 처리 과정에 들어갔을 수 있다. 관리자 화면에 차단 문구가 나온다는 사실만으로 앞단에서 막았다고 판단할 수는 없다.

보호 범위도 확인해야 한다. IPv4뿐 아니라 IPv6, 다른 포트와 별도 도메인, 원본 서버 직접 접속이 같은 PHP로 이어지는지 살펴야 한다. 허용된 주소에서는 정상 이용이 되고 허용되지 않은 주소에서는 거절되는지 함께 확인한다. 서버의 IP나 열린 포트가 발견되거나 접속 시도가 기록되는 것과 취약한 PHP까지 접근할 수 있는 것은 다르다.

공개 블로그나 쇼핑몰은 모든 방문자의 IP를 미리 등록하기 어렵다. 관리자 화면에만 화이트리스트를 적용했다면 그 보호 효과는 인정하되 공개 PHP 페이지는 별도로 관리해야 한다. 반면 내부 전용 서비스의 모든 진입 경로를 제한했다면 외부 공격에 노출되는 범위를 크게 줄일 수 있다. 화이트리스트는 패치를 기다리는 동안뿐 아니라 패치 후에도 불필요한 접근을 줄이는 수단으로 유지할 가치가 있다.

허용 IP를 알아내서 위조할 수는 없을까

패킷에 적힌 출발지 IP를 위조하는 것은 가능하다. 하지만 허용 IP를 아는 것만으로 그 주소의 사용자처럼 웹 연결을 맺기는 어렵다. 일반적인 TCP 기반 HTTP·HTTPS 연결은 양쪽이 응답을 주고받는 절차로 시작한다. 공격자가 출발지를 허용 IP로 바꾸면 서버의 응답은 실제 그 IP 쪽으로 돌아간다. 응답을 볼 수 없는 외부 공격자는 주소만 바꿔 정상 연결을 쉽게 완성할 수 없다. 통신 경로를 장악한 경우는 조건이 달라지지만 허용 IP를 알아냈다는 사실만으로 화이트리스트가 무력화되는 것은 아니다. ^[6]

웹 요청의 헤더를 속이는 문제는 따로 봐야 한다. 프록시는 방문자의 요청을 먼저 받아 원본 서버에 전달하는 중간 서버다. 원본 서버에는 프록시의 IP가 보일 수 있어 X-Forwarded-For 같은 헤더로 방문자 주소를 전달한다. 외부 요청에도 이 값을 임의로 넣을 수 있으므로 누구나 보낸 헤더를 그대로 믿으면 접근 제한을 우회할 여지가 생긴다. 신뢰하는 프록시가 전달한 정보만 사용하도록 구성해야 한다. 이는 TCP 연결의 출발지 주소 자체를 위조하는 것과 다르다. ^[7]

원본 서버가 CDN이나 프록시의 IP만 허용하는 구성도 의미를 구분해야 한다. 지정한 중간 서버를 거치게 하는 효과는 있지만 그 서버가 공개 요청을 전달한다면 최종 방문자는 여전히 불특정 다수일 수 있다. 최종 이용자를 소수 IP로 제한한 구성과 같지는 않다.

허용된 환경과 서비스 거부 공격은 별도 관리가 필요하다

회사 공인 IP 하나를 등록했어도 여러 직원과 기기가 그 주소를 함께 쓸 수 있다. VPN 출구 IP도 마찬가지다. 허용된 단말이나 VPN 계정이 침해되면 공격자는 IP를 위조하지 않고도 허용된 경로에서 요청을 보낼 수 있다. 이는 특정 PHP2Shell 침해 사례가 아니라 IP 기반 통제의 일반적인 한계다. NIST도 네트워크 위치만으로 사용자와 기기를 신뢰하지 않는 원칙을 설명한다. 허용 범위를 좁히고 계정 인증과 단말 관리를 함께 유지해야 한다. ^[8]

서비스 거부 공격은 PHP 취약점 공격과 목적과 방식이 다르다. SYN flood는 연결을 시작하는 패킷을 대량으로 보내 연결 처리 자원을 소모시키며 출발지 IP를 위조하기도 한다. 정상적인 웹 연결을 완성하지 않아도 부담을 줄 수 있고 웹서버에서 요청을 거절해도 그 앞의 회선과 장비 자원은 소모될 수 있다. 화이트리스트가 모든 서비스 거부 공격까지 막는 것은 아니므로 회선·네트워크 단계의 대응도 필요하다. ^[9]

WAF는 요청의 내용이나 패턴을 보고 의심스러운 요청을 거르는 웹 방화벽이다. 알려진 공격을 차단하는 데 도움이 되지만 탐지에서 빠지는 요청이나 정상 이용을 잘못 막는 경우도 확인해야 한다. OWASP도 가상 패치를 사용할 때 실제 수정 계획을 함께 유지하도록 안내한다. 접근 제한, 요청 검사, PHP 패치는 서로 다른 위험을 줄이는 조치다. ^[10]

패치 뒤에도 확인할 것

PHP 개발팀은 10월 23일 CVE-2026-115560과 관련된 추가 RCE 경로를 안내했다. 특정 세션 설정과 애플리케이션의 실행 중 설정 변경이 겹치는 드문 조건이며 영향을 받는 구성에는 다음 정기 수정 릴리스까지 세션 업로드 진행 기능을 끄도록 권고했다. 모든 설치에 같은 조건이 적용되는 것은 아니므로 최초 패치 뒤에도 후속 공지를 확인해야 한다. ^[11]

세션 업로드 진행 기능은 파일을 올리는 동안 진행 상태를 세션에 기록하는 기능이다. 이 기능을 끄는 것과 사이트의 모든 파일 업로드를 막는 것은 다르다. 해당 설정 하나로 PHP2Shell의 모든 경로가 해결된다고 해석해서도 안 된다. 내 환경에 적용되는 조건과 조치 범위를 확인할 필요가 있다.

이미 침해됐는지도 별개의 문제다. 패치는 공격자가 앞서 남긴 파일이나 변경한 계정, 유출한 비밀정보를 되돌려 주지 않는다. 의심스러운 파일 수정·프로세스·접속 흔적이 있다면 따로 조사해야 한다. 그렇다고 취약한 버전을 썼다는 이유만으로 침해를 확정할 수도 없다.

운영자에게 확인할 질문

직접 관리한다면 서비스별로 실제 사용하는 PHP와 수정본 공급자를 먼저 확인하고 해당 패키지의 CVE 대응 내역과 실행 상태를 대조하면 된다. 호스팅이나 운영을 맡겼다면 “이번 수정본이 실제 웹 서비스에 적용됐는지”, “IP 제한은 어느 경로에서 PHP 실행 전에 작동하는지”, “공개 기능과 지원 종료에는 어떻게 대응하는지”를 물어볼 수 있다. 민감한 서버 정보를 공개 페이지에 노출하기보다 내부 관리 수단으로 확인하고 결과를 남기는 편이 좋다.

나는 화이트리스트를 적용한 서비스를 무방비 상태와 같다고 보지는 않는다. 제대로 구성했다면 무작위 외부 공격을 차단하는 효과가 분명하다. 패치가 필요한 이유는 그 효과가 작아서가 아니라 허용된 경로로 들어온 요청에도 알려진 PHP 결함을 악용할 여지를 남기지 않기 위해서다. 검증된 백포트로 결함을 고치고 접근 제한을 유지하면서 지원 기간에 맞춰 다음 환경을 준비하는 것이 현실적인 대응이라고 생각한다.

이 글은 2026년 10월 31일 공개된 자료를 기준으로 정리했다. 실제 조치 전에는 공급자의 최신 공지를 확인해야 한다.