Amazon, 공개 전인 10월 17일 PHP2Shell 공격 시도 포착

AI 요약

AWS Threat Intelligence는 MadPot 허니팟 기록에서 PHP2Shell 공격 시도를 확인했습니다. 해당 시도는 CVE-2026-109618과 CVE-2026-109619 공개 나흘 전인 2026년 10월 17일에 발생했으며, 상용 익명화 네트워크와 연관된 IP에서 시작됐습니다. 당시 취약점은 공개 전 엠바고 상태였습니다. 공격자가 취약점 정보를 어떻게 입수했는지는 밝혀지지 않았습니다.

공개 전후 공격 흐름

엠바고 해제 시각은 10월 21일 14시 UTC였습니다. Amazon은 공개 당일 02시 UTC 무렵 가장 이른 개념 증명(PoC) 익스플로잇을 확인했고, 02시부터 08시 사이에는 다른 익명화 인프라에서 MadPot을 겨냥한 추가 공격 시도를 포착했습니다. 페이로드와 익명화 인프라가 서로 달라 여러 공격자가 관여한 것으로 보인다고 AWS는 설명합니다. 분석은 진행 중이며, 각 시도가 실제 시스템 침해에 성공했는지는 불분명합니다. 엠바고 해제와 패치 공개 뒤 몇 시간 안에 PoC가 더 등장했고, 센서를 겨냥한 공격도 거의 즉시 관찰됐습니다. AWS는 PHP2Shell이 현재 광범위하게 악용되고 있다고 밝혔습니다.

AWS는 엠바고가 공격자도 같은 취약점을 먼저 발견하는 상황까지 막아주지는 않는다고 봅니다. 따라서 공개일을 최초 공격 시점으로 간주하지 말고, PHP2Shell 조사 범위를 최소 10월 17일부터 잡으라고 권고합니다. 또 공개된 패치 차이나 보안 권고를 바탕으로 익스플로잇을 만드는 비용이 AI 보조 분석으로 낮아져, 취약점 세부 정보가 공개된 뒤 공격까지 걸리는 시간이 짧아지고 있다는 설명입니다. 인터넷에 노출된 중요 시스템은 패치와 완화 조치의 목표 시간을 시간 단위로 잡고, 특정 CVE 서명에만 의존하지 않는 탐지 체계를 갖추라고 제안합니다.

대응 권고와 지표

AWS는 CVE-2026-109618과 CVE-2026-109619를 완전히 해결하려면 수정된 PHP 버전으로 업그레이드해야 하며, 두 문제를 모두 해결하는 설정 변경만의 대안은 없다고 밝혔습니다. 즉시 패치할 수 없다면 애플리케이션 영향을 확인한 뒤 PHP 멀티파트 파일 업로드 차단을 고려할 수 있습니다. 로그에서는 업로드 요청의 PHP_SESSION_UPLOAD_PROGRESS 문자열과 의심스러운 POST 요청을 확인하고, 웹 애플리케이션 서버에서 예상하지 못한 프로세스 실행이나 파일 변경이 있었는지도 점검하라고 권고합니다.

AWS가 공개한 관찰 IP는 103.216.220.92(10월 17일), 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37(나머지는 10월 21일)입니다. 이 주소들은 여러 사용자가 공유하는 익명화 인프라를 포함하므로 이번 활동에만 쓰인 주소가 아닙니다. AWS는 관찰 기록을 조사하되 IP 목록만으로 차단하지 말라고 안내합니다. AWS는 MadPot 허니팟의 위협 정보를 내부 탐지 시스템에 연동해 악성 스캔을 자동으로 탐지하고 제한한다고 설명했으며, 분당 2,000억 건이 넘는 이벤트를 분석한다고 밝혔습니다.

Hacker News 반응

• @hyperpape — Matthew Prince의 게시물에 따르면 Cloudflare는 공개 전 공격 시도를 수천 건, 공개 뒤에는 수만 건, 현재는 수백만 건 관찰했습니다. 다만 발표 시각을 14:00 UTC로 읽으면 Chainguard가 이미 이미지를 공개한 뒤 몇 시간 지난 시점입니다. 누군가 Chainguard 빌드를 보고 문제를 파악해 익스플로잇을 만들었는지 알기 어렵습니다. 정확한 시간표가 있으면 이해에 도움이 되겠습니다.
  • @00deadbeef — Cloudflare 사례는 유출 뒤 사람들이 PoC를 만든 다음의 기간을 말합니다. Amazon이 포착한 것은 며칠 더 이르니 상당히 우려스럽습니다.
  • @cubefox — 그렇다면 공개되지 않은 또 다른 유출이 있었거나, 공개 직전에 누군가 독립적으로 익스플로잇을 발견했을 수 있습니다. 후자는 우연이 겹친 셈이라 가능성이 훨씬 낮다고 봅니다.
  • @post-it — 공격자가 오래전부터 익스플로잇을 알고 있었지만 보류하다가 공개가 임박한 사실을 알고 지금이 아니면 안 된다고 판단했을 수도 있습니다.
  • @sullivanmatt — 2026년 10월 21일 07:43 UTC에 게시된 글이 있고, PHP Foundation 블로그에 따르면 Chainguard는 07:41 UTC에 이미지를 배포했습니다. 제가 기억하기로 Chainguard가 엠바고를 깬 큰 이유 중 하나는 Cloudflare가 공격을 관찰하고 있었기 때문입니다.
