PHP 프로젝트가 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 버전을 긴급 배포했다. 이번 릴리스는 공격자가 별도의 인증 없이도 PHP가 구동 중인 서버에서 임의 코드를 실행할 수 있는 치명적 취약점 두 건을 수정한 것으로, 전 세계 웹의 상당 부분이 PHP 기반으로 동작한다는 점에서 파장이 작지 않다. PHP 재단은 이번 패치와 함께, 취약점이 어떻게 발견되고 고쳐졌는지, 그리고 지난 2년간 PHP 보안 체계가 어떻게 바뀌어 왔는지를 상세히 공개했다.

무엇이 문제였나: 메모리 관리와 에러 처리의 약점

이번에 수정된 두 취약점은 모두 PHP 엔진의 가장 핵심적인 부분, 즉 메모리 관리와 에러 처리 로직에 자리하고 있었다. 거의 모든 PHP 요청이 이 두 영역을 거쳐 가기 때문에, 영향 범위가 넓고 심각도도 높았다. 동시에 바로 그 중요성 때문에 수정이 까다로웠다. 하위 호환성을 깨뜨리지 않으면서, 성능을 떨어뜨리지 않으면서, 수많은 서드파티 확장 모듈에 영향을 주지 않으면서 고쳐야 했기 때문이다.

2024년 보안 감사에서 시작된 긴 추적

이번 취약점의 뿌리는 2024년으로 거슬러 올라간다. PHP는 그해 수년 만에 처음으로 외부 보안 감사를 받았다. PHP 재단이 Sovereign Tech Agency의 지원을 받아 OSTIF를 통해 감사를 조직했고, 실제 감사는 보안 업체 Quarkslab이 수행했다. 이 과정에서 PHP 재단이 계약한 핵심 개발자가 Quarkslab이 지적한 문제를 수정하던 중, 훗날 CVE-2026-109618로 명명된 OOM(메모리 부족) 문제의 첫 징후를 발견했다.

당시에는 이 문제를 악용할 수 있는 이론적 가능성만 제기됐을 뿐, 구체적인 공격 경로는 발견되지 않았다. 다른 명확하고 영향이 큰 문제들에 밀려 이 OOM 이슈는 우선순위에서 뒤로 밀렸다.

해결책을 둘러싼 내부 갈등과 수개월의 지연

PHP 보안팀은 이 OOM 문제를 고치기 위해 여러 경쟁 방안을 검토했지만, 각 방안마다 하위 호환성 붕괴, 새로운 서비스 거부(DoS) 가능성, 또는 조율이 사실상 불가능해 보이는 다수 서드파티 확장 모듈 수정 필요성이라는 트레이드오프가 있었다. 합의 기반으로 운영되던 보안팀은 선택지를 좁히지 못했고, 잘못된 결정을 내릴지 모른다는 우려 속에서 작업이 수개월간 멈췄다 재개되기를 반복했다.

PHP 재단은 이를 두고 “원격 코드 실행으로 이어지는 명확한 경로가 알려지지 않았던 점”과 “엔진 내부를 깊이 이해하는 소수 핵심 개발자들이 다른 업무에 쫓기고 있었던 점”이 겹치면서 생긴 구조적 실패였다고 솔직하게 인정했다. 이후 보안팀은 의사결정 과정을 다수결 중심으로 바꾸고 타협을 장려하는 방향으로 프로세스를 개편하는 작업을 이어가고 있다.

재단 조직 개편과 AI 도구를 활용한 보안 강화

지난 몇 달간 PHP 보안 업무 체계는 눈에 띄게 달라졌다. 2026년 5월, PHP 재단은 기존 보안팀과 함께 트리아지·조율·하드닝을 담당하는 에코시스템 보안팀(Ecosystem Security Team)을 신설했다. 또한 재단 상주 AI 보안 엔지니어로 합류한 Volker Dusch의 활동이 보안팀과 재단 간 소통을 크게 개선했고, 7월에는 Alexandre Daubois가 보안 리포트 처리를, 9월에는 Daniel Scherzer가 하드닝 작업을 맡기 위해 합류했다.

기술적으로는 올해 초 Alpha-Omega와 협력해 Anthropic의 Claude Mythos로 PHP 코드베이스를 스캔했고, 이후에는 보고서와 익스플로잗 검증을 위한 OpenAI의 Daybreak Red, 그리고 PHP가 지원하는 모든 플랫폼에 맞춘 새니타이저 빌드와 재현 환경까지 도구를 확장했다. AI 기반 보안 스캐닝과 전통적인 새니타이저·재현 환경 구축을 병행하는 방식이 눈에 띈다.

Patch the Planet 프로그램과 다수 보안 기업의 교차 발견

PHP 재단은 PHP 프로젝트를 ‘Patch the Planet’ 프로그램에 참여시켰고, 이에 따라 보안 업체 Calif가 2026년 7월 30일부터 PHP 감사를 시작했다. 8월 11일, Calif의 연구원 Ryan A는 2024년에 발견했던 OOM 문제와 동일한 근본 원인을 가진 무조건적 원격 코드 실행(RCE) 취약점을 보고했다. 같은 날 OpenAI도 독립적으로 동일한 근본 원인을 보고했고, 이후 OpenAI는 9월 18일에, Wiz는 8월 24일에 각각 추가 공격 경로를 보고했다. 여러 독립적인 보안 조직이 비슷한 시기에 같은 근본 원인을 찾아냈다는 점은, 해당 취약점이 실제로 악용 가능한 수준에 도달해 있었음을 보여준다.

한국 개발자가 지금 해야 할 일

국내 다수의 웹 서비스, CMS(워드프레스 등 포함), 레거시 시스템이 여전히 PHP 기반으로 운영되고 있다. 이번 취약점은 인증 없이 원격 코드 실행이 가능한 수준이므로, 서버 운영자라면 우선순위를 가장 높게 두고 즉시 버전을 업데이트해야 한다. 원문에서는 구체적인 업데이트 절차를 별도로 안내하고 있으니, php.net의 공식 발표문과 기술 세부 사항을 함께 확인하는 것이 안전하다. 또한 이번 사례는 오픈소스 프로젝트의 보안 체계가 단순히 패치 발표로 끝나는 것이 아니라, 감사·트리아지·조직 개편까지 포함하는 장기 과정이라는 점을 보여주므로, PHP 생태계에 의존하는 기업이라면 재단의 보안 활동에 대한 후원이나 기여도 고려해볼 만하다.

원문: Today’s PHP security release, and how we’re strengthening security