Cloudflare, php2shell 취약점 방어 규칙 배포

AI 요약

PHP 런타임 취약점 두 건인 CVE-2026-109618과 CVE-2026-109619가 php2shell로 공개됐습니다. PHP 5.4 이상 웹 서버가 영향을 받으며, 특수 제작한 HTTP 요청으로 서비스 거부(DoS), 원격 코드 실행(RCE), 데이터 노출이 발생할 수 있습니다. Cloudflare는 PHP Foundation, OpenAI, Wiz 등과 대응을 조율했고, 2026년 10월 초부터 완화책을 개발해 공개 약 9시간 전에 배포했습니다. 공격 트래픽과 규칙 일치량을 살펴 공격자가 페이로드를 바꾸며 우회하려는 시도도 추적했다고 밝혔습니다.

취약점의 차이

두 문제 모두 요청 처리 중 예외가 발생했을 때 메모리를 잘못 정리하거나 참조하는 데서 비롯합니다. CVE-2026-109618은 메모리 부족으로 처리가 중단된 뒤 초기화가 끝나지 않은 내부 데이터를 정리 과정에서 사용합니다. CVE-2026-109619는 치명적 오류로 요청이 중단된 뒤 해제된 메모리를 가리키는 참조가 남고, 같은 PHP 프로세스가 다음 요청을 처리할 때 잘못된 메모리에 접근합니다. 이 과정에서 프로세스가 중단되거나 민감한 정보가 노출되고 공격자 코드가 실행될 수 있습니다.

PHP 런타임 자체의 결함이므로 웹사이트 코드나 플러그인만 고쳐서는 해결되지 않습니다. 관리자는 PHP 소프트웨어를 보안 업데이트해야 합니다. 호스팅 업체가 PHP를 관리한다면 업체에 업데이트를 요청해야 합니다. 불필요한 업로드를 막고 업로드 크기를 제한하면 노출을 줄일 수 있지만 PHP 수정 사항을 대체하지는 않습니다.

Cloudflare WAF 방어

Cloudflare는 일반적인 요청 기반 규칙만으로는 악성 요청과 정상 요청을 항상 구분하기 어렵다고 설명합니다. 이에 같은 HTTP 트랜잭션에서 요청과 원본 서버의 응답을 함께 분석하는 full transaction detection 기능을 만들었습니다. 응답에서 익스플로잇 성공을 식별하는 신호를 추가해 오탐을 줄이고, 조건에 맞는 원본 응답이 요청자에게 전달되기 전에 차단합니다. php2shell 규칙은 이 기능을 적용한 첫 관리형 탐지 규칙입니다.

WAF를 사용하는 모든 요금제에 보호 기능을 자동 배포했습니다. 무료 사용자는 Cloudflare Managed Free Ruleset의 규칙을 별도 조치 없이 적용받습니다. 유료 요금제는 Cloudflare Managed Ruleset에 규칙이 배포됐으며, Professional, Business, Enterprise 사용자는 규칙 세트가 차단 모드인지 확인해야 합니다. 모든 요금제에는 높은 신뢰도의 서명을 차단하는 Managed Response Firewall Default 규칙도 배포됐습니다. 고객은 Security Analytics의 Events에서 규칙 ID를 기준으로 차단 기록을 확인하고 애플리케이션에 맞게 적용 범위를 조정할 수 있습니다. Cloudflare는 새 공격 기법이 나타나면 규칙을 갱신하겠다고 밝혔습니다.

Hacker News 반응

