PHP2Shell 취약점 정리: 영향 범위와 PHP 패치 확인 순서

내용 이해를 돕는 참고 사진 · Photo by Brett Sayles on Pexels · 이용허락

워드프레스와 플러그인을 최신으로 유지했는데도, 그 아래에서 실행되는 PHP 때문에 긴급 업데이트가 필요할 수 있음. 2026년 10월 21일 공개된 PHP2Shell이 그런 사례임. PHP 자체의 두 취약점을 다루는 이름으로, 인증하지 않은 외부 요청이 코드 실행으로 이어질 수 있어 웹 서버 운영자는 우선순위를 높여 확인할 필요가 있음. PHP 공식 보안 공지

확인 기준: 2026년 10월 22일, 한국 시간. 이후 변경 사항은 공식 공지를 다시 확인할 것.

핵심 요약

• PHP2Shell은 CVE-2026-109618과 CVE-2026-109619를 가리킴. 애플리케이션 코드만의 문제가 아님.
• 각 지원 브랜치의 최초 수정 버전은 8.2.35, 8.3.36, 8.4.27, 8.5.12임.
• PHP 런타임 패치와 관련 워커 재시작이 핵심임. 임시 설정이나 WAF만으로 조치가 끝났다고 판단하면 안 됨.

두 취약점은 어떤 원리인가

CVE-2026-109618은 메모리 부족, 즉 OOM 처리 과정의 메모리 손상 문제임. 요청 내부 데이터가 완전히 초기화되기 전에 처리가 중단되고, 정리 과정에서 불완전한 상태를 정상 데이터처럼 사용할 수 있음. 단순히 메모리가 부족해 서버가 느려지는 상황과 달리, 메모리 안전성 문제로 연결된다는 점이 중요함. PHP 프로젝트의 OOM 취약점 권고문

CVE-2026-109619는 요청 사이에 오래된 전역 상태가 남는 문제임. 메모리가 해제된 뒤에도 관련 상태가 유지되고, 같은 워커의 뒤이은 요청이 이를 참조할 수 있음. 해제된 메모리를 다시 사용하는 use-after-free와 연결되며, 연구진은 코드 실행뿐 아니라 프로세스 메모리 노출도 설명하고 있음. PHP 프로젝트의 전역 상태 취약점 권고문 · 공동 연구진 안내

워드프레스 사용자만 확인하면 될까

워드프레스·드루팔·줌라는 연구진이 영향을 입증한 대표 사례임. 취약한 코드는 PHP 내부에 있으므로 특정 CMS를 쓰지 않는 자체 서비스도 확인 대상이 됨. 공격 경로마다 필요한 조건은 달라, PHP 사이트라는 사실만으로 이미 침해됐다고 단정할 수도 없음. 메모리 노출은 악성 파일을 남기거나 명령을 실행하지 않고 발생할 수 있다는 점도 조사할 때 고려해야 함. 영향과 공격 경로에 대한 연구진 설명

내용 이해를 돕는 참고 사진 · Photo by Al Nahian on Pexels · 이용허락

수정 버전과 배포판 패키지를 함께 확인하기

PHP 브랜치	최초 수정 릴리스
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

위 표는 PHP 프로젝트의 릴리스 기준임. 배포판이 보안 패치를 백포트했다면 앞쪽 버전 숫자가 작아도 수정된 패키지일 수 있음. 예를 들어 Ubuntu 24.04의 공지에는 8.3.6-0ubuntu0.24.04.13이 수정 패키지로 안내되어 있음. 따라서 8.3.6만 보고 미패치라고 결론 내리지 말고, 배포판 버전과 패키지 전체 리비전을 함께 비교해야 함. Ubuntu 릴리스별 수정 패키지 안내

운영자가 확인할 순서

1. 실제로 웹 요청을 처리하는 런타임부터 확인함. 셸의 PHP CLI와 웹 서버의 PHP-FPM·mod_php가 같은 설치본인지 구분해야 함. 별도 컨테이너와 여러 FPM 풀도 점검 목록에 넣을 것.
2. 공급자 수정 패키지나 수정된 컨테이너 이미지를 적용함. 호스팅을 이용하면 서비스 업체에 PHP2Shell 패치 여부와 적용 범위를 문의함.
3. 관련 서비스를 재시작하고 다시 확인함. 파일만 교체하고 기존 프로세스가 계속 실행되는 상태를 피해야 함. 컨테이너는 수정 이미지로 재배포한 실행본인지 확인함.
4. 정상 기능과 오류 로그를 함께 확인함. 로그인·업로드처럼 자주 쓰는 흐름을 확인하고, 배포 과정의 오류와 기존 이상 징후를 나눠 기록해 둠.

업데이트 이후 Apache·PHP-FPM 등 장시간 실행되는 워커를 재시작해야 한다는 점은 연구진과 Ubuntu 안내에도 명시되어 있음. 런타임 업데이트·재시작 안내 · Ubuntu 조치 절차

임시 완화책은 패치를 기다리는 동안의 조치임

