Amazon, PHP2Shell 악용을 CVE-2026-109618 공개 4일 전인 10월 17일로 추적

Amazon Threat Intelligence는 2026년 10월 17일에 PHP2Shell 악용 시도를 관찰했다고 보고했습니다. 이는 CVE-2026-109618 및 CVE-2026-109619가 2026년 10월 21일에 공개되기 4일 전입니다. 이 발견은 방어자가 대응 기간을 권고일이 아닌 최초 알려진 악용 시점부터 계산해야 하며, 인터넷에 노출된 중요 시스템의 패치는 7일 또는 30일 단위가 아닌 시간 단위의 문제로 취급해야 함을 의미합니다.

Amazon이 실제로 감지한 내용

Amazon Threat Intelligence는 2026년 10월 17일, CVE-2026-109618 및 CVE-2026-109619의 공개 4일 전에 MadPot 허니팟 네트워크에 대한 PHP2Shell 악용 시도를 식별했습니다. 이 시도는 상업용 익명화 네트워크와 관련된 IP 주소에서 발생했습니다.

Amazon은 당시 취약점이 아직 엠바고 상태였기 때문에 익명화된 IP 주소에서 허니팟을 대상으로 한 공격은 위협 행위자에 의해 수행되었음을 시사한다고 밝혔습니다. 또한 행위자가 공개 전에 악용 정보를 어떻게 획득했는지는 불분명하다고 밝혔습니다. 관찰된 시도 중 실제 시스템에서 성공했을지 여부도 불분명하다고 회사는 언급했습니다.

MadPot은 Amazon의 허니팟 시스템입니다. Amazon은 분당 2,000억 개 이상의 이벤트를 분석하고 MadPot 허니팟 네트워크의 위협 인텔리전스를 통합하여 알려진 악용 시도를 실시간으로 식별하고 차단한다고 밝혔습니다.

PHP2Shell 악용 타임라인

PHP 엠바고는 2026-10-21 14:00 UTC에 해제될 예정이었습니다. 악용 활동은 해당 경계의 양쪽에 집중되었습니다.

시간 (UTC) 이벤트
2026-10-17 103.216.220.92에서 MadPot에 대한 최초 PHP2Shell 악용 시도
2026-10-21 ~02:00 엠바고 해제 전, 취약점에 대한 최초 PoC 악용 코드 식별
2026-10-21 02:00-08:00 추가 익명화 인프라에서 다양한 페이로드를 사용한 추가 PHP2Shell 악용 시도
2026-10-21 14:00 엠바고 해제 및 패치 출시
2026-10-21 14:00 이후 몇 시간 내에 추가 PoC 악용 코드가 나타나 거의 즉시 Amazon 센서에 사용됨

Amazon은 페이로드와 익명화 인프라 선택이 다양하여 단일 행위자가 아닌 여러 행위자임을 시사한다고 설명합니다. PHP2Shell이 현재 야생에서 광범위하게 악용되고 있다고 회사는 밝혔습니다.

엠바고는 다른 누군가가 같은 버그를 찾을 때까지만 방어자를 보호합니다

Amazon의 첫 번째 교훈은 조정된 공개가 여전히 올바른 모델이지만, 방어자는 공개 날짜가 최초 악용 날짜라고 가정해서는 안 된다는 것입니다. PHP2Shell의 경우, 침해가 권고보다 앞설 수 있습니다. 10월 17일 허니팟 공격은 이 주장에 대한 Amazon의 구체적인 증거입니다.

패치-악용 창은 구조적 이유로 줄어들고 있습니다

Amazon의 두 번째 교훈은 패치에서 작동하는 악용 코드까지의 시간이 단축되고 있다는 것입니다. 과거에는 Amazon이 관찰한 대부분의 악용이 공개 PoC 출시 이후에 발생했다고 밝혔습니다. 소수의 능력 있는 행위자가 악용 코드를 만들고 다른 모든 사람들은 그들을 기다렸습니다. Amazon은 AI 지원 분석이 패치 diff나 권고를 작동하는 악용 코드로 전환하는 비용을 낮추기 때문에 이러한 의존성이 약화되고 있다고 말합니다. 결과적으로 더 많은 행위자가 취약점의 기술적 세부 사항이 공개되면 몇 시간 또는 몇 분 안에 행동할 수 있습니다.

