Reddit

Wiz got pre-auth RCE on WordPress, Drupal and Joomla through vulnerabilities in PHP itself

PHP 자체 취약점으로 WordPress·Drupal·Joomla에서 인증 전 원격 코드 실행 가능

Wiz Research는 PHP의 메모리 안전성 결함 네 가지를 두 개의 CVE로 보고했으며, 취약한 PHP를 쓰는 서버에서 인증 없이 메모리를 읽거나 코드를 실행하는 공격을 시연했습니다. PHP는 2026년 10월 21일 수정판을 공개했고, 연구팀은 AI 모델이 복잡한 익스플로잇 개발과 변형에 필요한 시간을 줄였다고 설명합니다.

에디터 노트

이번 사례에서 실질적인 위험은 CMS별 결함이 아니라 요청 간에 재사용되는 PHP 작업자의 메모리 상태에 있습니다. 따라서 CMS 업데이트만으로 해결되지 않으며 PHP 런타임 패치가 필요합니다. 메모리 공개가 실제로 발생했다면 런타임 수정과 자격 증명 교체도 별개 작업이라는 댓글의 지적이 타당합니다. 다만 원문은 어떤 자격 증명을 교체해야 하는지 정하는 절차나 공개된 악용 사례를 제시하지 않습니다. AI가 발견과 익스플로잇 개발에 기여했다는 설명은 Wiz의 연구 결과와 자체 평가입니다. 복잡한 결함을 여러 환경에 맞춰 조정하는 시간이 줄었다는 주장은 구체적인 연구 과정과 함께 제시됐지만, AI가 없었을 때 필요한 시간과 비교한 측정치는 원문에 없습니다. 댓글에서 제기한 수정 바이너리의 선공개 문제도 우려로 제시됐을 뿐, 공개 일정만으로 공격자가 실제로 이점을 얻었는지는 확인되지 않습니다. 원문이 제시한 70%라는 인터넷 웹사이트 비중도 산정 기준을 설명하지 않으므로 위험의 범위는 PHP 사용 여부와 실제 배포 버전을 기준으로 봐야 합니다.

AI 요약

PHP 엔진의 메모리 안전성 결함 네 가지가 두 개의 CVE로 공개됐습니다. Wiz Research는 취약한 PHP를 실행하는 WordPress, Drupal, Joomla에서 인증 전 원격 코드 실행(RCE)을 시연했고, 별도로 PHP 작업자(worker) 메모리에서 비밀번호와 토큰, API 키 등을 읽을 수 있음을 보였습니다. 취약점은 애플리케이션 코드가 아니라 PHP 자체에 있어 간단한 PHP 프로그램도 영향을 받을 수 있습니다. 보고된 취약점은 PHP 5.4 이후 버전에 걸쳐 있으며 PHP는 2026년 10월 21일 수정판을 공개했습니다.

취약점 작동 방식

네 가지 사례는 요청 처리 중 치명적 오류, 특히 메모리 부족 오류가 발생한 뒤 PHP 내부 상태가 정리되지 않는 문제에서 비롯됩니다. 요청 힙을 해제한 뒤에도 전역 상태가 해제된 메모리를 가리키면 같은 작업자가 다음 요청을 처리할 때 공격자가 그 메모리를 다시 차지해 오래된 포인터를 악용할 수 있습니다.

CVE-2026-109618에는 업로드 진행률 처리 과정의 unserializer use-after-free가 포함됩니다. Wiz는 이를 메모리 공개와 메모리 변조에 연결해 WordPress, Drupal, Joomla에서 인증 전 RCE를 보였습니다. 같은 CVE의 원격 메모리 공개 문제는 애플리케이션이 세션을 시작하지 않아도 영향을 줄 수 있으며, 공격자가 보낸 요청과 무관한 작업자 메모리 내용도 노출될 수 있습니다.

CVE-2026-109619에는 치명적 오류의 backtrace에서 발생하는 use-after-free와 OPcache의 type confusion이 포함됩니다. backtrace 사례에서는 이전 요청의 메모리를 가리키는 전역 값이 남아 다음 요청의 진단 처리 중 메모리 변조로 이어집니다. OPcache 사례에서는 공유 상태를 기록하는 도중 메모리 할당 오류가 나면 작업자별 포인터 인덱스와 공유 frontier가 어긋날 수 있습니다. 다른 작업자가 해당 슬롯을 재사용하면 잘못된 형식의 포인터를 읽어 공유 OPcache 상태를 손상시킵니다. Wiz는 backtrace 결함으로 Drupal에서, OPcache 결함으로 WordPress에서 인증 전 RCE를 시연했습니다.