PHP 공식 공지는 일부 경로에 대해 업로드 진행 상태 기능 비활성화, 요청 크기 제한 등 노출을 줄이는 방법을 안내함. 하지만 적용 위치와 워커 재시작 여부가 중요하고 모든 변형을 막지는 못함. 특히 memory_limit=-1 같은 변경은 자원 고갈과 가용성에 영향을 줄 수 있어 설정 한 줄만 복사해 일괄 적용하기보다 공식 조건과 운영 환경을 함께 검토해야 함. WAF를 이용하더라도 런타임 업데이트를 대신하는 것으로 보지 않는 편이 맞음. PHP 공식 완화책과 한계 · 연구진의 운영상 주의사항

내용 이해를 돕는 참고 사진 · Photo by Brett Sayles on Pexels · 이용허락

내 서버에서 버전을 확인할 때 주의할 점

터미널에서 아래 명령은 CLI용 PHP 버전과 설정 파일 위치를 확인하는 출발점으로 쓸 수 있음. 단, 이것만으로 웹 서비스의 패치 완료를 증명할 수는 없음. 여러 PHP 버전이 설치되어 있거나 컨테이너별로 실행본이 다르면, 브라우저 요청을 처리하는 쪽은 다른 버전일 수 있기 때문임.

# 셸에서 실행되는 PHP의 버전과 설정 경로 확인
php -v
php --ini

# Debian/Ubuntu 계열: 설치된 PHP 관련 패키지와 전체 리비전 확인
dpkg-query -W 'php*'

php 명령이 없다고 웹 서버가 PHP를 사용하지 않는다는 뜻도 아님. 예를 들어 호스트에 CLI가 없고 컨테이너 안에서만 PHP가 실행되는 구성이 가능함. 관리 화면의 런타임 정보, 실제 배포 이미지, FPM 서비스 구성을 함께 확인하는 편이 정확함. 버전을 확인하려고 공개 경로에 phpinfo() 진단 페이지를 새로 노출하지는 말 것.

패키지 목록은 설치 현황을 보여줄 뿐, 그 실행본이 현재 트래픽을 받는지는 알려주지 않음. 운영 점검에서는 도메인 → 웹 서버 설정 → PHP 처리 방식 → 실행 서비스나 컨테이너 → 설치 패키지를 연결해 기록하면 누락을 줄일 수 있음. 위 명령의 출력값을 이 글에 예시로 만들어 넣지 않은 이유도 환경별로 결과가 다르기 때문임.

업데이트를 끝냈다고 판단할 체크리스트

• 대상: 외부 공개 서비스와 내부 관리 서비스의 PHP 실행 위치를 목록으로 만들었는가.
• 패키지: PHP 공식 릴리스 또는 배포판의 수정 패키지 전체 버전과 대조했는가.
• 실행본: 패키지만 바꾼 상태가 아니라 관련 워커·컨테이너가 실제 교체됐는가.
• 기능: 대표 페이지, 로그인, 세션 유지, 파일 업로드 등 서비스가 쓰는 기능을 확인했는가.
• 기록: 적용 대상, 패키지 또는 이미지 버전, 재시작 시각, 확인 담당자를 남겼는가.
• 예외: 아직 바꾸지 못한 서버와 임시 완화 조치의 해제 계획을 따로 관리하는가.

이 목록은 운영 확인을 위한 제안임. 구성 변경이 실제 서비스에 미칠 영향은 별도 검토해야 함. 특히 호스팅 서비스라면 관리자 권한이 없는 사용자가 서버 명령을 실행하는 대신, 공급자에게 해당 CVE 두 개에 대한 적용 여부와 재시작 완료 여부를 확인하는 것이 현실적인 출발점임.

자주 헷갈리는 질문

워드프레스만 업데이트하면 끝일까?

CMS와 PHP 런타임은 별도 구성요소임. 애플리케이션을 갱신했다고 기반 런타임까지 함께 교체됐다고 가정하지 말고, 호스팅 또는 배포 환경의 PHP 수정 여부를 확인해야 함. 연구진의 업데이트 안내

에러가 없으면 안전하다고 볼 수 있을까?

서비스가 정상으로 보이는지와 취약한 런타임인지 여부는 다른 질문임. 오류 로그가 조용하다는 이유만으로 패치를 미룰 근거는 되지 않음. 반대로 HTTP 500 오류나 워커 재시작이 있었다는 사실만으로 침해됐다고 단정해서도 안 됨. 의심되는 시간대의 접근 로그와 런타임 로그를 함께 보존하고, 필요하면 담당 보안팀의 조사를 진행하는 편이 좋음.

컨테이너 이미지 태그가 같으면 수정되지 않은 걸까?

태그 이름만으로 실제 이미지 내용을 구별하기 어려운 운영 방식도 있음. 운영자가 확인할 것은 사용 중인 실행본의 실제 PHP 버전과 배포된 이미지의 식별 정보임. 새 이미지를 받았는지뿐 아니라 실행 컨테이너가 새 이미지로 교체됐는지도 함께 확인해야 함.

이번 점검의 기준은 취약점 이름을 알고 있는지가 아니라, 외부 요청을 받는 PHP 실행본이 수정됐고 이전 워커까지 교체됐는지임. 패키지 적용 기록과 재시작 시각을 남겨 두면 여러 서버를 관리할 때 빠진 대상을 확인하는 데도 도움이 됨.