보안 권고: 치명적인 원격 코드 실행 취약점이 있으니 지금 바로 업데이트하세요

요약

PHP가 인증 없이 원격 코드를 실행할 수 있는 치명적 취약점 두 개를 고치고 즉시 업데이트를 당부했습니다.

PHP 프로젝트가 10월 21일 공식 사이트에 올린 보안 권고입니다. 새로 나온 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35가 두 취약점을 고쳤고, 웹 요청을 처리하는 모든 PHP 설치가 위험하다고 밝혔습니다.

왜 중요한가

PHP-FPM, mod_php, FrankenPHP 등 실행 방식과 관계없이 웹 요청을 받는 PHP는 모두 영향을 받습니다.
위험이 가장 큰 mod_php에서는 애플리케이션 코드가 돌기 전에 인증 없는 요청 하나로 공격이 시작되는 사례가 확인됐습니다.
지원이 끝난 PHP 8.1 이하 사용자는 배포판의 백포트(새 수정을 옛 버전에 옮긴 것)에 기대거나 버전을 올려야 합니다.

핵심 내용

첫째 취약점은 메모리 부족 처리 중 덜 초기화된 요청 데이터를 정리 단계가 정상 데이터로 착각하는 문제입니다.
둘째 취약점은 이미 해제된 메모리를 가리키는 요청 상태가 남아, 같은 워커(요청 처리 프로세스)의 다음 요청이 이를 쓰는 문제입니다.
리눅스 배포판과 LTS 업체는 패치를 미리 받았고, 보안팀은 PHP 7.4~8.1용 최소 소스 백포트도 따로 공개했습니다.
당장 올릴 수 없다면 메모리 한도 해제, 요청 크기 축소, 업로드 진행률 기능 끄기로 노출을 줄이라고 했습니다.
다만 이런 완화책은 특정 공격 경로만 막을 뿐 설치를 안전하게 만들지는 못한다고 강조했습니다.

HN 반응

일부 이용자는 멀티파트 요청 차단과 업로드 진행률 끄기 설정을 공유했고, 이것만으로는 막을 수 없다는 반론도 나왔습니다.
일부 기관만 패치를 미리 받은 탓에 정보가 새어 나갔다는 비판과, 공개 유예(엠바고)가 그래도 쓸모 있다는 반론이 맞섰습니다.

30개 표시 · 전체 650개

nr37813시간 전 HN

수정된 버전이 예정보다 조금 일찍 배포됐고, 기술적인 세부 내용도 전부 공개됐습니다.

https://www.php.net/archive/2026.php#2026-10-21-5

OOM 메모리 손상을 통한 RCE - https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

오래된 전역 상태를 통한 RCE - https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
jamietanna11시간 전 HN

PHP 재단이 공식적으로 정리한 취약점 설명과, 공개 및 수정까지의 일정에 관한 내용입니다: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
headinthesky11시간 전 HN

지금까지 나온 얘기로는 이 취약점이 꽤 오래전부터 알려져 있었던 것 같습니다. 그러니 패치도 다 준비해 두고 한꺼번에 내보낼 시간이 있었던 거죠.

저는 아직 컨테이너 업데이트와 패키지 업데이트를 기다리는 중입니다. cpanel이나 plesk는 아무 소식도 없고요. 이게 무슨 난장판인지.
00deadbeef10시간 전 HN

cPanel이 아무 공지를 안 했을 수는 있어도, 패치는 이미 나와 있습니다.
headinthesky9시간 전 HN

네, 20~30분 전에 막 나왔더군요. 지금 고객사들 업그레이드하는 중입니다.
elyobo12시간 전 HN

그렇다면 권장된 완화책(multipart 폼 차단, 업로드 진행률 기능 비활성화)이 실제로 도움이 되는 셈이네요. 충분하다고까지는 못 하더라도요.
TekMol17시간 전 HN

여기서 많은 분이 패치를 더 일찍 내놓으라고 합니다.

하지만 수정본을 일찍 공개하면 피해가 줄어들지 커질지는 분명하지 않습니다.

패치가 있으면 익스플로잇을 만들기가 아마 더 쉬워질 겁니다. 그러면 공격 횟수가 늘어나겠죠.

전 세계가 더 이른 시각에 맞춰 움직이도록 조율할 방법은 없습니다. 인스턴스를 패치해야 하는 사람이 수십만 명은 될 거라고 봅니다.