보안 리더가 변경해야 할 사항

Amazon은 이 사건이 무효화한다고 말하는 세 가지 작업 가정을 나열합니다.

  1. 인터넷에 노출된 시스템의 중요 취약점의 경우 패치 및 완화 기간을 시간 단위로 측정하십시오. 7일 또는 30일 SLA는 더 이상 존재하지 않는 지연을 가정합니다.
  2. 조사를 공개 날짜가 아닌 최초 알려진 악용 시점부터 시작하십시오. PHP2Shell의 경우 Amazon은 최소한 2026년 10월 17일부터 조사할 것을 권장합니다.
  3. 특정 CVE에 대한 시그니처에 의존하지 않는 탐지에 투자하십시오. 최초 악용은 종종 그러한 시그니처가 존재하기 전에 발생하기 때문입니다.

PHP2Shell에 대한 권장 수정 조치

Amazon은 다섯 가지 조치를 나열합니다.

  1. 수정된 PHP 버전으로 즉시 업그레이드하십시오. Amazon은 업그레이드가 CVE-2026-109618 및 CVE-2026-109619 모두에 대한 유일한 완전한 수정이며, 두 문제를 완전히 해결하는 구성 전용 해결 방법은 없다고 밝혔습니다.
  2. 즉시 패치할 수 없는 PHP 배포판에서 멀티파트 파일 업로드를 차단하는 것을 고려하십시오. 애플리케이션에 미치는 영향을 확인한 후에 수행하십시오.
  3. 양식 업로드에서 PHP_SESSION_UPLOAD_PROGRESS 문자열을 포함하는 POST 요청을 찾으십시오.
  4. 웹 서버 로그에서 의심스러운 활동을 검토하십시오.
  5. 웹 애플리케이션 서버에서 예기치 않은 프로세스 실행 또는 파일 수정을 확인하십시오.

AWS는 또한 패치하는 동안 AWS WAF를 사용하여 PHP2Shell RCE 취약점에 대한 완화를 적용하는 방법에 대한 동반 게시물을 게시했습니다.

Amazon이 관찰한 IP 주소

Amazon은 활동과 관련된 6개의 IP 주소를 게시했습니다. 이러한 주소에는 공유 익명화 인프라가 포함되며 이 위협 활동에만 국한되지 않으며, 조직은 이러한 주소를 완전히 차단하기보다는 관련 관찰을 조사해야 한다고 명시적으로 밝혔습니다.

IP 주소 관찰 날짜
103.216.220.92 2026-10-17
31.223.184.166 2026-10-21
37.19.200.5 2026-10-21
134.209.159.64 2026-10-21
103.114.163.188 2026-10-21
95.217.98.37 2026-10-21

Hacker News 토론이 추가하는 내용

보고서에 대한 Hacker News 스레드(197포인트, 55개 댓글)는 주로 두 가지 질문에 집중되었습니다. Amazon이 설명하는 악용이 실제로 성공했는지, 그리고 Amazon 자체 Linux 패치가 공개하는 공개보다 뒤처진 이유입니다.

관찰된 활동 중 실제 침해가 있었나요?

댓글 작성자들은 Amazon이 악용 시도와 성공적인 침투를 구분하는지 물었습니다. 한 댓글 작성자는 작동하는 악용 코드보다는 프로빙만 보았다고 설명했습니다.

서버 로그에서 프로빙은 봤지만 실제 악용은 보지 못했습니다. 봇넷이 취약점 스캐너에 추가한 것 같지만 실제 작동하는 악용 코드의 예는 아직 보지 못했습니다. GitHub에는 수백 개의 vibe coded 시도가 있지만 제가 아는 한 그중 어느 것도 작동하지 않습니다.

