Reddit

PHP2Shell: Critical vulnerabilities in the backbone of the web

PHP2Shell: 웹 기반을 위협하는 PHP 핵심 치명적 취약점

PHP 핵심 코드에서 메모리 부족 처리 오류와 요청 간 전역 상태 잔존이라는 두 취약점이 발견됐습니다. 인증 없이 원격 코드 실행이나 PHP 프로세스 메모리 유출이 가능하며, 완전한 해결책은 영향을 받는 PHP 런타임을 패치 버전으로 업데이트하고 관련 프로세스를 재시작하는 것입니다.

에디터 노트

이번 취약점의 범위는 WordPress나 Drupal의 플러그인 문제가 아니라 PHP 런타임입니다. 그래서 애플리케이션 업데이트만으로는 대응이 끝나지 않으며, 안내된 수정 버전으로 런타임을 올리고 작업자까지 재시작해야 합니다. 설정 완화책도 각각 특정 경로만 줄이고 기능이나 가용성에 부담을 줄 수 있습니다. 댓글에서는 C 기반 런타임의 메모리 안전성과 PHP 선택을 둘러싼 논쟁이 이어졌습니다. 이번 사례만으로 PHP 언어 전체의 설계 결함을 입증했다고 보기는 어렵지만, 런타임 구현의 메모리 안전성 문제가 널리 배포된 서비스에 큰 영향을 준다는 점은 분명합니다. AI가 발견과 악용 연결을 가속했다는 연구진의 설명에는 취약점이 2024년부터 알려졌다는 댓글의 보완이 붙습니다. 발견 시점과 실제 공격 가능한 경로를 만든 시점을 구분해야 하는 쟁점입니다.

AI 요약

PHP2Shell은 PHP 런타임에서 발견된 두 종류의 메모리 안전성 취약점을 묶어 부르는 이름입니다. 취약점은 애플리케이션 코드가 아니라 PHP 자체에 있어 WordPress, Drupal, Joomla뿐 아니라 취약한 PHP 버전으로 실행되는 다른 서비스에도 영향을 줄 수 있습니다. 연구진은 인증 없이 원격 코드를 실행하고 다른 요청의 비밀번호, 인증 토큰, API 키, 인증서 등이 담긴 PHP 프로세스 메모리를 읽는 공격을 시연했습니다. 메모리 유출은 코드 실행 없이도 발생할 수 있습니다.

취약점과 영향

CVE-2026-109618은 메모리 부족(out-of-memory) 처리 과정에서 발생하는 메모리 손상입니다. 연구진은 이를 이용해 WordPress, Drupal, Joomla에서 인증 전 원격 코드 실행을 보였습니다. CVE-2026-109619는 요청 사이에 남는 전역 상태(stale global state)와 use-after-free 문제입니다. WordPress와 Drupal에서 원격 코드 실행을, 애플리케이션에 종속되지 않는 메모리 유출을 시연했습니다. 두 취약점의 심각도는 CVSS 9.2로 기재됐습니다. PHP 5.4부터 영향을 받은 릴리스가 있으며, 각 버전과 취약점에 따른 노출 여부는 다를 수 있다고 안내합니다.

패치와 임시 완화

완전한 해결책은 PHP 런타임을 패치 릴리스로 올린 뒤 Apache, PHP-FPM과 장기 실행 작업자를 재시작하는 것입니다. 안내된 최초 수정 버전은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12입니다. 애플리케이션만 업데이트해서는 런타임 취약점이 해결되지 않습니다.

즉시 업데이트하기 어렵다면 일부 공격 경로의 노출을 줄이는 설정을 적용할 수 있지만, 패치를 대신하지는 못합니다. memory_limit=-1은 메모리 제한 처리에 의존하는 일부 공격 경로를 막을 수 있지만, 메모리 고갈 대응을 운영체제에 넘깁니다. 이때 cgroup v2의 memory.max 같은 자원 제한을 함께 적용하라고 안내합니다. RLIMIT_AS와 RLIMIT_DATA는 같은 취약한 오류 경로를 일으킬 수 있어 대체 수단으로 쓰지 말라고 합니다. post_max_size와 max_input_nesting_level을 낮추거나 세션 업로드 진행률 기능을 끄는 방법도 일부 메모리 압박 경로만 제한합니다. display_errors를 끄고 fatal_error_backtraces를 비활성화하면 특정 정보 유출 경로를 줄일 수 있으며, PHP-FPM 작업자를 더 자주 교체하면 요청 사이에 상태가 남는 위험을 낮출 수 있습니다. 각 설정은 애플리케이션 기능이나 가용성에 영향을 줄 수 있습니다.

