2026 년 10 월 21 일 밤, 일본의 인터넷 서비스들이 차례로 '긴급 유지보수'에 들어갔다. 온라인 쇼핑몰, 유치원용 앱, 은행, 철도, 지자체. 같은 밤, 런던과 암스테르담에서도 정부 웹사이트들이 조용히 사라져 있었다.
누군가 해킹당했을까? 그렇지 않다. 오히려 그 반대의 경우다. 아무 일도 일어나지 않은 채로 세계의 관리자들이 스스로 문장을 닫아버린 것이다.
이 사고의 직접적인 원인은 PHP 프로그래밍 언어의 핵심 부분에 발견된 두 가지 중대한 취약점, 즉 별칭 'PHP2Shell'으로 불린 것이었습니다. 본 기사는 각 기업의 공식 발표, 각국 정부의 권고, 그리고 현장 보도를 종합하여 무엇이 발생했는지, 그리고 아직 밝혀지지 않은 것이 무엇인지 가능한 한 쉽게 정리해 드립니다. 전문 용어는 발생 즉시 설명을 덧붙입니다.
책을 읽은 뒤 다시 처음부터 다시 읽게 될 것이다. 처음의 "누군가가 해킹당했는가"라는 질문에 대한 답이 마지막에는 조금 다르게 보이기 때문이다.
먼저 결론부터 말씀드리면, 알 수 있는 점과 아직 알 수 없는 점입니다.
알아낸 사실
- 결함은 PHP 의 '에러 발생 시 후속 조치'에 있으며, 로그인 없이 원격 조작으로 이어질 수 있습니다. 수정 버전은 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 입니다.
- 근본적인 문제는 2004 년경의 연구, 2020 년 보고서, 2024 년 외부 감사까지 거슬러 올라가지만, 실제로 공격 가능한 형태로 만든 것은 2026 년 여름에 AI 를 활용한 조사였습니다.
- 비밀유지계약 (엔버고) 이 공개 2 일 전에 무너졌고, 발표는 1 일 일찍 연기되었습니다.
- 방어 기업의 대응 방식은 전원이 자동으로 방어망을 구축하는 방식, 고객이 선택하는 방식, 침입 후 대응하는 방식으로 구분됩니다.
- 각국 정부는 동시 다발적으로 경고하며 "수리가 안 된다면 즉시 중단해야 한다"고 명확히 밝혔다.
아직 알지 못하는 것들
- 실제로 몇 건이 침입되었는지 (공식적으로는 아직 확인된 대규모 성공 사례는 없다).
- 공표 4 일 전의 공격 시도에서 정보가 어디서 유래했는지.
- 정보 유출의 기원이 정확히 어디에서 시작되었는지.
- AI 의 기여도가 각 회사의 설명처럼 결정적인 지점까지 도달했는지에 대한 의문.
목차
- 먼저 결론부터 말씀드리면, 알 수 있는 점과 아직 알 수 없는 점입니다.
- 제 1 장 멈춘 밤: 무엇이 일어났는가
- 제 2 장 PHP2Shell 을 '요리실'로 비유한다면
- 용어 미니사전
- 제 3 장 10 년 동안 잠들어 있던 버그를 AI 가 발생시켰다
- 제 4 장 약속이 무너진 이유: 엔버고의 72 시간
- 제 5 장 방어 기업의 '유가'의 차이
- 클라우드flare: 모든 사용자에게 우선 자동으로
- Fastly: 고객에게 선택권을 부여하다
- 아카마이: 규칙과 질서
제 1 장 멈춘 밤: 무엇이 일어났는가
PHPは、ウェブサイトの裏側で動く言語である。W3Techsの集計では、サーバー側の言語が分かるサイトの約7割がPHPを使っていると伝えられている（宮野宏樹氏のnote、Wizのブログ）。WordPressもDrupalもJoomlaもWikipediaのMediaWikiも、PHPの上で動く。
PHP 개발 팀은 10 월 20 일 두 가지 중대한 취약점의 수정 버전을 발표할 것이라고 예고했습니다. 원래 발표 예정일은 10 월 22 일 오후 2 시 (UTC) 였으나, 정보 유출로 인해 발표가 10 월 21 일 오후 2 시 (UTC, 일본 시간 23 시) 에 앞당겨졌습니다. 실제 수정 버전은 예고된 시간 직전에 발표되었다는 보도가 있습니다 (IT Daily (독일)).
그 기간 동안 일본에서는 IPA 가 10 월 21 일 일자에 사전 경고를 발표하여 PHP 를 사용하는 경우 재고 관리와 공개 직후 바로 해결할 수 있도록 준비할 것을 요구했습니다. 같은 문서에서 IPA 는 자신들이 악용된 공격을 확인하고 있다고는 명시하지 않았습니다.
국내 보안 대응 현황은 보안 실험실의 정리에서 명확히 드러나 있습니다. BASE, 컬러미샵, 사쿠라 인터넷 등이 긴급 유지보수에 들어갔으며, 쿠사나기 (KUSANAGI) 는 수정 버전 패키지를 배포했습니다. 다만 해당 페이지는 단순한 서비스 정지 사실만으로는 공격 피해나 정보 유출이 발생했음을 단정할 수 없다고 명시하고 있습니다. 이 구분은 본 기사의 내용을 더 읽어나가는 데 있어 중요한 전제 조건이 됩니다.
제 2 장 PHP2Shell 을 '요리실'로 비유한다면
전문 용어를 쓰지 않고 작동 원리를 설명해 보겠습니다.
PHP 는 주문을 받아 요리를 만드는 주방이라고 생각하세요. 한 명의 요리사가 차례로 들어오는 주문을 같은 주방에서 처리합니다.
일반적으로 코크는 조리 작업을 마친 후 도구를 정리하고 다음 고객용 작업대를 비웁니다. 그러나 PHP 는 '조치할 수 없는 상황'이 발생했을 때 정리를 하지 않고 비상출구로 뛰쳐나가는 구조를 가지고 있습니다. 메모리 (작업대) 가 부족해진 경우가 대표적인 예입니다. Fastly 의 설명에 따르면 이跳出은 longjmp() 메커니즘을 통해 이루어지며, 메모리 한계 초과, 실행 시간 초과, 연결 단절 등 일상적으로 발생하는 오류에서도 사용된다고 합니다 (Fastly 블로그).
문제는 바로 '점프 후'라는 시점이다. 완성되지 않은 요리나 이미 버려야 할 재료의 '지시 카드'가 작업台上에 남아있는데, 다음 주문을 받을 때 요리사가 그 카드를 믿고 행동하게 된다. 카드가 가리키는 곳에 공격자가 교체해 둔 내용이 있다면 요리사는 공격자가 말한 대로 움직이게 된다. 이것이 Wiz 가 기술 설명에서 언급한 '해제된 메모리의 재사용'에 해당한다 (Wiz).
그리고 이 결함은 요리사의 솜씨 (앱 코드라면) 보다 더 초기 단계, 주문 영수증을 읽는 단계에서 발생합니다. 아무리 꼼꼼하게 만든 사이트라 해도, 방어 체계가 작동하기 전에 문제가 해결되어 버립니다. 네덜란드의 NCSC 가 스스로 사이트를 중단한 이유도 바로 여기에 있습니다 (Techzine).
용어 미니사전
- 원격 코드 실행 (RCE): 멀리 떨어진 곳에서 상대방의 컴퓨터에서 원하는 명령을 실행하는 것.
- CVE 는 취약점에 대한 세계 공통 식별자입니다. 이번에는 CVE-2026-109618 과 CVE-2026-109619 입니다.
- CVSS: 심오함을 나타내는 점수입니다. 공식 점수는 10 점 만점 중 9.2 점이며, 확산된 '10.0'은 오류였습니다 (PHP 개발 팀 내부 설명).
- WAF/가상 패치: 사이트의 입구에 설치하는 검문소. 실제 수리 (패치) 가間に合わない 경우, 임시로 판을 치는 듯한 방어 수단이다.
- EDR: 서버 내부의 감시자. 침입 후의 이상한 움직임을 탐지합니다.
- ASLR: 프로그램이 사용하는 메모리 주소를 매번 섞는 기법입니다. 마치 매번 다른 통로로 이어지는 미로와 같습니다.
- 엔버고/TLP: 수정이 완료될 때까지 상세 내용을 숨기는 약속과 그 공유 규칙.
제 3 장 10 년간 잠들어 있던 버그를 AI 가 발생시켰다
이 결함은 갑자기 발생한 것이 아닙니다.
칼리프 (보안 기업) 의 기록에 따르면, PHP 의 메모리 한계와 관련된 원격 취약점은 2004 년 스테판 에셔가 처음 지적했고, 2020 년에도 유사한 버그가 발견되었습니다. 2024 년 OSTIF 와 Quarkslab 의 외부 감사에서 동일한 문제를 재발견했으나, 실제 공격 가능한 증거는 없었습니다 (Unite.AI 요약, 칼리프). PHP 파운데이션은 이 기간 동안의 수정 지연을 '구조적 실패'로 인정했습니다 (PHP 파운데이션).
상황이 바뀌었던 것은 2026 년 여름이었다.
- 7 월 30 일: 칼리프가 감사 개시를 결정했습니다.
- 8 월 11 일: 칼리프와 오픈AI 가 각각 독립적으로 동일한 근본 원인을 보고했습니다.
- 8 월 19 일~24 일: 위즈가 별도의 경로를 통해 발견하여 Drupal 과 WordPress 에서의 공격 성공을 확인하고, 24 일에 보고했습니다.
캘리포니아의 라이언 오스틴이 오픈AI 의 GPT-5.6 솔을 활용하여 발견한 사실과 Wiz 가 자체 분석 인프라에 더해 Gemini 4 Argon 과 GPT-5.6 Sol 을 사용했다는 점은 각 기업이 공표한 내용 (Wiz 와 오픈AI 의 발표를 보도한 기사) 입니다. Wiz 는 한 연구자가 약 일 주 만에 완료한 작업을, 과거에는 최상위 팀이 수 개월 걸어야 할 수작이라고 설명했습니다.
여기서 가장 중요한 점은 AI 가 변화시킨 것이 '발견'이 아닌 '실용화 장벽'이라는 점입니다. 메모리의 결함은 존재한다고 알려져 있더라도, 실제로 작동하는 공격으로 만들기 위해서는 방대한 시행착오가 필요합니다. Wiz 는 AI 가 환경별 조정과 실패 분석을 대신함으로써 그 장벽이 낮아졌다고 설명합니다.
다만, 냉철한 관점도 함께 제시해 두겠습니다.
- 조사 방향이 연구자의 지시에 따라 정해졌다는 정리도 있다 (SmartScope).
- PHP Foundation 은 AI 가 보고서의 검증과 정리를 지원하지만, 최종 판단과 수정은 인간이 수행한다고 밝혔습니다 (MLex 가 전한 성명서).
- 게시판에는 "AI 의 성과로 홍보되고 있으나 실제로는 인간의 분석이 결정적이었다"는 반론도 제기되고 있습니다 (Hacker News 의 토론을 요약한 페이지. 검증 필요).
"AI 가 찾았다"라는 표현은 절반은 정확하고 절반은 단순화한 것입니다. 이 점은 나중에 '아직 알지 못하는 것'에서 다시 다룰 것입니다.
제 4 장 약속이 무너진 이유: 엔버고의 72 시간
이 부분이 바로 이 사건의 가장 중요한 포인트입니다.
취약성이라는 세계에는 '발견자는 수정이 완료될 때까지 침묵한다'는 약속이 있습니다. 이번에도 PHP Foundation, OpenAI, Calif, Wiz, 클라우드 기업, CDN 기업, 그리고 각국 정부가 약 2 개월을 준비했습니다. 영국 NCSC 는 의회에서 정부 장관이 답변한 바에 따르면, 공개 발표 약 1 주日前에 OpenAI 에서 설명을 들었습니다(The Register).
그 약속은 짧은 시간 만에 무너졌다. PHP Foundation 의 설명에 따르면, 10 월 20 일 오후 3 시 (UTC) 경에 2 개의 CVE 번호가 게시판과 SNS 에 유출되었다. 공개 시간과 점수 10.0 이 붙은 정보가 잘못 전달된 것이다. 기술적 세부 사항은 누설되지 않았으나, PHP 는 예고 시간을 앞당겨 오후 7 시 30 분에 발표하고 공개일을 10 월 21 일로 앞당겼다. 또한 오후 8 시 경, Calif 가 자신의 공격 데모 영상을 실수로 공개해버렸다 (Simon Willison 의 요약, Unite.AI).
그리고 10 월 21 일 7 시 41 분 (유니버설 시간 기준, 일본 시간 기준 16 시 41 분) 에 컨테이너 기업 체인가드가 공식 발표보다 6 시간 이상 일찍 수정된 이미지를 공개했습니다. PHP 재단은 이를 '일방적으로 약속을 위반한 것'으로 비난했습니다(The Register). 체인가드의 공동 창업자 뤼앙 로렌스氏の 견해는 다릅니다. 이미 여러 회사가 '실제 공격을 목격했다'고 밝힌 바 있으므로, 고객을 보호하기 위해 행동한 것이라고 주장했습니다(The New Stack).
어떤 것이 옳은지. 사실, 이 부분은 아직 결론이 나지 않았습니다. 관측 회사 ELLIO 가 첫 번째 공격 요청을 확인한 것은同日 8 시 36 분 (UTC) 으로, Chainguard 의 공개로부터 1 시간 채 되지 않은 때였습니다(The Hacker News). 시간은 가깝지만 인과 관계는 아직 증명되지 않았습니다.
아카메이는 10 월 22 일 'TLP 는 제안이 아니다 (TLP 는 제안이 아니다)'라는 긴 글을 공개했습니다. 구체적인 이름을 언급하지는 않았지만, '확인하다', '재현하다', '조기 공개하다'라는 경쟁이 지켜야 할 고객을 위험에 빠뜨렸다고 비판했습니다. 하트블리드, 멜트다운/스펙트르, 로그 4 쉘의 비밀 유지 실패를 예로 들며, "정보를 빨리 받아들이는 것은 빨리 자랑하기 위함이 아니라 고객을 보호하기 위함이다"라고 주장했습니다 (아카메이).
반면, 현장의 상황은 더 복잡하다. PHP Foundation 내부의 Alexandre Daubois氏は, 여러 곳에서 같은 날 약속이 깨졌다고 적었다. 익명投稿의 스크린샷, 도구 화면, 짧은 영상 등. 그리고 watchTowr 가 공개 자리에서 '본물'이라고 확인하고, CVE 번호까지 제시했다 (Daubois氏の 블로그). 이렇게 되면, 한 사람의 '배신'으로 정리하기는 어렵다. InfoWorld 가 인용한 전문가들은 이 비밀을 지키는 것이 거의 불가능했다고 평가했다 (InfoWorld).
더욱이 기이한 점은 공개 4 일 전의 기록이라는 점입니다. 아마존은 10 월 17 일 현재, 익명화 네트워크를 통한 공격 시도가 자체 사칭 환경 (MadPot) 에 도달했음을 밝힌 바 있습니다. 누가 어디서 정보를 얻었는지는 아마존조차도 '알 수 없다'고 밝히고 있습니다 (아마존).
즉, 누수가 발생하기 전에 이미 누군가가 움직였을 가능성이 있다. 엔버고의 붕괴는 원인 중 하나일 뿐, 모든 원인은 아니었다.
제 5 장 방어 기업의 '유가'의 차이
시간을 확보하여 패치가 적용되지 않도록 하는 '가상 패치'는 각 기업이 서로 다른 철학으로 운영해 왔습니다.
클라우드flare: 모든 사용자에게 우선 자동으로
클라우드flare 는 10 월 21 일 3 시 02 분 (유니버설 시간 기준, 일본 시간 기준 12 시 02 분) 에 무료 플랜 포함 모든 WAF 사용 고객에게 표준으로 방어를 활성화했습니다. (PPC Land, 클라우드플레어 공식 블로그)
특징은 요청과 응답을 조합하여 판단하는 '전 거래 감지 (full transaction detection)'입니다. 의심스러운 주문 티켓을 확인하는 것뿐만 아니라, 주방이 어떻게 응답했는지도 확인합니다. 공격이 성공했을 때만 나타나는 응답을 포착하여, 실수로 정상적인 통신을 중단하는 위험을 줄이려 했습니다. 이 기능의 첫 번째 프로덕션 활용은 PHP2Shell이라고 보고되었습니다.
다만, 클라우드플레어 자체는 이를 임시 조치로만 간주하고 있습니다. 공격자가 규칙의 반응을 관찰하며 공격 방식을 변형하는 사례도 관측되었습니다 (Coolify, THN).
Fastly: 고객에게 선택권을 부여하다
Fastly 는 자체 다음 세대 WAF 를 구축하여 방어 규칙을 마련했으나, 고객 스스로 규칙을 활성화하는 방식을 채택했다. 또한 블로그에서 솔직하게 이 사실을 밝혔다. 현재 방어 수준은 부분적일 뿐이며, 특정 설정 방식으로는 정상적인 통신의 상당 부분을 차단해야 할 수도 있다는 점을 강조했다. 더 나아가 PHP 설정값 (post_max_size=8M, max_input_nesting_level=4, session.upload_progress.enabled=0 등) 과 로그에 남는 단서 (0 번째 줄에서 발생한 비자연스러운 메모리 부족 오류, 반복되는 세그멘테이션 오류 등) 까지 상세히 공개했다 (Fastly).
자동으로 보호할지, 아니면 보호 여부를 선택하게 할지. 어느 것이 정답이라는 논의는 아닙니다. 보호 대상이 전문 IT 담당자가 없는 작은 사이트인지, 아니면 자체 통신을 세밀하게 조정하는 개발 조직인지에 따라 답이 달라집니다.
아카마이: 규칙과 질서
아카메이는 앱 및 API 보호기 (App & API Protector) 의 탐지 규칙 (규칙 번호 3000991) 을 공개하면서 앞서 언급한 TLP 보고서에서 업계의 행태에 경고를 내렸다고 밝혔다 (아카메이).
CrowdStrike: 입에 넣은 후의 관찰
CrowdStrike 는 WAF 를 우회한 이후의 상황을 설명했습니다.该公司的 검증 결과, 1 회 익명 요청으로도 웹 서버가 쉘을 실행하고 명령을 수행할 수 있었다고 밝혔습니다. 당시 프로세스는 다운되지 않고 정상적인 '200' 응답을 반환했으며, 애플리케이션 로그에도 흔적이 남지 않았습니다. CrowdStrike 는 "남아있는 것은 평소에도 익숙한 메모리 한계 초과라는 1 줄의 오류 메시지뿐"이라고 말했습니다.
그들이 종종 간과하는 다른 주인공들
사전 조사 메모에는 구글과 마이크로소프트의 구체적인 대응이 확인되지 않았다고 기록되어 있었으나, 이번 검증 결과 이는 사실이 아니라는 것이 밝혀졌습니다.
- 구글 클라우드에서는 서비스별 수정 절차 외에도 클라우드 어머 설정 및 만디언트 탐지 규칙 추가를 안내했습니다 (보안 대응 실험실).
- 마이크로소프트, AWS, Vercel, Palo Alto Networks, Datadog 등도 각각 가이드라인과 탐지 방법을 제시하고 있습니다(The Hacker News 의 목록 참조).
또한 IP 주소 차단 목록에 주의해야 한다는 경고도 함께 나왔습니다. 아마존은 관측된 송신원에 공유匿名化 기반이 포함되어 있으며, 단순히 차단하는 것보다 조사에 활용해야 한다고 밝혔습니다. VulnCheck 또한 공격 도구의 이름이 쉽게 변경될 수 있음을 경고했습니다.
제 6 장 세계 각국의 움직임: 같은 밤, 같은 결단
각국 정부 기관은 거의 동시에 유사한 결론에 도달했습니다. "수정이 불가능하다면 중단해야 한다"는 것이었습니다.
- 미국: CISA 는 수정 사항의 즉시 적용을 요구했으며, 즉시 업데이트가 불가능하거나 PHP 8.1 이전 버전을 사용하는 경우 시스템 오프라인 운영을 권고했습니다. (CISA) 발표 당시에는 악용 사례가 확인되지 않았다고 언급했습니다. NSA 또한 공격자가 서버의 파일이나 데이터베이스에 접근할 수 있다고 경고했습니다. 다만, 미국 정부가 공식적으로 사이트 정지를 확인한 사례는 The Register 의 보도에서는 찾아볼 수 없습니다.
- 영국: NCSC(영국 사이버 보안 센터)도 유사한 권고안을 발표했고, 의회는 정부 서비스 32 건이 이용 불가, 4 건이 부분 이용 불가로 보고되었다. NCSC는 기업 등에 5 만 건의 경고도 발송했다(The Register, NCSC).
- 유럽연합은 CERT-EU 가 2026-018 호 권고안을 발의하여, 문제가 해결되지 않는 경우 공개 애플리케이션을 외부에서 격리하라고 권고했다고 밝혔습니다. 유럽연합, ENISA, Europol 이 공동으로 발표한 성명도 있습니다 (SecurityWeek).
- 네덜란드: NCSC 가 해당 사이트를 자체적으로 차단했습니다. 독일, 프랑스, 벨기에, 핀란드 등에서도 정부 사이트가 차단된 사실이 보도되었습니다 (Techzine, The Register).
- 기타: 호주 ASD, 캐나다 CCCS, 싱가포르 CSA, 인도 CERT-In 또한 경보 발령을 내렸습니다.
여기 흥미로운 점은 일본과 미국의 비교입니다. 일본에서는 총리가 SNS 에서 '수정이 어렵다면 사이트의 일시 정지가 효과적이다'라고 주장하며, 정지된 조직은 일부 집계에서 211 개에 달했다고 합니다(미야노 히로키 씨의 노트. 일본 경제신문 보도를 출발점으로 한 분석). 해당 기사는 미국에서는 정지된 사례가 적다고 지적하고, 사이버 보험 체계와 일상적인 업데이트 수행 능력의 차이를 꼽고 있습니다.
다만, 이에 신중한 해석이 필요합니다. 영국과 유럽도 대규모로 중단한 사례가 있으며, '일본만이 중단했다'는 것은 아닙니다. 미국에 대해서도 '확인된 중단이 적다'는 것과 '중단하지 않았다'는 것은 동일하지 않습니다. 일미 차이를 논할 때, 운용의 성숙도뿐만 아니라 공개 전 조정 과정에서 얼마나 많은 이해관계자가 포함되었는지에 따른 정보의 순서 문제도 중요합니다.
제 7 장 WAF 너머의 것: '어려움'은 '안전'이 아니다
여기서 기술적으로 읽을 만한 이야기를 하나 소개합니다.
Fastly 는 공개된 공격 코드 중 상당수가 실행 환경의 메모리 배치를 모르면 성공하지 못하므로 "많은 환경에서는 예상보다 안전할 수 있다"고 언급했습니다. 그러나 그 다음 날 VulnCheck 는 ASLR 가 활성화된 x86-64 의 일반적인 프로덕션 설정에서도 통과하는 공격을 공개했습니다. 해당 회사의 담당자는 악용이 어렵다는 점과 방어되어 있다는 점을 혼동해서는 안 된다고 밝혔습니다(The Register).
한편, GitHub 와 함께 수백 가지 공격 코드가 존재하지만 대부분 작동하지 않습니다. Mandiant 의 기술 책임자는 대부분 '대기'로 만들어진 것으로, 원격 실행이 불가능하며, 일부는 검증되었으나 표준 mod_php 환경에서는 통과하지 못했다고 설명했습니다. 또한 PHP Foundation 은 10 월 23 일 기준으로, 공개 전 성공 사례나 수정된 환경에서의 악용 사례에 대한 증거는 없다고 밝혔습니다(The Register).
즉, 실제 상황은 '대규모 공격 시도', '대부분 불완전', '매우 일부만 본래이며 진화 중'이라는 세 가지 층위를 가지는 구조로 볼 수 있다. WAF 는 이 중간 층위를 제거하는 데 도움이 된다. 하지만 공격자가 규칙의 반응을 보고 형태를 바꾸는 것 (Cloudflare 의 관찰) 을 고려하면, WAF 는 그저 시간을 벌 수 있는 수단일 뿐이다. WAF 가 검사하는 본문 길이에 한계가 있고, 패딩 (수분) 으로 피할 수 있다는 점도 지적되고 있다 (Abstract Security 의 설명). 따라서 입구 (WAF), 내부 (EDR 또는 프로세스 모니터링), 그리고 근본 (패치) 의 세 가지 층위가 필요하다.
제 8 장 일본 현장에서 일어난 일
국내의 움직임은 몇 가지 기록으로 추적할 수 있습니다.
- 시계열 정리에는 츠바사의 메모장이나 레지트의 기사, 평조마키의 노트가 상세하다.
- 일부 기업은 통보에서 'PHP'를 명시했으나 다른 기업은 '소프트웨어 취약점'이라고만 적었습니다. 중단 사유를 밝히지 않는 사례가 많아 중단된 대상이 외부에서 구별하기 어려웠습니다.
- 22 일에 IPA 와 JPCERT/CC 가 공식적인 경고를 발령했다. JPCERT/CC 는 흔적이 발견되지 않았다고 해서 공격을 받지 않았다고 단정할 수 없다고 밝히고, 패치와 동시에 침해 사건의 조사도 요청했다.
- 발테크는 PHP 취약점을 표적으로 한 공격으로 인한 불법 접근 및 정보 유출 가능성을 공개하며 약 25 개의 서비스를 중단시켰습니다. 다만 CVE 번호는 명시되지 않았으며, PHP2Shell과의 연관성은 확인되지 않았습니다 (유지 씨의 노트).
중단과 피해는 구분하여 고려해야 합니다. 그렇다고 해서 '중단'만으로도 안심할 수 없습니다. 복구 작업이 끝난 후에도 이미 침입되지 않았는지 반드시 확인해야 합니다. 바로 이 두 단계의 작업이 지금도 많은 현장에서 이어지고 있습니다.
제 9 장 AI 시대의 의미: 속도만으로는 부족하다
그렇다면 이 사건은 무엇을 의미하는 것일까.
아마존의 보안 책임자는 패치 공개부터 실제 공격까지의 시간이 구조적으로 단축되고 있다고 지적한다. 과거에는 일부 강력한 공격자가 만든 공격 코드가 다른 공격자에 의해 유포되었으나, AI 가 수정 차이를 통해 공격 코드를 생성하는 비용을 낮췄기 때문에 더 많은 공격자가 수 시간, 경우에 따라서는 수 분 만에 공격을 수행할 수 있게 되었다고 한다. 또한 7 일이나 30 일이라는 수정 기한은 이미 존재하지 않는 여유를 전제로 한다는 점도 언급한다 (THN 이 전달한 아마존의 견해).
Wiz 도 이를 'AI 의 변곡점'이라 부르며, 복잡성이 방벽 역할을 하지 않을 가능성을 지적했습니다. 오픈AI 는 최첨단 AI 가 공격자보다 먼저 결함을 발견함으로써 방어 측에 대응할 시간을 확보했다는 점을 주장하며 5 단계 대응 체계를 제안했습니다 (이는 회사의 제안이며 정부의 규칙이 아닙니다. ROIC.AI 의 설명 참조).
그러나 그 창은 짧았습니다. 창을 좁힌 것은 AI 만이 아니었습니다. 인간 조직의 발걸음도 크게 어지러워졌습니다.
제 개인적인 결론을 굳이 단언의 형태로 적어두겠습니다.
이번 사건은 '가장 빠른 방어 AI 가 승리한다'는 이야기로 끝난 것이 아닙니다. 승패를 가른 것은 공격자의 시계, 패치의 시계, 그리고 인간 조직의 시계라는 세 가지 시계의 오차 때문입니다.
- 공격자의 시계는 AI 로 가속화되었다.
- 패치용 시계는 PHP 재단의 소규모 팀이 하루 앞당겨 일정을 조정하며 치열하게 추격해 맞췄습니다.
- 조직의 시계는 약속, 통지, 승인, 정지라는 인간의 절차 속에서 진행되었습니다.
PHP Foundation 은 AI 지원 관련 보고서가 급증했으며, 7 월 이후 15 개의 CVE 를 공개한 반면, 무효·중복·재현 불가능한 보고가 100 건을 초과했다고 설명하며 기업과 정부에 지원을 요청했습니다 (PHP Foundation, Unite.AI). 발견 속도가 빨라질수록 이를 해결하는 인간의 한계가 드러납니다.
또 하나의 놓칠 수 없는 후일담이 있다. 10 월 23 일 PHP Foundation 은 세 번째 RCE(CVE-2026-115560) 를 확인했다고 밝혔다. 다만 매우 특수한 설정 조합이 필요하여 실제로는 발생하기 어렵고, session.upload_progress.enabled=0 으로 완화할 수 있으므로 긴급 패치가 나오지 않고 다음 정기 릴리스에서 수정할 예정이라고 한다(The Register). Fastly 가 경고한 "찾아낸 경로를 수정하더라도 그 메커니즘 자체는 그대로 남는다"는 우려가 현실로 이어지고 있다.
제 10 장 독자별 - 오늘 밤 할 수 있는 일
- 사이트 운영자: PHP 실행 환경과 실제 웹 요청을 처리하는 PHP 버전을 확인합니다. 수정 버전을 적용한 후 PHP 프로세스와 컨테이너를 재시작하여 반영 여부를 확인합니다.
- 구리 PHP 를 사용하는 분: PHP 8.1 이전에는 일반적인 공식 릴리스가 없었습니다. 지원 대상 버전으로 전환하거나, 제공元の 백포트를 확인하세요.
- 수정 후: 의심스러운 프로세스 (PHP 워커가 쉘을 실행하지 않았는지), 비정상적인 메모리 부족 오류, 의심스러운 파일을 조사합니다. 메모리에서 읽힐 수 있는 비밀 정보는 안전을 위해 교체합니다.
- 일반적인 사용자: "メンテナンス 중" 표시는 공격을 당했다는 의미가 아니라 예방 작업이 진행 중임을 의미하는 경우가 많습니다. 가장 효과적인 2 차 피해 방지는 가짜 메일의 링크를 클릭하지 않는 것입니다.
결론: 처음의 질문으로 돌아옴
시작에서 나는 이렇게 물었다. 누군가 해킹당했는지.
정답은 다음과 같습니다. 최소한 공식적으로는 대규모 성공이 아직 확인되지 않았습니다. 그럼에도 불구하고 전 세계의 사람들이 의도적으로 사이트를 중단했습니다. 자신의 시계가 공격자의 시계를 따라잡지 못한다는 것을 알았기 때문입니다.
처음 움직인 자는 지키었는지, 아니면 비밀의 원을 깨뜨렸는지. 마지막 움직인 자는 늦었는지, 아니면 기다림으로써 전체를 지키었는지.
AI 가 취약점을 발견하는 속도는 앞으로도 계속 증가할 것이다. 그 때에 묻히는 것은 누가 더 빠른가라는 것이 아니라, 누가 더 오래 기다릴 수 있는가, 그리고 기다리는 동안 무엇을 준비해 두는 가라는 점이다.
다시 한번, 첫 문장으로 돌아가서 다시 읽어보세요. '멈춘 밤'의 풍경이 조금 다르게 보일 것입니다.
심층 탐구를 원하는 분들을 위한 책
- 체계적으로 배우는 안전한 웹 애플리케이션 제작법 (토카마리 히로시): 취약점이 발생하는 원리를 기초부터 익힐 수 있는定番서.
- 린과 디옵스의 과학 (Accelerate): 멈추지 않고 즉시 해결할 수 있는 조직을 만드는 데 도움이 되는 힌트를 제공합니다.
제로데이 (Zero Day) 까지 남은 시간 (김 제터): 이야기를 통해 읽을 수 있는 제로데이 공격의 역사.
관심 있으신 분이라면, 꼭 좋아요 ❤️ 클릭 부탁드립니다🙇 북마크에도 됩니다. 또한 관심 있는 주제가 있다면 키워드만 알려주시면, 향후 콘텐츠 소재로 활용하겠습니다.
정보원 목록
공식 발표·일차정보 (기업·재단)
- PHP2Shell: AI 가 인터넷의 70% 를 위협하는 치명적인 원격 코드 실행 취약점을 발견함 (Wiz)
- 클라우드flare 는 php2shell 취약점에 대한 보호 조치를 배포했습니다.
- Fastly 의 PHP2Shell 선제적 보호 (Fastly)
- TLP 는 제안 사항이 아닙니다 (Akamai)
- PHP 코어에 존재하는 위험한 원격 코드 실행 취약점 (Akamai)
- CrowdStrike 는 PHP2Shell 을 통한 위협으로부터 고객들을 보호합니다.
- 아마존 위협 지능은 마드포트 (Amazon) 에서 공개되기 전에 PHP2Shell 악용 사례를 사전에 식별했습니다.
- 오늘의 PHP 보안 릴리스와 PHP 보안 강화 방안 (PHP Foundation)
- PHP 보안 릴리스 (php.net)
- PHP2Shell (칼리프)
- 중요 취약점의 조정된 공개 (OpenAI)
- Google Cloud 의 핵심 PHP 취약점 대응
- PHP2Shell: PHP 의 치명적 취약점 (Datadog 보안 연구실)
- PHP2Shell 취약점 (VulnCheck)
- PHP2Shell 원격 코드 실행 취약점 악용 (watchTower)
- PHP2Shell 자주 묻는 질문 (watchTower)
- PHP2Shell: PHP 원격 코드 실행 (Sansec)
- PHP2Shell: 알아야 할 모든 것 (JFrog)
- Vercel PHP2Shell 보안 공지
- PHP 보안 공지 2026 (Coolify)
각국 정부 및 공공기관
- CISA: PHP 의 치명적 취약점은 즉시 패치해야 합니다.
- 영국 NCSC: PHP 를 타격하는 중대한 보안 취약점
- 영국 NCSC (PDF 버전)
- CERT-EU 보안 자문서 2026-018
- 호주 ASD: PHP 의 치명적 취약점
- 캐나다 CCCS: AL26-026
- 싱가포르 CSA: AL-2026-151
- 일본 CERT-In: CICA-2026-3650
- PHP 취약점 관련 사전 주의보 (2026 년 10 월 21 일)
보도·해설 (해외)
- PHP2Shell 이 영국 정부 서비스를 수십 개 마비시켰다 (The Register)
- PHP 는 공급망 보안 기업 체인가드 (Chainguard) 를 비난했습니다. (The Register)
- PHP2Shell 취약점을 우회하는 방법 (The Register)
- PHP2Shell 버그가 세 번째로 발견되었습니다(The Register).
- PHP2Shell 공개 4 일 전, 누군가가 이를 악용하려 했습니다 (The Hacker News)
- PHP 가 Unite.AI 의 Frontier AI 모델에서 발견된 두 가지 중대한 원격 코드 실행 (RCE) 취약점을 패치했습니다.
- PHP2Shell 버그가 붉은 경보를 울리고 있습니다 (Dark Reading)
- PHP 가 인터넷을 마비시켰다 (Techzine)
- 기술 및 보안 기업들이 PHP2Shell에 대응합니다 (SecurityWeek)
- PHP2Shell 은 정보공개 (coordinated vulnerability disclosure) 취약점의 존재를 드러냅니다.
- AI 가 치명적인 PHP 취약점을 발견했습니다. 더 큰 실패는 2024 년에 시작되었습니다. (The New Stack)
- 클라우드flare 는 공개 9 시간 전 php2shell 악용 사례를 차단했습니다 (PPC Land)
- 오픈AI 는 공격자가 발견하기 전에 PHP 취약점을 찾아냈다고 밝혔습니다 (PPC Land)
- PHP2Shell 루머가 잘못 이해한 점 (Alexandre Daubois)
- 오늘의 PHP 보안 업데이트 (Simon Willison)
- PHP Foundation 의 공식 입장 (MLex)
- PHP2Shell: PHP 원격 코드 실행 (Abstract Security)
- AI 가 PHP 취약점을 실제로 발견했는가? (SmartScope)
- 해커 뉴스 논평 요약 (zeli.app)
- PHP2Shell: 응급 패치 (IT Daily, 독일)
- ROIC.AI: 심각한 PHP 취약점이 100 만 대 이상의 시스템을 노출
보도·해설 (일본)
- PHP 의 중대한 취약점 'php2shell' 수정 버전 및 국내 서비스 대응 현황 (보안 대응 실험실)
- 사이트를 차단한 일본과 그렇지 않은 미국 (마노 히로키/노트)
- 【최신 소식】BASE 와 코도몬도 멈췄습니다 (유지／note)
- PHP 의 취약점인 php2shell 을 통해 현재 어떤 일이 일어나고 있는지 (마츠노 마스구/note)
- [EC 사업자용] 멈춘 장바구니와 쇼핑몰을 한 밤새 추적하기 (ツバサ의 메모장)
- 10 월 21 일과 22 일 (레지트) 에 PHP 취약점으로 인해 서비스 정지가 잇따랐습니다.
#PHP2Shell #사이버보안 #취약점 #생성형 AI #PHP #워드프레스 #AI 보안
출처: note 원문
번역: Qwen 3.5(.48) 초벌 + 교정 96청크
원문 보기 | 출처: note.com