• @mentalgear — 제가 오픈 소프트웨어를 좋아하지만, 엔드투엔드 사이버 침투가 가능한 오픈 웨이트 LLM 조합과 컴퓨팅 자원을 투입해 "돈을 벌게 해줘"라고 지시하는 행위, 그리고 이미 데이터와 정치·인프라 권력을 너무 많이 쥔 주체들이 오픈 인터넷의 최종 문지기로 커지는 상황이 무척 우려됩니다. 이 문제를 안전하게 다루고 권력을 더 평등하게 나눌 방법이 있다면 알려주세요.
  • @choeger — 이에 대한 대응책입니다. 소프트웨어가 정확하다는 점을 증명 가능하게 만드세요. 그러면 문지기도 공격자도 두려워할 필요가 없습니다.
  • @totetsu — 기관차의 발명은 열차 사고의 발명이기도 했습니다. V. 재앙은 "오픈 웨이트" 모델이 모든 것을 침투한다는 데만 있지 않습니다. 우리는 성숙하거나 안전해지지 못한 IT 혁명을 중심으로 세상을 구축했습니다. 이제 그 대가를 치르는 중입니다. 그 주체들은 LLM의 문지기도 될 겁니다.
  • @arm32 — 기관차가 무기로 쓰였다는 말은 들어본 적이 없는 것 같습니다. "핵분열이 핵 낙진을 낳았다"가 더 적절한 비유 아닐까요?
  • @unsnap_biceps — 열차 자체를 무기로 쓴 경우보다 고의로 탈선시킨 사례가 더 가까운 비유 같습니다. 예를 들면 Battle of Mill이 있습니다.
  • @solatic — "성숙하거나 안전해지지 못한 IT 혁명을 중심으로 세상을 구축했다"는 말에 반대하지는 않습니다. 하지만 실무에서 이 사건과 어떤 관련이 있나요? 제로데이 취약점입니다. 무엇을 했어야 할까요? PHP 배포를 금지하고 WordPress나 Wikipedia도 쓰지 말았어야 하나요?
  • @stymaar — 정식 안전성 증명이 없는 한 메모리 안전하지 않은 언어를 어떤 용도로든 쓰지 말고, 강한 샌드박스 기능이 있는 OS만 쓰며 모든 소프트웨어를 샌드박스에 넣어야 합니다. 또는 익스플로잇이 발생했는데 가능한 모든 예방 조치를 했다는 점을 입증하지 못하면 소프트웨어 작성자에게 형사상 과실 책임을 물어야 합니다. 발전 속도는 크게 느려졌겠지만 앞으로 닥칠 혼란은 피했을 겁니다. 커피 머신이 폭발해 사람을 다치게 하면 제조사가 책임지지만, 커피 머신이 봇넷에 포함돼 핵심 인프라를 마비시키고 사람이 죽어도 IoT 기기를 안전하게 만들지 않은 제조사에게는 아무 책임도 묻지 않는다는 게 오히려 이상합니다.
  • @solatic — PHP 스크립트 자체는 메모리 안전합니다. 문제는 특정 PHP 스크립트가 아니라 메모리 안전하지 않은 언어로 작성한 PHP 런타임입니다. 그 기준을 적용하면 CPython이 일부 C로 작성됐으니 Python도 메모리 안전하지 않습니다. Ruby와 .NET 생태계의 언어도 마찬가지입니다.
  • @stymaar — 맞습니다. 보안을 다른 산업만큼 진지하게 다뤘다면 위 언어들은 모두 SPARK나 그 후속 언어로 작성됐을 겁니다. Rust가 나오기 훨씬 전부터 그랬을 겁니다.
  • @locknitpicker — 확인해보면 "메모리 안전 언어"에도 메모리 안전 문제를 포함한 CVE가 꽤 쌓였다는 걸 알게 될 겁니다. RustSec도 확인해보세요.
  • @tick_tock_tick — 대단한 선언과 해답처럼 들립니다. 공격자와 방어자 사이에는 본질적인 비대칭이 있으므로 성공하는 공격자는 늘 나옵니다.
• @lexoj — 보안 사고가 이렇게 많이 난 뒤로 현재와 미래에는 보안 전문가가 더 많아지거나 사이버 보안에 더 많은 시간을 써야 한다는 점이 분명해 보입니다.
  • @pixel_popping — 오늘날에는 AI를 활용한 심층 검증 없이 프로그래밍하는 일이 무모해졌다는 사실을 더 잘 보여줍니다.
• @sankalpmukim — 대응 속도가 정말 인상적입니다.
  • @pelican0 — 글에 따르면 Cloudflare는 PHP Foundation, OpenAI, Wiz 등과 대응을 조율했습니다. 2026년 10월 초부터 완화책을 개발했고 공개 약 9시간 전에 배포했습니다.
• @Melatonic — CrowdStrike를 쓰는 분들께 질문합니다. Linux 센서 설정에서 "Enhanced PHP visibility"를 켜면 단점이 있나요? 수정: Cloudflare와 CrowdStrike를 혼동했을 수도 있지만 질문은 남겨둡니다.
• @CrimsonRain — 고맙습니다, Cloudflare. 이 조치 하나로 수백만 개 웹사이트가 해킹당하는 일을 막을 수 있겠네요.

원문: Cloudflare Blog / 번역·요약: Trawling