요약
아마존은 PHP2Shell 취약점이 공개되기 나흘 전부터 이미 악용 시도가 있었다고 밝혔습니다.
아마존 위협 인텔리전스팀이 PHP의 원격 코드 실행 취약점 CVE-2026-109618과 CVE-2026-109619를 분석한 글입니다. 허니팟(공격을 끌어들여 관찰하는 미끼 서버) 네트워크 MadPot 기록에서, 엠바고(공개 유예) 중이던 10월 17일 상업용 익명화 네트워크 IP의 시도를 찾았습니다.
왜 중요한가
- 엠바고는 다른 누군가가 같은 버그를 찾기 전까지만 방어자를 지켜 준다는 점이 드러났습니다.
- 침해 조사는 공개일인 21일이 아니라 첫 악용 시점인 17일부터 해야 합니다.
- AI로 패치를 공격 코드로 바꾸기가 쉬워져 패치 기한을 며칠이 아닌 몇 시간 단위로 잡아야 한다고 봤습니다.
핵심 내용
- 공격자가 공개 전에 어떻게 정보를 얻었는지, 시도가 실제로 성공했을지는 아직 모른다고 했습니다.
- 예정된 공개 시각(21일 14시, UTC)보다 몇 시간 앞서 개념 증명(PoC, 공격이 가능함을 보여 주는 코드)이 돌았습니다.
- 공개 뒤에는 여러 공격자의 시도가 곧바로 이어졌고, 지금은 널리 악용되고 있습니다.
- 수정된 PHP 버전으로 올리는 것만이 두 취약점을 모두 막는 방법이라고 했습니다.
- 패치가 늦어지면 파일 업로드 요청을 막는 임시 조치를 시험해 보고 17일 이후 로그를 점검하라고 권했습니다.
HN 반응
- 엠바고를 깬 체인가드를 탓한 PHP 팀이 머쓱해졌다는 주장과, 아마존은 나중에 로그에서 찾았을 뿐이라는 반론이 맞섰습니다.
- 패치 대신 AI로 만든 C 프록시를 앞에 두자는 제안에는 프록시 자체가 새 취약점이 될 수 있다는 비판이 이어졌습니다.
10월 17일에 이미 이 취약점을 들쑤시거나 악용하고 있었다면, PHP 팀이 공개 성명에서 Chainguard에 책임을 떠넘긴 것 자체가 낯 뜨거운 일이 됩니다.
결국 PHP 팀은 자기들이 만든 이 난장판에서 책임을 회피하고 내팽개치는 겁니다. "Chainguard가 엠바고를 깼다", "돈으로 우리를 후원해 달라", "우리는 그냥 자원봉사자일 뿐이다", "몇 년 전부터 알고는 있었지만 PoC가 없었다. 보안 수정보다 기능 출시를 우선했으니까". 전부 책임 회피일 뿐입니다.
이번 사태를 보면서 제가 참여하는 프로젝트에는 PHP를 절대 쓰지 않겠다고 마음먹었습니다. PHP 팀은 크게 사고를 쳤고, 사방팔방으로 책임을 돌리고 있습니다.
이게 달라지는 건 딱히 없고, 17일까지 거슬러 올라가 로그를 확인해 보라는 정도입니다. Amazon은 21일 전에 이 취약점이 악용되고 있다는 걸 알았다고 주장하지 않습니다. 그렇게 주장하는 사람은 아무도 없는 것 같고요. 표현상 나중에 로그를 거슬러 조사하다가 발견했다는 뜻일 수도 충분히 있습니다. 초기에 있었다는 수천 건의 시도 중 성공한 게 있다는 명확한 증거도 아직 못 봤습니다. 대부분 이리저리 찔러 보며 알아내려는 사람들로 보이고, 잘해야 특정 환경 한 곳에서 어쩌다 동작한 정도였을 겁니다.*
맞습니다, 이제 우리는 새로운 세상에 살고 있고 이 경험에서 배워 공개 방식을 다르게 다뤄야 합니다. 이런 시대에 서드파티 유출이 따라붙은 첫 대형 RCE 공개였으니, 누가 영향을 받든 이런 문제가 생기는 건 피할 수 없었을 겁니다. 다음번에는 더 낫기를 바랍니다.
공개 과정에서 이 모든 일의 발단이 된 가장 큰 실수는, Calif가 X의 바이브 코더들 말을 곧이곧대로 믿고 영상을 일찍 올린 것이라고 봅니다. 사람들 반응을 보면, 돌이켜 볼 때 PHP가 다가올 릴리스를 미리 알린 것도 실수였을지 모르겠습니다.
[*] 보안 연구자 세계에서는 이게 표준인가요? 엠바고를 몇 시간 앞질러서 괜히 공포를 키우고 더 많은 사람을 위험에 빠뜨리는 게요?
무언가를 바꾸자는 얘기가 아니고, 제 댓글에도 그런 말은 없었습니다. Amazon이 10월 17일에 이걸 찔러 보는 징후를 일부 봤다고 했다면, PHP가 Chainguard에 공개적으로 책임을 돌린 건 엉뚱한 곳을 겨눈 것이고 자기들이 릴리스를 조율하지 못한 걸 덮으려는 회피였다는 게 드러납니다. 바뀌어야 한다면 PHP 팀의 그 회피 태도가 바뀌어야 합니다.
보안 연구자 세계에 표준이라는 건 없습니다. 저는 PHP에도 Chainguard에도 관심이 없지만, 그보다 더 큰 관심사가 있습니다. PHP 쪽 사람들은 Chainguard에 책임을 넘길 수 있겠지만, 사실 몇 년 전부터 이 문제를 제대로 다루지 못한 건 PHP 팀입니다. Amazon이 10월 17일에 이미 이걸 찔러 보는 걸 보기 시작했다면, 다른 공개나 발견도 있었을 가능성이 높습니다. 하다못해 OpenAI도 최초 PoC가 공개된 것과 거의 같은 시기에 이걸 찾아냈잖아요.
엠바고 시점에는 이 익스플로잇이 실제로 유효하게 쓰인 사례가 확인되지 않았다는 PHP의 말이 틀렸나요? 엠바고가 깨지고 사람들이 앞다퉈 일찍 악용하려 들었던 상황에서도요.
악용될 가능성이 있었으니 일찍 릴리스했어야 한다는 주장일 수도 있겠죠. 하지만 PHP(그리고 이를 뒷받침한 다른 쪽들)가 트위터에 돌던 익스플로잇을 검토해서 그걸로는 이 공격이 성공할 수 없다는 걸 확인했다고 했는데, 저는 그 말을 믿습니다.
다시 말하지만 Amazon은 10월 17일에 이걸 찔러 보는 걸 봤다고 하지 않았습니다. 지금 와서 돌이켜 보니 17일자 로그에서 이게 보인다고 말한 겁니다(그게 성공했을지도 알 수 없고요). Amazon이 당시에 실제로 이걸 포착했다고 정정한다면 저도 동의하겠습니다. 다만 그런 말은 안 했습니다.
여기서 누구 탓을 하느라 시간을 쓰는 이유를 모르겠습니다. 이런 취약점이 문제가 되는 유일한 이유는 나쁜 사람들이 그걸로 나쁜 짓을 하기 때문입니다. 공개된 날 밤에 이런 보고와 그 밖의 많은 보고를 봤는데, 합리적인 사람이라면 누구라도 조기 릴리스 기준을 충족한다고 판단할 만한 충분한 근거라고 생각했습니다. 합리적인 사람들끼리도 거의 모든 일에서 의견이 갈릴 수 있다는 걸 알게 됐네요.
저는 오히려 우리 모두가 이 시간에, 우리(와 다른 모든 사람)가 찾아내고 있는 나머지 취약점들을 어떻게 최대한 빨리 고치고, 앞으로 몇 달 동안 패치와 완화책을 필요한 모든 사람에게 최대한 빨리 배포할 것인가를 이야기했으면 좋겠습니다.
(제가 이걸 일찍 릴리스하기로 결정한 사람입니다)
버그가 실제로 악용되고 있지 않다면 조율된 공개와 패치를 원하게 됩니다.
악용되고 있다면 가능한 한 빨리 내놓고 싶고요.
PHP 팀은 첫 번째 경우라고 생각했고 그에 맞게 움직였습니다. 알고 보니 두 번째 경우였던 거죠. 하지만 그들이 그걸 알 수 있었다거나 알았어야 한다는 징후는 보이지 않습니다. 가진 정보로는 옳은 결정을 내린 겁니다.
MediaWiki가 제가 PHP를 다시는 (직접) 안 만지게 되는 걸 막는 마지막 걸림돌이에요. 그리고 규모가 큰 위키를 위한, 그대로 갈아 끼우고 이전할 수 있는 대체재는 상상하기도 어렵고요. ㅠㅠ
캐시로 게시(publish-to-cache)하면 노출을 크게 줄일 수 있습니다. 특히 인터넷상의 누구에게나 가입을 허용할 필요가 없다면요.
다들 왜 이 패치만이 상황을 해결할 유일한 방법이라는 데 그렇게 매달리는지 모르겠습니다. 인터넷 서비스를 공격하는 방식은 악의적인 페이로드를 만들어 보내는 겁니다. 애플리케이션 서버 앞에 프록시를 두는 건 아주 영리한 방법이고, 특히 그 프록시가 입력을 디코딩해서 안전한 방식으로 다시 인코딩하는 한 가지 일만 할 수 있다면 더 그렇습니다. 저는 몇 시간 만에 Claude로 프록시를 만들었는데, 이 php2shell 공격은 물론 가까운 시일 내에 발견될지도 모르는 다른 많은 공격까지 완전히 차단합니다. 무엇보다 multipart-form-data 페이로드를 디코딩한 뒤, 공격자가 고른 구분자 대신 프록시가 임의로 만든 안전한 구분자로 다시 인코딩합니다.
저희는 배포 환경에서 직접 쓰고 있고, 어제 PHP를 패치하고 싶지 않거나 패치할 수 없는 모든 분(아마 지금 수백만 대의 서버일 겁니다)을 위해 MIT 라이선스로 무료 공개했습니다.
https://github.com/Qbix/proxy
신뢰할 수 없는 입력을 처리하는 인터넷 프록시 서버를 바이브 코딩으로, 그것도 C로 짠 건 정말 조심해야 할 것 같습니다.
저도 그렇게 생각합니다. 조심하셔야죠.
그래도 확인하기는 아주 쉽습니다. 어떤 파일에도 읽기·쓰기 권한이 전혀 없도록 샌드박스에 넣을 수도 있고요. 악의적인 방향으로 할 수 있는 일이라고 해 봐야 요청을 버리거나 잘못된 형식의 요청을 전달하는 정도인데, 코드가 그런 걸 허용할 방법이 없다는 건 쉽게 알 수 있습니다.
이 글을 읽고 코드를 확인해 봤습니다. 할당 실패 여부를 확인하지 않는 malloc 호출이 잔뜩 보이더군요. 당신 생각만큼 뻔히 완벽하게 안전하지는 않다고 봅니다.
완벽하게 안전하긴 하죠. 제 열린 창문이 방탄인 것과 같은 방식으로요. 총알이 그냥 통과해 날아가니까 유리가 깨지지 않거든요.
게다가 작성자는 이 사이트에서 선의로 대화하고 있지 않습니다. 어제 올라온 이 스레드 https://news.ycombinator.com/item?id=50181138 를 보세요. 이 프로젝트의 심각한 취약점들이 지적되자 작성자는 이력을 숨기려고 force push를 했고, 지적받은 취약점은 고치지 않았습니다(예를 들어 https://github.com/Qbix/proxy/blob/5a9f8a96f4bdaaaa5444b6986853e9b9724a94bc/src/sanitize.c#L39 는 여전히 PHP의 multipart 파서와 일치하지 않아서, 구분자를 공백으로 바꾸기만 하면 방어 전체가 무력화될 수 있습니다). 쓰레기의 전형입니다.
잘 생각해서 만든 쓰레기도 아니에요. Claude로 프록시를 쓰레기처럼 찍어낼 거면 하다못해 Rust로 만들거나, 기존 프록시를 수정하거나, 겨우 컴파일되는 C 코드를 바이브 코딩하기 전에 제일 먼저 떠올라야 할 50가지 방법 중 아무거나 하나는 했어야죠.
의도가 좋다는 건 이해하지만, 프록시에 취약점이 있으면 그것도 악용될 수 있습니다. 많은 사람이 nginx를 프록시로 쓰는데, nginx도 몇 년에 걸쳐 고쳐 온 자체 취약점이 있습니다. 문제 하나를 해결하면서 다른 문제를 열어 놓았을 수 있어요. 앞단에 두는 서비스들조차 자체 취약점이 있고 그걸 고쳐야 합니다.
다른 누군가가 접근할 수 있는 시스템은 본질적으로 안전하지 않고, 보안 강화가 필요합니다.
프록시의 본질적인 위험은 결국 "프록시를 통과했으면 괜찮다"로 요약되는 규칙이 생기게 된다는 겁니다. 그렇게 해서 달걀처럼 깨져 열리는 거고요.
적어도 공격자와 애플리케이션이 가진 비밀·권한 사이에 계층을 하나 더 두는 셈이라서, 서비스를 공격하는 데 드는 복잡도가 한 단계 늘어납니다.
그리고 이번 같은 경우에는 공격자가 대신 고를 수 있는 악용 가능한 PHP 서버가 널려 있으니, 확실히 추가 방어 효과는 있습니다.
그래도 필요한 바로 그날 직접 만들어 쓰겠다고 하진 않을 겁니다.
물론 그렇지만, 논리적으로 생각해야 합니다.
이 패치에만 의존하면 이번 CVE들만 막을 수 있지만, 일반적으로 프록시는 그보다 더 많은 걸 막아 줄 수 있습니다. 순수하게 보안이 더해지는 것 맞죠?
그리고 PHP를 패치할 수 없거나 하지 않을 거라면, 당하고 나서 PHP-FPM이 임의의 명령을 실행하게 되는 것보다는 이게 무조건 낫습니다. 그건 최악 중의 최악이고, 리눅스 사용자 권한으로 막을 수 있기를 바라야 하는 상황인데 앱은 사실상 끝난 겁니다. PHP-FPM은 PHP가 .php 파일을 덮어쓰는 것도 허용해서, 다음에 공격받으면 임의의 코드가 영구적으로 남게 됩니다.
참고로 https://qbixserver.com 은 제가 몇 달 전에 시작한 프로젝트로, nginx 없이 동작하는 순수 PHP 서버입니다. php-fpm처럼 미리 프로세스를 띄워 두지 않고, 클래스를 로드한 뒤에 fork합니다. php2shell에는 취약하지 않고, PHP 코드를 로드할 때 즉석에서 다시 써서 더 안전하게 만들 수 있습니다. 예를 들어 PHP 스크립트가 .php 파일에 쓰지 못하게 막고, require($filename)이 $filename이 실제로 .php로 끝나는지 확인하게 하는 식으로 여러 가지를 합니다.
이 프록시가 더하는 보안은 순수하게 추가되는 것이고, 상황을 악화시킬 수 없습니다. 아무 권한도 없는 리눅스 사용자로 실행할 수 있어서 입력을 변환하기만 합니다. 입력을 변환해서 PHP가 더 나쁜 짓을 하게 만드는 잠복 코드가 있을 수 있느냐고요? 그래서 저장소를 Claude에게 보여 주고 백도어가 있는지 물어봐야 하는 겁니다. 전부 오픈소스이고 바이너리는 GitHub Actions로 빌드했습니다. GitHub를 믿지 못하겠다면 직접 컴파일할 수도 있겠지만, 그러면 GCC를 믿어야 하죠. (켄 톰슨이 30년 전에 컴파일러에 대한 신뢰를 다룬 흥미로운 강연을 했습니다.) 하지만 이쯤 되면 보통 사람들이 걱정하는 수준을 한참 넘어선 얘기입니다.
아니요. 프록시 자체에 메모리 취약점이 있어서 공격자가 원격 코드 실행을 할 수 있게 될 수도 있습니다.
맞아요. 하지만 그럴 수 없습니다. 여러 이유가 있는데요.
이 코드에 또 다른 RCE로 이어지는 버그가 있다면 얘기가 달라지죠.
사람들은 대체 언제쯤 LLM이 신탁이 아니라는 걸 이해할까요. LLM 몇 개가 코드가 안전하다거나 백도어가 없다고 말한다고 해서 그게 사실인 건 아닙니다.
그래도 LLM이 백도어가 있다고 하면서 어떻게 쓰이는지까지 보여 주면, 있다는 건 꽤 확신할 수 있죠.
Claude가 백도어를 못 찾았다면 백도어를 못 찾는 거겠죠. 여전히 신탁은 아니지만, 사전 확률을 갱신하는 데는 쓸모 있는 피드백입니다.
맞아요. 하지만 그럴 수 없습니다. 여러 이유가 있는데요.
프록시는 오픈소스이고 PHP 런타임이나 웹 애플리케이션보다 훨씬 단순합니다. 코드는 입력을 받아 출력을 만들 뿐이고, 기본적으로 파이프입니다. 악용할 만한 다른 기능이 없습니다.
BSD나 리눅스 같은 운영체제는 프로세스를 특정 사용자 권한으로 실행하고 그 사용자에 제한을 강제할 수 있습니다. 그러니 이 프록시는 목적이 하나뿐이므로 그냥 가둬 두면 됩니다. 여러 일을 하고 제한할 수도 없는 당신의 애플리케이션과 달리, 프록시는 혼동된 대리인(confused deputy)이 될 일이 없습니다.
이번 일로 배운 건, 가능한 한 많이 마이크로서비스로 분리해서 각 서비스를 제대로 샌드박스에 넣어야 하고, 그래야 병목 지점(chokepoint)을 만들 수 있다는 겁니다.
좋은 아이디어네요! Rust나 Go처럼 더 안전한 언어로 구현하는 건 어떻게 생각하세요?
글쎄요, PHP가 C로 되어 있고 저는 C를 훨씬 잘 아니까요. 하지만 이 프록시는 워낙 단순해서 LLM이나 기계적인 프로그램으로도 Rust나 Go로 트랜스파일할 수 있을 겁니다.
어느 쪽이든 여기서 메모리 누수는 그다지 중요하지 않습니다.
30분 전에 여기에 이 프록시에 대한 글을 올렸습니다: https://news.ycombinator.com/item?id=50197861
수정하지 않은 WordPress 도커 이미지로 시연하는 게 가장 좋을 겁니다. 지금 예시는 서버에 공들여 만든 php 파일들을 두고 있잖아요.
오래 도는 서비스에서 메모리 누수가 왜 중요하지 않다는 거죠?
"여기서 메모리 누수는 그다지 중요하지 않다"는 Rasmus의 묘비명 후보로 손색이 없겠네요.
그건 순항 미사일에나 넣을 수 있는 종류의 말이죠. 메모리 누수로 프로그램이 10분 안에 죽겠지만, 순항 미사일은 5분 안에 터질 테니 상관없으니까요.
불을 끄는 중에 소화기가 1년 뒤에 넘어질 수 있다는 건, 불을 끄지 말아야 할 이유로는 정말 말도 안 되는 소리니까요.