PHP 취약점 2건 21일 수정…'웹 70%'는 피해 아닌 사용 비중

인증 없이 서버에서 코드를 실행할 수 있는 PHP 취약점 2건이 21일(현지시간) 수정됐다. 두 건 모두 CVSS v4.0 기준 9.2점이다. 오픈AI와 보안업체 Wiz는 각자 이 취약점을 발견해 신고했다고 밝혔다.

PHP 개발팀은 21일 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 배포했다. 웹 요청을 처리하는 PHP 설치라면 영향권에 들 수 있다고 안내했다. 취약점은 CVE-2026-109618과 CVE-2026-109619다. 첫 번째는 메모리 부족을 처리하는 과정에서 내부 데이터가 잘못된 상태로 남는 문제다. 두 번째는 해제된 메모리를 이후 요청이 다시 참조할 수 있는 문제다.

발견 경로는 한 곳의 공으로 정리하기 어렵다. 오픈AI는 Calif가 GPT-5.6 Sol을 사용해 취약점을 찾았다고 밝혔다. Wiz는 자사 연구진이 8월 19일 이 취약점을 발견했다고 설명했다. PHP 재단은 Calif와 오픈AI의 첫 신고를 8월 11일로 기록했다. Wiz의 신고는 8월 24일로, 두 신고 시점은 13일 차이다.

'웹사이트의 70%'라는 숫자는 Wiz가 PHP의 사용 비중을 설명하며 쓴 표현이다. WordPress·Drupal·Joomla 같은 PHP 기반 서비스가 영향을 받을 수 있다는 취지다. 이 비율만큼의 사이트가 취약하다거나 침해됐다는 수치는 어디에서도 나오지 않았다.

◇ 공개 전 공격 시도, 허니팟 탐지에 한정

아마존($AMZN)의 AWS 위협 인텔리전스 팀은 자사 허니팟에서 17일 취약점 악용 시도를 탐지했다고 밝혔다. 공격자가 공개 전 정보를 어떻게 얻었는지는 불분명하다고 덧붙였다. 허니팟은 공격을 유인하려고 만든 미끼 시스템이다. 이 탐지가 실제 서비스 서버의 침해나 데이터 유출을 뜻하는 것은 아니다.

PHP 재단은 공개 당시 모니터링한 공개 PoC(개념 증명 코드) 가운데 작동하는 익스플로잇은 찾지 못했다고 밝혔다. AWS의 탐지와 재단의 점검은 관측 대상이 달라 직접 비교하기 어렵다.

공개 일정은 앞당겨졌다. 취약점 ID가 공개 전 온라인 포럼과 소셜미디어에 돌자 PHP 재단은 일정을 22일에서 21일로 당겼다. 재단은 이 과정에서 제한된 공격 세부사항이 담긴 영상이 유통됐고, 수정 패치 공개보다 6시간 이상 앞서 빌드 이미지가 배포된 일도 있었다고 밝혔다.

◇ 서버 분리 권고에 서비스 중단 사례도

패치를 바로 적용하지 못하는 서버에는 유럽과 영국의 보안 기관이 공용망에서 분리하거나 내리라고 권고했다. 인터넷 아카이브도 이번 취약점 여파로 한때 오프라인 상태가 됐다가 패치 뒤 복구됐다.

PHP 개발팀은 가능한 한 즉시 수정 버전으로 올리라고 권고했다. PHP 재단은 임시 설정 조치가 특정 공격 경로의 노출을 줄일 수는 있어도 완전한 해결책은 아니라고 선을 그었다. PHP 8.1 이하는 프로젝트 차원의 정기 보안 업데이트 대상이 아니다. 일부 배포판과 장기지원 업체가 별도 수정본을 내놓을 수 있어, 구버전을 쓰는 곳은 공급자에게 제공 여부를 확인해야 한다고 재단은 안내했다.

◇ 오픈AI의 Daybreak, 수익 효과는 별개 문제

오픈AI는 Daybreak를 승인된 방어 조직에 취약점 탐지·분류·수정 검증 도구를 제공하는 프로그램으로 소개했다. 이번 PHP 대응에서는 Calif, Wiz, 유지보수자와 협력했다고 밝혔다. 포천은 오픈AI가 이런 보안 도구로 수익을 얻을 태세라고 짚었다. 다만 Daybreak의 유료 매출이 이번 사건으로 얼마나 늘었는지는 공식 자료에서 확인되지 않는다.

PHP 재단은 이번 취약점의 뿌리 일부가 2024년 외부 보안 감사에서 이미 징후로 포착됐다고 설명했다. 당시에는 구체적인 원격 코드 실행 경로를 찾지 못했고, 호환성과 서비스 거부 위험 같은 절충 문제로 수정도 늦어졌다고 밝혔다. 재단은 PHP가 오랫동안 소규모 보안팀과 유지보수 인력에 의존해 왔다고도 설명했다.

온라인 커뮤니티 반응은 엇갈렸다. Reddit의 PHP·시스템 관리자 커뮤니티에는 패치 적용 여부, 호스팅 업체 대응, 공개 전 공격 탐지에 따른 로그 조사 필요성을 묻는 글이 올라왔다. 일부 이용자는 자체 로그에서 공격 흔적을 찾지 못했다고 적었는데, 개별 관찰일 뿐 전체 피해 현황을 대표하지는 않는다.

Hacker News에서는 공개 전 패치 조율과 공지 시점을 비판하는 의견과 함께 기업 홍보성 메시지를 우려하는 글이 나왔다. 반대로 신고자보다 수정이 지연된 구조와 유지보수 자원 부족을 봐야 한다는 의견도 있었다.

PHP 사이트를 운영하는 곳이 먼저 확인할 것은 자사 PHP 버전이 8.2~8.5 수정 버전에 해당하는지, 또는 배포판·호스팅 사업자가 백포트(최신 버전의 보안 수정을 구버전에 옮겨 적용한 것) 수정본을 제공하는지다.