PHP2Shell이란: PHP 해킹 취약점 경과와 내 사이트 대처 방법

2026년 10월 21일, 전 세계 웹사이트 운영자에게 같은 경고가 돌았습니다. PHP로 동작하는 웹사이트라면 로그인 없이 요청 몇 번만으로 서버가 장악될 수 있으니 바로 업데이트하라는 내용입니다. 이 취약점 묶음을 보안 업계에서는 PHP2Shell이라고 부릅니다.

PHP는 웹사이트를 만드는 데 쓰는 프로그래밍 언어입니다. 워드프레스, 그누보드, 드루팔, 줄라 같은 설치형 홈페이지와 쇼핑몰 프로그램이 PHP로 만들어져 있고, 웹 서버가 방문자의 요청을 받을 때마다 PHP 엔진이 이 프로그램을 실행합니다. 이번 문제는 워드프레스나 플러그인이 아니라 그 아래의 PHP 엔진 자체에 있어서, PHP로 돌아가는 사이트 대부분이 영향을 받습니다.

이 글은 2026년 10월 25일까지 나온 공식 공지와 보안 업체 발표를 바탕으로 무슨 일이 있었는지, 내 사이트는 어디에 해당하는지, 무엇부터 해야 하는지 순서대로 정리합니다.

PHP2Shell을 숫자로 보면

PHP2Shell은 CVE-2026-109618과 CVE-2026-109619 두 취약점을 함께 부르는 이름입니다. CVE는 공개된 보안 취약점마다 붙는 고유 번호이고, CVSS는 심각도를 10점 만점으로 매긴 점수입니다.

PHP2Shell의 규모

• 9.2점두 취약점의 심각도CVSS 4.0 기준, 등급은 치명적(Critical)
• 69.2%PHP를 쓰는 웹사이트 비율서버 언어가 알려진 사이트 중, W3Techs 10월 25일
• 2012년영향받는 가장 오래된 버전(PHP 5.4)의 출시 연도

W3Techs 집계에 따르면 서버 언어가 확인되는 웹사이트의 69.2%가 PHP를 씁니다. 언론에서 "전 세계 웹사이트의 70%"라는 표현이 나온 것은 이 비율 때문입니다. 같은 집계에서 PHP 사이트의 26.8%는 PHP 7, 7.7%는 PHP 5를 쓰고 있었습니다. 뒤에서 보겠지만 이 두 버전에는 PHP 프로젝트의 공식 수정판이 나오지 않았습니다.

두 취약점이 하는 일

두 취약점 모두 PHP가 메모리를 정리하는 과정의 실수에서 나옵니다. PHP 공식 보안 공지의 설명을 풀면 다음과 같습니다.

PHP2Shell을 이루는 두 취약점

항목	CVE-2026-109618메모리 부족 처리 중 손상	CVE-2026-109619지난 요청의 잔여 상태
무슨 일이 생기나	요청 준비 중 메모리가 바닥나면 반쯤 만들어진 데이터를 정리 단계가 그대로 믿고 씀	이미 지운 메모리를 가리키는 값이 남아 있다가 같은 작업 프로세스의 다음 요청이 그 값을 씀
공격 방법	조작한 업로드 요청으로 메모리를 일부러 소진	치명 오류를 일으킨 뒤 다음 요청에서 남은 값을 사용
로그인 필요 여부	필요 없음	필요 없음
심각도	9.2	9.2

그림 1. PHP 공식 사이트의 10월 21일 보안 공지 첫 문단. 수정 버전 네 개와 즉시 업데이트 권고가 적혀 있습니다.

원격 코드 실행(RCE)은 공격자가 내 서버에서 원하는 명령을 실행할 수 있게 되는 상태를 말합니다. 이렇게 되면 홈페이지 파일 변조, 회원 정보 유출, 악성코드 설치, 다른 공격의 발판으로 쓰는 일까지 가능해집니다. 이름에 붙은 "Shell"도 서버의 명령 창(셸)을 얻는다는 뜻입니다.

