요약
PHP 8.2.35가 인증 없이 원격 코드 실행을 허용하는 치명적 취약점 두 개를 고쳤습니다.
PHP 개발팀이 보안 업데이트로 PHP 8.2.35를 내놓았습니다. 고친 취약점은 CVE-2026-109618과 CVE-2026-109619이며, 개발팀은 PHP 8.2 사용자 모두에게 즉시 업데이트하라고 당부했습니다.
왜 중요한가
- 로그인 없이 외부에서 서버에 코드를 실행할 수 있는 결함이라 PHP 8.2로 돌아가는 서버 전반이 위험합니다.
- 완전한 임시 방어책이 없어서 업데이트 말고는 안전한 대응이 없습니다.
- PHP 8.2는 올해 말 지원이 끝나므로 패치 뒤에도 지원되는 버전으로 옮길 준비가 필요합니다.
핵심 내용
- 두 취약점 모두 치명적 등급이며 인증 없는 원격 코드 실행(RCE, 외부에서 서버 명령을 마음대로 실행하는 공격)으로 이어질 수 있습니다.
- 개발팀은 완전한 우회 대책이 없다며 업데이트가 유일하게 안전한 선택이라고 밝혔습니다.
- PHP 8.2는 2026년 12월 31일 지원이 끝나고, 그 뒤로는 보안 수정도 나오지 않습니다.
- 자세한 내용은 php.net의 보안 권고와 변경 기록에 있고, 윈도용 소스와 바이너리도 함께 배포됩니다.
HN 반응
- 이용자들은 위즈·캘리프·오픈AI가 함께 공개한 취약점이라고 전하며, 패치까지 두 달 걸린 책임이 제보자와 PHP 보안팀 중 누구에게 있는지를 두고 맞섰습니다.
- 사전 예고 탓에 패치보다 몇 시간 먼저 개념 증명 코드가 퍼졌다는 비판과, 예고가 있어야 관리자가 곧바로 패치할 수 있다는 반론이 엇갈렸습니다.
위즈(Wiz), 캘리프(Calif), 오픈AI가 함께 조율해서 공개한 것으로 보입니다.
https://www.php2shell.com/
https://www.wiz.io/blog/php2shell-php-rce
https://calif.io/php2shell/
https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/ (아직 열리지 않음)
https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ (아직 열리지 않음)
'내부 서클'에 못 낀 사람들은 다들 놀림감 취급을 받는 기분이에요. 오픈AI와 보안 업체들이 이걸 두 달이나 쥐고 있었고, 누가 먼저 수정본을 받을지는 자기들끼리 정해 놓고는, 제대로 막지도 못해서 나머지는 속수무책으로 내버려 둔 셈이잖아요.
php8.5용 공식 임시 수정본 [1]은 24시간 전, 아니 2주 전에라도 보안 세부 내용을 밝히지 않고 공개할 수 있었을 거예요. 특히 POC가 올라온 시점에는요. 공들여 쓴 이런 블로그 글보다 훨씬 쓸모 있었을 겁니다.
제가 놓친 게 있을지도 모르지만, 이런 식으로 처리한 탓에 치른 비용(개발자·SRE 시간, 놓친 매출, 잠재적인 데이터 유출과 해킹)이 만만치 않아요.
[1] https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
이 보안 업체들은 두 달 전에 제보했습니다. PHP 보안팀이 이를 인정하는 데 한 달이 걸렸고, PHP 팀이 패치를 개발해 내놓는 데 또 한 달이 걸렸습니다.
누군가에게 화를 내야 한다면 제보자들은 아닙니다.
수정본을 공개하는 것이 곧 보안 세부 내용을 공개하는 것입니다.
제가 듣기엔 "웹폼 하나 채워서 냈다"거나, "'당신 코드에서 취약점을 찾았으니 돈을 보내라'는 식으로 하루에도 수십억 통씩 오는 메일 중 하나처럼 읽히는 메일을 security@php로 보냈다"는 얘기로 들려요.
저라면 이런 RCE에 대한 자세한 내용을 알고 있다면 제보했겠지만, 일주일이 지나도록 답이 없으면 다른 경로를 알아봤을 거예요.
앞으로 며칠 안에 자세한 내용이 더 나오겠지만, 처음에는 심각도를 낮게 잡았다가 파고들수록 "아 이런 젠장" 하게 되는 일은 드물지 않습니다.
이 건이 언제 "메모리 안전성 문제"에서 "php2shell/RCE"로 바뀌었는지는 알 수 없습니다.
캘리프의 보고서는 타임라인이 다소 빈약하지만, 행간을 읽어 보면 이를 실제로 악용 가능한 취약점으로 만드는 데 시간이 꽤 걸린 것으로 보입니다.
마지막으로, 적어도 LLM 이전에는(지금은 조금 낡았을 수도 있지만) 책임 있는 보안 공개의 관례상, 실제로 악용되는 징후가 없다면 보통 벤더를 기다립니다(최대 90일). RCE여도 마찬가지입니다. 아니, RCE일수록 더 그렇습니다.
보안 담당도 아닌 PHP 기여자나 메인테이너 아무에게나 연락을 돌리다가 패치도 없이 유출되는 상황이 가장 피해야 할 일입니다. 그게 정말 최악의 결과입니다.
네, 이건 나쁜 일이지만, 알고 보면 수십 년 동안 나쁜 상태였고 훨씬 더 나빠질 수도 있었습니다.
이 글에 따르면 연구자 중 한 명은 PHP 보안 책임자를 지낸 사람인데, 2004년부터 이 버그를 알고 있었다고 합니다. 그러니 지금의 팀도 신뢰할 만한 제보로 받아들였을 거라고 생각해요. https://calif.io/php2shell/
다른 곳에서도 말씀드렸지만( https://bugs.php.net/bug.php?id=78876 ), 저는 정말 헷갈립니다. PHP 버그 트래커를 보면 해당 버그들은 이미 수정됐거든요. 그러면 LLM이 여전히 통하는 다른 변형을 찾아낸 게 아닐까 싶은데, 그렇다면 이번 보고서가 앞뒤가 잘 안 맞습니다.
그 제보가 받은편지함에서 눈에 띄었을지 의문입니다. 아마 LLM이 쏟아낸 쓰레기 제보 속에 묻혀 있었을 테니까요. 제가 아는 오픈소스 프로젝트 보안 메일링 리스트 여럿이 그렇습니다. 오픈소스 GitHub 이슈, hackerone 등에 어떤 영향이 있었는지는 다들 보셨잖아요. 이메일로 하는 표준 제보 경로에서도 똑같은 일이 벌어지고 있습니다.
이 일러스트들, 멋지긴 한데 하나같이 대수롭지 않은 걸 침소봉대하고 있어서 너무 정신 사나워요.
그럴 리가 없다고 봅니다. 이 사람들은 보안 업계에서 꽤 알려진 이름들이고, 심각도 높은 취약점을 제보해 본 경험도 풍부합니다.
게다가 이쪽 모회사들이 LLM에 돈을 쏟아붓고 있다는 점에서도 경험이 풍부하죠.
다른 데서도 말했지만, AI가 쓴 "보안 공개" 글은 정말 지긋지긋해요. 진짜 문제인 경우에도 읽다 보면 고칠 의욕이 사라지거든요.
그렇긴 해도 PHP 팀은 이 건을 형편없이 처리했어요. 다들 "대비"하라고 알려 주면 누구한테 무슨 도움이 되나요? 공황만 만들 뿐이죠.
미리 경고를 주면 전 세계 여러 시간대의 시스템 관리자들이 수정본이 나오는 시각에 맞춰 업데이트할 준비를 할 수 있습니다. 이건 아주 중요합니다. 이런 취약점에서 몇 시간씩 늦는 건 용납할 수 없습니다.
그런데 그 사전 경고가 한 일이라고는 개념 증명(PoC)이 그 '값진' 몇 시간 전에 유출되게 만든 것뿐인 것 같은데요.
다들 AI 때문에 화가 나 있을 뿐이에요. 그래서 AI와 엮인 쪽을 탓하는 거죠. 경찰이 흑인을 보면 무조건 범죄자로 단정하는 거랑 비슷합니다.
PHP 보안팀이 왜 이걸 인정하고 수정본을 개발해야 하는 거죠? 오픈소스 소프트웨어인데요.
질서 있고 빠르게 전 세계에 배포하려면 유지보수 팀과 배포판 쪽이 함께 움직여야 합니다.
그럼 위즈가 자체 PHP 패치를 만들고, 캘리프도 (조금 다른) 자체 패치를 만들고, 오픈AI도 자체 패치를 만들면, PHP 사용자인 저는 어느 버전을 써야 하나요? 직접 병합해야 하나요? 캘리프 것이 위즈 것보다 나은가요? 오픈AI 것이 캘리프 것보다 나은가요? 서로 보완하는 관계인가요?
구버전 소프트웨어에서는 실제로 그런 일이 생깁니다. Red Hat이 어떤 컴포넌트에 백포트해서 배포하는 패치는 Canonical이나 Debian의 것과 같지 않을 수 있어요.
질문하신 내용을 모르는 대부분의 사용자는 배포판이 알아서 정리해 주기를 믿고 맡깁니다(그러려고 큰돈을 내는 경우도 많고요).
그 사람들은 이미 서로 연락하고 있었어요. 모여서 자기들이 찾아낸 문제를 막아 주는 패치 하나를 정할 수도 있었을 텐데요.
그럼 아무나 PHP 새 릴리스를 내놓을 수 있다는 건가요?
네, 진짜 수정본이 나올 때까지 두 달 동안 사람들이 쓸 수 있도록 누군가 안전한 버전을 배포할 수도 있었죠.
그건 동작하는 익스플로잇을 공개하는 것과 사실상 같습니다.
그리고 그게 나쁜 일은 아니에요. 그게 나쁜 일이라면, 논리적 결론은 수정본을 절대 공개하지 말고 실제 악용이 시작되기 전에는 미리 패치도 하지 말라는 게 되잖아요.
아니요, 나쁜 일입니다.
제가 수정본을 낸다고 해 봅시다. 저는 이름 없는 아무개인데, 세상에 대고 "PHP 문제를 고쳤으니 제 버전을 쓰세요!"라고 합니다. 뭘 고쳤는지는 비밀이고, 그냥 믿으라고 하고요.
LLM을 쓰면 공격자들이 제 수정본을 역분석해서 실제 공격으로 만드는 데 길어야 몇 시간이면 됩니다. 한편 저는 아무도 들어 본 적 없는 아무개라서, 소식을 들은 사람들도 제 수정본을 덜컥 믿고 설치하지 않으니 수정본을 쓰는 사람은 극소수입니다. 그런데 익스플로잇은 저 때문에 세상에 풀렸고, 저 때문에 사이트들이 털리고 있는 겁니다.
이게 문제 아닌가요?
지금 말씀하신 게 오늘 일어난 일과 뭐가 다른가요? 취약점 설명까지 같이 나왔다는 점만 빼면요. 보안 업데이트를 내놓은 탓에 지금 사이트들이 털리고 있다고 말할 수도 있어요.
왜 사람들이 당신을 알아야 한다고 생각하시죠? 이 문제를 배포판 메인테이너, 보안 업체, 호스팅 업체 등에 먼저 직접 제보한다면, 그쪽 이름을 알리는 데 활용해서 경각심을 일으킬 수 있어요.
몇 시간 만에 공식 패치가 나왔습니다. 원래대로라면 훨씬 더 오래 걸렸을 거고요.
게다가 오늘은 일이 꼬인 경우였습니다. 제대로 진행됐다면 버그가 공개될 때쯤에는 공식 패치가 이미 나와 있었을 겁니다.
그리고 2개월 전에 보안 패치를 내놨다면, 버그가 공개되기 전에 보안 패치가 있었겠죠.
2개월 전에는 패치도 없었고 빠르게 패치를 만들 방법도 없었습니다. 그때 세부 내용을 공개했다면 아주 나빴을 겁니다.
패치가 완성되는 대로 바로 냈어야 한다는 뜻이라면, 버그가 공개되기 전에 나오긴 했겠죠... 한 5분쯤요. 패치 공개 하루나 이틀 전에 경고를 주면 관리자들이 바로 패치할 준비를 하거나 릴리스 시각 전에 서버를 내려 둘 수 있습니다.
유출이 있었어도 관리자들은 경고를 받았고, 경고 없이 공식 패치가 떨어지는 것보다는 나았습니다. 경고 없이 공식 패치가 떨어지는 건 경고 없이 비공식 패치가 떨어지는 것보다 낫고, 그건 또 경고 없이 익스플로잇 세부 내용이 풀리는 것보다 낫고요.
우리는 패치가 2개월 미만에 만들어지는 가정을 이야기하고 있어요. AI 에이전트가 있으면 완화책을 패치하고 테스트하는 데 길어야 며칠이면 된다고 100% 장담할 수 있습니다. 몇 달이 아니라요.
서버를 꺼 두라고 경고할 정도라면 패치도 같이 주는 게 낫죠.