PHP2Shell 총정리: PHP 치명적 취약점 2건, 내 사이트는 안전할까?

2026년 10월 22일 기준

PHP 엔진 자체에서 로그인 없이 서버를 장악할 수 있는 치명적 취약점 2건이 나왔고, 10월 21일 긴급 패치가 배포됐습니다. PHP로 돌아가는 웹사이트를 운영한다면 지금 바로 PHP 버전을 확인해야 합니다.

워드프레스, 그누보드, 라이믹스, 줌라, 마젠토 같은 인기 설치형 프로그램은 모두 PHP 위에서 돌아갑니다. 이번 문제는 이런 프로그램의 버그가 아니라 PHP 자체의 버그라서, 게시판이나 플러그인만 업데이트해서는 막을 수 없습니다.

이 글에서는 사건 경과, 취약점 원리, "EU 긴급 경계령" 보도의 사실 여부, 실제 공격 현황, 그리고 내 서버 점검 방법까지 정리했습니다.

한눈에 보기

항목	내용
별칭	PHP2Shell
CVE 번호	CVE-2026-109618(예외 상황 처리 미흡), CVE-2026-109619(Use After Free)
유형	인증 없는 원격 코드 실행(RCE)
심각도	CVSS v4.0 기준 각 9.2(치명적)
발견자	Calif, Wiz, OpenAI 보안 연구자
수정 버전	PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
패치 배포	2026년 10월 21일 오후 10시 30분~11시경(한국시간)
영향 범위	웹 요청을 처리하는 모든 PHP. mod_php가 가장 위험
구버전	8.1 이하는 공식 릴리스 없음(7.4~8.1용 소스 백포트만 공개)
근본 해결책	PHP 업데이트 + 워커 재시작

사건 경과

원래 10월 22일에 공개할 예정이었지만, 하루 앞서 세부 내용이 유출되면서 일정이 앞당겨졌습니다. 시각은 모두 한국시간 기준입니다.

시점(한국시간)	내용
10월 20일	취약점 세부 내용 유출. PHP 보안팀이 긴급 릴리스 사전 공지, CERT-EU가 보안 권고 2026-018 발표
10월 21일 오후 10시 35분~11시	PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 배포(매체마다 시각 차이 있음)
10월 21일 오후 11시 17분	미국 NVD가 CVE 등록(분석 진행 중)
10월 21일	watchTowr가 자사 허니팟에서 악용 시도 관찰 보고
10월 21일	KISA 보호나라, 'PHP 제품 보안 업데이트 권고' 게시
10월 22일 새벽 2시 50분	Docker Hub 공식 php·wordpress 이미지에 수정판 반영
10월 22일 오전 6시 15분	AlmaLinux 8·9·10 운영 저장소에 패치 패키지 배포

출처: Tanium, Arvion, AlmaLinux, The Hacker News

두 취약점은 어떻게 동작하나

두 취약점의 뿌리는 같습니다. 요청이 비정상적으로 끝날 때 PHP가 메모리를 깨진 상태로 남겨두고, 공격자가 그 틈을 이용해 원하는 코드를 실행하는 구조입니다.

CVE-2026-109618 — 메모리 부족 처리 결함

요청이 PHP의 메모리 한도를 넘으면 PHP는 하던 일을 즉시 중단합니다. 그런데 몇몇 지점에서는 내부 데이터가 반쯤만 준비된 상태로 멈추고, 뒤정리 과정이 이 깨진 데이터를 정상으로 오인합니다.

CVE-2026-109619 — 해제된 메모리 재사용 결함

요청 처리가 끝난 뒤에도 내부 상태가 이미 반납된 메모리를 가리킨 채 남아, 같은 워커가 다음 요청을 처리할 때 이를 참조합니다(use-after-free). 코드 실행뿐 아니라 서버 메모리 내용 유출도 가능합니다. 공격 경로는 파일 업로드 진행률을 추적하는 session.upload_progress 기능입니다.

두 가지가 특히 위험합니다.

웹사이트 코드가 실행되기도 전, PHP가 요청을 받는 단계에서 터집니다. 사이트 코드가 아무리 안전해도 소용없습니다.
로그인이나 사용자 클릭이 필요 없습니다. 다만 CVSS상 공격 난이도는 '높음'으로, 어느 서버나 한 번에 뚫리는 수준은 아닙니다.

빨간 상자가 취약점이 터지는 지점입니다. 웹사이트 코드는 아직 실행되기 전이라, 플러그인이나 게시판 업데이트로는 막을 수 없습니다.

출처: BleepingComputer, AlmaLinux, Abstract Security

어디까지 영향을 받나

웹 요청을 처리하는 PHP라면 실행 방식과 관계없이 모두 대상입니다. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed가 포함되며, PHP 보안팀은 실제 공격이 시연된 mod_php를 가장 위험하다고 봤습니다.