• @VladVladikoff — 서버 로그에서 탐색 시도는 봤지만 실제 익스플로잇은 보지 못했습니다. 봇넷 취약점 스캐너에 항목이 추가된 것 같지만 실제로 작동하는 익스플로잇 사례는 아직 없습니다. GitHub에는 분위기만 보고 만든 시도가 수백 개 있지만 제가 알기로는 작동하지 않습니다. 누군가 반례를 보여주면 좋겠습니다. Amazon은 17일부터 알고도 엠바고 시한을 맞추지 못하고 Amazon Linux 패치를 10월 22일에 내놓은 셈이라 이 게시물이 민망합니다.
  • @onionisafruit — Amazon의 각 조직이 언제 알았는지는 모르겠습니다. 이 게시물은 10월 17일에 공격이 있었다는 과거 허니팟 기록을 찾아낸 뜻이지, 그날 Amazon이 알았다는 뜻은 아닌 것 같습니다.
  • @boplicity — 왜 17일부터 알고 있었다고 생각하나요? "10월 17일로 거슬러 올라가는" 공격 시도라는 말은 그때 발생했다는 뜻이지 그날 발견했다는 뜻은 아닙니다.
• @bcvvvy — 그렇다면 Amazon Linux는 왜 아직 수정하지 않았나요? Bottlerocket AMI에 emSign 폐기 인증서가 없는 문제도 그렇습니다. 고객을 위험에 빠뜨리는 형편없는 회사입니다.
  • @asah — 반대 의견입니다. 수정 사항이 다른 방식으로 고객 시스템을 망가뜨리면 고객은 더 곤란해집니다. 어느 쪽이든 문제가 됩니다.
  • @bcvvvy — 수정 사항을 배포한 곳은 upstream을 가져오는 곳을 포함해 거의 모든 다른 공급업체입니다. 변명할 이유가 없습니다.
  • @Tomdarkness — upstream을 겨냥한 수정 사항을 자원봉사자가 관리하는 패키지와 이미지가 훨씬 빨리 배포했습니다. 검증되지 않은 다운스트림 패치가 아닙니다. 이 시점에는 고객이 애플리케이션을 오프라인으로 내렸을 가능성이 높으니 상황을 더 악화시키기도 어려웠을 겁니다.
• @menomatter — 공격 시도와 실제 침해 성공을 구분해서 집계하나요? 익스플로잇이 얼마나 쉽게 작동하는지 알고 싶습니다. 어제 올라온 글에서는 쉬운 공격이 아니며 LFI가 필요하다고 했습니다.
• @Tomdarkness — Amazon은 패치가 나오기 며칠 전부터 익스플로잇과 실제 공격을 알고 있었는데도 패치 공개 후 18시간이 지나서야 Amazon Linux 패키지를 업데이트한 셈입니다. 이 게시물은 AWS가 의도한 메시지를 전달하지 못하는 것 같습니다.
  • @boplicity — 왜 17일에 알고 있었다고 생각하나요? 과거 로그를 다시 조사하는 것과 기록이 생성될 때 그 의미를 파악하는 것은 다릅니다.
  • @Tomdarkness — 사후에 발견한 것이라면 블로그가 더 분명히 밝혔어야 합니다. 글만 보면 MadPot이 CVE 공개 전 탐지를 했다고 홍보하는 것처럼 읽힙니다. 패치 공개 약 12시간 전인 10월 21일 02시부터 08시까지 추가 시도를 식별했다고 했고, CVE 서명에 의존하지 않는 탐지를 권고했습니다. 또 분당 2,000억 건이 넘는 이벤트를 분석하고 MadPot 위협 정보를 통합해 알려진 공격을 실시간 차단하며, 허니팟이 신속한 대응과 분석을 돕는다고 설명했습니다.
• @ActionHank — 기술 회사들은 같은 자전거를 타면서 누가 더 낫다고 자랑하는 학생들 같습니다. 그 자전거는 모두를 위협하는 큰 취약점인데 아무도 고치지 않았고, 누가 먼저 발견했는지만 내세웁니다. Amazon에서 이 보도자료를 승인한 사람에게 말하자면, 원한 반응을 드리겠습니다. "와, 정말 대단하네요." 왜인지는 모르겠지만 AI 때문에 모두가 절박하고 초라해 보입니다. 다음에는 고객을 보호할 패치를 실제로 제때 내놓으세요.

원문: AWS Security Blog / 번역·요약: Trawling