[특집] PHP2Shell 사흘의 기록 — AI가 바꾼 취약점의 속도, 유출된 엠바고, 그리고 지금 서버 운영자가 할 일

이 글이 다루는 것, 다루지 않는 것

2026년 10월 21일, PHP 프로젝트가 엔진 자체의 치명적 취약점 두 건(CVE-2026-109618, CVE-2026-109619)의 수정판을 냈습니다. 별칭은 PHP2Shell. 이 글은 사건의 경과와 대응, 숫자의 해석, 운영자가 할 일을 다룹니다.

결함이 메모리에서 정확히 어떻게 어긋나는지는 쓰지 않습니다. 공개 직후라 아직 패치되지 않은 서버가 많고, 공격 시도가 계속되고 있기 때문입니다. 그 부분은 시간이 지난 뒤 Wiz와 Calif의 원문, PHP 공식 권고를 직접 보시길 권합니다. 방어에 필요한 수준의 설명은 아래 "한 문단으로 이해하는 결함"에 넣었습니다.

한 문단으로 이해하는 결함

PHP는 요청 하나를 받을 때마다 메모리를 빌려 쓰고 끝나면 반납합니다. 그런데 요청 처리 도중 메모리 상한(memory_limit)에 걸리거나 치명적 오류가 나서 작업이 중간에 끊기면, 정리가 덜 끝난 흔적이 남을 수 있습니다. 같은 작업 프로세스가 다음 요청을 처리할 때 그 흔적을 정상 값으로 믿고 쓰는 것이 문제입니다. 그래서 응용 프로그램 코드가 안전해도 소용이 없습니다. PHP 재단은 이것이 "메모리 관리와 오류 처리라는, 거의 모든 요청이 지나가는 곳"에 있어 고치기 어려웠다고 설명합니다. 이 정도가 공식 권고가 공개한 수준이고, 이 글도 여기까지만 씁니다.

사흘의 기록

시각은 모두 UTC입니다. 출처는 PHP 재단 블로그, php.net 공지, Amazon Threat Intelligence, Cloudflare, ELLIO입니다.

1부 · 왜 22년 동안 고쳐지지 않았나

2004년의 경고와 2024년의 "서비스 거부"

Calif의 연대기에 따르면 이 계열의 문제는 2004년 슈테판 에서의 공개 경고까지 거슬러 올라갑니다. 그 뒤 2020년에 관련 버그가 보고됐고, 2024년 첫 외부 감사에서 같은 부위의 문제가 다시 나왔습니다.

감사에 참여했던 전 Quarkslab 감사원의 글(Tolmo)이 이 대목을 솔직하게 적었습니다. 그들은 문제를 서비스 거부(DoS) 로 분류해 보고했습니다. 서버를 쓰러뜨릴 수 있다는 점은 맞았고, 쓰러지고 남은 흔적이 어떤 결과로 이어지는지는 따라가 보지 않았다는 것입니다. CVE 번호가 2024년에 배정됐지만 2026년 공개 당일까지 공개되지 않았습니다.

PHP 재단도 같은 이야기를 합니다. 해결책 후보가 여럿 있었지만 각각 호환성 파괴, 새로운 서비스 거부 가능성, 수많은 서드파티 확장 수정이라는 대가가 있었고, 합의제로 운영되는 보안팀이 결정을 못 내리는 사이 작업이 몇 달씩 멈췄다 재개되기를 반복했습니다. 재단은 이를 "구조적 실패"라고 부릅니다. 눈에 띄는 대목은 이것입니다.

"우리는 그렇지 않은 척하지 않겠다. 이 지연은 보안팀의 의사결정 방식과 자원 부족이 함께 만든 구조적 실패였다." — PHP 재단 블로그 (2026-10-21, 요지)

교훈은 "AI가 갑자기 새 결함을 만들었다"가 아닙니다. 오래된 결함이 '이론상 위험'에서 '입증된 위험'으로 넘어가는 문턱이 낮아졌다는 것입니다. 그 문턱이 우선순위를 가르는 기준이었기 때문에, 기준 자체가 흔들렸습니다.

2부 · AI가 바꾼 것은 발견이 아니라 '입증의 비용'

