요약
PHP RCE 취약점 소식을 미리 올려 엠바고를 깨뜨린 HN 이용자가, 엠바고가 있는 줄 몰랐다며 사과했습니다.
본문
저는 당시 공개를 앞두고 있던 CVE-2026-109618, CVE-2026-109619 관련 PHP RCE(원격 코드 실행) 취약점에 대해 이곳에 글을 올렸습니다. 그 글이 조율된 공개(발견자와 개발 측이 취약점 공개 시점을 맞추는 절차) 일정에 적지 않은 연쇄 영향을 미쳤고, 여러분의 일을 늘렸다는 점을 잘 알고 있습니다.
진심으로 죄송합니다. 제 행동의 책임은 전적으로 제게 있습니다.
뒤이어 일어난 일들은 제가 조금도 의도한 것이 아니었습니다.
글을 올릴 때 저는 엠바고(정해진 시점까지 공개하지 않기로 한 약속)가 있다는 사실을 전혀 몰랐습니다. 제게 소식을 전해 준 분은 엠바고가 없다고 했습니다. 그분도 자기에게 소식을 전한 사람에게서 같은 말을 들었습니다.
저는 4주마다 나오는 PHP 릴리스를 챙기고, 소스에서 직접 컴파일해 씁니다. 저와 비슷한 처지의 사람들에게 이번 업데이트가 얼마나 중요하고 급한지 알리려던 것이 제 의도였습니다.
보시다시피 그 의도는 꽤 황당한 방식으로 역효과를 냈습니다. 이번 일로 교훈을 얻었습니다.
HN 반응
- 통보받지 않은 엠바고는 깰 수도 없다는 위로가 많았지만, 몰랐을 리 없다거나 먼저 제보했어야 한다는 반론도 나왔습니다.
- AWS가 공개 전부터 악용 정황을 포착했다는 지적과 함께, 두 달 동안 패치를 내지 못한 PHP 메인테이너 쪽 책임을 묻는 의견도 있었습니다.
엠바고의 당사자도 아니고 엠바고가 있다고 누가 알려 준 적도 없다면... 엠바고를 지킬 필요가 없습니다. 오히려 기본적인 내용을 흘리거나 엠바고에 이의를 제기하는 것까지 고려해 볼 만합니다. 당신 같은 상황이라면, 소식이 당신에게 닿기 전에 이미 정보 비대칭은 깨진 상태였습니다. 관련 없는 제3자가 엠바고를 지켜야 한다는 생각이 어디서 나왔는지 모르겠습니다.
엠바고는 비밀을 지키기 위한 것이 아닙니다. 조율된 공개(coordinated disclosure)의 게임 이론에 관한 것입니다.
한쪽에는 스스로를 돌아보는 글쓴이가 있고, 다른 한쪽에는 체인가드의 댄 로렌크가 있네요.
음, 이건 반복되는 죄수의 딜레마네요.
엠바고 정보 없이 RCE 정보만 받았다면 엠바고를 깬 건 당신이 아닙니다. 체인 위쪽의 다른 누군가가 깬 거죠.
이 사태 전체가 분석될 테고, 결국 우리 모두 더 나아질 겁니다.
책임 있는 공개(responsible disclosure)도 적용되지 않습니까? 널리 알려지지 않은 것 같은 취약점을 알게 되면, 먼저 책임감 있게 신고하려고 해야 하지 않나요?
이 경우에는 글쓴이가 "믿을 만한 소식통에 따르면 발표가 예정되어 있다"라고 썼으니 엠바고를 알고 있었던 것으로 보입니다. 보안 취약점 공개에서는 발표 전에 알리면 안 된다는 것이 통상적인 전제라고 생각합니다. 설령 발표 일정은 몰랐고 RCE에 대해서만 들었다 해도, 그 존재를 공개적으로 알리는 것이 괜찮아 보이지는 않습니다.
그런 식의 공개 방식은 취약점을 발견했을 때의 이야기입니다. 이미 CVE가 공개된 사안을 이야기하는 것과는 비교하기 어렵습니다.
CVE가 공개되면 엠바고가 끝나는 거 아닌가요? CVE 할당(allocate)과 공개(publish)가 다른 게 바로 그 때문이라고 생각했는데요.
아니요, CVE 할당은 훨씬 전에 이뤄질 수 있습니다. 식별자를 요청하는 것일 뿐이라 아주 일찍 예약해 둘 수 있어요.
예를 들면: https://www.cve.org/CVERecord?id=CVE-2026-50000
제 생각에는 그분도 같은 말씀을 하신 겁니다.
CVE 할당은 실제 공개보다 훨씬 먼저 이뤄지지만, 엠바고를 끝내는 것은 공개 쪽입니다.
아니요, CVE는 취약점이 발견되기도 전에 할당될 수 있어요!
이 사람이 취약점의 심각성과 엄청난 파급력을 못 알아봤고, CVE를 찾아보려다 못 찾았는데도 그걸 별일 아니라고 넘기고 글을 올렸다는 건 말이 안 돼요.
자기 소셜 미디어 지인들, 메일링 리스트, 포럼에서 아무도 이 얘기를 하지 않는 게 이상하다고 생각하지 않았다는 말도 믿어야 하나요? 본인은 사람들에게 알려 주고 싶어서 그랬다고 하죠.
"어, 왜 이걸 알리는 일이 하필 나한테 떨어졌지?" 하고 멈춰 서서 생각해 보지 않았다는 것도 믿어야 하고요. 발표되고 12시간도 안 돼서 주류 언론 뉴스가 됐는데 말이에요.
지금까지 유출했다느니 수정본을 일찍 풀었다느니 하면서 비난받은 사람이나 회사만 적어도 다섯 곳은 봤어요.
누구 잘못이라면 저는 PHP 메인테이너들 쪽을 봅니다.
엠바고는 두 달쯤 지켜졌다는데, 그동안 패치도 못 냈잖아요.
제가 알기로는 사실상 얼리 액세스를 받는 보안 업체들의 패거리가 자기네 걸 먼저 고치고 나면, 그제야 더러운 일반 대중에게 버그를 고칠 특권을 내려 주려고 만든 제도예요.
PHP가 "꽤 끔찍한 프로그래밍(pretty horrible programming)"이라고 불렸던 데는 이유가 있죠.
그리고 뭐, 그 점은 달라진 게 없네요.
누군가가 악의적이고 계산적이었다기보다 자신만만하고 생각이 짧았을 수 있다는 가능성을 진지하게 묻는 거라면... 네, 저는 그게 아주 쉽게 믿어져요. 프로세스 안전이라는 게 존재하는 이유가, 개인으로서든 집단으로서든 우리가 이런 일에 형편없기 때문이거든요.
아이러니하게도 HN 커뮤니티 가이드라인에도 있죠. 선의로 해석하라고요.
친절하시네요, 피트. 그런데 당신이 여기에 앞선 글을 올리기 한참 전에 이미 유출돼서 악용되고 있었습니다: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
거기엔 유출됐다는 주장은 없습니다.
바보 같은 소리 마세요. 적용받지도 않았고 통보받은 적도 없는 엠바고를 깬 책임이 당신에게 있을 수는 없습니다.
맞는 말씀입니다. 분명히 해 두자면, 사실관계를 모른 채 HN에 글을 올린 것에 대한 책임은 제가 집니다.
아무 잘못도 안 했는데 "책임을 지겠다"고 하시네요.
애초에 사실을 알고 있었는지 어떻게 알 수 있겠습니까? 당신이 알고 있던 것은 엠바고가 없다는 얘기와 단지 모순되지 않는 정도가 아니라, 엠바고가 없다고 명시적으로 들은 것이었다고 하셨습니다. 어느 지점부터는, 우리가 진짜라고 믿는 것의 논리적 사슬을 얼마나 위쪽까지 따라 올라가 확인해야 하는지에 한계가 있습니다. 그리고 이번 일은 당신이 무모했다고 할 만큼 뻔한 사례로 보이지 않습니다.
우리는 모두(음, 모두는 아니겠지만, 신경 쓸 가치가 있는 부류, 그리고 적어도 대다수이길 바랍니다) 가진 정보를 바탕으로 최선을 다해 판단하며 살아갑니다. 진실이라고 믿을 만한 진짜 근거가 있는 정보를 가지고 선의로 행동했다면, 의심할 이유가 없던 사람이 꽤 단순한 사실로 말해 준 것을 두고 잘못된 정보를 받았거나 크게 오해했음을 어떻게든 직감했어야 한다고 기대하는 건 부당해 보입니다.
섣부른 아마추어 심리 분석이 될 위험이 있지만, 이번 일에 정말 죄책감을 느끼시는 것 같아서 말씀드립니다. 그 자체로 보면 다르게 하기 어렵지 않았을 행동의 결과에 죄책감을 느끼는 마음에 저도 공감합니다. 그런데 제 경험상 별로 잘못이 없는데도 스스로를 몰아세우는 나쁜 버릇이 있는 사람들은, 입장이 바뀌면 다른 사람에게 그런 기준을 들이대는 건 공정하지 않다는 걸 알아봅니다. 저도 어떤 사실을 안다고 해서 그것이 늘 사실처럼 느껴지지는 않는다는 점 때문에 많이 힘들어합니다. 남이 말해 준다고 마법처럼 나아지지는 않겠지만, 그래도 다른 사람에게서 듣는 것에는 가치가 있다고 생각합니다. 그러니 제가 짐작한 심정이 맞다면, 이 모든 일은 당신 잘못이 아닙니다. 현실적으로 당신이 통제할 수 없던 상황 때문에 이 소동의 한가운데 끼게 된 불운을 가능한 한 자책하지 않으셨으면 합니다.
뭘 사과하시는 건지 모르겠습니다. 뉴욕 타임스 1면에 오르고 일본 총리까지 나서야 했을 만큼 심하게 부풀려진 버그예요. 이 버그는 웹 서버로 오는 공개 요청만으로는 악용하기가 간단하지 않아서, 뭐가 그렇게 난리인지 잘 모르겠습니다. 매일 올라오거나 터지는 수백 개쯤 되는 다른 CVE와 다를 게 없어요.
어차피 터무니없는 선정성 때문에 해커뉴스 헤드라인에 오를 겁니다. 대부분의 DevSecOps 담당자는 아침 뉴스를 본 상사의 전화로 알게 되느니 여기서 먼저 소식을 접하는 쪽을 택할 거라고 생각합니다.
"웹 서버로 오는 공개 요청만으로는 악용하기 간단하지 않다"는 게 무슨 뜻입니까? 기본 설치 상태의 PHP 애플리케이션 여러 개에서 악용 가능한 것으로 알려져 있습니다. 이건 정말 초비상 사태입니다.
사람들이 오늘 일찍 메인에 올라온, 악용이 간단하지 않다는 글에 꽂힌 것 같아요. 게다가 PoC가 수없이 나돌지만 대부분 작동하지 않는 것도 한몫하고요.
맞아요, 제가 걱정하는 게 바로 그겁니다. 가장 널리 퍼진 공개 PoC/데모가 작동하지 않는다는 건 중요하지 않습니다. 신경 써야 할 건 (현재) 비공개 상태이면서 실제로 작동하는 PoC뿐인데, 그런 게 여럿 있는 것 같습니다.
가장 직접적인 익스플로잇은 공급망이 침해되어 있어야 하니, 위험도는 평범한 의존성 익스플로잇 수준입니다.
오픈AI, 위즈 등에 대해 무슨 말을 하셔도 좋지만, 오픈AI, 위즈, 클라우드플레어, PHP 재단, 그리고 사실상 모든 CERT가 한목소리로 PHP 앱을 내리고 즉시 패치하라고 권고한다면 저는 그 조언을 따르고 싶습니다.
미친 듯한 언론 보도 때문에 PoC가 쏟아질 건 당연하고 대부분 작동하지 않겠지만, 작동하는 PoC가 나왔는지 트위터를 계속 새로고침하는 건 시간을 잘 쓰는 것도 아니고 좋은 보안 전략도 아닙니다.
이건 그냥 틀린 말 아닌가요? 지금 무슨 이상한 전화 전달 게임이라도 하는 겁니까? 아니면 "직접적인 익스플로잇"이라는 표현이 의도하신 것보다 훨씬 많은 일을 떠맡고 있는 건가요?
웹 폼을 통한 다른 경로는 ASLR이 없어야 합니다. 그러니 엔드포인트에 요청을 엄청나게 많이 쏴야 해요. 속도 제한 같은 걸로 엣지(CDN)나 리버스 프록시(NGINX) 수준에서 아마 완화할 수 있을 겁니다. 매번 확실하게 먹히는 단순한 SQL 인젝션 공격이라기보다는 웹 버전 로 해머(row hammer)에 가깝습니다.
아주 오래된 리눅스 위의 LAMP 스택이라면 기본 상태에서도 뚫릴지 모르죠. 제발 공포 조장 좀 그만하세요. 보안 커뮤니티에 도움이 안 됩니다.