AI 활용과 공개 일정

Wiz는 Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol을 연구에 사용했다고 밝혔습니다. 특히 Gemini 4 Argon이 취약점 발견과 익스플로잇 개발, 공격 탐지, 패치 검증에 기여했다고 설명합니다. 연구팀의 주장은 AI가 PHP 버전과 설정, 메모리 배치에 맞춰 익스플로잇을 조정하고 실패를 분석해 반복 시험하는 데 필요한 전문 작업을 줄였다는 것입니다. 복수의 결함을 연결하고 각 환경에서 시험과 디버깅을 반복해야 했던 과정이 AI와 도구를 활용해 실용적인 공격으로 이어졌다고 설명합니다.

공개 일정에 따르면 Wiz는 2026년 8월 19일 첫 취약점을 발견했고, 8월 20일 Drupal, 8월 21일 WordPress에서 인증 전 RCE를 확인했습니다. 8월 24일 PHP 보안팀에 보고했고, PHP는 9월 21일 보고를 확인해 조정된 수정 작업을 시작했습니다. PHP 수정판과 공개 발표는 10월 21일 이뤄졌습니다. Wiz는 PHP 팀, Calif, OpenAI 및 여러 클라우드·CDN 업체와 패치 검증과 탐지, 패치 적용이 어려운 조직을 위한 완화책을 준비했다고 밝혔습니다. 원문은 패치가 근본적인 해결책이라고 권고하며, 패치 전에는 비정상적인 multipart 요청과 메모리 제한 오류, 반복되는 HTTP 500 응답, 예상 밖의 PHPSESSID 쿠키, 설명되지 않는 작업자 교체를 조사 단서로 들었습니다.

Reddit 반응

  • @Wild-Turn7693 — PHP 엔진을 통해 WordPress, Drupal, Joomla 세 곳에서 인증 전 RCE를 구현한 Wiz의 작업은 상당합니다. 오래된 컨테이너나 내부 서비스에서 PHP 버전이 무엇인지 모르는 회사가 많습니다. CMS를 업데이트해도 밑단 런타임은 고쳐지지 않습니다. 오래된 컨테이너가 계속 트래픽을 처리한다면 기본 이미지를 다시 빌드해도 해결되지 않습니다. 어디 있는지조차 모르는 PHP 배포 환경을 패치하느라 고생하겠네요.
  • @Fun_Comfort_9803 — 메모리 공개 문제도 주목해야 합니다. 공격자가 PHP 작업자에서 API 키나 세션 토큰을 가져갔다면 런타임을 패치해도 그 자격 증명은 무효화되지 않습니다. 악용 흔적을 찾은 팀은 노출된 비밀 정보가 있는지 확인하고 교체해야 합니다.
    • @Wild-Turn7693 — 애플리케이션 담당자도 참여해야 합니다. PHP 작업자의 메모리에 어떤 데이터베이스 자격 증명, API 토큰, 세션 비밀값이 있었는지는 그들이 알고 있습니다. PHP 버전 검사만으로는 무엇을 교체해야 하는지 알 수 없습니다.
  • @EthicalExaggeration — 공개 금지 시점 6시간 전에 수정 바이너리를 배포한 건 엉망이었습니다. 누구든 빌드를 비교해 취약 코드를 좁힐 수 있었고, 관리자는 공식 권고를 기다리는 중이었습니다. 공격자에게 큰 선행 시간을 준 셈입니다.
    • @radcorp — 이 취약점을 보고한 쪽이 Wiz이고 두 달 넘게 작업했습니다. 뭐가 그렇게 놀랍다는 건가요?
    • @Wild-Turn7693 — PHP 런타임을 통해 주요 CMS 세 곳에서 인증 전 RCE를 구현한 건 인상적입니다. 연구에 두 달이 걸렸다고 해서 쉬운 작업이 되는 건 아닙니다.
  • @DeCiel — php2shell 취약점 발견 관련 통화에 참여했습니다. 기본적으로 Gemini 사이버 모델을 사용해 취약점을 발견했다고 합니다. 모회사가 최첨단 모델을 만들고 무료로 무제한 이용할 수 있는 상황이죠.
  • @ReadGroundbreaking17 — 더 설명해 주시겠어요, 아니면 우리가 속마음을 알아서 읽어야 하나요?

원문: Wiz 블로그 / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