PHP 버전	상태	조치
8.5	8.5.11 이하 취약	8.5.12로 업데이트
8.4	8.4.26 이하 취약	8.4.27로 업데이트
8.3	8.3.35 이하 취약	8.3.36으로 업데이트
8.2	8.2.34 이하 취약	8.2.35로 업데이트(2026년 12월 31일 지원 종료)
7.4~8.1	지원 종료, 공식 릴리스 없음	직접 빌드용 소스 백포트만 공개. 배포판·LTS 업체 패치 확인 또는 상위 버전으로 이전
7.3 이하	지원 종료, 수정 없음	상위 버전으로 이전

취약한 코드 경로는 PHP 5.4.0까지 거슬러 올라간다는 분석이 있습니다. 다만 PHP 프로젝트가 공식으로 범위를 확인한 것은 아닙니다.

규모도 큽니다. CybelAngel은 인터넷에 노출된 PHP 호스트를 약 224만 개로 추산했고, 이 중 59%가 공식 수정판이 나오지 않는 구버전을 쓴다고 봤습니다. 민간 업체 추정치이고 공식 통계는 아닙니다.

출처: Help Net Security, Arvion, Tenable, CybelAngel

"EU 긴급 경계령" 사실일까

EU가 경고한 것은 사실이지만, "긴급 경계령 발령"은 과장된 표현입니다. EU 기관의 보안을 담당하는 CERT-EU가 10월 20일 보안 권고(Security Advisory) 2026-018을 낸 것이고, 법적 비상조치는 아닙니다.

돌아다니는 주장	확인 결과
EU가 PHP 취약점을 경고했다	사실. CERT-EU 권고 2026-018
EU가 긴급 경계령을 발령했다	과장. 보안 권고를 국내 언론이 강하게 옮긴 표현
패치 못 하면 사이트를 꺼야 한다	절반만 맞음. 즉시 패치가 어려우면 인터넷 노출 서비스를 격리하는 것을 검토하라는 권고
심각도 10점 만점이다	공식은 9.2. 10.0은 보안업체 watchTowr의 자체 평가
PHP 5 이상 전부 취약하다	CERT-EU의 초기 추정. PHP 공식 확인 범위는 아님

참고로 CERT-EU의 초기 권고는 패치 공개 전에 나온 것이라, 버전 정보는 이후 PHP 공식 발표로 대체됐습니다. 국내에서는 한국인터넷진흥원(KISA)이 10월 21일 보호나라에 정식 보안 권고를 올렸습니다(아래 참고).

출처: Tenable, Brandefense, Stingrai, Wikipedia

국내 공식 안내: KISA 보호나라 권고

KISA 디지털위협대응본부 취약점관리센터는 10월 21일 'PHP 제품 보안 업데이트 권고'를 게시했습니다. 영향받는 버전을 쓰는 사용자는 최신 버전으로 업데이트하라는 내용입니다.

보호나라는 두 취약점을 다음과 같이 분류했습니다.

CVE-2026-109618: 예외 상황 처리 미흡(Improper Handling of Exceptional Conditions). 앞서 설명한 메모리 부족 처리 결함입니다.
CVE-2026-109619: 해제된 메모리 재사용(Use After Free).

제품	영향받는 버전	해결 버전	해당 CVE
PHP 8.5	8.5.12 미만	8.5.12 이상	109618, 109619
PHP 8.4	8.4.27 미만	8.4.27 이상	109618, 109619
PHP 8.3	8.3.36 미만	8.3.36 이상	109618, 109619
PHP 8.2	8.2.35 미만	8.2.35 이상	109618, 109619

PHP 8.1 이하는 공식 보안 지원이 끝났으므로, 지원 중인 버전으로 업그레이드하라고 권고합니다. 궁금한 점은 KISA 사이버민원센터(국번 없이 118)에 문의할 수 있습니다.

출처: KISA 보호나라 보안공지(2026-10-21), PHP 공식 공지, GitHub 권고 CVE-2026-109618, GitHub 권고 CVE-2026-109619

실제 공격은 시작됐나

공격 시도는 이미 관찰됐고 공격 도구도 공개됐지만, 실제 피해가 확인된 사례는 아직 공개되지 않았습니다. 패치 전 서버는 위험이 빠르게 커지는 단계입니다.

Cloudflare: 패치 공개 전부터 초기 공격 시도를 포착했고, 임시 방화벽(WAF) 규칙을 배포
watchTowr: 10월 21일 자사 허니팟(미끼 서버)에서 악용 시도 관찰
Wiz: 두 결함을 묶은 공격 스크립트로 최신 워드프레스·드루팔·줌라 환경을 실험실에서 재현
Sansec: 분석 글과 공격 도구가 이미 공개돼 있다고 밝힘
미국 CISA: 패치 직후 시점에는 실제 악용 취약점 목록(KEV)에 두 CVE 모두 미등재

보안 연구자 Kevin Beaumont는 수년 만에 나온 최대급 취약점 중 하나로, 대규모 침해 사고로 이어질 것이라고 경고했습니다.

출처: The Hacker News, Tanium, Brandefense, Help Net Security

