PHP2Shell, 공개 나흘 전부터 공격 탐지돼…패치뿐 아니라 과거 기록도 확인해야 할까

AI 요약

PHP 보안 취약점 PHP2Shell 두 건이 패치 공개 전부터 공격 시도의 표적이 됐습니다. AWS는 허니팟에서 10월 17일 공격 시도를 확인했다고 밝혔고, 취약점 정보와 PoC 영상도 공개 일정 전에 유출됐습니다. 패치 적용과 함께 침해 흔적을 되짚는 대응이 필요하다는 질문이 Reddit에서 제기됐습니다.

취약점과 영향 범위

CVE-2026-109618은 메모리 부족(out-of-memory, OOM) 상황에서 발생하는 손상 문제이며, CVE-2026-109619는 오래된 전역 상태(stale global state) 문제입니다. 두 취약점의 CVSS 점수는 9.2입니다. Apache의 mod_php 환경에서는 인증 없이 원격 코드 실행(RCE)이 확인됐습니다. PHP 재단은 웹 요청을 처리하는 PHP 설치라면 PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed를 포함해 위험에 노출될 수 있다고 밝혔습니다.

취약점은 PHP 5.4 이후 거의 모든 릴리스에 영향을 줍니다. PHP 재단은 패치를 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35에 포함했고, PHP 7.4, 8.0, 8.1용 최소 소스 백포트도 공개했습니다. 취약점은 민감한 프로세스 메모리를 읽는 데도 악용될 수 있어 자격 증명과 API 키 같은 정보가 노출될 가능성이 있습니다. 재단은 패치가 불가능할 때 일부 공격 경로의 노출을 줄이는 조치를 안내했지만, 그 조치만으로 안전해지지는 않는다고 설명했습니다.

공개 전 공격 시도와 유출

SecurityWeek 보도에 따르면 WatchTowr는 패치가 공개될 무렵 센서에서 실제 공격 시도를 관측했지만 성공 사례는 확인하지 못했습니다. Hadrian, Patchstack, Cloudflare, Vega도 공격 시도를 보고했습니다. Hadrian은 관측한 공격 대부분이 PHP 세션 업로드 진행률(session upload-progress) 경로를 악용했다고 밝혔습니다. AWS는 허니팟에서 공개 나흘 전인 10월 17일 공격 시도를 확인했습니다.

취약점은 10월 22일 책임 공개(responsible disclosure) 일정에 맞춰 공개될 예정이었지만, 관련 정보가 10월 20일 온라인에 유출돼 PHP 재단은 패치를 하루 앞당겼습니다. 작동하는 PoC를 시연한 영상도 일정 전에 실수로 공개돼 PoC 개발을 앞당겼다고 재단은 설명했습니다. 일부 핵심 인프라 기관에 전달된 완화 조언도 유출됐을 가능성이 있습니다. Chainguard가 수정 사항을 포함한 빌드 이미지를 공개한 시점은 정식 공개보다 6시간 이상 빨랐습니다. 재단은 공격자가 정식 패치 전에 바이너리 형태의 수정 사항을 분석할 수 있었다고 지적했습니다.

발견과 패치 범위

Wiz, OpenAI, Calif는 8월 취약점을 발견하고 패치가 준비될 때까지 공개를 보류했습니다. Calif는 PHP의 OOM 문제가 2020년에 처음 발견됐고 2024년 보안 점검 중 다시 확인됐지만, 당시에는 악용 가능성을 입증하지 못해 패치되지 않았다고 설명했습니다. AI 모델을 활용한 분석으로 OOM 결함을 더 깊이 조사했고, 이를 RCE로 연결했습니다. Calif와 OpenAI는 8월 11일 OOM에서 RCE로 이어지는 문제를 각각 보고했고, OpenAI와 Wiz는 추가 공격 경로를 제보했습니다.

Wiz는 두 CVE가 PHP의 메모리 안전성 문제 네 건을 묶었지만 모든 변형을 포괄하지는 않는다고 설명했습니다. 추적된 변형과 아직 추적되지 않은 변형이 함께 존재한다는 분석입니다. PHP는 WordPress, Drupal, MediaWiki 등을 지원하며, Wiz는 전 세계 웹사이트의 70%가 PHP의 영향을 받는다고 밝혔습니다. PHP 재단은 7월 1일 이후 새 CVE 15건을 공개했으며 AI가 PHP 취약점을 더 많이 찾아내는 데 기여했다고 전했습니다.

Reddit 반응