Wiz는 "한 명의 연구자가 일주일에 해낸 일이 예전에는 세계적 수준 팀의 몇 달 작업이었다"고 주장합니다. 모델은 Wiz Atlas(자체 취약점 연구 에이전트), Gemini 4 Argon, GPT-5.6 Sol을 썼다고 밝혔습니다. 구글 딥마인드의 보안 책임자는 Argon이 "발견, 공격 검증, 탐지, 수정 검증"에 기여했다고 말했습니다.

같은 날 나온 반론

이 서사에는 반론도 만만치 않습니다. 코어닷투데이가 확인한 것만 정리하면 다음과 같습니다.

• "새 발견이라기보다 오래전 기록의 재조합": 2004년 경고, 2020년 버그, 2024년 감사 기록이 이미 있었다는 점에서, 모델이 훈련 데이터에서 본 이력을 따라간 것일 수 있다는 지적(익명 블로그 deadneurons).
• Calif 본인의 설명이 가장 흥미롭습니다. 연구자는 특별한 도구나 비공개 모델 없이 공개된 모델을 썼다고 하면서, 모델은 기본 상태에서 "가장 최신이고 눈에 띄는 버그에서 인근 오래된 코드로" 움직이지, "20년 된 모호한 기법에서 출발하지 않는다"고 적었습니다. 그래서 대상의 취약점 이력을 아는 사람이 방향을 줄 때 성과가 났다는 것입니다. "대상을 알아야 한다"는 원칙은 AI 시대에도 유효하다는 결론입니다.
• Wiz와 OpenAI 모두 상업적 이해관계가 있다는 점도 지적됩니다(영국 BISI 분석, Latent Space).

저는 이 논쟁에서 "AI가 한 일"을 둘로 나눠 보는 편이 정확하다고 봅니다. 하나는 후보를 찾는 일, 다른 하나는 후보가 실제로 되는지 환경마다 맞춰 가며 입증하는 일입니다. Wiz 글이 강조하는 것은 뒤쪽입니다. 앞쪽은 이미 사람도 오래 해 온 일이고, 뒤쪽이 비싸서 우선순위가 밀렸던 것입니다.

크게 보기

3부 · 비밀이 새는 데 걸린 시간

조율된 공개가 설계대로 간 구간

조율된 공개(coordinated disclosure)는 발견자가 유지보수자에게 먼저 알리고, 수정이 준비될 때까지 대중에게는 비밀로 하다가 같은 날 함께 공개하는 관행입니다. 이번에는 이것이 규모 있게 작동했습니다. 클라우드·CDN·호스팅 업체가 공개 전에 방화벽 규칙을 배포했고(Cloudflare는 공개 약 9시간 전), 배포판은 수정 패키지를 미리 받았습니다.

크게 보기

OpenAI는 이 과정을 5단계로 제안합니다. 수정·검증, 영향받는 조직에 시간 주기, 정부와 조율, 제품별 업데이트 준비, 공개 후 배포 지원입니다. 미국에서는 ONCD와 CISA, 영국에서는 NCSC가 사전에 브리핑을 받았고, 영국 NCSC는 5만 건의 경고를 보냈다고 상원에서 답변했습니다.

이틀 전에 깨진 부분

PHP 재단의 기록에 따르면 공개 이틀 전인 10월 20일 15시경 CVE 번호 두 개가 온라인에 돌기 시작했습니다. 시각도 점수(10.0)도 틀렸습니다. PHP는 사전 예고를 당겨 발표하고 공개일을 하루 앞당겼습니다. 이어 발견자인 Calif가 개념 증명 영상을 실수로 올렸다가 지웠고, 사본이 퍼졌습니다. 영상이 개념 증명 제작을 앞당겼다는 것이 재단의 평가입니다.

그리고 공개 6시간 전, Chainguard가 수정이 포함된 이미지를 먼저 게시했습니다. 재단은 이를 "몇 주에 걸친 조율을 무시한" 일방적 엠바고 파기로 규정했습니다. Chainguard 측은 실제 공격이 이미 나타나 일찍 내보냈다고 설명했고, 커뮤니티에서는 공방이 이어졌습니다. 한 가지 사실은 짚어 둡니다. 수정이 이미지 형태로 공개되면 변경 내용을 살펴볼 수 있게 되므로, 앞당긴 배포는 방어자에게 시간을 주는 만큼 다른 쪽에도 주는 양날입니다.

아마존의 미끼 서버가 본 것

