PHP2Shell의 지옥: AI가 패치 대응 시간을 며칠에서 몇 시간으로 단축시킨 방법

연말연시를 앞두고 대규모의 교묘한 사이버 사고가 발생하는 이유는 무엇일까요? 보안 전문가들이 Log4J/Log4Shell의 악몽에서 벗어났다고 생각할 때쯤, 대규모 혼란을 야기하는 일련의 치명적인 PHP 결함이 나타났습니다.

10월 21일, 수백 개의 웹사이트가 공격자의 익스플로잇 때문이 아니라, 기술 팀이 패치를 검토하고 적용하는 동안 해당 웹사이트가 악용되는 것을 방지하기 위해 정부, 기업 및 조직에 의해 선제적으로 오프라인 상태가 되었습니다. 원인은 전체 웹사이트의 약 70%를 차지하는 언어인 PHP의 두 가지 치명적인 결함이었습니다. PHP2Shell로 알려진 CVE-2026-109618 및 CVE-2026-109619는 적절한 조건 하에서 인증되지 않은 공격자가 서버에서 원격 코드 실행(RCE)을 수행할 수 있게 합니다.

이 버그들은 PHP의 기반이 되는 C 언어에 존재하며, 이번 사건의 기술적 세부 사항을 파고드는 것도 흥미롭지만, 더 큰 이야기는 이 메모리 부족(OOM) 버그가 새로운 것이 아니라는 점입니다. 이 버그는 2004년에 처음 제기되었고, 2019년, 그리고 2024년에 다시 제기되었습니다. 가장 중요한 이야기는 12년 동안 우선순위에서 밀려났던 이 동일한 OOM 버그가 왜 2026년 여름에 갑자기 PHP 재단 보안 팀 전체의 최우선 과제가 되었는가 하는 점입니다.

그렇다면 무슨 일이 일어난 걸까요? 바로 AI 모델이 등장했습니다.

AI는 버그 발견과 버그 악용 사이의 시간을 단축시켰습니다

이 버그들은 악용하기가 쉽지 않습니다. 이러한 결함을 연결하여 작동하는 공격 벡터를 만드는 데는 PHP가 요청 전반에 걸쳐 메모리를 할당하고 재사용하는 방식에 대한 깊은 이해가 필요합니다. 노련한 보안 연구원들은 업무 중 가장 어려운 부분이 영향력을 입증하는 것임을 알고 있습니다. 도달할 수 없는 버그는 악용할 수 없고, 악용할 수 없는 버그는 기술 팀의 자원이 제한적이고 이미 백로그가 너무 많은 세상에서 수정 작업을 진행할 만큼의 긴급성을 만들어낼 수 없기 때문입니다.

이 버그들이 오랫동안 해결되지 않은 이유는 아무도 이를 악용하는 방법을 알아내지 못했기 때문입니다. 또한 수정 작업이 복잡하고 하위 호환성, 서비스 거부(DoS) 가능성, 조정이 불가능한 타사 확장 프로그램 변경 사이에서 심각한 절충이 필요했기 때문에 2024년의 수정 노력은 중단되었습니다. 이 시나리오는 보안 결과를 분류하는 모든 팀에게 익숙하게 느껴질 것입니다. 즉, 비용이 많이 드는 수정이 필요한 이론적인 문제는 명확하고 입증된 영향력을 가진 문제에 밀리기 마련입니다.

올여름, PHP 프로젝트가 OpenAI의 'Patch the Planet' 프로그램에 추가되기 전까지는 그랬습니다. PHP에 대한 새로운 AI 지원 보안 감사는 버그를 노출했을 뿐만 아니라, 수정 우선순위를 정하는 데 필요한 작동하는 익스플로잇 개념 증명(PoC)을 생성했습니다. Calif의 타임라인은 버그에 대한 경로를 찾은 후 PHP 재단에 작동하는 개념 증명(PoC)을 전달하기까지 2주도 채 걸리지 않았음을 보여줍니다. 그리고 Wiz는 보고서에서 무엇이 차이를 만들었는지 명확히 언급했습니다. "최첨단 AI 모델과 적절한 도구를 사용하면 한 명의 연구원이 이전에 세계적인 수준의 팀이 몇 달 동안 수행했을 작업을 일주일 만에 완료할 수 있습니다."

간단히 말해, 이 취약점은 어떤 모습일까요?

PHP 요청의 메모리가 부족해지면 PHP는 즉시 요청을 중단합니다. 이러한 갑작스러운 중단은 메모리 정리 단계를 건너뛰게 하여 Use After Free 메모리 손상 취약점을 생성합니다. 정확히 잘못된 순간에 PHP는 부분적으로 초기화된 내부 데이터를 남겨두고 나중에 이를 유효한 것으로 처리하여 메모리를 손상시키거나, 이전 요청의 메모리를 가리키는 내부 상태를 남겨둘 수 있습니다.