또 다른 댓글 작성자는 악용 코드가 사용하기 쉬운지 물었고, 별도의 기사에서 악용이 쉽지 않고 로컬 파일 포함(LFI)이 필요하다고 주장했다고 언급했습니다. Amazon 자체는 어떤 시도가 실제 시스템에서 성공했는지 불분명하다고 밝혔으므로 원본 자료는 이 질문을 해결하지 못합니다.

Amazon 자체 패치 타임라인에 대한 비판

여러 댓글 작성자는 블로그 게시물이 Amazon Linux 패키지가 패치 출시보다 늦었기 때문에 자체 메시지를 약화시킨다고 주장했습니다. 한 댓글 작성자는 amazonlinux/amazon-linux-2023 저장소의 GitHub 이슈를 지적했습니다.

Amazon은 이 악용 코드와 패치 출시 며칠 전에 활발히 사용되고 있다는 사실을 알고 있었습니다. 그럼에도 불구하고 패치 출시 후 18시간이 지나서야 Amazon Linux 패키지의 업데이트 버전을 제공했습니다.

또 다른 댓글 작성자는 Amazon의 Amazon Linux 패치가 10월 22일에 예정되어 있었고 이를 근거로 게시물을 부끄럽다고 말했습니다. 이는 Amazon Linux 릴리스 타이밍에 대한 댓글 작성자의 주장이며, AWS 블로그 게시물 자체는 Amazon Linux 패키지 가용성에 대해 논의하지 않습니다.

다른 공급업체 텔레메트리와의 중복

한 댓글 작성자는 Matthew Prince의 트윗을 인용하여 Cloudflare가 발표 전 수천 건, 발표 후 수만 건, 트윗 시점에는 수백만 건의 시도를 보았다고 말했습니다. 같은 댓글 작성자는 타임라인 모호성을 지적했습니다. 발표가 14:00 UTC를 의미한다면 Chainguard가 이미지를 게시한 후 몇 시간 후이며, 정확한 타임라인은 행위자가 해당 빌드에서 악용 코드를 파생했는지 여부를 확립하는 데 도움이 될 것입니다.

PHP 프로젝트의 공개 처리에 대한 비판

스레드의 일부는 연구자와 PHP 내부자에 대한 비공개 통지와 거의 동시에 악용이 어떻게 시작될 수 있는지 의문을 제기했습니다. 한 댓글 작성자는 다음과 같이 썼습니다.

연구자들이 취약점을 발견하고 PHP 내부자에게 통지한 후 공격이 시작된 것은 매우 의미심장합니다. 악의적인 행위자가 동일한 악용 체인을 완전히 독립적으로 동시에 발견했다고 누가 정말 믿겠습니까?

또 다른 댓글 작성자는 PHP 팀의 공개 커뮤니케이션에 대해 더 가혹하게 비판하며 Chainguard와 자금 문제에 책임을 돌리는 것으로 응답을 설명했습니다. 세 번째 댓글 작성자는 고객을 위한 수정 사항을 제공하는 대신 공급업체가 누가 취약점을 먼저 감지했는지 경쟁하고 있다는 더 넓은 불만으로 비판을 일반화했습니다.

해결되지 않은 사항

원본 자료는 여러 질문을 열어 둡니다. Amazon은 공개 전 행위자가 악용 세부 정보를 어떻게 얻었는지, 어떤 시도가 성공했는지, 다양한 페이로드 뒤에 특정 행위자가 누구인지 말하지 않습니다. 댓글 스레드는 10월 17일 활동이 공개 전 무기화였을 가능성을 제기하지만 Amazon이나 댓글 작성자 모두 그 연쇄를 입증하는 증거를 제공하지 않습니다. 그러나 Amazon의 운영 지침은 이러한 답변에 의존하지 않습니다. 인터넷에 노출된 PHP 배포판을 몇 시간 안에 패치하고, 포렌식 타임라인을 최초 알려진 악용 날짜부터 시작하고, CVE별 시그니처가 아닌 행동 탐지에 의존하십시오.

Sources