Today's PHP Security Release, and How We're Strengthening PHP Security — The PHP Foundation
오늘의 PHP 보안 업데이트와 보안 체계 강화
PHP 재단은 원격 코드 실행으로 이어질 수 있는 취약점 두 건을 수정한 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 배포했습니다. 재단은 수정 지연의 구조적 원인과 보안 인력 확충 계획을 공개했으며, 조율된 공개 시점보다 6시간 앞서 수정 이미지를 배포한 Chainguard의 결정도 설명했습니다.
- 주제
에디터 노트
가장 큰 쟁점은 Chainguard의 조기 공개가 실제 공격에 대응한 결정이었는지, 패치 역공학을 앞당겨 위험을 키웠는지입니다. PHP 재단은 공개 시점까지 작동하는 공격을 확인하지 못했다고 했고, Chainguard CEO는 보안 업체들이 실제 공격을 봤다는 정보를 받았다고 밝혔습니다. 댓글에서도 탐지된 것이 공격 시도인지 사용 가능한 공격인지 의견이 갈립니다. 제공된 자료만으로 실제 공격 여부를 확정하기는 어렵지만, 수정 이미지를 다른 사용자보다 6시간 먼저 공개하면 패치 분석 시간을 공격자에게도 준다는 재단의 우려는 구체적입니다. 동시에 취약점 수정이 2024년부터 지연된 원인을 재단이 구조적 실패로 인정했고 인력과 절차 개선을 약속한 점도 사안의 일부입니다. 조기 공개 논란과 장기간의 자원 부족은 별개의 문제로 남습니다.
AI 요약
PHP 프로젝트가 메모리 관리와 오류 처리 영역의 취약점 두 건을 수정한 보안 업데이트를 배포했습니다. 조건이 맞으면 인증 없이 서버에서 코드를 실행할 수 있는 취약점이며, 수정 버전은 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다. PHP 재단은 취약점이 발견되고 수정된 과정, 보안 업무 체계의 변화, 생태계의 지원 필요성을 공개했습니다.
취약점 발견과 수정 지연
메모리 관리 문제는 2024년 외부 보안 감사에서 처음 단서가 나왔습니다. 당시 잠재적 공격 가능성을 논의했지만 구체적인 공격 경로는 확인하지 못했습니다. 수정안을 검토하는 과정에서는 하위 호환성을 깨거나 서비스 거부 위험을 키우거나, 다수의 서드파티 확장에 변경을 요구하는 선택지가 문제였습니다. PHP 보안팀은 합의에 따라 결정을 내렸고, 엔진을 깊이 아는 개발자도 부족해 수정 작업이 수개월 동안 멈췄다 다시 시작됐습니다. 재단은 이를 보안팀의 의사 결정 방식과 자원 부족에서 비롯된 구조적 실패라고 인정했습니다.
2026년 8월 11일 Calif가 같은 근본 원인에서 비롯된 무조건적 원격 코드 실행 취약점을 보고했습니다. OpenAI도 같은 날 같은 원인을 보고했고, Wiz와 OpenAI가 추가 공격 경로를 전했습니다. 재단은 이 보고들로 문제가 미치는 범위가 분명해지자 수정 작업을 최우선 과제로 삼았습니다. 재단은 재정 지원 덕분에 여러 사람이 전담해 작업할 수 있었다고 밝혔습니다. AI 보안 연구가 늘면서 보고도 증가했습니다. 7월 1일 이후 CVE 15건을 공개했고, 유효하지 않거나 중복되거나 재현할 수 없는 보고 100건 이상을 처리했습니다. AI 도구는 보고 검증과 같은 원인의 보고 분류를 돕지만, 판단과 패치 작업은 사람이 맡는다고 설명했습니다.
보안 체계와 공개 일정
PHP 재단은 2026년 5월 생태계 보안팀(Ecosystem Security Team)을 만들어 기존 보안팀과 함께 취약점 분류, 조율, 강화 작업을 맡겼습니다. 보안 엔지니어와 보안 보고 처리를 담당할 인력을 추가했고, sanitizer 빌드와 PHP 지원 플랫폼별 CI 재현 환경도 마련했습니다. 재단은 Anthropic의 Claude Mythos로 PHP를 검사한 뒤 OpenAI Daybreak Red 등 다른 도구도 활용했다고 밝혔습니다. Calif는 7월 30일부터 PHP 감사를 시작했고 Trail of Bits도 감사를 진행했습니다.
취약점 공개 예정일을 이틀 앞둔 10월 20일, CVE 식별자와 잘못된 공개 시각, 실제 9.2점이 아닌 CVSS 10.0이라는 점수가 온라인에 퍼졌습니다. 기술 세부사항은 유출되지 않았다고 재단은 밝혔습니다. PHP 프로젝트는 사전 공지를 앞당기고 배포 시각을 10월 22일에서 21일로 하루 앞당겼습니다. 배포판들이 수정본을 준비할 시간을 주면서 공개를 서두르는 절충안이었다고 설명했습니다. 이후 Calif가 공개한 개념 증명 영상이 퍼졌고 공격 코드도 늘었습니다. 재단은 공개 시점까지 기능하는 공격을 확인하지 못했다고 밝혔습니다.
Chainguard는 10월 21일 예정 시각보다 6시간 이상 먼저 수정된 이미지를 공개했습니다. PHP 재단은 사전 배포된 패치를 받았던 다른 배포자들과 달리 Chainguard가 조율된 공개를 깼고, 공격자가 다른 사용자보다 먼저 바이너리에서 수정 내용을 분석할 시간을 얻었다고 비판했습니다. Chainguard CEO Dan Lorenc은 Chainguard가 실제 공격이 진행 중이라는 정보를 들었고, 취약점과 수정본이 이미 쉽게 발견될 수 있다고 판단해 이미지를 조기 공개했다고 설명했습니다. 수정 이미지는 누구나 이용할 수 있게 무료로 공개했다고도 밝혔습니다.
재단의 향후 계획
재단은 보안팀의 결정을 과반수로 내리고 타협을 장려하도록 절차를 바꾸고 있다고 밝혔습니다. 복잡한 수정이 교착 상태에 빠지면 재단 지도부가 더 일찍 관여하도록 하겠다는 계획도 제시했습니다. PHP 코드베이스를 깊이 아는 엔지니어가 부족한 만큼, 재단은 인력을 늘리고 보안팀에 필요한 자원을 마련하려면 PHP를 사용하는 조직의 후원이 필요하다고 요청했습니다.
Reddit 반응
- @u/AndyMcQuade — Chainguard는 앞으로 사전 배포본을 받지 못하게 될 것 같네요.
- @u/MitAllesOhneScharf — Chainguard에서 일하는 것으로 보이는 사람이 남긴 글입니다. 우리는 조율된 공개를 위해 팀과 협력했지만, 실제 공격이 시작됐을 때 제가 조기 공개를 결정했습니다. 취약점과 패치가 모두 매우 복잡했는데 유지보수자들이 훌륭하게 해냈습니다. 패치를 충분히 시험했고 잘 작동합니다. 이미지는 무료로 공개했고 앞으로도 그렇게 하겠습니다.
- @u/sullivanmatt — 그 사람은 CEO인 Dan Lorenc입니다.
- @u/Antique-Ad-9282 — 왜죠? 어젯밤 GitHub에 개념 증명이 여럿 올라왔고 대부분 조금 뒤에 삭제됐습니다. 이미 유출돼 사용 중이었다면 왜 공개 시각을 지켜야 하나요? 재단은 몇 달 전부터 알고 있던 문제의 수정안보다 발표 일정에 더 신경 쓴 것 같네요.
- @u/kexxty — 실제로 사용됐다는 증거는 아직 제시되지 않았습니다. 다른 사람들은 개념 증명 시험 외에는 확인하지 못했다고 밝혔습니다.
- @u/SirJerryLion — Chainguard의 행동은 터무니없습니다. 조율된 취약점 공개에서 조율이라는 말도 의미가 있어야 합니다.
- @u/amouat — Chainguard CEO Dan Lorenc이 LinkedIn에 올린 설명입니다. 그는 PHP 재단과 유지보수자들이 압박이 큰 상황에서 훌륭히 대응했다며, 자신의 결정으로 부담을 더한 점을 사과했습니다. 다른 보안 업체들이 실제 공격을 봤다고 전해 들은 뒤 수정본을 배포하기로 했으며, 조율 공개 절차의 지침에 따라 즉시 관계자들에게 알렸다고 설명했습니다.
- @u/LLMsMustUpvoteThis — 실제 공격 시도와 공개된 공격 코드는 다릅니다. Chainguard가 패치 이미지를 공개하면 공격자는 패치를 역공학해 취약점을 파악할 수 있습니다. 몇 시간 안에 다른 PHP 사용자들이 패치할 수 없는 상황에서 공개한 이미지는 Chainguard 고객 외에는 방어에 별 도움이 되지 않았습니다.
- @u/EskilPotet — 패치가 널리 퍼지기 전에 취약점을 공개하는 이유가 궁금합니다. 패치를 역공학할 수 있다면 공개가 공격을 더 쉽게 만들지 않나요? 왜 기다리지 않나요?
- @u/ancillarycheese — 실제 공격이 확인되면 패치가 없어도 시스템을 끄거나 다른 완화 조치를 할 수 있도록 경고해야 합니다.
- @u/Beneficial_Slide_424 — PHP는 8월에 두 곳에서 취약점을 제보받고도 왜 패치하지 않았나요? 원격 코드 실행 취약점 수정에 석 달이 걸린다는 게 말이 되나요?
- @u/DoctorWaluigiTime — 글에서도 이 문제를 다룹니다. AI 보안 연구로 보고가 늘었고, 팀은 7월 1일 이후 CVE 15건을 공개하면서 유효하지 않거나 중복되거나 재현할 수 없는 보고도 100건 넘게 처리했습니다.
- @u/voidiciant — PHP 보안 소식이면 별 감흥이 없었는데, 이번 글을 읽고 이 거대한 시스템을 지키는 유능하고 열정적인 사람들이 겪는 압박을 생각하게 됐습니다. 더 공감하도록 노력하겠습니다.
- @u/Youknowimtheman — PHP 문제는 2024년에 처음 발견했지만 당시에는 예산 제약 때문에 악용 가능성 평가까지 진행하지 못했습니다. 그때는 숙련자 여러 명이 며칠씩 수작업으로 해야 했던 평가를 이제는 AI 도구로 빠르게 할 수 있습니다. PHP 개발자들은 근본적인 엔진 구성 요소를 크게 고치는 방안을 여러 번 시도했지만 완전히 해결하지 못하거나 회귀를 일으켰습니다. 보안 엔지니어와 중요 기반 시설 감사에 더 많은 지원이 필요합니다.
- @u/benjaminovich — 공개 일정이 여러 이유로 앞당겨졌는데, 단순한 의사소통 오류였을 가능성은 없나요? 어떤 방식으로 조율했는지 모르니 성급하게 책임을 묻는 듯합니다.
- @u/New-Track8557 — 그럴 수도 있지만 다른 모든 협력사는 정해진 시각에 공개했는데 Chainguard만 달랐다는 점은 이상합니다.
- @u/cosmic-parsley — 이메일과 PHP 공지에 시각이 나와 있었습니다. 몇 주 동안 개발한 패치의 공개 시각을 잘못 이해했다면 매우 미숙한 일입니다. Chainguard도 의도적으로 결정했다고 확인했습니다.
원문: Reddit / 번역·요약: Trawling