10월 17일에 이미 탐색이나 악용이 진행 중이었다면, 공개 발표에서 Chainguard를 비난한 PHP 팀도 비판을 피하기 어려움. “Chainguard가 엠바고를 깼다”, “금전적으로 지원해 달라”, “우리는 자원봉사자일 뿐이다”, “수년 전부터 알았지만 보안 수정 대신 기능 출시를 우선해 개념 증명 코드가 없었다”는 모두 자신들이 만든 혼란에 대한 책임 회피로 보임.
PHP 팀이 크게 잘못하고도 사방으로 책임을 돌리는 모습을 보니, 내가 참여하는 프로젝트에서는 PHP를 절대 쓰고 싶지 않아짐.
달라지는 건 17일까지 거슬러 로그를 확인해야 한다는 것뿐임. Amazon은 21일 이전에 악용 사실을 알고 있었다고 하지 않았고, 사후에 로그를 뒤져 발견했다는 뜻일 수도 있음. 초기 수천 건의 시도 중 성공한 것이 있다는 명확한 증거도 아직 못 봤으며, 대부분 취약점을 알아내려는 탐색이나 추측이고 기껏해야 특정 환경에서만 일부 성공한 것으로 보임.
이번 일을 교훈 삼아 취약점 공개 절차를 바꿔야 함. 지금 같은 환경에서 제3자 유출까지 동반한 첫 대형 원격 코드 실행 취약점 공개라면, 어느 프로젝트라도 이런 혼란을 겪었을 가능성이 큼.
공개 과정에서 사태를 촉발한 가장 큰 실수는 Calif가 X의 바이브 코딩 개발자들 말을 믿고 영상을 일찍 올린 것임. 사람들의 반응을 보면 PHP가 출시를 미리 예고한 것도 결과적으로 실수였을 수 있음. 보안 연구자들은 원래 엠바고보다 몇 시간 먼저 공개해 더 많은 사람을 위험에 빠뜨리고 불안을 키우는 것인가?
MediaWiki만 아니면 PHP를 직접 다룰 일은 완전히 끊을 수 있을 것 같음. 대규모 위키를 그대로 이전해 대체할 만한 제품은 상상하기 어려움.
왜 이 패치만이 유일한 해결책이라고 보는지 모르겠음. 공격은 악성 입력을 통해 이뤄지므로, 애플리케이션 서버 앞에 입력을 디코딩한 뒤 안전하게 다시 인코딩하는 프록시를 두는 것이 현명함. Claude로 몇 시간 만에 만든 프록시는 php2shell과 앞으로 발견될 수 있는 여러 공격을 완전히 차단함. multipart-form-data도 공격자가 정한 경계 문자열 대신 자체 생성한 안전한 무작위 경계 문자열로 다시 인코딩함.
실제 배포 환경에서 사용 중이며, PHP를 패치하기 어렵거나 원하지 않는 서버를 위해 어제 MIT 라이선스로 무료 공개함. 그런 서버가 지금 수백만 대일 것으로 봄. https://github.com/Qbix/proxy
PHP 팀은 늘 이랬음. 소프트웨어 품질을 높이기보다 하위 호환성을 고려하지 않은 기능 추가에 매달려 왔음. 진지한 프로젝트라면 PHP를 쓰지 말아야 함.
Matthew Prince에 따르면 Cloudflare는 발표 전 수천 건, 발표 후 수만 건, 현재는 수백만 건의 시도를 관측함. https://x.com/eastdakota/status/2113079352682570051.
다만 발표 시각을 UTC 14:00으로 해석하면 Chainguard가 이미지를 공개한 지 몇 시간 뒤임. 누군가 그 빌드를 분석해 취약점을 파악하고 공격 코드를 만들었을 가능성이 있는지는 모르겠지만, 정확한 시간순 정리가 있으면 이해에 도움이 될 것 같음.
https://x.com/dok2001/status/2112811965735202970는 2026년 10월 21일 UTC 07:43에 게시됐고, PHP Foundation 블로그에 따르면 Chainguard는 UTC 07:41에 배포함. 기억하기로는 Cloudflare가 이미 공격을 관측하고 있다는 사실이 Chainguard가 엠바고를 깬 주요 이유 중 하나였음.
Cloudflare가 말한 시점은 유출 이후 이미 개념 증명 코드가 만들어진 때임. Amazon의 탐지 시점은 며칠 더 앞선다는 점이 상당히 우려됨.
패치 공개 한 시간 전부터 LLM 봇이 주도한 것으로 의심되는 공격 시도가 로그에 남아 있음. 애플리케이션과 무관한 여러 URL로 POST 요청을 보냈고, 내가 앞단 프록시에 추가한 multipart 폼 POST 차단 규칙에 걸림.
GMT 오전 9시 직후에도 의심스러운 시도가 잠깐 몰림. 해당 URL로 multipart 폼 요청이 올 이유가 없어 공격은 확실해 보이지만, 같은 형태를 쓰는 다른 오래된 공격일 가능성도 있음. WordPress 계열 URL은 아님.
서버 로그에서 취약점 탐색은 봤지만 실제 악용은 못 봄. 봇넷이 취약점 스캐너에 이를 추가한 듯하지만, 실제로 동작하는 공격 코드는 아직 접하지 못함. GitHub에는 바이브 코딩으로 만든 시도가 수백 개 있지만, 내가 아는 한 작동하는 것은 없음. 반례가 있다면 보고 싶음.
Amazon의 이번 글도 민망함. 17일부터 알고도 엠바고 일정에 맞춰 Amazon Linux를 패치하지 못했고, 패치는 오늘인 10월 22일에야 나올 예정임.
Amazon 내부의 각 조직이 언제 알았는지는 모르지만, 이 글이 10월 17일에 인지했다는 뜻은 아닌 것 같음. 허니팟의 과거 로그를 조사하다 17일에 php2shell 탐색이 있었다는 사실을 발견한 것으로 읽힘.
왜 17일부터 알고 있었다고 보는가? “2026년 10월 17일까지 거슬러 올라간다”는 것은 발생 시점이지, 그날 식별했다는 뜻은 아님.
공격 시도와 침투 성공을 구분해서 집계하는가? 이 취약점을 실제로 악용하기 쉬운지 알고 싶음. 어제 올라온 글에서는 악용이 어렵고 로컬 파일 포함(LFI) 취약점이 필요하다고 했음.
실험실 환경에서도 기본 원리부터 직접 공격을 구현하려니 어려움을 겪고 있음.
“악용 시도”를 발표할 때는 정확히 무엇을 관측했는지 명확히 밝혀 줬으면 함.
통제되지 않은 메모리 손상으로 충돌을 일으킬 수 있는 요청인지, 실제 코드 실행이 가능한 공격의 징후인지에 따라 의미가 크게 달라짐. Amazon 발표만으로는 어느 쪽을 봤다는 것인지 알기 어려움.
연구자들이 취약점을 발견하고 PHP 내부 관계자들에게 알린 뒤 공격이 시작됐다는 점은 시사하는 바가 큼. 악의적 행위자가 같은 시기에 똑같은 공격 연쇄를 완전히 독립적으로 발견했다고 정말 믿는가?
PHP Foundation은 내부자들이 정보를 공유하거나 팔고 있는 동안 두 달 넘게 손 놓고 있었던 이유를 더 제대로 해명해야 함.
OpenAI 블로그에 따르면 수정과 출시를 제외한 모든 과정을 자신들이 주도했다고 함. 그렇다면 주도한 쪽이 책임져야 하지 않을까?