패치와 점검 방법

근본 해결책은 PHP 업데이트 하나뿐입니다. 설정 변경이나 방화벽은 시간을 버는 임시 조치일 뿐입니다.

수정 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. 어느 경로든 마지막에는 침해 흔적을 한 번 점검하는 것이 좋습니다.

패치 순서

인터넷에 노출된 서버부터 우선 업데이트합니다.
리눅스 배포판(Debian, Ubuntu, AlmaLinux 등)을 쓴다면 배포판 보안 공지의 패키지를 설치합니다. 버전 숫자가 달라도 수정이 백포트됐을 수 있으니 두 CVE 반영 여부를 확인합니다.
Docker를 쓴다면 공식 이미지를 다시 받아 컨테이너를 재배포합니다.
업데이트 후 PHP-FPM과 웹서버를 재시작합니다. 기존 워커 프로세스가 남아 있으면 여전히 구버전이 돕니다.

점검할 때 주의할 점

터미널의 php -v는 명령줄(CLI)용 PHP 버전만 보여줍니다. 웹사이트를 실제로 처리하는 PHP는 phpinfo() 페이지나 PHP-FPM 버전으로 확인해야 합니다.
가상호스트별 PHP, 컨테이너 이미지, 제품에 내장된 PHP까지 모두 확인합니다.
phpinfo() 페이지는 확인 후 반드시 삭제합니다.

당장 패치가 어려울 때(임시 조치)

CVE-2026-109619 대응: php.ini에서 session.upload_progress.enabled=0으로 끄고 모든 워커를 재시작
CVE-2026-109618 대응: memory_limit=-1(무제한)로 두되, 앱이 바꿀 수 없도록 FPM 풀이나 Apache 설정의 php_admin_value로 지정. 메모리 고갈 위험이 있어 패치 전까지만 사용
VPN이나 IP 허용 목록으로 접근을 제한하거나, 인터넷 노출 서비스를 격리(CERT-EU 권고)
Cloudflare 같은 WAF 경유. 단, WAF를 거치는 트래픽만 보호되고 패치를 대신하지 못함

침해 흔적 확인

이미 뚫렸을 가능성에 대비해 웹셸(서버에 심어두는 뒤문 파일) 여부와 서버 로그를 점검합니다. PHP 워커가 sh, bash, curl 같은 프로그램을 실행한 흔적이 있다면 의심해봐야 합니다.

출처: BleepingComputer, Tanium, CybelAngel, 데일리시큐

국내 운영자를 위한 체크리스트와 FAQ

그누보드·라이믹스 기반 커뮤니티나 오래된 쇼핑몰은 PHP 5·7 같은 구버전에 머물러 있는 경우가 많아 특히 주의가 필요합니다.

웹사이트가 쓰는 PHP 버전 확인(CLI 말고 웹 기준)
수정 버전(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) 또는 배포판 패치 적용
PHP-FPM·웹서버 재시작, 컨테이너 재배포
8.1 이하라면 상위 버전 이전 계획 수립
호스팅 사용 시 업체에 패치 적용 여부 문의 (도움이 필요하면 KISA 118)
웹셸·이상 로그 점검

Q. 워드프레스나 그누보드를 업데이트하면 되나요?

아닙니다. 문제는 그 아래에서 돌아가는 PHP 자체에 있어, PHP 런타임을 업데이트해야 합니다.

Q. 호스팅 업체를 쓰면 어떻게 하나요?

공유 호스팅은 PHP를 업체가 관리합니다. 관리 페이지에서 PHP 버전을 확인하고, 패치 일정을 업체에 직접 문의하세요.

Q. PHP 7이나 8.1을 쓰는데요?

공식 지원이 끝난 버전이라 바로 설치할 수 있는 공식 패치가 없습니다. 배포판이나 LTS 업체의 백포트 패치를 확인하고, 근본적으로는 8.2 이상으로 올려야 합니다.

Q. 사이트를 꺼야 하나요?

패치를 바로 적용할 수 있다면 꺼야 할 이유는 없습니다. 패치가 당장 불가능한 중요 서비스라면 접근 제한이나 일시 격리를 검토하세요.

마무리

PHP2Shell은 개별 사이트의 보안 수칙으로는 막을 수 없는, 언어 엔진 자체의 결함입니다. 공격 도구가 이미 공개됐으니, PHP 버전을 확인하고 패치 후 재시작까지 오늘 안에 끝내는 것을 권합니다.

이 글은 공개된 보안업체·언론 자료를 정리한 것이며 보안 컨설팅이 아닙니다. 상황은 계속 바뀌고 있으니 실제 조치는 PHP 공식 공지와 사용 중인 배포판·호스팅 업체 안내를 따르세요.

참고 자료

공식 공지

KISA 보호나라 — PHP 제품 보안 업데이트 권고(2026-10-21)
PHP 공식 보안 공지
GitHub 보안 권고 — CVE-2026-109618
GitHub 보안 권고 — CVE-2026-109619

보안업체·언론 자료