PHP 재단은 10월 21일, 보안 결함의 수정이 늦어진 경위를 공개했다. 2024년에 이상 징후를 파악한 메모리 처리 결함이 올해 8월에야 원격 코드 실행으로 이어진다는 사실이 명확해졌고, 수정판은 10월 21일 나왔다. 재단은 지연의 원인을 보안팀의 의사결정 방식과 인력 부족이 낳은 ‘구조적 실패’라고 인정했다.
PHP는 웹서버에서 프로그램을 실행하는 언어다. 이번 문제는 사이트 운영자가 작성한 코드보다 아래에서, 요청을 처리하고 오류를 수습하는 PHP 자체의 동작에 있다. 지난 9월 다룬 워드프레스 코어의 보안 업데이트와 별도로, 이번에는 그 아래에서 실행되는 PHP를 고쳐야 한다. 재단은 같은 날 공개한 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35로 즉시 업데이트하라고 권고했다. 수정 대상은 서로 관련된 치명적 취약점 두 건이며, 공식 위험도 점수는 각각 CVSS v4.0 9.2다.
오류로 끝나야 할 요청이 어떻게 서버 공격으로 이어졌나
첫 번째 결함(CVE-2026-109618)은 메모리가 부족해지는 순간의 처리 방식에서 생겼다. 요청에 필요한 내부 데이터를 아직 다 준비하지 못했는데 실행이 중단되면, 뒤이어 정리하는 코드가 미완성 데이터를 정상 데이터처럼 다룰 수 있었다. 메모리가 부족해 요청이 실패하는 데 그치지 않고, 메모리 손상과 공격자의 코드 실행으로 이어지는 경로다.
Apache 웹서버에 PHP를 모듈로 붙이는 mod_php 환경에서는 로그인하지 않은 사용자의 요청만으로, 사이트의 프로그램이 실행되기도 전에 공격이 가능함을 입증했다. PHP-FPM도 안전한 예외는 아니다. 공식 공지는 웹 요청을 받는 모든 PHP 설치를 위험 대상으로 본다. 다만 공격 경로와 필요한 애플리케이션 조건은 실행 방식에 따라 다르다.
두 번째 결함(CVE-2026-109619)은 이전 요청의 흔적이 다음 요청까지 남는 문제다. 오류 처리나 세션 작업이 내부 상태를 남긴 뒤 치명적 오류로 중단되면, 메모리를 해제하고도 그 메모리를 가리키는 값이 남을 수 있다. 같은 작업 프로세스가 다음 요청을 처리하면서 이를 다시 사용하면 문제가 생긴다. 공식 권고문은 mod_php와 PHP-FPM에서 세션 생명주기를 이용한 원격 코드 실행을 검증했다고 설명한다. 두 취약점을 ‘메모리가 모자라면 모두 뚫린다’고 읽어서는 안 되지만, 우리 사이트 코드에 오류가 없다는 이유로 PHP 업데이트를 미룰 수도 없다.
2024년에 알았는데 왜 결정을 못 내렸나
출발점은 2024년 외부 보안 감사였다. 독일 Sovereign Tech Agency의 지원을 받아 OSTIF가 조율하고 Quarkslab이 수행한 감사에서 나온 문제를 고치던 재단 계약 개발자가 메모리 부족 결함의 징후를 발견했다. 당시에는 악용 가능성이 제기됐지만 구체적인 공격 경로를 찾지 못했다. 영향이 분명한 다른 문제들이 먼저 처리됐다.
해결책이 전혀 없었던 것은 아니다. 보안팀은 여러 접근을 검토했지만 기존 프로그램과의 호환성이 깨지거나, 새로운 서비스 거부 위험이 생기거나, 수많은 외부 확장 모듈을 함께 바꿔야 하는 부담이 있었다. 잘못 고치면 이미 돌아가는 사이트에 장애를 낼 수 있었다. 합의를 바탕으로 움직이는 팀은 어느 손실을 감수할지 정하지 못했고, 엔진을 깊이 아는 소수 개발자는 다른 책임도 맡고 있었다. 수정 작업은 수개월 동안 멈췄다가 재개되기를 반복했다.
전환점은 2026년 8월 11일이었다. 보안업체 Calif와 OpenAI가 같은 근본 원인에서 비롯된 문제를 각각 보고했고, Calif는 원격 코드 실행을 제시했다. 이후 Wiz 등에서 추가 공격 경로가 보고됐다. 재단은 이날부터 보안 업무를 맡은 팀 전체가 수정을 최우선으로 삼았다고 밝혔다. 2024년부터 완성된 공격 방법을 알고 방치했다는 이야기와는 구별해야 한다. 결함의 징후를 알았지만 위험을 충분히 파악하지 못했고, 어려운 수정 결정을 내릴 구조도 부족했다는 설명이다.
설정 하나가 아니라 오류 처리 구조를 바꿨다
공개된 패치는 메모리 부족을 만난 즉시 실행 흐름을 강제로 빠져나가던 방식을 바꾼다. 먼저 다음 안전 지점에서 오류를 처리하도록 하고, 메모리 사용량이 더 높은 한계를 넘으면 프로세스를 즉시 종료한다. 정상적인 메모리 제한은 유지하면서 정리 코드가 미완성 상태를 읽지 않도록 하는 방식이다. 다음 요청까지 남을 수 있는 전역 상태도 더 넓게 초기화한다.
실제 수정 커밋에는 389개 파일 변경이 표시된다. 엔진의 메모리 관리 코드와 여러 확장 모듈, 메모리 부족 상황을 검사하는 테스트가 함께 들어 있다. 파일 수가 결함의 심각도를 뜻하지는 않는다. 이번 수정이 특정 사이트의 조건문 한 줄을 고치는 작업과 왜 다른지 보여 주는 범위다.
공개를 하루 앞당겨도 배포 준비는 필요했다
수정을 마친 뒤에는 배포 순서가 문제가 됐다. 재단에 따르면 원래 공개 예정일은 10월 22일이었다. 20일 온라인에 취약점 번호와 잘못된 공개 시각, 10.0이라는 잘못된 위험도 점수가 퍼지자 PHP 프로젝트는 사전 공지를 앞당기고 공개를 21일 14:00 UTC로 옮겼다. 즉시 내놓지 않은 이유는 배포판 업체들이 아직 업데이트 패키지를 만들고 있었기 때문이다. 결함만 알려지고 사용자가 설치할 수정판이 없는 간격을 줄이려 했다.
공조가 끝까지 지켜지지는 않았다. 재단은 Calif가 실수로 시연 영상을 공개했고, Chainguard가 합의된 시각보다 6시간 이상 먼저 수정된 이미지를 배포했다고 밝혔다. 바이너리 형태라도 수정본이 공개되면 공격자가 변경을 분석할 수 있다. 한 업체의 사용자가 먼저 보호받는 것과 나머지 사용자가 업데이트할 때까지 정보를 함께 관리하는 것은 충돌할 수 있다.
운영자는 지금 무엇을 확인해야 하나
직접 서버를 관리한다면 자신이 쓰는 PHP 계열의 수정판이나 배포업체가 보안 패치를 이식한 패키지가 적용됐는지 확인해야 한다. 배포판은 기존 버전 표기를 유지한 채 수정을 넣을 수 있으므로 숫자만 보고 판단하지 말고 공급업체의 보안 공지를 함께 봐야 한다. 호스팅 서비스를 쓴다면 PHP 업데이트 적용 여부와 적용 일정을 제공업체에 물을 수 있다. PHP 8.1 이전 버전은 프로젝트의 정규 지원이 끝났으므로 공급업체의 별도 지원이나 지원 중인 버전으로의 이전 여부도 확인해야 한다.
공식 공지에는 당장 업데이트하지 못할 때 특정 공격 경로를 줄이는 설정도 나온다. 그러나 메모리 제한을 풀거나 일부 세션 기능을 끄는 조치는 전체 결함을 해결하지 않으며 운영상 부작용도 따진 뒤 적용해야 한다. PHP 프로젝트는 완전한 해결책으로 업데이트를 제시한다.
재단은 보안팀이 다수결과 절충을 통해 결정을 내릴 수 있도록 절차를 바꾸고, 복잡한 수정이 막히면 재단 지도부가 더 일찍 관여하도록 하겠다고 밝혔다. 5월에는 생태계 보안팀을 만들었고 7월과 9월에도 관련 인력이 합류했다. 도구가 찾아낸 보고서를 분류하는 일도 늘었다. 7월 1일 이후 공개한 CVE는 15건이지만 무효·중복·재현 불가로 처리한 보고서는 100건이 넘었다고 한다. 보고서 검증과 같은 원인의 묶음 처리에는 AI를 쓰되 판단과 패치는 사람이 맡는다.
사이트를 맡기는 업체를 평가할 때도 발견 능력과 수정 능력을 따로 볼 필요가 있다. 취약점이 접수된 뒤 누가 우선순위를 정하는지, 호환성 문제로 결정이 막히면 어디로 올리는지, 수정판을 실제 서비스에 적용하는 담당자가 누구인지가 이번 지연과 직접 연결되는 질문이다. 재단은 PHP에 의존하는 기업·호스팅 업체·공공기관에 지속적인 후원을 요청했다. 결함을 찾은 뒤 수개월씩 붙잡고 해결할 엔지니어를 늘리기 위해서다.
출처: PHP 재단의 보안 릴리스 설명, PHP 공식 보안 공지, 메모리 부족 취약점 권고문, 전역 상태 취약점 권고문