"아마존의 모의 운영"으로 알려진 부분은 정확히는 MadPot, 아마존이 운영하는 미끼 서버 네트워크(허니팟)입니다. 일부러 허술하게 보이는 서버를 세계 곳곳에 두고 그곳으로 들어오는 시도를 기록합니다. Amazon Threat Intelligence가 쓴 글의 요지는 이렇습니다.

크게 보기

• 10월 17일: 상업용 익명화 네트워크의 IP 한 곳에서 첫 시도가 한 건 기록됐습니다. 아마존은 "엠바고 중에 익명화 IP가 미끼를 노렸다는 것은 공격자의 활동을 시사하지만, 그 사람이 어떻게 정보를 얻었는지는 불분명하다"고 썼습니다. (The Hacker News는 아마존 대변인이 '대체로 일회성 탐색'이라 했다고 전합니다.)
• 10월 21일 02시~08시: 첫 개념 증명이 돌기 시작했고, 다른 익명화 인프라에서 시도가 더 잡혔습니다. 페이로드가 제각각이라 여러 주체로 보이지만, "실제 환경에서 통했을지는 불분명"하다고 합니다.
• 공개 뒤에는 "광범위한 공격 시도"가 관측됐다고 씁니다.

아마존이 끌어낸 교훈은 세 가지입니다. ① 엠바고는 다른 누군가가 같은 결함을 찾을 때까지만 방어자를 보호한다. ② 패치에서 작동하는 공격 코드까지의 시간은 구조적으로 줄고 있다. 패치 차이나 권고문에서 공격 코드를 만드는 데 드는 비용을 AI가 낮췄기 때문이다. ③ 그러므로 7일·30일짜리 패치 기준은 "더는 없는 지연"을 전제하고 있다. 아마존은 시간 단위로 재고, 조사도 공개일이 아니라 10월 17일부터 시작하라고 권합니다.

다만 아마존 자신도 그 시도들이 성공했을지는 모른다고 썼고, 아마존 리눅스 2023의 수정 패키지가 공개 약 하루 뒤(22일)에야 나와 깃허브 이슈에서 거센 비판을 받았다는 점도 같이 기록해 둡니다.

4부 · 숫자는 어떻게 읽어야 하나

"웹사이트의 70%"라는 문구가 곳곳에 나왔습니다. 출처를 따라가면 이 숫자는 W3Techs가 집계한, 서버 쪽 언어가 파악된 사이트 중 PHP 사용 비율(69.3%, 10월 24일 확인) 입니다. 이 숫자는 "PHP를 쓰는 사이트의 비율"이지 "공격에 노출된 사이트의 비율"이 아닙니다. 영국 BISI는 "70%가 위협받는다는 주장은 모든 PHP 사이트를 공격 가능한 것으로 취급하며, 현재 증거는 이를 뒷받침하지 않는다"고 썼고, BBC도 이 수치를 검증할 수 없다고 적었습니다.

세 가지를 구분하면 숫자가 정리됩니다.

1. PHP를 쓰는가: 약 70%. 위험의 상한일 뿐입니다.
2. 취약한 버전인가: 5.4부터 8.5.11까지 전부 영향권이지만, 수정판이 나온 것은 8.2~8.5뿐이라 8.1 이하는 "수정판 없음"입니다. 공개 전날 Modat는 노출된 PHP 서비스의 79%가 이미 지원 종료 버전이라고 집계했습니다.
3. 실제로 뚫리는가: 이것이 가장 불확실합니다. 심각도 점수만 해도 PHP는 CVSS v4 9.2, 미국 NVD는 3.1 기준으로 9.8과 8.1, 레드햇·아마존 리눅스는 8.1, 유출본은 10.0이었습니다. 공격 복잡도를 높게 보느냐 낮게 보느냐의 차이입니다.

겁낼 것과 따져 볼 것

공개 직후 두 진영이 갈렸습니다.

크게 보기

• 경계 쪽: Cloudflare는 공개 전 10시간 동안 수천 건, 공개 45분 안에 수만 건, 2시간 안에 수십만 건의 시도를 봤고 공격자가 우회를 위해 페이로드를 바꾼다고 밝혔습니다. 영국은 32개 정부 서비스를 내렸고, 한국은 과기정통부가 민간 분야 사이버위기 경보를 '관심'에서 '주의'로 올렸습니다.
• 신중 쪽: ELLIO의 관측으로는 초기 페이로드 대부분이 미완성이었고, watchTowr·Huntress·CISA는 확인된 성공 사례가 없다고 했습니다. Sansec은 공개된 개념 증명 다수가 기본 설정 PHP에서는 동작하지 않는다고 평가했고, 한 개발자는 깃허브에 쏟아진 수천 개의 "PoC"를 직접 돌려 보라며 대부분이 제대로 동작하지 않는다고 썼습니다.

