AI가 찾은 PHP 취약점, 패치 배포가 진짜 병목

PHP 사례가 보여준 발견 이후의 일

OpenAI는 10월 21일 중대 취약점 공개 조율 발표에서 최근 두 달 동안 PHP 유지관리자, 보안 연구자, 인프라 제공업체와 취약점 대응을 진행했다고 밝혔다. 회사 설명에 따르면 Calif가 Patch the Planet 활동에서 GPT-5.6 Sol을 이용해 중대 결함 하나를 찾았으며, Wiz도 두 취약점을 독립적으로 발견하고 보고했다. 수정과 릴리스는 PHP 유지관리자가 주도했다.

이 사건을 ‘OpenAI가 PHP를 단독으로 고쳤다’고 요약하면 역할 분담이 사라진다. 모델이 후보를 발견하는 작업, 재현과 영향 범위를 검증하는 작업, 여러 릴리스에 수정 사항을 적용하는 작업, 서비스 운영자가 업데이트하는 작업은 서로 다르다. AI 보안의 성과를 평가하려면 각 단계의 기여와 한계를 나눠야 한다.

PHP 공식 사이트는 10월 21일 보안 공지에서 인증되지 않은 원격 코드 실행으로 이어질 수 있는 취약점 2건을 알리고 즉시 업데이트를 권고했다. CVE-2026-109618과 CVE-2026-109619가 대상이다. 이 글은 공격 재현 절차가 아니라 공식 수정 적용과 운영 검증의 의미를 다룬다.

버전 번호를 읽되 배포판의 수정 이력도 확인해야 한다

PHP가 공지한 수정 릴리스는 8.5.12, 8.4.27, 8.3.36, 8.2.35다. 공식 안내는 웹 요청을 처리하는 PHP 설치를 위험 범위로 설명하고, 특히 mod_php에서 높은 위험을 언급한다. WordPress나 자체 PHP 애플리케이션의 코드 변경이 없어도 기반 런타임을 확인해야 하는 이유다.

다만 운영체제 배포판이나 장기 지원 업체는 수정 사항을 이전 버전에 백포트할 수 있다. 화면에 보이는 상위 버전 문자열만으로 패치 여부를 단정하면 오탐 또는 누락이 생길 수 있다. PHP 8.1 이전 계열의 경우 PHP 프로젝트의 일반 지원이 종료됐다는 사실과 별도 공급자의 보안 지원 여부도 구분해야 한다.

OpenAI는 PHP 버전 확인 도구와 Codex 스킬을 공개했다. 이 도구는 HTTP 헤더나 로컬 PHP가 보고하는 버전을 비교한다. 저장소 설명은 헤더가 숨겨지면 UNKNOWN을 반환하며, OK 역시 실제 수정 코드를 독립적으로 검증한 결과는 아니라고 명시한다. 점검 도구가 손쉬워질수록 그 결과의 의미를 정확히 읽는 일이 중요해진다.

공개 조율의 핵심은 비밀 유지보다 보호 시간이다

OpenAI가 제안한 체계는 다섯 단계로 요약된다. 상위 프로젝트의 취약점을 검증하고 수정한 뒤, 영향을 받는 조직에 보호 조치 시간을 주고, 정부 기관과 조율하며, 관련 제품의 업데이트를 준비하고, 패치가 나온 후 공개 안내와 실제 적용을 지원한다. Patch the Planet은 공개 정보와 운영 지침을 모으는 접점이다.

이 제안은 유지관리자가 사전 공유 대상을 결정하고, 참여 조직에는 보호 업무에 필요한 정보를 제공하는 구조다. 특정 회사에 무조건 먼저 알려준다는 의미도, 모든 내용을 동시에 공개한다는 의미도 아니다. 실제 악용, 정보 누출, 수정 지연 같은 상황이 발생하면 공개 시점을 다시 판단해야 한다는 조건이 포함돼 있다.

경쟁의 초점은 모델의 발견 건수에서 생태계의 대응 처리량으로 옮겨간다. Google OSS 버그바운티의 검증 병목이나 Anthropic OSS Scanner의 유지관리자 부담에서 보듯, AI가 보고서를 늘리는 속도와 사람이 이를 검증하는 속도는 같지 않다. 재현 가능한 증거, 중복 제거, 여러 버전의 회귀 테스트가 함께 제공돼야 탐지 증가가 방어 증가로 이어진다.

한국 기업은 웹서버 목록보다 실행 경로를 파악해야 한다

국내 기업에는 직접 운영하는 웹서버 외에 외주 쇼핑몰, 사내 관리 페이지, 호스팅 상품, 오래된 컨테이너가 섞여 있을 수 있다. 자산 목록에 PHP라고 표시된 시스템만 확인하면 숨어 있는 런타임을 놓칠 수 있다. 먼저 서비스 소유자와 호스팅 공급자에게 영향을 받는 실행 환경, 공급자가 제공한 수정 패키지, 실제 적용 시간을 확인해야 한다.

패키지를 설치한 다음에는 웹 요청을 처리하는 워커와 백그라운드 프로세스가 새 런타임을 사용하도록 반영됐는지 봐야 한다. CLI 결과 하나로 모든 컨테이너와 서버를 대표하게 해서는 안 된다. 업데이트가 어려운 시스템은 공급자의 임시 완화 지침과 운영상 부작용을 함께 검토하되, 이를 영구 수정과 혼동하지 않아야 한다.

이 구분은 Claude의 검증 가능한 양자 회로 최적화 사례와도 통한다. AI가 내놓은 결과는 무엇을 검증하는 검사인지 분명할 때 의미가 있다. 이번 사례에서 성공 지표는 ‘취약점을 찾았다’보다 ‘영향 자산의 수정이 실제로 실행 중이다’에 가까워야 한다.

FAQ

OpenAI가 두 취약점을 모두 단독 발견했나?

아니다. 발표는 Calif의 모델 활용 발견과 Wiz의 독립 발견을 설명하고, PHP 유지관리자가 수정과 릴리스를 주도했다고 밝힌다.

공식 수정 버전은 무엇인가?

PHP 공지 기준 8.5.12, 8.4.27, 8.3.36, 8.2.35다. 배포판의 백포트 여부와 지원 정책은 공급자 공지를 함께 확인해야 한다.

버전 확인 도구가 UNKNOWN이면 안전한가?

아니다. 버전 정보를 얻지 못했거나 인식할 수 없는 경우일 수 있다. UNKNOWN은 패치 완료 판정이 아니다.

도구가 OK면 더 확인할 필요가 없나?

도구 자체도 실제 보안 수정을 독립 검증하지 않는다고 설명한다. 설치 패키지, 배포판 공지, 웹 워커의 실제 실행 상태를 대조해야 한다.

이번 제안은 모든 취약점의 새로운 의무 규칙인가?

아니다. OpenAI가 보안 커뮤니티의 의견을 구하는 대응 체계 제안이다. 각 프로젝트와 운영자의 책임·권한을 대체하지 않는다.