• @ExtremeSet8866 — AWS가 공개 제한이 풀리기 나흘 전인 10월 17일 익명화된 인프라에서 PHP2Shell 공격 시도를 허니팟으로 확인했다고 정리했습니다. 10월 17일부터 웹 및 PHP-FPM 로그를 살펴보고, 특히 멀티파트 요청과 세션 업로드 진행률 요청을 확인하자고 제안했습니다. 메모리 읽기로 노출될 수 있는 비밀정보의 교체와 오래된 가상 호스트, 장비, 스테이징 서버의 점검도 언급하며 룩백 범위와 21일 이전 탐지 여부를 물었습니다.
• @Self-reliantBattling — 17일부터 FPM 로그를 조사하다가 아무도 기억하지 못하던 스테이징 서버에서 수상한 멀티파트 요청을 발견했다고 했습니다.
  • @papajan78 — 어떤 문자열이나 패턴을 검색하는지 공유해 달라고 물었습니다.
• @LLMsMustUpvoteThis — 성공적인 공격이 확인됐는지 물으며, 공개된 세부 정보만으로 공격자가 탐색을 시작했을 수 있지만 취약점 연결 과정이 복잡했고 패치 전에 성공한 사례는 보지 못했다고 했습니다. 공개 대상 정보를 알고 있던 사람들이 더 신중했어야 한다고 덧붙였습니다.
  • @_BB-King_ — 지금까지는 스캔만 봤다고 답했습니다.
  • @InverseX — 성공 사례가 있다고 답하고 우회 PoC 링크를 제시했습니다.
  • @DmitriRussian — 그 링크가 성공적인 침해의 증거가 되는 이유를 물었습니다.
• @alphaxion — 로그를 수동으로 뒤지는 데 그치지 말고 SIEM을 활용하자고 했습니다. Elastic 같은 도구에 로그를 모으면 과거 기록을 검색하고 공개 전 이상 징후도 확인하기 쉽다고 설명했습니다.
  • @Kaligraphic — 중앙 로그 수집은 오래전부터 가능한 방식이라며, 여전히 도입하지 않은 조직은 기술보다 구조나 조직 문제가 있을 수 있다고 답했습니다.
  • @alphaxion — 중앙 수집만으로 충분하지 않으며 대시보드와 경보를 활용해 로그를 능동적으로 분석해야 한다고 덧붙였습니다.
  • @Die_Quelle — 로그를 모아도 평소에 이상 징후를 찾을 인력과 시간이 부족하다고 했습니다.
  • @BooleanOverflow — SIEM에 들어간 로그보다 장비 내부 로그가 더 많을 수 있고, 일부 흔적은 상세 로그에서만 찾을 수 있다고 지적했습니다.
• @yawkat — 룩백 조사를 하다가 두 달간 업데이트를 미룬 개인 WordPress 사이트가 침해된 사실을 발견했다고 했습니다. 공격자는 데이터베이스를 가져갔지만 다른 시스템으로 이동하지는 못했다고 했습니다.
  • @NoSelf5869 — PHP2Shell과 무관한 침해인지 물었습니다.
  • @yawkat — PHP2Shell을 계기로 조사했지만 해당 침해는 PHP2Shell과 관계없었다고 답했습니다.
• @nayntuck2 — 멀티파트 업로드 진행률 경로를 특히 살펴볼 만하다고 했습니다. 일반 액세스 로그에는 관련 정보가 남지 않을 수 있어 해당 기간의 FPM 로그 수준이나 원시 패킷 기록을 확인해야 한다고 덧붙였습니다.
• @ar_e_art — 10월 20일 23시경 일부 핵심 인프라 기관에 완화 조언이 전달됐고 유출 가능성이 있었으며, 10월 21일 07시 41분에는 Chainguard가 수정 빌드를 공개했다고 지적했습니다. 17일부터 정보 유출 시점까지만 볼 것이 아니라 호스트별 실제 패치 시점까지 조사 기간을 늘리자고 제안했습니다.
• @showbizusa25 — SIEM에서 흔적이 보이지 않는다고 서버가 깨끗하다고 단정하지 말라고 했습니다. 필요한 요청 필드가 애초에 기록되지 않았다면 검색할 자료도 없으므로 실제로 무엇을 기록했는지 확인해야 한다고 설명했습니다.
• @PsychologicalFlan877 — 17일부터 21일까지의 기간에 침해가 없었는지 확인하는 일을 패치와 별도의 사고 대응으로 취급해야 한다고 했습니다. 애플리케이션 서버보다 더 오래된 로그를 보유했을 수 있는 엣지, WAF, 로드밸런서 기록부터 확인하겠다고 덧붙였습니다.

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