PHP2Shell.
AI가 공격 경로를 잇다.
10년 넘게 존재한 메모리 안전성 문제는 어떻게
인증 없는 서버 코드 실행으로 이어졌을까?
발견의 맥락부터 데이터 탈취 경로, 운영자의 대응까지.
수치와 버전 범위: PHP 보안 권고 · Docker 공지 · PHP 10/23 후속 공지
JavaScript가 꺼져 있습니다. 본문·버전표·출처는 그대로 읽을 수 있습니다. 단계별 탐색, 버전 입력 확인, 코드 탭과 복사 기능은 JavaScript를 켜면 사용할 수 있습니다.
무슨 일이 있었나
문제는 PHP로 만든 개별 웹사이트보다 한 층 아래, 요청을 실행하는 엔진에 있었다.
PHP2Shell은 PHP 코어의 메모리·상태 관리 결함들을 두 CVE로 묶어 부르는 이름이다. 조건이 맞으면 로그인하지 않은 외부 공격자가 서버에서 코드를 실행하거나 프로세스 메모리를 읽을 수 있다.[02][03][04]
애플리케이션 아래의 문제
정상적인 PHP 코드로 만든 서비스도 영향을 받을 수 있다. WordPress 플러그인 하나를 고치는 방식으로 끝나는 사건이 아니다.[04]
실패한 요청의 뒷정리
메모리 부족이나 치명적 오류로 처리가 중단될 때, 정리되지 않은 내부 상태가 잘못 사용되는 것이 공통 문제다.[10]
실행 중인 PHP를 교체
업데이트 파일을 내려받는 데서 멈추면 안 된다. 웹 요청을 처리하는 워커나 컨테이너가 수정된 런타임으로 실행되어야 한다.[09]
10년 이상 된 결함 계열을 연구자와 AI가 분석하고, 실제 공격 가능한 경로와 변종을 입증한 사건이다. PHP Foundation은 OOM 문제의 징후를 2024년에 이미 파악했다고 밝혔다.[05]
AI는 정확히 무엇을 했나
발견을 이해하려면 ‘위험한 패턴을 아는 것’과 ‘작동하는 공격을 입증하는 것’을 구별해야 한다.
사람의 가설을 넓힌 분석
Calif 연구자는 과거 PHP의 메모리 한도·오류 처리 연구를 출발점으로 삼았다. AI는 코드 분석, 위험 패턴의 일반화, 변종 탐색을 도왔다. OpenAI는 Calif가 GPT-5.6 Sol을 활용했다고 설명한다.[06][07]
출발 가설, 실험 설계와 결과 판단에는 연구자가 관여했다. ‘AI가 혼자 자동으로 해킹했다’는 식의 요약은 연구 과정을 생략한다.
복잡한 연결과 반복 검증
Wiz도 독립적으로 발견·보고했다. Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol을 사용해 버그 연결, 환경별 메모리 배치 분석, 디버깅과 패치 검증을 지원받았다고 밝혔다.[04]
연구팀이 보여 준 변화는 어려운 메모리 버그를 실제 동작하는 공격으로 연결하고, 다른 환경에 맞춰 시험하는 비용이 낮아졌다는 것이다.
위 도식은 역할을 이해하기 위한 종합 정리다. 실제 연구는 여러 번 왕복하며 진행됐다.[06][07]
OOM 문제의 징후를 인지
Quarkslab 감사 후속 작업에서 PHP 개발자가 위험을 파악했다. 구체적 RCE 경로가 없고 수정의 호환성·인력 문제가 겹쳐 작업이 지연됐다.[05]
Calif의 PHP 감사 시작
Patch the Planet 프로그램으로 조사 시작. Calif는 8월 1일 여러 RCE 경로를 찾았다고 기록한다.[06]
보고에서 작동 확인까지
Calif가 11일 보고, 14일 RCE 개념증명 전달, 15일 PHP 측 작동 확인 순으로 진행했다.[06]
Wiz의 독립 발견과 보고
Wiz가 별도 연구로 발견하고 CMS 환경에서 인증 전 RCE를 검증한 뒤, 24일 PHP 보안팀에 보고했다.[04]
정보 유통으로 공개 일정 변경
CVE 번호와 잘못된 ‘CVSS 10.0’ 정보가 퍼져, 예정된 22일보다 공개를 하루 앞당겼다. 이후 시연 영상도 일시 공개됐다.[05]
보안 릴리스와 후속 권고
21일 두 취약점의 수정 버전 공개. 23일에는 드문 세션 설정 조합에 대한 추가 공지가 나왔다.[01]
PHP Foundation은 기존 확장 모듈과의 호환성, 성능과 부작용 우려, 합의 중심의 결정 방식, 인력 부족을 함께 지목했다. 따라서 이 사건은 AI의 분석 능력뿐 아니라, 발견한 결함을 실제로 수정·배포할 수 있는 유지보수 체계의 문제이기도 하다.[05]
같은 뿌리, 다른 실패 지점
메모리를 할당하고 해제하는 순서와, 그 메모리를 가리키는 내부 상태의 수명이 어긋난다.
초기화 도중의 중단
PHP는 메모리 부족(OOM) 때 longjmp()로 현재 처리를 빠져나간다. 이때 초기화가 덜 된 요청 데이터가 남으면, 종료 정리 코드가 이를 정상 데이터로 취급해 메모리를 손상시킬 수 있다.
대표 입증: Apache mod_php에서는 앱 코드 실행 전 요청 시작 단계의 RCE가 검증됐다. FPM은 시작 실패 시 자식 워커를 종료해 이 경로가 다르다. 공식 OOM 권고는 FPM의 영향 가능성을 설명하지만 해당 경로의 완전한 FPM 공격 입증은 명시하지 않는다.[02]
이전 요청을 가리키는 상태
요청 메모리를 해제해도 워커의 전역 상태가 옛 주소를 보관할 수 있다. 같은 워커의 다음 요청이 초기화 전에 이를 사용하면, 해제 후 사용(use-after-free)이 발생한다.
대표 조건: 상태를 남기는 동작(producer)과 다음 요청에서 이를 쓰는 동작(consumer)이 필요하다. 세션 수명주기 경로는 mod_php와 FPM에서 검증됐다. FPM 경로에는 정상 시작 후의 앱 동작과 fatal error 조건 등이 관여한다.[03]
‘해제 후 사용’을 책상에 비유하면
방을 비울 때 주소 메모도 함께 지운다. 다음 요청은 새 상태를 만든다.
방 주인은 바뀌었는데 옛 메모를 믿고 들어간다. 잘못된 데이터를 객체처럼 다룰 수 있다.
이해를 위한 비유다. 실제 성립 여부에는 메모리 재사용, 상태 종류, 오류 시점 등이 관여한다.[13]
OOM · 메모리 부족이란?
Out of Memory. 요청 처리에 필요한 메모리를 더 할당하지 못하는 상태다. PHP의 memory_limit 도달과 실제 시스템 할당 실패는 구별해야 한다.
워커 · 요청마다 새로 생길까?
웹 요청을 처리하는 프로세스다. 환경에 따라 같은 프로세스가 여러 요청을 연속 처리하므로, 요청 사이에 남은 상태가 중요하다.
RCE · 무엇을 실행한다는 뜻일까?
Remote Code Execution. 외부 입력을 통해 서버에서 의도하지 않은 코드를 실행시키는 것이다. 획득 권한은 프로세스의 실행 계정에 좌우된다.
공식 CVSS v4.0 벡터에는 사전 권한 불필요(PR:N), 사용자 동작 불필요(UI:N)와 함께 높은 공격 복잡도(AC:H), 추가 실행 조건(AT:P)이 명시된다. ‘비인증’은 ‘어떤 서버든 한 번에 성공’과 다르다.[02][03]
어떤 과정을 거쳐 탈취되는가
각 단계를 눌러 보자. 두 취약점을 하나의 필수 공격 체인으로 묶지 않고, 대표 경로를 나누어 설명한다.
109619: 이전 요청이 상태 게시 → 오류로 초기화 누락 → 메모리 해제·참조 잔존 → 같은 워커의 다음 요청이 접근 → 해제 후 사용·RCE 가능.
대표 stale-state 경로: 이전 요청의 상태 → 오류·해제 후 참조 잔존 → 같은 워커의 다음 요청 → 옛 참조 사용 → 메모리 손상.
코드 실행 없이 비밀정보 노출
연구팀은 PHP 프로세스 메모리를 원격으로 읽는 경로도 시연했다. 메모리에 존재하는 비밀번호, 토큰, API 키 등이 노출될 수 있다. 모든 비밀이 매번 들어 있다는 의미는 아니다.[04]
서버 권한으로 데이터에 접근
RCE가 성공하면 공격자는 PHP 워커 계정이 읽을 수 있는 설정·파일과 연결 가능한 서비스에 접근할 수 있다. DB 자격증명이나 클라우드 권한이 과도하면 피해가 더 커질 수 있다.
권한에 따른 후속 피해를 설명한 분석 예시다. 개별 피해자의 실제 탈취 기록을 뜻하지 않는다.[02][13]
얼마나 넓게 영향을 받는가
설치 범위, 실제 공격 가능 조건, 성공한 침해의 규모는 각각 다른 질문이다.
CMS, 사내 앱, API, 컨테이너, 장비 관리 UI.
패치 버전과 배포판 보안 백포트 적용 여부.
SAPI, 설정, 앱 동작, 워커 재사용 등 조건.
로그·프로세스·포렌식으로 확인해야 할 영역.
NCSC는 오래된 버전에만 한정하지 말고, 인터넷 노출 시스템부터 PHP 설치 전반을 식별하라고 권고한다. 장비·서비스에 내장된 PHP도 조사 대상이다.[08]
CMS 이름이 취약점의 경계는 아니다
Wiz는 WordPress, Drupal, Joomla에서 인증 전 RCE를 시연했다. 이는 PHP 엔진 결함의 파급력을 보여 주는 예시이며, 해당 CMS만 위험하다는 뜻은 아니다.[04]
컨테이너도 런타임을 포함한다
Docker 자체의 보안 결함은 아니지만, PHP가 들어 있는 이미지와 그 이미지로 실행한 앱은 영향을 받을 수 있다. 새 이미지를 가져와 재빌드·재배포해야 한다.[10]
공격 성공 시: PHP 워커 계정
파일 접근권한 · DB 계정 범위 · 네트워크 접근 · 서비스 토큰
피해 상한: 배포 환경의 권한 설계
최소 권한과 격리는 확산을 줄인다. root 권한이나 모든 테넌트 탈취가 자동으로 따라오는 것은 아니다.[13]
약 70%는 연구팀·업체가 PHP의 보급도를 설명한 수치다. 실제 노출·미패치·공격 성공 비율을 측정한 통계가 아니다. 이 리포트는 검증되지 않은 전 세계 피해 건수를 추정하지 않는다.[13]
공격은 관측됐지만, 성공 규모는 별도다
| 1차 관측 출처 | 무엇을 확인했나 | 무엇까지는 알 수 없나 |
|---|---|---|
| AWS · 10/21 공격 시도 | MadPot에서 10/17로 거슬러 올라가는 시도와, 공개 전후 추가 시도를 보고했다.[12] | 해당 시도가 실환경에서 성공했을지는 불명확하다고 명시했다. |
| Cloudflare · 10/21 공격 트래픽 | 고객 대상 공격과, 방어를 우회하려고 페이로드를 바꾸는 동작을 관측했다고 밝혔다.[11] | 트래픽 탐지 건수를 데이터 탈취 성공 건수로 바꿀 수 없다. |
| CrowdStrike · 10/23 관측 한계 명시 | RCE를 자체 재현했으나, 자사 관측에서 성공한 실전 악용이나 광범위한 무기화 공격은 확인하지 못했다고 밝혔다.[13] | 한 업체의 미관측은 전 세계에 침해가 없었다는 증명이 아니다. |
무엇으로 업데이트해야 하나
아래는 두 핵심 CVE에 대한 첫 업스트림 수정 버전이다. 운영 시에는 같은 계열의 최신 보안 릴리스를 확인한다.
| PHP 계열 | 미수정 업스트림 범위 | 첫 수정 버전 | 대응 |
|---|---|---|---|
| 8.5 | 8.5.0 – 8.5.11 | 8.5.12 | 수정 버전으로 업데이트 |
| 8.4 | 8.4.0 – 8.4.26 | 8.4.27 | 수정 버전으로 업데이트 |
| 8.3 | 8.3.0 – 8.3.35 | 8.3.36 | 수정 버전으로 업데이트 |
| 8.2 | 8.2.0 – 8.2.34 | 8.2.35 | 수정 버전으로 업데이트 |
| 5.4–5.6 / 7.x / 8.0–8.1 | 지원 종료 계열도 조사 대상 | 정식 보안 릴리스 없음 | 지원 계열 이전 또는 검증된 공급자 백포트 |
버전표: PHP 공식 공지 · Docker 영향 범위. 두 CVE 중 적어도 하나의 영향이 포함되는 조사 범위이며, 모든 변종이 모든 버전에 존재한다는 뜻은 아니다. 8.6 사전 릴리스는 별도 공지를 확인한다.
PHP 버전 빠른 대조
입력은 이 파일 안에서만 처리한다. 업스트림 버전표와 비교하며, 서버 스캔이나 침해 진단은 수행하지 않는다.
Linux 배포판·LTS 공급자는 예전 버전 번호를 유지하면서 보안 수정만 백포트할 수 있다. 공급자의 CVE 공지와 패키지 변경 기록으로 확인한다. PHP 팀은 7.4·8.0·8.1용 최소 소스 백포트도 제공했지만, 이는 정규 지원 재개와 다르다.[01][09]
PHP는 다음 정기 버그수정 릴리스까지 session.upload_progress.enabled=0을 권고했다. 초기 session.serialize_handler가 php_binary 또는 php_serialize인데, 앱이 런타임에 php로 바꾼 뒤 session_start()를 호출하고 업로드 진행 기능도 켜진 드문 조합에 대한 추가 RCE 경로다.
런타임에 직렬화 핸들러를 바꾸지 않는 앱은 이 후속 경로의 조건에 해당하지 않는다. 별도 CVE-2026-115560의 상세 공지는 다음 릴리스에 예정돼 있다. 두 핵심 CVE의 수정과 이 후속 권고를 구분해 관리해야 한다.[01]
방어는 ‘발견 → 교체 → 검증’
인터넷 노출 시스템을 먼저 처리하고, 내장 PHP와 실행 중인 워커까지 확인한다.
운영자 대응 체크리스트
0 / 6CLI의 PHP와 웹의 PHP는 다를 수 있다
php -v는 CLI 바이너리의 결과다. 웹서버가 다른 PHP 버전이나 ini를 쓰는지, 이전 프로세스가 계속 실행 중인지 확인한다. 공개 phpinfo() 페이지를 만들기보다 접근 제한된 운영 경로로 검사한다.[09]
관리형 서비스도 적용 방식을 확인
자동 패치 여부는 상품·런타임에 따라 다르다. 직접 만든 이미지는 재빌드 책임이 남는다. 호스팅사에는 적용 CVE, 패키지 빌드, 웹 워커 교체 여부를 요청한다.[09][10]
공식 임시 완화를 적용하고 업데이트 시점을 정한다. 완화도 적용하기 어렵거나 지연된다면 노출 중단을 검토하라는 것이 NCSC의 권고다.[08]
체크리스트는 NCSC 권고와 Google Cloud·Mandiant 운영 지침을 바탕으로 정리했다. 체크 상태는 현재 페이지를 열어 둔 동안만 유지된다.
세션·오류 설정
업로드 진행 기능 비활성화는 확인된 세션 경로를 줄인다. PHP 8.5의 fatal_error_backtraces=0은 확인된 backtrace 경로에 한정된다. 요청 파싱 이전 서버 설정에 적용하고 워커를 재시작한다.[03]
OOM 유발 경로 줄이기
공식 OOM 권고는 메모리 한도·요청 크기·입력 구조 제한을 다룬다. memory_limit=-1은 PHP 한도만 없애며 실제 할당 실패를 막지 못한다. 자원 고갈 위험이 있어 격리 한도와 함께 검토한다.[02]
WAF · 원본 서버 제한
WAF는 알려진 공격 패턴을 줄이는 데 도움을 준다. 규칙 적용·차단 모드와 원본 서버 직접 접근을 확인한다. Cloudflare는 요청과 응답을 함께 보는 방어를 배포했지만 PHP 패치를 계속 권고한다.[11]
자주 생기는 오해
긴급하게 대응하되, 확인된 사실과 해석을 구분한다.
PHP-FPM이면 안전한가?
안전하다고 볼 수 없다. mod_php와 FPM은 요청 시작 실패 때의 처리 방식이 다르지만, 다른 세션·앱 경로가 존재한다. 공식 개별 권고와 Foundation 회고는 FPM 입증 범위의 서술에도 차이가 있다. 이 리포트는 경로별 조건을 구분하고, FPM도 업데이트 대상으로 취급한다.[02][03][05]
WordPress만 최신으로 바꾸면 되는가?
PHP 런타임 업데이트가 필요하다. CMS 업데이트 화면과 호스팅의 PHP 관리 화면은 다를 수 있다. 공급자의 PHP 패키지나 컨테이너 이미지가 수정됐고, 실행 중인 서비스에 반영됐는지 확인한다.[10]
로그인·MFA가 있으면 공격을 막는가?
애플리케이션 로그인 이전에 도달할 수 있는 경로가 있다. 따라서 앱의 MFA만으로 런타임 결함이 해결되지는 않는다. 앞단의 네트워크 접근 통제는 도달 가능성을 줄일 수 있지만, PHP 업데이트는 별도로 해야 한다.[02]
공개된 PoC가 있다는 것은 대규모 침해가 확인됐다는 뜻인가?
그렇지 않다. PoC가 크래시만 보여 주는지, 특정 환경의 RCE까지 재현하는지, 실전에서 성공했는지 구분해야 한다. CrowdStrike는 공개 코드 다수가 크래시 검증 수준이며 안정적 RCE로 바꾸는 작업은 별도라고 설명했다.[13]
출처와 조사 기준
공식 보안 권고를 우선하고, 발견팀의 설명과 보안업체의 실제 관측을 구별했다.
- 01PHP · 2026 공식 보안 공지와 릴리스 ↗
10/21 긴급 업데이트, 10/23 Session upload progress 후속 공지. 버전·추가 CVE·설정 권고의 기준.
- 02PHP GHSA · RCE via OOM corruption ↗
CVE-2026-109618. OOM 중단·초기화·종료 처리, SAPI 차이, CVSS와 완화의 한계.
- 03PHP GHSA · RCE via stale global state ↗
CVE-2026-109619. producer/consumer, 동일 워커·요청 간 참조, 세션·오류 경로.
- 04Wiz · PHP2Shell 연구 원문 ↗
2026.10.21. 독립 발견, AI 도구, CMS RCE 및 메모리 노출 시연. 성과 설명은 연구팀의 주장으로 읽었다.
- 05PHP Foundation · 보안 릴리스 회고 ↗
2026.10.21. 2024년 인지, 수정 지연과 조직 문제, 연구 보고, 공개 일정 변경의 경위.
- 06Calif · php2shell 연구 기록 ↗
가설과 역사적 단서, AI 보조 분석, 7~8월 감사·보고·검증 일정.
- 07OpenAI · Patch the Planet 공동 대응 ↗
2026.10.21. Calif의 GPT-5.6 Sol 사용, PHP 주도 수정, 공개 전 방어 준비와 조정.
- 08영국 NCSC · Critical security issue affecting PHP ↗
2026.10.21. 자산 조사·노출 우선 대응·임시 완화·오프라인 전환·침해 확인 권고.
- 09Google Cloud · 대응 및 Mandiant 운영 지침 ↗
10/21 게시, 10/23 PDT 추가 업데이트. 워커 재시작, 메모리 증거, 런타임 재배포와 클라우드 적용 범위.
- 10Docker · PHP2Shell 고객 영향과 업데이트 ↗
2026.10.22. PHP 5.4 이후 영향, 이미지 업데이트, 재빌드·재배포 책임.
- 11Cloudflare · WAF 방어와 공격 관측 ↗
2026.10.21. 요청·응답을 함께 보는 탐지, 공격 변형 관측, 패치 병행 필요.
- 12AWS · MadPot의 공개 전 공격 시도 ↗
2026.10.21. 10/17 및 공개 전후 공격 시도 관측. 실환경 성공 여부는 불명확하다고 명시.
- 13CrowdStrike · 실전 악용의 조건과 관측 한계 ↗
2026.10.23. RCE 재현, 공개 PoC 평가, 성공한 실전 악용의 미관측 및 조사 지표.
표현 기준: 코드·도식은 이해를 위한 재구성이다. 공격 페이로드나 재현용 공격 코드는 싣지 않았다. 후속 피해는 조건부 가능성으로 설명하고, 실제 침해 건수와 혼동하지 않았다. PHP Foundation의 FPM RCE 서술과 개별 GHSA의 경로별 입증 범위 차이도 반영했다.
파일 구성: CSS·JavaScript·SVG를 이 HTML 안에 포함했다. 외부 폰트·이미지·CDN·분석 스크립트를 불러오지 않는다. 외부 출처는 링크를 눌렀을 때 열린다.
댓글 0
불러오는 중…