Wiz가 PHP2Shell 공격 시도를 추적했지만 성공 사례는 없었고, 공개 후 인터넷 노출 취약 머신은 67% 줄었다
- Wiz 텔레메트리에서 PHP2Shell 공격 시도는 관측됐지만 성공 사례는 없었고, 임의 대상을 완전히 공격하는 공개 PoC도 아직 확인되지 않음
- Wiz 데이터셋 조직의 65%가 PHP를 쓰는 가운데, 2026년 10월 21일 공개 이후 인터넷에 노출된 취약 머신의 일별 수는 약 67% 감소했고, 취약 인스턴스가 하나 이상 있는 조직 수는 약 47.9% 줄어 일주일 뒤 초기 영향 조직의 53% 미만만 취약하게 남음
- 9bie의 오픈소스 익스플로잇 킷 중 구형 체인은 12,655,437바이트 요청이 8MB post_max_size를 넘어 실패했고, 신형 체인은 PHP 메모리를 고갈시켰지만 필요한 메모리 주소를 얻지 못해 체인을 완료하지 못함
- 103.151.172.95의 Roundcube 공격 시도는 Apache 워커를 점유하려고 연결을 지연시키고 3,000바이트 필드 1,001개로 힙 셰이핑을 했지만 필요한 메모리 고갈 흐름을 만들지 못함
- PHP2Shell 이름을 단 별도 도구는 취약점과 무관하게 세션 포이즈닝과 애플리케이션의 별도 LFI 취약점을 이용한 것으로 관측됨
Hacker News opinions
Wiz 허니팟에서 성공한 PHP2Shell 공격이 없다는 것뿐이지, 취약점 자체는 Steal my Bitcoin 챌린지에서 이미 뚫렸음. Dan Guido가 Trail of Bits에서 유니버설 익스플로잇이 있다고 한 걸로 아는데, 그쪽 실적 보면 일단 믿어볼 만함.
stealmybitcoin.com 글이 HN에 올라왔을 때는 아무도 못 뚫었으니 취약점은 가짜고 AI 마케팅이라는 댓글이 수백 개였음. 실제로 뚫린 뒤로는 조용하고, 그때 댓글 단 사람 대부분은 아직도 모를 거임.
지난주엔 회사들이 php2shell이 몇 달째 활개 쳤다고 하던데, 그랬으면 로그에 이상한 에러가 잔뜩 있어야 하는 거 아님? 나는 아직 좀 수상하게 봄.
LiveOverflow 영상에 자세히 나오는데, 우승자는 KillaBoi PoC임. 챌린지 사이트는 처음엔 PHP가 아니라서 안 뚫렸다가 PHP로 바꾼 뒤 두 시간 만에 뚫렸고, LiveOverflow도 요청 두 번으로 RCE 되는 익스플로잇을 보여줌.
Steal my Bitcoin은 현실적인 PHP 구성이 전혀 아님. 내장 PHP 개발 서버를 쓴 장난감이고, 같은 워커에 요청이 떨어져야 한다는 조건도 챌린지엔 없었음. pm.max_requests=1이면 100% 안전한 거면 유니버설 익스플로잇이라는 말부터 틀린 거 아님?
현대 PHP 운영 스택에서 증명된 취약점은 아직 없음. 챌린지는 php -S 개발 서버를 쓴 장난감이고, OOM corruption도 mod_php에서만 완전한 익스플로잇이 증명됐고 php-fpm은 완전한 익스플로잇이 없다는 게 권고안 내용임. 8.5의 stale global state는 debug fatal_error_backtraces가 켜졌을 때 취약했음.
Trail of Bits가 대체 뭘 했다고 100% 신뢰한다는 건지.
Dan Guido가 유니버설이라고 한 건 아닌 걸로 앎. 걔는 그냥 되는 익스플로잇이 있다고 했고, 공개하면 패치할 시간이 줄어드니까 안 보여준다는 쪽임. Steal my Bitcoin 익스플로잇도 특정 스택에서만 되고, 그래서 사이트에 축소된 phpinfo를 올린 거고.
Bleeping Computer는 성공적으로 악용됐다고 보도했는데, 같은 기사에서 PHP 6도 취약 버전에 넣었음. 걔네 검증 기준은 좀 못 믿겠음.
며칠째 이거에 파묻혀서 타임라인 정리 중임. 특정 구성에서 성공한 사례는 여러 개 있지만 단일 워커 mod_php나 실제 배포와 얼마나 비슷한지 애매한 랩인 경우가 많고, Dan Guido의 광범위 익스플로잇 주장은 세부가 거의 없고, 야생 시도는 수백만 건인데 실제 침해 증거는 적음. Unit 42는 자기 주장을 철회했음.
PHP는 진짜 구리고 오래된 언어라서 널리 쓰이는데 돈과 인력 투자가 적음. 공격자 입장에선 완벽한 표적임.
Adel Karimi 허니팟은 스캐너들이 실제로 익스플로잇했고, CISA가 PHP2Shell을 KEV에 넣은 데도 영향을 줬다고 함. bumblebee, numbat, galah 같은 오픈소스 작업도 대단하고.
패치 중인 팀이라면 인터넷에 노출된 호스트와 컨테이너가 어떤 PHP 버전을 쓰는지 목록부터 만들어야 함. 그 목록이 비어 있는 경우가 많고, 패치해도 이미 심어진 건 안 없어지니까 웹 루트와 업로드 디렉터리에서 새 PHP 파일이나 수정된 파일을 찾고 패치 전 접근 로그도 봐야 함. 허니팟 성공률이 낮다고 내 서버가 안전한 건 아님.
Fil-C로 PHP 포팅하는 건 GitHub에 올라와 있고, 테스트해 보니 모든 익스플로잇이 DoS로 바뀐다고 함.
벤치마크는 돌려봤음? Zend 할당자가 세밀한 추적과 잘 안 맞아서 시스템 할당자로 바꿔야 한다는 얘기도 있던데.
어떤 테스트와 어떤 PoC로 확인한 건지 궁금함. 공개 php2shell 킷은 이미 stock 8.4에서 워커를 8/8 크래시시키고 0/8 셸만 얻었고, OOM 터지는 건 memory_limit이 설계대로 동작한 거지 시스템 익스플로잇이 아님. Pix 아니면 증거를 내놔.