PHP는 웹 서버와 연결되는 방식이 여러 가지인데, 공식 공지는 웹 요청을 처리하는 모든 PHP 설치가 위험하다고 밝혔습니다. 그중 위험이 가장 큰 것은 아파치 웹 서버에 PHP를 모듈로 붙인 mod_php 방식입니다. 이 방식에서는 프로그램 코드가 실행되기도 전에 공격이 성공하는 사례가 확인됐습니다.

PHP 연결 방식별 위험(공식 공지 기준)

연결 방식	영향
아파치 mod_php	가장 위험 프로그램 코드 실행 전 공격 확인
PHP-FPM(엔진엑스 등과 함께 사용)	영향 있음
php-cgi	영향 있음
FrankenPHP, LiteSpeed	영향 있음

2004년까지 올라가는 출발점

이번 취약점의 뿌리는 PHP의 메모리 한도 처리입니다. 발견 업체 Calif는 사건 정리 페이지를 2004년에서 시작합니다. 그해 PHP 보안 연구자 Stefan Esser가 메모리 한도를 이용한 첫 원격 취약점을 찾았고, 위험이 커서 공격 코드를 공개하지 않았습니다. 2020년에는 긴 변수가 메모리 부족을 일으킨다는 버그(#78876)가 보고됐지만 큰 문제로 다뤄지지 않았습니다.

2024년에는 독일 정부 지원 기관(Sovereign Tech Agency)의 후원으로 보안 업체 Quarkslab이 PHP를 외부 감사했습니다. PHP 재단의 설명에 따르면 이때 메모리 부족 처리의 공격 가능성이 다시 거론됐지만 구체적인 공격 경로를 찾지 못했고, 여러 수정안이 서로 장단점이 있어 결정을 내리지 못한 채 남았습니다. 재단은 이 지연을 "보안팀의 의사결정 방식과 인력 부족이 만든 구조적 실패"라고 스스로 평가했습니다.

오래된 메모리 문제의 흐름(2004년~2024년)

1. 12004년Stefan Esser가 메모리 한도를 이용한
   첫 원격 취약점 발견
2. 22020년메모리 부족 버그
3. 32024년Quarkslab 외부 감사에서 다시 거론,
   공격 경로 미확인으로 수정 미뤄짐

2026년 여름, 이 문제가 다시 드러났습니다. OpenAI가 7월 30일 Calif를 오픈소스 보안 지원 사업(Patch the Planet)에 초대했고, Calif는 AI 도구와 함께 PHP 소스 코드를 검토해 8월 11일 첫 취약점을, 8월 21일 두 번째 취약점을 PHP에 보고했습니다. Calif는 "모든 연구소가 이미 AI로 이 코드를 감사했기 때문에 치명적인 것을 찾으리라 기대하지 않았다"고 적었고, 처음 발견할 때 누구나 쓸 수 있는 모델만 썼다고 밝혔습니다. 보안 업체 Wiz도 별도로 같은 계열의 문제를 찾아 8월 24일 보고했고, 워드프레스와 드루팔에서 로그인 없는 원격 코드 실행을 확인했습니다.

그림 2. 발견 업체 Calif가 사건 경과를 그린 만화 중 2004년, 2020년, 2024년, 2026년 장면입니다.

발견부터 비공개 수정까지(2026년 7월~10월)

1. 17월 30일OpenAI가 Calif를
   보안 지원 사업에 초대
2. 28월 11일Calif가 AI 도구와 함께
   찾은 첫 취약점 보고
3. 38월 21일~24일Calif 두 번째 보고,
   Wiz 별도 보고
4. 48월~10월PHP 보안팀이 비공개로 수정,
   리눅스 배포판에 미리 전달

유출과 긴급 배포, 공격까지의 나흘

원래 공개일은 10월 22일이었습니다. 그런데 공개 전에 정보가 새면서 일정이 하루 당겨졌습니다. 아래 시각은 모두 한국 시간입니다.

10월 17일부터 23일까지(한국 시간)

1. 110월 17일Amazon 미끼 서버에
   첫 공격 시도 관측
2. 210월 21일 0시CVE 번호가 온라인에 먼저 퍼짐,
   새벽 4시 30분 PHP 사전 공지
3. 310월 21일 새벽 5시Calif가 실수로
   공격 시연 영상 공개
4. 410월 21일 오전카페24 임시 설정 순차 적용,
   낮 12시 Cloudflare 차단 규칙
5. 510월 21일 밤 11시PHP 수정 버전 배포,
   공격 시도 급증
6. 610월 23일후속 취약점
   CVE-2026-115560 안내

PHP 재단은 공개 과정이 흔들린 이유를 세 가지로 설명했습니다. 10월 20일 CVE 번호와 잘못된 배포 시각, 잘못된 점수(10.0)가 먼저 온라인에 올라왔습니다. 몇 시간 뒤 발견 업체 Calif가 실제로 동작하는 공격 시연 영상을 실수로 공개했고, 복사본이 퍼지며 공격 코드 개발을 앞당겼습니다. 배포 당일에는 컨테이너 이미지 업체 Chainguard가 공식 배포 6시간여 전에 수정이 들어간 이미지를 먼저 내놓아, 무엇이 바뀌었는지 공격자가 볼 수 있게 됐습니다.

Amazon은 공격 관측용 미끼 서버(허니팟)에서 공개 나흘 전인 10월 17일 첫 시도를 발견했습니다. 공격자가 어떻게 미리 정보를 얻었는지는 밝혀지지 않았습니다. 10월 21일에는 여러 공격자의 시도가 이어졌고, 수정판 배포 몇 시간 안에 새 공격 코드가 나와 곧바로 쓰였습니다.

공격이 실제로 성공했는지는 업체마다 관측이 다릅니다. watchTowr는 10월 21일부터 실제 공격을 관측했다고 밝혔고, Rapid7은 10월 22일 기준 공개된 공격 코드가 특정 운영체제와 PHP 버전, 웹 서버 조합에서만 동작해 범용성은 낮다고 분석했습니다. 다만 두 업체 모두 즉시 업데이트를 권고했습니다.

10월 23일 후속 취약점 CVE-2026-115560

10월 23일 PHP는 세션 업로드 진행률 기능과 관련된 추가 취약점 CVE-2026-115560을 안내했습니다. 이 문제는 10월 21일 수정판에도 남아 있어 다음 정기 배포에서 고칠 예정입니다. PHP는 발생 조건이 매우 드물다고 설명했습니다. 프로그램이 세션 저장 형식을 실행 중에 바꾸는 특이한 구성에서만 생깁니다.

PHP의 10월 23일 안내 원문

We suggest you set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector.

다음 정기 배포 전까지 세션 업로드 진행률 기능을 꺼 두면, 가능성은 낮지만 남아 있는 원격 코드 실행 경로까지 막을 수 있다는 뜻입니다.

PHP 공식 공지, 2026년 10월 23일

이 설정은 10월 21일 공지에서도 임시 조치로 안내된 것입니다. 이미 적용했다면 그대로 두면 됩니다. 업로드 진행률 표시 기능을 쓰는 사이트는 그 기능이 동작하지 않을 수 있습니다.

내 사이트는 어디에 해당하나요?

대처 방법은 사이트를 어떻게 운영하는지에 따라 다릅니다. 먼저 내 사이트가 아래 셋 중 어디에 해당하는지 확인합니다.

운영 방식별로 해야 할 일

운영 방식	누가 PHP를 업데이트하나	내가 할 일
쇼핑몰 빌더, 블로그 서비스처럼 서버를 직접 다루지 않는 서비스	서비스 운영사	운영사 공지 확인
웹 호스팅에 워드프레스 등 설치	호스팅 업체 (버전 선택은 내가 하는 경우가 많음)	업체 공지 확인, 관리 화면에서 PHP 버전 확인과 변경
클라우드 서버나 자체 서버	나 또는 개발사	업데이트, 재시작, 침해 흔적 확인까지 전부

PHP 버전은 다음 위치에서 확인할 수 있습니다. 워드프레스는 관리자 화면의 도구 > 사이트 상태 > 정보 > 서버 항목에 PHP 버전이 나옵니다. 호스팅은 업체 관리 화면의 PHP 버전 설정 메뉴에서 볼 수 있습니다. 서버에 접속할 수 있다면 터미널에서 php -v를 실행합니다. 다만 명령 창의 PHP와 웹 서버가 쓰는 PHP가 다른 경우가 있으므로, 웹 서버 쪽 버전도 함께 확인해야 합니다.

수정 버전과 지원 종료 버전

확인한 버전을 아래 표와 대조합니다. 지원 중인 버전은 같은 계열의 수정 버전 이상이면 됩니다.

PHP 버전별 수정 여부(2026년 10월 25일 기준)

사용 중인 버전	공식 수정판	해야 할 일
8.5	8.5.12	8.5.12 이상으로
8.4	8.4.27	8.4.27 이상으로
8.3	8.3.36	8.3.36 이상으로
8.2	8.2.35	8.2.35 이상으로, 12월 31일 지원 종료 대비
7.4, 8.0, 8.1	없음 (소스 수정본만 제공)	배포판, LTS 업체 패키지 적용 또는 8.2 이상으로 이전
7.3 이하, 5.x	없음	지원 버전으로 이전

PHP 8.2는 2026년 12월 31일에 보안 지원이 끝납니다. 이번에 업데이트하면서 8.3 이상으로 옮길 수 있는지도 함께 검토하는 편이 좋다고 생각합니다. 오래된 워드프레스 테마나 플러그인은 새 PHP에서 오류가 날 수 있으므로, 가능하면 복제본이나 스테이징 서버에서 먼저 확인합니다.

서버를 직접 운영한다면 해야 할 일

서버를 직접 관리한다면 아래 순서로 진행합니다. 영국 국가사이버보안센터(NCSC)와 PHP 공지의 권고를 합친 순서입니다.

서버 운영자의 대처 순서

1. 11. 목록 만들기PHP가 도는 서버를
   인터넷에 열린 것부터 확인
2. 22. 업데이트계열별 수정 버전이나
   배포판 패키지로 올림
3. 33. 작업 프로세스 재시작PHP-FPM, 아파치를
   모두 다시 시작
4. 44. 못 올리면 임시 조치공식 임시 설정 적용,
   그래도 어려우면 서비스 중단 검토
5. 55. 침해 흔적 확인10월 17일 이후 기록부터
   의심 요청과 파일 변경 점검

업데이트를 바로 할 수 없을 때 PHP가 안내한 임시 설정은 다음과 같습니다. PHP는 이 설정들이 노출을 줄일 뿐 안전하게 만들지는 않는다고 분명히 했습니다.

업데이트 전 임시 설정(PHP 10월 21일 공지)

설정	막는 대상	주의할 점
session.upload_progress.enabled=0	CVE-2026-109619의 세션 경로, 후속 CVE-2026-115560	php.ini나 FPM 풀 설정에 넣고 재시작 (ini_set, .user.ini는 늦음)
fatal_error_backtraces=0	PHP 8.5의 치명 오류 추적 경로	8.5에서만 해당
memory_limit=-1	CVE-2026-109618의 PHP 메모리 한도 경로	프로그램이 다시 바꾸지 못하게 관리자 설정으로 지정
post_max_size 8M(업로드 필요 시 32M)	메모리 소진용 대용량 요청	upload_max_filesize는 이보다 작게

Cloudflare는 10월 21일 낮 12시(한국 시간)부터 무료 요금제를 포함한 모든 이용자에게 PHP2Shell 차단 규칙을 기본 적용했습니다. 유료 요금제는 관리형 규칙이 차단 모드인지 확인하라고 안내했습니다. 다만 Cloudflare도 공격자가 규칙을 피하려고 요청을 계속 바꾸고 있다며 PHP 업데이트를 함께 하라고 권고했습니다.

그림 3. Cloudflare의 차단 규칙 공지. 무료 요금제에도 별도 설정 없이 적용됐습니다.

국내에서는 카페24가 10월 21일 오전부터 PHP 8.x 이하 전체 서비스에 session.upload_progress.enabled Off를 순차 적용하고, 최신 PHP 버전으로 옮길 것을 권장했습니다.

그림 4. 카페24의 10월 21일 긴급 조치 공지 중 작업 내용. 이 조치는 임시 설정이므로 공지에서도 완전한 방어를 보장하지 않는다고 밝혔습니다.

침해 흔적은 공개일이 아니라 10월 17일부터 살펴야 합니다. Amazon은 웹 서버 기록에서 업로드 양식 안에 PHP_SESSION_UPLOAD_PROGRESS 문자열이 든 POST 요청을 찾고, 웹 서버에서 예상하지 못한 프로세스 실행이나 파일 변경이 있었는지 확인하라고 권했습니다. Wiz는 업로드 요청 뒤 메모리 한도 오류나 500 오류가 반복되는 경우, 비정상적으로 크거나 깨진 PHPSESSID 쿠키, 이유 없는 PHP 작업 프로세스의 재시작을 신호로 꼽았습니다.

흔한 오해 바로잡기

PHP2Shell을 둘러싼 흔한 오해

• 워드프레스와 플러그인을 최신으로 올리면 해결된다

  결함은 PHP 엔진에 있습니다. 워드프레스, 테마, 플러그인 업데이트로는 고쳐지지 않고 PHP 버전을 올려야 합니다.

• Cloudflare 같은 방화벽을 쓰면 업데이트하지 않아도 된다

  방화벽 규칙은 알려진 공격 형태를 막는 임시 방어입니다. 공격자가 요청을 바꾸고 있어 업데이트가 함께 필요합니다.

• 작은 회사 사이트라 노릴 이유가 없다

  Amazon과 watchTowr는 특정 회사가 아닌 미끼 서버에서 공격을 관측했습니다. 공격자가 인터넷의 서버를 가리지 않고 찾는다는 뜻이라 규모와 관계없이 대상이 됩니다.

• 업데이트만 하면 끝이다

  공격 시도는 공개 나흘 전부터 있었습니다. 업데이트 뒤에도 그 사이에 침입 흔적이 없는지 확인해야 합니다.

잠깐 확인PHP 7.4로 운영 중인 자체 서버가 있습니다. 가장 알맞은 조치는 무엇일까요?

A배포판이나 LTS 업체의 수정 패키지를 적용하거나 PHP 8.2 이상으로 옮기고, 그동안 임시 설정을 적용한다BPHP 7.4는 오래된 버전이라 영향이 없으므로 그대로 둔다C워드프레스 보안 플러그인을 설치한다

이번 사건이 남긴 것

PHP 재단은 재발 방지책으로 보안팀이 다수결로 결정하고 타협안을 권장하는 방식으로 절차를 바꾸고, 수정이 막힌 심각한 취약점은 재단 지도부에 더 빨리 올라가게 하겠다고 밝혔습니다. 2026년 5월 생태계 보안팀을 만들고 AI 보안 담당 엔지니어를 두는 등 인력도 늘리고 있습니다.

PHP 재단은 AI를 활용한 보안 연구로 취약점 보고가 늘고 있다고 밝혔습니다. 오래된 오픈소스 코드에서 이런 발견이 더 잦아질 가능성이 큰 편입니다. 운영자 입장에서 보면 "중대 취약점이 공개되면 며칠이 아니라 몇 시간 안에 공격이 시작된다"는 점이 이번에 다시 확인됐습니다. Amazon도 인터넷에 열린 시스템의 치명적 취약점은 조치 목표를 일 단위가 아니라 시간 단위로 잡으라고 권고했습니다.

마무리로 짚어 볼 것

1. PHP2Shell은 PHP 엔진의 결함이라 사이트 프로그램과 플러그인 업데이트로는 해결되지 않습니다.
2. 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상이 공식 수정판이고, 8.1 이하는 배포판 패키지나 버전 이전이 필요합니다.
3. 공격 시도는 10월 17일부터 있었으므로 업데이트 뒤에도 그 이후 기록을 점검합니다.

직접 해 보기

• 내 사이트가 서비스형, 호스팅, 자체 서버 중 어디에 해당하는지 확인하기
• 웹 서버가 실제로 쓰는 PHP 버전을 확인해 수정 버전 이상인지 대조하기
• 호스팅 업체나 개발사의 조치 공지와 조치 일시 받아 두기
• 자체 서버라면 업데이트 뒤 PHP 작업 프로세스를 재시작하고 10월 17일 이후 기록 점검하기