이 두 가지 버그를 작동하는 공격으로 전환하는 것은 복잡했습니다. 다음이 필요했습니다:

• 깊게 중첩된 폼 필드가 있는 작은 요청을 사용하여 PHP가 요청 크기보다 훨씬 더 많은 메모리를 할당하도록 함으로써 특정 시점에 메모리 부족 오류를 강제로 발생시킴 (Calif)
• 공격자가 제어하는 데이터가 해제된 메모리에 위치하도록 하여 PHP가 이를 자체 내부 구조로 읽도록 함 (Calif)
• 일부 체인에서는 두 번째 결함을 사용하여 메모리 내용을 유출하고 위치를 파악함으로써 주소 무작위화를 무력화함 (Wiz)

이 익스플로잇의 기술적 세부 사항을 이해하고 싶다면, 작동 방식을 단계별로 설명하는 공개 PHP2Shell 워크스루를 방문하세요: [지금 재생]

새로운 세상: 실시간으로 공격 시도 지켜보기

AI의 도움을 받는 것이 보안 연구원과 기술 팀뿐이라면 좋았을 것입니다. PHP2Shell 사건은 공격자가 공개된 정보와 패치를 익스플로잇으로 전환하는 속도가 얼마나 빨라졌는지 보여주는 단계적 변화를 우리가 처음으로 목격한 사례입니다. AWS 및 Cloudflare와 같은 조직은 사전에 정보를 받았기 때문에 고객 기반 전반에서 야생의 공격 시도를 감시할 수 있었습니다. 그리고 PHP는 전체 웹사이트의 약 70%에서 사용되는 것으로 파악될 수 있기 때문에, PHP2Shell의 공격 표면은 매우 넓습니다.

• Cloudflare는 공개 발표 전 10시간 동안 수천 건의 PHP2Shell 공격 시도를 확인했습니다. 발표 후 24시간도 채 되지 않아 수백만 건의 공격 시도를 추적하고 있었습니다.
• Amazon 위협 인텔리전스는 공개 발표 4일 전인 10월 17일로 거슬러 올라가는 PHP2Shell 공격 시도를 식별했습니다. 패치가 출시된 지 몇 시간 만에 AWS는 "야생에서 광범위한 공격 시도"를 확인했다고 밝혔습니다.

이는 팀이 더 이상 30일, 심지어 7일의 패치 및 완화 타임라인에 의존할 수 없음을 의미합니다. 치명적인 취약점의 경우, AI의 사용으로 인해 해당 타임라인이 몇 시간으로 단축되었습니다.

핵심 요약

기술 및 보안 팀은 두 가지 가정을 재검토해야 합니다.

첫째, "알려진 익스플로잇 없음"이라는 말은 더 이상 예전만큼 안심할 수 있는 근거가 되지 못합니다. AI 도구로 인해 익스플로잇을 만드는 비용이 획기적으로 낮아졌기 때문입니다. 과거에는 이론적이라고 치부했던 취약점들도 이제는 다시 살펴봐야 합니다. 코딩 비용이 저렴해지면서 익스플로잇 제작 비용 또한 저렴해졌습니다.

둘째, 몇 주가 걸리는 수정 작업은 이제 몇 시간 만에 이루어지는 공격과 경쟁해야 하며, 이는 투자 대비 효과(ROI) 계산 방식을 완전히 바꿔놓았습니다. 선제적 예방이 가장 확실한 위험 완화 전략으로 빠르게 자리 잡고 있습니다. 만약 팀에서 패치가 지원되지 않는 구버전 PHP로 애플리케이션을 운영 중이라면, 업데이트 과정에서 심각한 난관에 봉착할 수 있습니다. 기술 부채가 곧 치명적인 보안 문제로 직결된 셈이며, AI를 활용한 공격자들의 역량이 강화됨에 따라 이러한 추세는 앞으로 더욱 가속화될 것입니다. PHP는 사실상 인터넷 서버 인프라의 상당 부분을 지탱하고 있어, 패치 배포는 매우 거대한 작업이 될 것으로 예상됩니다. 웹 애플리케이션뿐만 아니라 어플라이언스를 비롯해 인터넷에 연결된 모든 시스템과 제품이 영향을 받을 수 있다는 점을 고려하면, 보안 담당자들에게는 지속적인 골칫거리가 될 가능성이 큽니다. 각 팀은 알려진 치명적 익스플로잇에 대응하는 것을 넘어, 사람이 작성했든 AI가 생성했든 상관없이 소프트웨어 개발의 모든 단계에서 보안을 최우선으로 고려하는 자세를 갖춰야 합니다. [



챌린지 시작하기][

전문가 상담하기]