두 진영의 사실이 모두 맞습니다. 그래서 결론은 "성공 사례가 아직 없다"는 보고가 "안전하다"는 뜻은 아니라는 것입니다. 성공이 확인되지 않은 것과 성공이 없었던 것은 다르고, 시도 자체는 실재하며, 공개된 도구는 계속 개선됩니다. 믿을 만한 PoC를 받았다는 업체도 있습니다. 동시에 출처가 불분명한 PoC는 직접 돌리지 말라는 KISA의 당부도 중요합니다. 가짜 PoC에 악성코드가 실려 유포된 사례가 JFrog 등에서 보고됐습니다.

큰 사건들과 나란히 놓으면

하트블리드(2014)·로그4셸(2021)과 비교하는 시각이 많았습니다. 그러나 이번 사건은 "누구나 요청 한 줄로 당하는" 유형이 아니라는 점에서 앞선 사건과 결이 다르다는 평가가 우세합니다. 반대로 비슷한 점은 방어자가 자기 자산을 목록으로 갖고 있지 않았다는 것입니다. 로그4셸이 "내 서비스 어디에 이 라이브러리가 들어 있지?"를 물었다면, PHP2Shell은 "내 장비 어디에 PHP가 들어 있지?"를 묻습니다. 관리 화면에 PHP가 내장된 장비, 외주로 만든 오래된 사이트, 도커 이미지, 이벤트용 임시 서버가 그 대상입니다. 영국 NCSC 같은 곳의 제품 목록에도 방화벽 장비와 이메일 서버가 이미 올라 있습니다.

5부 · 누가 어떻게 막았나

크게 보기

유지보수자라는 병목

가장 오래 남는 대목은 PHP 재단의 호소일지 모릅니다. 재단은 이렇게 썼습니다. 도구는 버그를 더 빨리 찾지만, 오래된 설계 결정에 대해 올바른 수정을 정하고, 호환성을 따져 패치를 검토하는 일은 도구가 못 한다. 그런 결정을 내릴 수 있는 엔진 전체를 아는 엔지니어는 너무 적다는 것입니다. 보안팀은 7월 1일 이후 15건의 CVE를 냈고 무효·중복·재현 불가로 판명된 신고 100여 건을 처리했습니다. AI 덕에 신고량이 늘었다는 뜻입니다.

크게 보기

OpenAI는 Codex for OSS와 Patch the Planet 지원, 취약점 발견 후 대응 틀의 제안으로 응답했습니다. 다만 "발견은 AI가, 수정은 소수의 사람이"라는 비대칭은 구조적으로 남아 있습니다.

6부 · 운영자 점검표

공식 자료(php.net 공지, KISA 대응 수칙, Cloudflare·Google·AWS 문서)에서 공통으로 나오는 항목만 순서대로 정리했습니다.