패치 뒤에도 메모리 제한과 요청 크기를 애플리케이션 사용량에 맞춰 검토해야 합니다. 수정 버전에는 하드 메모리 제한이 추가되며, 한도에 도달하면 프로세스가 종료되고 종료 처리기가 실행되지 않습니다. SELinux나 AppArmor는 작업자의 권한과 프로그램 실행을 제한하는 보완책으로 제시되지만, 모든 공격이나 메모리 유출을 막는 대책은 아닙니다. 이상하게 크거나 형식이 잘못된 PHPSESSID 응답 쿠키, 비정상적인 multipart 요청 뒤의 메모리 오류나 반복된 HTTP 500, 설명되지 않는 PHP 작업자 충돌과 재시작은 조사 신호가 될 수 있습니다. 이런 신호만으로 침해를 확정할 수 없고, 흔적이 없다고 영향이 없다고 판단할 수도 없습니다.

Reddit 반응

  • @u/throwaway490215 — 너무 큰 요청으로 PHP가 테이블을 만들다 메모리 할당에 실패하면, 항목 수는 증가했지만 해당 슬롯은 쓰이지 않은 상태가 될 수 있습니다. 정리 과정이 그 슬롯까지 순회하면서 실제 객체가 아닌 메모리를 포인터와 유형 정보로 취급하고, 그 결과 공격자가 원하는 주소에 쓰기를 유도할 수 있다는 설명입니다.
    • @u/tripleplay23 — 설명대로라면 큰 요청 뒤 정리 과정에서 PHP 서버가 바로 충돌할 것 같습니다. 실제 공격에는 더 복잡한 조건이 있나요?
    • @u/artofthenunchaku — 해당 요청을 처리한 작업자는 충돌하지만 PHP 서버 전체가 종료되는 것은 아니라고 이해했습니다. 작업자가 충돌하기 전에 공유 메모리에 자료 구조를 남기고 다른 작업자가 이를 가져간다는 설명입니다.
    • @u/throwaway490215 — 작업자 충돌은 보통 500 오류로 나타납니다. 이를 실제 공격으로 만드는 과정이 어렵고, 공개된 동작 코드가 있는지는 모르겠다고 덧붙였습니다.
  • @u/currentscurrents — 취약점을 발견한 그룹의 설명을 링크하며 AI 도구, 특히 Gemini 4를 발견 과정의 공으로 돌렸다고 전했습니다.
    • @u/MorrisonLevi — 취약점의 핵심은 2024년에 이미 알려졌지만 실제 악용 방법을 찾기 어렵고 수정도 까다로워 우선순위가 밀렸다는 설명을 덧붙였습니다. AI가 이론적으로 위험한 문제를 실제 공격으로 잇는 과정을 크게 가속했을 수 있다고 봤습니다.
    • @u/PascalsBadger — 사전 발표와 유출 뒤 한 보안 업체가 실수로 공개한 영상이 여러 표적에서 동작하는 개념 증명을 보여줬고, 삭제된 영상의 복사본이 퍼지며 PoC 개발과 유통이 빨라졌다고 적었습니다.
  • @u/hazpotts — PHP를 선택한 사람을 탓하기보다, 널리 쓰이는 런타임의 취약점이라 영향 범위가 큰 점을 봐야 한다고 주장했습니다. PHP 7과 8은 이전보다 나아졌고 Python과 Node도 C/C++ 런타임을 쓴다고 덧붙였습니다.
    • @u/throwaway490215 — 언어와 런타임의 설계 선택도 중요하며, 메모리 안전 보장이 없는 C 기반 구현이 PHP의 위험을 키운다고 반박했습니다.
    • @u/chucker23n — PHP라는 언어 자체보다 C로 구현한 런타임 선택의 문제로 볼 수 있고, 더 안전한 언어로 재구현하는 방안도 있다고 답했습니다.
  • @u/bagabe — 오래되고 널리 쓰이는 언어와 런타임에는 여러 세대에 걸쳐 취약점이 생긴다며 PHP 생태계 이용자를 탓하는 반응을 비판했습니다.
    • @u/FingerAmazing5176 — 자체 설계와 호스팅 비용을 감당하기 어려운 소규모 업체가 WordPress와 Drupal을 쓰며, 대형 업체도 Drupal 템플릿을 사용한다고 말했습니다.

원문: Wiz / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