PHP 프로젝트가 10월 21일 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 동시에 공개했다. 이 릴리스는 특정 조건에서 인증받지 않은 공격자가 PHP 구동 서버에서 코드를 실행할 수 있는 두 건의 심각한 취약점을 수정한다. PHP는 정부 서비스, 온라인 상점, 은행, 미디어 사이트 등 웹의 상당 부분을 떠받치고 있어, 운영 환경이 있다면 즉시 업데이트가 필요하다. 다만 이번 사안이 주목받는 이유는 패치 자체보다, 그 취약점이 발견되고 수정되기까지의 과정과 PHP 보안 운영 체계의 구조적 변화에 있다.
두 취약점은 모두 거의 모든 요청이 거쳐 가는 영역, 즉 메모리 관리와 오류 처리에 자리 잡고 있었다. 엔진의 중심부에 위치했다는 점이 문제를 심각하게 만든 동시에, 하위 호환성을 깨지 않고 성능을 떨어뜨리지 않으면서 수많은 서드파티 확장과의 충돌 없이 고치기 어렵게 만들었다. 핵심 엔진을 깊이 아는 개발자가 소수인 상황에서, 중심부 결함일수록 수정 난도가 기하급수적으로 올라간다는 오픈소스의 전형적 딜레마가 드러난 셈이다.
2024년에 이미 감지됐던 신호
문제의 뿌리는 2024년으로 거슬러 올라간다. 당시 PHP는 수년 만에 처음으로 외부 보안 감사를 받았다. PHP 재단이 Sovereign Tech Agency의 자금을 확보해 OSTIF를 통해 감사를 조직했고 Quarkslab이 수행했다. 그 과정에서 재단과 계약한 코어 개발자가 CVE-2026-109618의 배경이 되는 OOM(메모리 부족) 문제의 초기 징후를 발견했다. 그러나 당시에는 실제 공격 경로가 확인되지 않았고 영향이 분명한 다른 문제들에 가려져, 잠재적 위험으로만 분류됐다.
수정 시도는 번번이 벽에 부딪혔다. 보안팀은 여러 해법을 고안했지만 각각 하위 호환성 파괴, 새로운 서비스 거부(DoS) 가능성, 조율이 사실상 불가능해 보이는 다수 서드파티 확장의 수정 요구라는 대가를 안고 있었다. 합의제로 운영되던 소규모 팀은 잘못된 선택의 후폭풍을 우려해 결정을 내리지 못했고, 원격 코드 실행 경로가 아직 알려지지 않았다는 점까지 겹쳐 작업은 수개월간 멈췄다 재개되기를 반복했다. PHP 재단은 이를 "의사결정 절차와 자원 부족이 함께 빚은 구조적 실패"라고 스스로 규정했다. 이후 보안팀은 합의제 대신 다수결로 결정하고 타협을 장려하는 방향으로 절차를 바꾸기 시작했다.
사람과 도구를 함께 늘린 재편
지난 몇 달간 조직은 크게 달라졌다. 재단은 2026년 5월 에코시스템 보안팀을 신설해 분류·조율·하드닝을 분담하게 했고, 7월에는 Alexandre Daubois가 보안 신고 처리와 수정을, 9월에는 Daniel Scherzer가 하드닝을 맡아 합류했다. 도구 측면에서도 Alpha-Omega와 협력해 Anthropic의 Claude Mythos로 PHP를 스캔했고, 이후 신고와 익스플로잇 검증을 위한 OpenAI의 Daybreak Red, 그리고 PHP가 지원하는 모든 플랫폼의 CI와 일치하는 새니타이저 빌드 및 재현 환경을 추가했다.
전환점은 외부 연구에서 왔다. Patch the Planet 프로그램을 통해 보안업체 Calif가 7월 30일 감사에 착수했고, 8월 11일 연구자 Ryan A가 2024년에 포착했던 OOM 문제와 동일한 근본 원인에서 비롯된 조건 없는 원격 코드 실행을 보고했다. 같은 날 OpenAI가 독립적으로 동일한 근본 원인을 보고했으며, 8월 24일 Wiz, 9월 18일 OpenAI가 추가 공격 경로를 알려 왔다. 2년간 잠재적 위험으로만 남아 있던 문제의 전체 영향이 그제야 분명해졌고, 8월 11일 이후 이 수정은 재단 보안 인력 전체의 최우선 과제가 됐다.
여기서 한국 실무자가 눈여겨볼 대목은 AI의 역할 구분이다. AI 기반 연구가 늘면서 보안팀이 받는 신고량도 급증해, 7월 1일 이후 15건의 CVE를 공개하는 동안 무효·중복·재현 불가로 판명된 신고가 100건을 넘었다. 재단은 AI가 신고 검증과 근본 원인별 묶음에는 도움이 되지만, 모든 판단과 패치는 사람이 수행한다고 못 박았다. 오래된 설계 결정에 대한 올바른 수정 방안을 고르고 호환성 트레이드오프를 저울질하는 일은 도구가 대신할 수 없다는 것이다.
조율된 공개가 막판에 무너지다
수주에 걸친 조율된 공개는 목표일 이틀 전까지는 순조로웠다. 그러나 10월 20일 15시경(UTC) 두 CVE 식별자가 잘못된 공개 시각과 잘못된 CVSS 점수(실제 9.2를 10.0으로 표기)와 함께 온라인에 유포됐다. 기술적 세부는 새지 않았다. 재단은 사전 공지를 19시 30분으로 앞당기고 릴리스를 10월 22일에서 21일로 하루 당겼다. 배포판 벤더들이 아직 패키징 중이어서 즉시 공개하면 다수 사용자가 간편한 업데이트 경로를 잃는 상황이었기 때문에, 하루 앞당기는 것이 신속성과 준비 시간 사이의 최선의 절충이었다.
이후 혼란이 이어졌다. 신고 업체 중 하나인 Calif가 PoC 동작 영상을 실수로 공개했다가 삭제했으나 사본이 유포돼 여러 익스플로잇 PoC 개발을 앞당겼다. 결정적으로 10월 21일 07시 41분, 공개 6시간여 전에 Chainguard가 엠바고를 일방적으로 깨고 수정이 담긴 빌드 이미지를 배포했다. 사전에 패치를 받은 배포사가 바이너리 형태의 수정본을 먼저 노출시킨 것으로, 공격자가 다른 모든 사용자가 기다리는 동안 수정 내용을 역분석할 수 있는 상황을 만들었다. 다만 보안팀은 공개 시점까지 실제 동작하는 익스플로잇은 확인하지 못했다고 밝혔다.
이번 사례의 교훈은 명확하다. 웹의 큰 축을 담당하는 PHP의 보안이 여전히 재단 자금으로 움직이는 소수 개발자와 약간의 자원봉사에 의존하고 있다는 점, 그리고 복잡한 트레이드오프에 묶인 수정이 긴급 상황이 되기 전에 리더십까지 빠르게 전달되도록 절차를 바꾸는 일이 관건이라는 점이다. 재단은 깊이 있는 코어 엔지니어를 늘리는 것을 핵심 과제로 삼고 후원을 호소했다. PHP에 의존하는 조직이라면 이번 패치를 적용하는 즉각적 대응과 더불어, 자신들이 쓰는 기반 기술의 유지보수 구조가 얼마나 얇은 층 위에 서 있는지 점검해 볼 시점이다.