1. 내 PHP부터 찾는다. 자산 대장이 아니라 실제 떠 있는 서버 기준으로 봅니다. 외주 사이트, 방치된 이벤트·테스트 서버, 관리자 페이지, PHP가 내장된 장비, 외부에서 가져온 컨테이너 이미지가 대상입니다.
2. 수정판으로 올린다. 8.2는 12월 31일에 지원이 끝나므로 KISA는 8.3 이상을 권합니다. 8.1 이하는 배포판·LTS 업체의 백포트 여부를 확인합니다.
3. 재시작한다. 설치만 하고 작업 프로세스를 재시작하지 않으면 메모리에 남은 옛 버전이 계속 돌아갑니다. 컨테이너는 새 이미지로 다시 배포합니다. 서버에서 php -v로 본 버전과 웹 서비스가 실제로 쓰는 버전이 다를 수 있으니 웹 서비스 쪽에서 확인합니다.
4. 당장 못 올린다면 보조 조치를 겹친다. 방화벽(WAF) 규칙, 요청 크기·업로드 제한, php.net 공지가 적은 임시 설정입니다. 모두 "완전하지 않다"고 명시돼 있습니다. 외부 접속 차단이나 일시 중단도 선택지입니다.
5. 10월 20일 이후 로그를 본다. 비정상적으로 큰 요청, 반복되는 500 오류·메모리 부족, 이유 모를 PHP 프로세스 재시작, 웹 서버가 셸이나 다운로드 도구를 실행한 흔적, 새로 생기거나 바뀐 PHP 파일, 외부로 나가는 알 수 없는 연결이 신호입니다. 아마존은 시작 시점을 10월 17일로 잡으라고 권합니다.
6. 인증정보를 바꾼다. 서버 메모리의 비밀번호·토큰·API 키가 노출될 수 있으므로 로그가 깨끗해도 DB 비밀번호, 외부 연동 키, 관리자 계정을 교체합니다(KISA).
7. 침해 정황이 있으면 끄지 않는다. 재시작하면 증거가 사라지므로 외부 연결을 먼저 막고 로그·프로세스·네트워크 정보를 확보한 뒤 KISA 보호나라에 신고합니다.
8. 출처 불분명한 PoC를 직접 돌리지 않는다. 버전과 기록으로 판단합니다.
9. 세 번째 번호도 챙긴다. CVE-2026-115560은 10월 21일 수정판에도 남아 있고 다음 정기 릴리스에서 고칩니다. 업로드 진행률 기능을 끄는 설정이 권고돼 있습니다.

7부 · 2026년의 의미

세 가지로 정리하겠습니다.

첫째, "발견되지 않은 결함"이라는 방어선이 약해졌습니다. 과거에는 복잡해서 아무도 시도하지 않는 결함이 사실상 안전 장치였습니다. 입증의 비용이 낮아지면 그 장치가 사라집니다. Wiz의 표현대로 복잡성이 더는 의미 있는 장벽이 아닐 수 있습니다.

둘째, 방어의 시간 단위가 바뀝니다. 아마존의 권고처럼 패치 기준을 "7일"에서 "시간"으로 줄여야 하는 곳이 늘 것입니다. 그러려면 자산을 알고, 재배포가 빠르고, 재시작이 두렵지 않은 체계가 필요합니다. 이번 사건의 가장 현실적인 교훈은 AI가 아니라 재배포 속도와 자산 가시성입니다.

셋째, 병목은 사람입니다. 발견도 입증도 자동화되는 시대에 수정은 여전히 호환성과 설계를 아는 소수의 몫입니다. PHP 재단이 후원을 호소한 이유이고, OpenAI가 유지보수자 지원을 내건 이유입니다.

코어닷투데이는 앞서 AI가 취약점을 스스로 찾기 시작했다, Gemini 4 Argon 모델 카드 정독에서 이 흐름을 다뤘습니다. 이번 사건은 그 예측이 실제 인프라 규모로 확인된 첫 사례에 가깝습니다. 아직 모르는 것도 많습니다. 공개 전 시도가 실제로 어떤 주체에게서 나왔는지, 성공한 침해가 있었는지는 이 글을 쓰는 10월 24일 기준으로 확인되지 않았습니다.

참고 자료

• Wiz Research, "PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet" (2026-10-21)
• Wiz, "Atlas: Wiz's autonomous AI Agent for vulnerability research" (2026-07-27)
• Calif Research, "php2shell" (2026-10-23 확인) — 연대기와 발견 과정
• OpenAI, "Patch the Planet: global response coordination as agents uncover critical vulnerabilities"
• The PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security" (2026-10-21)
• php.net 뉴스 2026 — 보안 공지(10-20, 10-21), 정보성 권고(10-23)
• Amazon Threat Intelligence, "PHP2Shell exploitation prior to public disclosure in MadPot" (2026-10-21); AWS 보안 공지 2026-143-AWS; AWS WAF 글
• Cloudflare, "Cloudflare deploys protections against php2shell vulnerability"; Google Cloud, Vercel, Akamai, Imperva 대응 글
• Tolmo, "We can now find flaws faster than anyone can fix them"
• ELLIO, VulnCheck, Sansec, watchTowr, UK BISI 분석, Elias Taylor — 초기 관측과 회의론
• The Register, BBC, The New Stack (엠바고 논쟁), ZDNet Korea, 바이라인네트워크
• KISA 보호나라 「PHP 제품 보안 업데이트 권고」「PHP2Shell 관련 기업 보안 대응 수칙」(2026-10-21·22), 「CVE-2026-115560 임시 조치」(10-24)