이 문제를 적극적으로 지켜보는 사람은 이미 인스턴스를 내릴 수 있는 상황이고요.

그렇다면 경종을 울려서 최대한 많은 사람이 지금 웹서버를 내리게 하고, 14시에 패치하게 하는 것이 피해를 최소화하는 데는 가장 좋을 수도 있습니다.

그리고 "shutdown -h now" 한 다음 나중에 다시 켜서 "apt update && apt upgrade"를 하는 것만으로는 부족합니다. 머신이 다시 올라오는 순간 해킹당할 수 있으니까요. 그러니 다음 부팅 때 웹서버가 시작되지 않도록 해야 합니다. Apache라면 "rm /etc/systemd/system/multi-user.target.wants/apache2.service" 같은 식으로 하고, 패치를 마친 뒤에 "ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/apache2.service" 같은 명령으로 심볼릭 링크를 다시 만들면 됩니다.
dmsch17시간 전 HN

PoC가 이미 여러 개 나와 있고, Cloudflare에 따르면 이 취약점은 이미 실제로 악용되고 있습니다: https://x.com/dok2001/status/2112811965735202970
AndroTux17시간 전 HN

이 문제를 적극적으로 지켜보는 사람은 이미 인스턴스를 내릴 수 있는 상황이고요.

이론상으로는 그렇죠. 현실에서는 몇 시간씩 서비스를 멈추겠다고 마음대로 결정할 수 없는 곳이 많습니다.
Gigachad16시간 전 HN

그럼 서버를 아무 해커한테나 내주는 쪽을 택하면 되겠네요.
yreg15시간 전 HN

서비스를 내린 큰 곳이 있기는 한가요? 위키백과는 왜 아직 멀쩡하죠, 완화에 성공한 건가요? Etsy는요?

whitehouse.gov, TechCrunch, Time 같은 WP 사이트들은요?

이름 알 만한 곳 중에 내려간 데는 안 보이는데요.
tux315시간 전 HN

위키백과는 어제 위키 본체를 패치했지만, 다른 도구들은 대부분 지금 다운된 상태입니다.

어제 정보가 샌 것도 일부는 사전 통지를 받은 사람이 너무 많았기 때문입니다.
mx7zysuj4xew14시간 전 HN

이게 어떻게 돌아가는 건지 이해를 못 하시는 것 같네요.

익스플로잇이 "유출"될 수 있는 건 APT가 쓰는 비공개 0day일 때뿐입니다.

경고가 나갔다면 이미 공개된 사실이에요. 엠바고 같은 걸 유지하는 건 의미 없는 쇼일 뿐입니다.
crote14시간 전 HN

"Windows 11에 치명적인 취약점이 있다."

자, 유출입니다. 이제 공개된 사실이니 사람들이 당장 악용하는 걸 보게 되겠죠? 하지만 이를 고치는 커밋이나 패치가 없고 우회책에 대한 암시조차 없다면, 그건 건초 더미에서 바늘 찾기입니다. 그야 정말 어디에나 있을 수 있으니까요!

사실 너무 잘 숨어 있어서 저도 아직 못 찾았습니다. 하지만 코드베이스가 워낙 방대하니 통계적으로 반드시 존재할 테고, 그러니 어딘가에 있다고 봐야 합니다. 방금 제가 W11 사용자 전원을 사지로 몰아넣은 건가요? 아니면 엠바고도 어느 정도는 쓸모가 있는 걸까요?
mx7zysuj4xew8시간 전 HN

핵심을 놓치고 계십니다.

여기서 "내부자 그룹이 아닌 사람들"은 전부 놀림감이 된 기분이다. OpenAI와 보안 업체들이 이걸 두 달 동안 쥐고 있으면서, 누가 먼저 수정본을 받을지 자기들끼리 정하고, 나머지는 방치했다.

자기들끼리와 벤더 사이에서만 비밀로 했다면 효과가 있었을 겁니다.

그런데 이들이 여러 곳에 선별적으로 정보를 풀었고, 그중 한 곳이 곧바로 유출했습니다.

충분히 예상할 수 있었던 결과입니다.

100% 조용하든가, 아니면 다 퍼지든가 둘 중 하나입니다.
Gigachad15시간 전 HN

