Reddit

PHP2Shell security flaws now sucessfully exploited in the wild

PHP2Shell 취약점, 실제 공격에서 악용 확인

연구자 Adel Karimi가 PHP 8.4.26과 Apache mod_php를 구동하는 허니팟에서 PHP2Shell 취약점의 메모리 정보 노출과 원격 명령 실행을 확인했습니다. 이번 증거는 특정 단일 워커 환경에서 나온 결과로, 다른 구성에서의 성공률이나 실제 서비스 침해 규모를 보여주지는 않습니다.

에디터 노트

이번 관측은 PHP2Shell이 공격자의 실제 원격 명령 실행으로 이어졌다는 점을 뒷받침합니다. 메모리 덤프에서 계산한 주소가 후속 페이로드에 들어갔다는 설명은 단순 스캔이나 충돌 기록보다 강한 증거입니다. 반면 Karimi가 명시했듯 단일 워커 mod_php 환경의 결과이므로, 이를 다른 구성의 성공률이나 운영 서버 침해 규모로 넓혀 읽을 근거는 없습니다. Reddit에서는 허니팟도 외부 공격자가 침입했다면 실제 악용으로 볼 수 있다는 주장과, 의도적으로 유리한 조건에서 반복 공격한 사례를 운영 환경과 구분해야 한다는 반론이 맞섰습니다. 둘은 서로 다른 질문에 답합니다. 허니팟 관측은 공격자가 작동하는 경로를 찾았다는 증거지만 실제 피해 규모를 말해주지는 않습니다. 댓글에서 제기된 낮은 트래픽과 반복 시도 조건도 이번 증거의 적용 범위를 따지는 데 유효하지만, 그것만으로 일반적인 PHP 서버가 안전하다고 결론 내릴 수는 없습니다. 패치 적용 뒤 실행 중인 PHP 프로세스가 새 코드를 쓰도록 재시작해야 한다는 댓글의 지적도 운영상 빠뜨리기 쉬운 조건입니다.

AI 요약

연구자 Adel Karimi가 운영하는 허니팟에서 PHP2Shell로 묶인 두 원격 코드 실행(RCE) 취약점, CVE-2026-109618과 CVE-2026-109619의 실제 악용 증거가 확인됐습니다. 대상은 PHP 8.4.26과 Apache mod_php를 실행하는 시스템입니다. 앞서 보안 업체들은 공격 시도와 취약점 탐색을 포착했지만, 작동하지 않는 익스플로잇으로 판단했습니다. 이번 관측은 취약점 악용으로 원격 명령 실행에 성공한 사례를 보여줍니다.

공격 증거와 적용 범위

Karimi에 따르면 공격 응답은 디코딩한 800 KiB 쿠키 덤프를 전달했습니다. 공격자는 덤프에서 공개 익스플로잇의 오프셋을 이용해 함수 주소를 계산했고, 그 주소가 뒤이은 실행 페이로드에 포함됐습니다. Karimi는 이 연결이 단순한 충돌 뒤 의심스러운 프로세스가 나타난 사례가 아니라, 메모리 정보 노출과 RCE가 이어진 증거라고 설명했습니다.

다만 관측 환경은 의도적으로 성공에 유리한 단일 워커(single-worker) mod_php 설정입니다. Karimi는 다른 워커 수, PHP 빌드, 애플리케이션에서의 익스플로잇 신뢰도를 측정한 결과가 아니라고 선을 그었습니다. Expel의 위협 연구원 Marcus Hutchins는 해당 분석을 확인하고, 자신이 본 실제 PHP2Shell 악용 증거 중 가장 설득력 있는 사례라고 평가했습니다.

패치와 추가 취약점

PHP 보안팀은 10월 21일 두 취약점의 패치를 공개했습니다. 패치 전에 CVE 번호와 일부 완화 정보가 유출되고 개념 증명(PoC) 익스플로잇도 공개됐지만, PHP 보안팀은 당시 공개된 익스플로잇이 작동하지 않는다고 밝혔습니다. Amazon Threat Intelligence도 패치 공개 나흘 전부터 공격자의 표적화 시도를 포착했으나, Dataminr TRACE 팀은 당시까지 탐색과 핑거프린팅, 작동하지 않는 익스플로잇만 확인했고 알려진 침해는 없었다고 전했습니다.

CISA는 PHP2Shell 공격 시도를 탐지하는 SIGMA 규칙을 공개했지만, 이 취약점들을 실제 악용 중인 취약점으로 지정하지는 않았습니다. PHP 보안팀은 별도의 RCE 취약점 CVE-2026-115560에 대해서도 패치 전 완화책을 안내했습니다. 이 취약점은 특이한 설정과 애플리케이션 코드가 함께 있을 때만 악용될 수 있으며, 패치가 나오기 전까지 session.upload_progress.enabled=0으로 설정하라고 권고했습니다.

Reddit 반응

  • @rankinrez — 의도적으로 성공에 유리하게 설정한 단일 워커 mod_php 환경입니다.
  • @mb194dc — 허니팟과 비트코인 탈취 실험 서버 모두 취약한 PHP 버전과 단일 워커, Apache를 사용했습니다. 공격자는 구성을 알고 있었고, 실제 서버보다 메모리 잡음이 적었습니다. 첫 셸에 성공하기까지 OOM 오류 30회와 프로세스 충돌 11회가 있었습니다.
  • @burgonies — 취약한 PHP 버전, Apache, 표준 메모리 설정, 적은 트래픽, WAF·EDR·모니터링 부재가 PHP 환경에서 예외라고 생각한다면 현실을 다르게 경험한 것 같습니다.
  • @cookiengineer — 첫 번째 CVE는 메모리 배치를 조금 조정하면 쉽게 악용할 수 있으며, 자신과 다른 연구자들이 각각 재현했습니다. 두 번째 CVE에는 첫 번째 취약점만으로 확보하기 어려운 힙 데이터가 더 필요하지만, CI/CD 환경에서는 컨테이너로 조건과 오프셋을 재현할 수 있다고 설명했습니다.
  • @aleqqqs — 허니팟의 조건은 실제 운영 환경과 어떤 점에서 다른가요?
  • @Glaive13 — 일부러 취약하게 만든 허니팟이 공격당한 일을 실제 공격 악용이라고 부르는 건 이상합니다.
    • @threeLetterMeyhem — 운영자가 허니팟을 의도적으로 취약하게 만들었더라도, 연구자나 허가받은 모의 침투자가 아닌 외부 공격자가 침입했다면 실제 공격입니다.
  • @BTC-brother2018 — 허니팟 침해가 실제 운영 시스템 침해와 같은 뜻은 아닙니다.
  • @sajkoterrapefft — 공격자가 익스플로잇을 다듬는 데 시간이 걸렸을 뿐, 이제 대규모 악용으로 이어질 수 있다는 신호라고 생각합니다.
  • @CitronSpirited9681 — 패키지를 업데이트해도 이미 실행 중인 PHP-FPM이나 Apache 프로세스의 메모리 속 코드는 바뀌지 않습니다. 패치 후 재시작을 놓칠 수 있으니 업데이트 시각과 프로세스 시작 시각을 대조하면 됩니다.

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

원문 보기 ↗토론 보기 ↗