이건 아직 공식적으로 공개 유예 중인 취약점은 아닌 것으로 확신함. 실제 취약점 두 개를 찾은 듯하며, 둘 다 비슷한 형태의 해제 후 사용(UAF) 취약점임.
내 시스템에는 패치를 적용했고 제대로 막혔기를 바라며, 트래픽을 탐지기로 미러링하면서 첫 공격이 언제 잡힐지 지켜보는 중임. 실제 공격 시도나 전체 내용 유출을 확인하기 전까지는 패치를 공개하지 않을 계획임.
이번 게시물은 실제 공격 코드라고 내세우고 있음. 이전 것은 구체적인 내용이 없는 PHP 측 공지였음.
현재 게시물은 개념 증명(PoC) 인데, 단순한 경고 공지가 어떻게 더 나은 출처라는 것인지 모르겠음. 더 못하다고 하는 자료도 읽지 않고, 추천하는 자료 역시 읽지 않아 실제 내용과 다르게 소개하고 있음.
Nginx에서 PHP로 향하는 multipart 요청을 차단하면 임시로 막을 수 있음. 여러 폼이 작동하지 않겠지만 해킹당하는 것보다는 나음.
Nginx 설정은 if ($http_content_type ~* "multipart") { return 403; }처럼 적용하면 됨.
php.ini에서 session.upload_progress.enabled = Off로 업로드 진행 상황 추적을 끌 수도 있지만, 모든 경우를 막지는 못하는 듯함.
https://jackalsyn.com/posts/php-up-2026.html의 PoC 코드를 조금 살펴보니, 완전히 작동하는 코드는 아닌 것으로 상당히 확신함.
이 코드는 세션을 다시 불러올 때 PHP가 업로드 진행 데이터를 해제한다고 가정함. 하지만 우리가 쓰는 PHP 8.4.24는 Z_TRY_ADDREF(progress->data)를 호출해 데이터를 유지하며, 다른 버전은 모르겠음. 조작된 함수 호출에도 유효하지 않은 필드가 들어 있는 듯함.
의심하는 대상은 이 PoC이지 공식 PHP 보안 경고가 아님. 공격을 재현하지 않았으므로 코드 검토에 따른 의문일 뿐, 실제 취약점을 악용할 수 없다는 증거는 아님. 어쨌든 CVE는 여전히 존재하고 공격이 multipart와 연결되므로, 전체 서비스를 끄지 않으려면 지금은 multipart를 차단하는 게 최선으로 보임.
업로드가 필요 없는 PHP 사이트라면, 이 취약점을 완화하기 위해 multipart/form-data POST 처리를 정확히 어떻게, 어디까지 비활성화해야 함?
PHP에 도달하기 전에 웹 서버에서 차단하면 됨. 이 스레드에서 nginx나 .htaccess를 검색하면 설정을 찾을 수 있음.