참고로 https://www.cyber.gov.au/alert/critical-vulnerabilities-in-php 도 다운됐습니다. deviant art 같은 중간 규모 사이트들도 지금 상당수가 내려가 있고요.
Shank15시간 전 HN

Wordpress VIP와 위키백과는 패치를 미리 받았을 거라고 짐작합니다. 어쨌든 PHP를 가장 많이 쓰는 곳들이니까요.
thinkingtoilet15시간 전 HN

권고대로 업로드를 막았을 뿐입니다. 우리가 내린 결정은 "서버를 아무 해커한테나 내주겠다"는 게 아니라고요.
xena14시간 전 HN

유일한 완화책은 영향받는 서비스로 가는 모든 트래픽을 차단하는 겁니다. 우마무스메도 스스로 서비스를 내리고 있어요. 가챠 게임도 하는 다운타임을 감수 못 할 이유가 없잖아요.
nubinetwork14시간 전 HN

umamusume

모바일 게임이 어떻게 PHP를 쓰죠? 게임 코드는 통신에 자체 소켓과 프로토콜을 쓰는 거 아닌가요?
gyaru13시간 전 HN

Cygames는 PHP를 엄청 좋아해서, 대부분의 게임 백엔드가 거의 PHP예요 ㅋㅋ
nubinetwork13시간 전 HN

그래서 확률이 그렇게 끔찍했던 건가 싶네요...
nkozyra14시간 전 HN

그건 효과적인 대응책이 아닙니다.
fredsted17시간 전 HN

참고로 익스플로잇은 이미 자유롭게 구할 수 있습니다. 이런 건 막을 수 없어요.

그게 아니더라도, 이미 공개된 정보만으로 본인이나 우리 에이전트가 익스플로잇을 만들 수 있고요.
cinpol17시간 전 HN

100% 확신하세요? 저는 PoC 2개를 개발 환경에 시험해 봤는데 아직까지는 안 됩니다. 그래서 이미 동작하는 익스플로잇이 있는지는 잘 모르겠네요.
TekMol17시간 전 HN

공개된 익스플로잇이 곧 패치될 그 버그를 노린 거라는 확인은 못 봤습니다.

공개된 익스플로잇은 multipart POST 요청을 걸러내면 쉽게 막을 수 있는 것 같습니다. 그러니 상황을 적극적으로 지켜보는 사람들은 그런 요청을 걸러서 이미 그 문제를 막을 수 있습니다.
system217시간 전 HN

저는 10분도 안 걸려서 뭔가를 만들어 내서 여러 사이트에 시험해 봤습니다. 따라 하기에 충분한 설명이 있는 페이지가 있어요.
rtuin17시간 전 HN

RCE 테스트까지 성공하셨나요, 아니면 취약점 확인만 하신 건가요? 지금까지 제가 찾은 글과 PoC는 전부 RCE 부분을 "현금화"하는 데는 실패하더군요.
system217시간 전 HN
메모리 손상까지는 끌고 갔습니다. 지금 제가 있는 곳은 새벽 3시라서, 아침에 이어서 하려고요. 일단 예방 차원에서 .htaccess 규칙을 설정했습니다.
```
  # BEGIN php2shell-mitigation
  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP:Content-Type} multipart [NC]
  RewriteRule .* - [F,L]
  </IfModule>
  <If "%{HTTP:Content-Type} =~ /multipart/i">
  Require all denied
  </If>
  # END php2shell-mitigation
```
php-fpm이 뭔가를 받기 전에 multipart를 무시하도록 rewritecond를 추가했습니다. nginx 서버에도 비슷하게 했고요. 그리고 .user.ini에 "session.upload_progress.enabled = Off"도 넣었습니다.

이 두 가지면 될 것 같긴 한데, 내일 아침에 더 깊이 파 보기 전까지는 1000% 확신하지는 못합니다. 눈은 타들어 가는데, 이 익스플로잇 때문에 스트레스를 받아서 잠도 못 자겠네요.
Macuyiko17시간 전 HN

저는 caddy에서 같은 설정을 했습니다:

@multipart header_regexp Content-Type (?i)multipart respond @multipart 403

@uploads_php path_regexp uploads_php ^/(?:./)?wp-content/uploads/..php(?:/.*)?respond @uploads_php 404

거기에 php.ini 변경("session.upload_progress.enabled = Off"와 strict mode)도 더했고요. 패치가 나올 때까지 버텨 주길 바랍니다.

Hacker News에서 보기 ↗