요약
PHP RCE 취약점 소식을 미리 올려 엠바고를 깨뜨린 HN 이용자가, 엠바고가 있는 줄 몰랐다며 사과했습니다.
본문
저는 당시 공개를 앞두고 있던 CVE-2026-109618, CVE-2026-109619 관련 PHP RCE(원격 코드 실행) 취약점에 대해 이곳에 글을 올렸습니다. 그 글이 조율된 공개(발견자와 개발 측이 취약점 공개 시점을 맞추는 절차) 일정에 적지 않은 연쇄 영향을 미쳤고, 여러분의 일을 늘렸다는 점을 잘 알고 있습니다.
진심으로 죄송합니다. 제 행동의 책임은 전적으로 제게 있습니다.
뒤이어 일어난 일들은 제가 조금도 의도한 것이 아니었습니다.
글을 올릴 때 저는 엠바고(정해진 시점까지 공개하지 않기로 한 약속)가 있다는 사실을 전혀 몰랐습니다. 제게 소식을 전해 준 분은 엠바고가 없다고 했습니다. 그분도 자기에게 소식을 전한 사람에게서 같은 말을 들었습니다.
저는 4주마다 나오는 PHP 릴리스를 챙기고, 소스에서 직접 컴파일해 씁니다. 저와 비슷한 처지의 사람들에게 이번 업데이트가 얼마나 중요하고 급한지 알리려던 것이 제 의도였습니다.
보시다시피 그 의도는 꽤 황당한 방식으로 역효과를 냈습니다. 이번 일로 교훈을 얻었습니다.
HN 반응
- 통보받지 않은 엠바고는 깰 수도 없다는 위로가 많았지만, 몰랐을 리 없다거나 먼저 제보했어야 한다는 반론도 나왔습니다.
- AWS가 공개 전부터 악용 정황을 포착했다는 지적과 함께, 두 달 동안 패치를 내지 못한 PHP 메인테이너 쪽 책임을 묻는 의견도 있었습니다.
엠바고의 당사자도 아니고 엠바고가 있다고 누가 알려 준 적도 없다면... 엠바고를 지킬 필요가 없습니다. 오히려 기본적인 내용을 흘리거나 엠바고에 이의를 제기하는 것까지 고려해 볼 만합니다. 당신 같은 상황이라면, 소식이 당신에게 닿기 전에 이미 정보 비대칭은 깨진 상태였습니다. 관련 없는 제3자가 엠바고를 지켜야 한다는 생각이 어디서 나왔는지 모르겠습니다.
엠바고는 비밀을 지키기 위한 것이 아닙니다. 조율된 공개(coordinated disclosure)의 게임 이론에 관한 것입니다.
한쪽에는 스스로를 돌아보는 글쓴이가 있고, 다른 한쪽에는 체인가드의 댄 로렌크가 있네요.
문제는 그 사람의 논리가 틀린 것도 아니라는 점입니다. (PoC가 퍼지고 있었고 취약점을 찾기 쉬웠다는 그의 말이 사실이라면요.) 그래도 결과적으로는 더 넓은 생태계보다 체인가드 고객을 우선시한 셈입니다.
토큰만 있으면 체인가드 패치가 없어도 찾기 쉬웠어요.
발견자가 자랑을 해대는 바람에 다들 찾아보기 시작했습니다. 그러다 PHP 재단이 웹사이트에 공지를 올리자 난리가 났죠. 릴리스 18시간 전에 이미 데모가 나와 있었습니다. 진퇴양난인 건 알지만, 솔직히 그 시점에는 패치를 내놨어야 합니다. 엉뚱한 패치를 고를까 봐 걱정이 컸다는 것도 압니다. 그래도 아무것도 없는 것보다 나쁜 건 없습니다.
링크 있어요?
https://www.linkedin.com/feed/update/urn:li:activity:7518756994284077056
맞아요, 글쓴이는 잘못한 게 없다고 생각합니다. 체인 어딘가에서 누군가 엠바고를 어겼겠지만, 그게 글쓴이는 아니었어요.
"조율된 공개"가 바로 비밀을 지키는 것, 즉 엠바고를 거는 것 아닌가요?
엠바고 정보 없이 RCE 정보만 받았다면 엠바고를 깬 건 당신이 아닙니다. 체인 위쪽의 다른 누군가가 깬 거죠.
이 사태 전체가 분석될 테고, 결국 우리 모두 더 나아질 겁니다.
책임 있는 공개(responsible disclosure)도 적용되지 않습니까? 널리 알려지지 않은 것 같은 취약점을 알게 되면, 먼저 책임감 있게 신고하려고 해야 하지 않나요?
이 경우에는 글쓴이가 "믿을 만한 소식통에 따르면 발표가 예정되어 있다"라고 썼으니 엠바고를 알고 있었던 것으로 보입니다. 보안 취약점 공개에서는 발표 전에 알리면 안 된다는 것이 통상적인 전제라고 생각합니다. 설령 발표 일정은 몰랐고 RCE에 대해서만 들었다 해도, 그 존재를 공개적으로 알리는 것이 괜찮아 보이지는 않습니다.
참고로 "책임 있는 공개(responsible disclosure)"는 저를 포함해 많은 사람이 싫어하는 용어입니다. 공개 자체의 타당성에 대해 전혀 자명하지 않은 가치 판단을 담고 있기 때문입니다.
이 용어는 기업이나 프로젝트가 보안 연구자를 무시하고 홀대하던 시절에 나왔습니다. 그런 조직은 대체로 위험 관리를 못하는 쪽이었고, "책임 있는 공개"라는 말을 만들어서 "정보는 우리에게 보내라, 그걸로 뭘 하든 얼마 동안 묵히든 우리 마음이다"라는 뜻으로 써 왔습니다.
저를 포함한 많은 보안 전문가는 "조율된 공개(coordinated disclosure)"라는 용어를 선호합니다. 발견자와 패치하는 쪽이 모두 선의를 갖고, 서로 소통하면서, 제때 문제를 고쳐 커뮤니티에 도움이 되도록 참여하는 방식을 가리키기 때문입니다.
차이는 이렇게 요약할 수 있습니다. 제가 Y사에 취약점 X를 신고했는데 Y사가 3년 동안 깔고 앉아 있다면, 그건 책임 있는 행동이 아닙니다. 특히 요즘에는 공격자가 그 취약점을 알고 악용할 가능성이 거의 확실하다시피 하므로, 대중에게 알려서 공식 패치가 아닌 방법으로라도 스스로를 지킬 수 있게 하는 편이 오히려 더 "책임 있는" 행동입니다.
물론 이 용어들이 아주 과학적인 것은 아닙니다. 그래도 이 이야기가 나올 때마다 이런 유래를 짚고 넘어가려고 합니다.
그런 식의 공개 방식은 취약점을 발견했을 때의 이야기입니다. 이미 CVE가 공개된 사안을 이야기하는 것과는 비교하기 어렵습니다.
무슨 말씀인지 모르겠네요. 공개된 CVE는 이미 공개된 거라 더 공개할 게 없는 것 아닌가요?
그분들이 그 정보가 PHP 업스트림에서 나왔다고 생각한 건 아닐까요? 저라도 공식 경로에서 온 것으로 보이는 새 PHP 버전을 받았다면, 책임 있게 공개할 만한 건 없다고 여겼을 것 같습니다.
CVE가 공개되면 엠바고가 끝나는 거 아닌가요? CVE 할당(allocate)과 공개(publish)가 다른 게 바로 그 때문이라고 생각했는데요.
엠바고가 풀리면 정보 전체가 공개되는 언론 엠바고와는 다릅니다. cve.org에 공개 기록이 올라오긴 하지만, 엠바고를 건 쪽이 취약점의 존재와 대응 방안이 공개된 뒤에도 핵심 세부 사항은 비공개로 남겨 두라고 고집하는 경우가 많습니다.
이 예를 보세요:
https://www.cve.org/CVERecord?id=CVE-2026-113119
지금 시점에도 이에 해당하는 Chromium 버그 트래커 항목은 비공개 상태입니다:
https://issues.chromium.org/issues/557075191
(그냥 아무거나 하나 골랐을 뿐이고, 다른 출처에서 정보가 공개돼 있는지는 확인하지 않았습니다.)
아니요, CVE 할당은 훨씬 전에 이뤄질 수 있습니다. 식별자를 요청하는 것일 뿐이라 아주 일찍 예약해 둘 수 있어요.
예를 들면: https://www.cve.org/CVERecord?id=CVE-2026-50000
제 생각에는 그분도 같은 말씀을 하신 겁니다.
CVE 할당은 실제 공개보다 훨씬 먼저 이뤄지지만, 엠바고를 끝내는 것은 공개 쪽입니다.
아니요, CVE는 취약점이 발견되기도 전에 할당될 수 있어요!
그게 그 주장과 모순되는지 잘 모르겠네요. CVE를 공개(publish)해야 비로소 공개되는 거니까요.
이번 엠바고가 깨졌을 때는 CVE 레코드가 아직 공개되지 않은 상태였습니다. 제가 알기로는 엠바고가 끝났을 때 원래 그래야 하듯 공개됐고요. (그 시점에는 더 이상 지켜보지 않아서 확실하지는 않습니다.)
실제로 일어난 일은 이렇습니다. 사정을 전혀 모르는 사람이 아주 많았고, "이 CVE ID 두 개가 PHP 취약점에 쓰일 예정"이라는 사실만 가지고 CVE 유출이라고 불렀습니다. "아직 정보 없음"이라고 적힌 CVE 데이터베이스 링크를 붙여 놓고 "CVE 유출!"이라고 외치는 글이 돌아다녔습니다. 이는 "CVE"를 "CVE 레코드"가 아니라 그냥 "취약점"이라는 뜻으로 뭉뚱그려 쓰는 데서 생긴 문제이기도 합니다. 그래도 정말 어처구니없고 짜증 나는 일이었습니다. CVE ID XYZ가 프로젝트 ABC에 쓰일 거라는 정보는 유출이 아닙니다. 말씀하신 대로 CVE 공개 여부가 중요하고, CVE 레코드의 내용이 새어 나갔을 때야 유출이라고 할 수 있습니다.
미끼를 던진 거면 좋겠네요. 그런 식으로 돌아가는 게 아니거든요.
알겠습니다, 제가 잘못 알았네요. 이분이 엠바고에 참여하지 않았다는 걸 몰랐습니다.
바로 그런 식으로 돌아갑니다. 엠바고에 참여한 사람은 자기가 정보를 공유하는 상대(원래는 대개 아무도 없어야 합니다!)가 엠바고를 알고 지키도록 만들 책임이 있습니다.
알지도 못하고 참여한 적도 없는 엠바고에 구속될 수는 없습니다.
피트가 정보를 받았을 때는 엠바고가 이미 깨져 있었어요.
친절하시네요, 피트. 그런데 당신이 여기에 앞선 글을 올리기 한참 전에 이미 유출돼서 악용되고 있었습니다: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
거기엔 유출됐다는 주장은 없습니다.
바보 같은 소리 마세요. 적용받지도 않았고 통보받은 적도 없는 엠바고를 깬 책임이 당신에게 있을 수는 없습니다.
맞는 말씀입니다. 분명히 해 두자면, 사실관계를 모른 채 HN에 글을 올린 것에 대한 책임은 제가 집니다.