PHP 보안 패치: 버전 검사기 OK보다 실제 실행 환경과 공급자 패치를 확인하세요

PHP 버전 검사기에 OK가 나왔더라도, 그것만으로 웹사이트의 보안 패치가 끝났다고 결재하면 안 됩니다. 이번에 남겨야 할 결과물은 초록색 결과 화면이 아니라 ‘어떤 PHP가 웹 요청을 처리하며, 그 실행 환경에 어떤 공급자의 수정이 반영됐는가’를 설명하는 기록입니다. 반대로 오래된 버전 문자열이 보인다는 이유만으로 공급자가 백포트한 수정까지 없다고 단정해서도 안 됩니다.

판단의 단위는 검사기의 색깔이 아니라, 웹 요청을 처리하는 실행 환경과 그 환경에 적용된 수정 내역의 연결입니다. 직접 서버를 운영한다면 실행 경로와 설치 패키지를 연결하고, 관리형 호스팅을 쓴다면 공급자의 적용 공지와 내 서비스의 적용 범위를 연결해야 합니다. 이 글은 그 연결이 끊기는 지점부터 살펴봅니다.

1. 먼저 맞춰 볼 공식 수정 버전

PHP는 2026년 10월 21일 공지에서 인증 없이 원격 코드 실행으로 이어질 수 있는 치명적 취약점 두 건을 수정했다고 발표했습니다. 식별자는 CVE-2026-109618과 CVE-2026-109619이며, 각 지원 분기의 수정 릴리스는 다음과 같습니다. 표의 버전은 서로 다른 분기의 대응값이지, 숫자가 큰 분기로 무조건 이전하라는 뜻은 아닙니다.

사용 중인 업스트림 분기	이번 공식 수정 릴리스	확인할 의미
PHP 8.5	8.5.12	해당 분기 수정 릴리스와 설치 상태 대조
PHP 8.4	8.4.27	해당 분기 수정 릴리스와 설치 상태 대조
PHP 8.3	8.3.36	해당 분기 수정 릴리스와 설치 상태 대조
PHP 8.2	8.2.35	해당 분기 수정 릴리스와 설치 상태 대조

각 분기의 공식 수정 릴리스입니다. 업스트림 버전 표는 개별 공급자 패키지의 수정 적용 증명이 아닙니다. 출처: www.php.net/archive/2026.php.

공식 공지는 PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 설치 환경을 업데이트 대상으로 다룹니다. 실행 방식마다 공격 경로와 조건이 다르므로 ‘특정 방식만 아니면 괜찮다’고 범위를 줄이지 않는 편이 맞습니다. 그렇다고 모든 사이트에서 이미 침해가 발생했다는 의미는 아닙니다. 취약 가능성과 실제 침해 여부는 별도로 판단해야 합니다.

이 표는 업스트림 릴리스 기준입니다. 리눅스 배포판이나 장기 지원 공급자는 이전 버전에 수정을 가져오는 백포트를 제공할 수 있습니다. 따라서 패키지의 표시 버전이 표보다 낮아 보여도 공급자의 보안 공지와 패키지 릴리스 정보를 함께 봐야 합니다. PHP 8.1 이하에 대해서는 PHP 프로젝트의 정규 업데이트가 종료됐다는 공지와 공급자별 백포트 가능성을 구분해야 합니다. 지원 종료를 곧바로 ‘수정 경로가 전혀 없다’는 뜻으로 바꿔 읽어서는 안 됩니다.

근거: PHP 공식 보안 공지의 위험 대상과 업데이트 방법.

2. 버전을 관측한 곳과 요청이 실행되는 곳은 다릅니다

서버에 접속해 확인한 CLI용 PHP와 웹 요청을 처리하는 PHP가 같은 설치를 가리킨다는 보장은 없습니다. 이 차이를 이해하려면 ‘한 서버에 PHP가 있다’는 설명 대신 ‘이 애플리케이션의 요청이 어디로 전달되는가’를 그려 보면 됩니다. 아래 그림은 실제 운영 서버 캡처가 아니라 관측 위치를 구분하기 위한 개념도입니다.

서로 다른 관측 경로입니다. 헤더와 CLI 결과를 얻은 것만으로 웹 요청 처리 환경의 수정 상태가 확인되지는 않습니다. 출처: raw.githubusercontent.com/openai/php2shell-checker/main/README.md.

URL 검사기는 HTTP 응답의 X-Powered-By 또는 Server 헤더에서 버전 정보를 읽습니다. 헤더가 숨겨졌거나 변경됐다면 실행 환경을 그대로 보여 주지 않을 수 있습니다. 로컬 검사는 php -v가 보여 주는 버전이 대상입니다. 두 결과를 나란히 적는 것만으로 실제 웹 실행 환경을 식별한 일이 되지는 않습니다.

실무적으로는 서비스 이름, 요청 처리 방식, 해당 환경의 PHP 패키지 또는 이미지 식별자, 공급자 수정 공지를 하나의 기록으로 묶는 접근이 유용합니다. 이는 이번 자료를 바탕으로 한 편집상 제안입니다. 모든 환경에서 똑같은 명령을 실행하라는 공식 절차가 아니며, 운영 설정 변경이나 외부 사이트 스캔을 이 글에서 수행한 것도 아닙니다.

관리형 호스팅이라면 내부 실행 파일을 직접 볼 수 없을 수 있습니다. 이때는 임의의 관리자 페이지를 만들거나 민감한 런타임 정보를 공개하는 대신, 호스팅 공급자에게 내 서비스의 PHP 분기와 수정 패키지 적용 여부를 확인하는 쪽으로 질문을 바꾸는 것이 좋습니다. ‘전체 플랫폼 대응 완료’라는 안내와 ‘내 요금제·서버·풀의 적용 완료’가 같은 범위인지도 구분해서 기록할 수 있습니다.

3. OK·VULNERABLE·UNKNOWN을 다음 행동으로 번역하기

검사기 README의 결과 정의는 보안 인증서가 아니라 내장된 분기별 기준과 관측 버전을 비교한 분류입니다. OK는 등록된 분기의 안정 패치 버전이 내장 기준을 초과했다는 뜻입니다. VULNERABLE은 관측 버전이 해당 기준 이하라는 뜻이고, UNKNOWN은 응답이나 버전이 없거나, 인식하지 못한 분기·버전 또는 더 새로운 사전 릴리스인 경우 등을 포함합니다.

관측 결과	이 결과로 말할 수 있는 것	다음에 연결할 근거	여기서 멈추면 안 되는 이유
OK, 종료 코드 0	관측 버전이 검사기의 분기 기준을 넘음	공식 수정 릴리스, 실제 요청 처리 환경	수정 코드 자체를 독립 검증한 결과가 아님
VULNERABLE, 종료 코드 1	관측 버전이 내장 기준 이하임	공급자 보안 공지, 백포트된 패키지 정보	표시 버전만으로 백포트 유무를 확정할 수 없음
UNKNOWN, 종료 코드 3	버전 판단에 필요한 관측이 부족하거나 미지원 상태임	공급자 확인 또는 실행 환경 식별	취약하지 않다는 판정도, 패치됐다는 판정도 아님

왼쪽은 도구 결과, 오른쪽은 편집상 후속 판단입니다. UNKNOWN은 패치됐다는 뜻이 아니며 OK도 수정 코드를 독립 검증하지 않습니다. 출처: raw.githubusercontent.com/openai/php2shell-checker/main/README.md.

여기서 중요한 반례는 두 가지입니다. 첫째, CLI 검사만 OK인 상황에서 웹 처리 환경이 아직 식별되지 않았다면 서비스 전체의 패치 완료 여부는 미확인입니다. 둘째, 오래된 업스트림 문자열을 유지하는 배포판 패키지라면 낮은 문자열만으로 미수정이라고 결론 내릴 수 없습니다. 두 사례 모두 실제 서버에서 재현한 사례가 아니라, README에 명시된 관측 한계를 적용한 판단 예시입니다.

검사기의 HTTP 동작 범위도 좁습니다. 먼저 HEAD를 보내고, HEAD가 405 또는 501일 때만 GET으로 재시도합니다. 리디렉션을 따라가지 않으며 응답 본문도 검사하지 않습니다. 따라서 검사 결과가 비어 있다는 이유로 애플리케이션 내부를 모두 검사했다고 해석해서는 안 됩니다. 숨겨진 헤더가 안전을 뜻하지 않는 것과 마찬가지로, 도구가 읽지 못한 영역은 계속 미확인 영역으로 남습니다.

근거: 검사기 README의 Results와 Limitations. 이 글에서는 검사기를 설치하거나 실행하지 않았으며, 외부 대상도 검사하지 않았습니다.

4. ‘패치 완료’ 기록을 하나의 연결로 만들기

아래 판단표와 증거 묶음은 공식 공지와 검사기 한계를 바탕으로 구성한 운영 해석이며, 특정 서버를 점검하거나 패치 적용을 실증한 결과가 아닙니다. 목적은 모르는 부분을 지우는 것이 아니라, 관측한 사실과 아직 확인하지 못한 사실을 분리하는 데 있습니다.

공식 업데이트 안내와 검사기의 관측 한계에서 도출한 운영 기록 제안입니다. 빈칸을 성공으로 채우거나 보편적 감사 절차로 해석하지 않습니다. 출처: www.php.net/archive/2026.php.

기록의 첫 칸은 서비스와 실제 웹 요청 처리 환경입니다. 두 번째 칸은 그 환경에 설치되거나 배포된 패키지·이미지의 식별 정보입니다. 세 번째 칸은 해당 공급자가 이번 취약점 수정을 포함한다고 안내한 근거입니다. 마지막 칸에는 적용 후 같은 서비스가 수정된 환경으로 요청을 처리하는지 확인한 담당자와 시점을 남깁니다. 실제 값이 없으면 빈칸을 성공 표시로 바꾸지 말고 ‘확인 필요’로 남겨야 합니다.

예를 들어 호스팅 지원팀에는 ‘PHP 최신인가요?’보다 ‘내 서비스가 사용하는 PHP 실행 환경에 두 CVE 수정이 포함됐는지, 어떤 공급자 공지와 적용 범위로 확인할 수 있나요?’라고 물을 수 있습니다. 직접 운영하는 경우에도 설치 명령이 성공했다는 로그와 서비스가 수정된 런타임을 쓰고 있다는 근거를 구분하면 인수인계가 쉬워집니다. 이 질문 방식과 기록 구조는 편집상 운영 제안이며, 보편적인 보안 승인 절차를 대신하지 않습니다.

업데이트가 당장 어렵다면 PHP 공식 공지의 임시 완화책과 적용 조건을 책임 있는 운영 담당자가 검토해야 합니다. 공지는 임시 조치가 특정 공격 경로의 노출을 줄일 뿐 설치 환경을 안전하게 만들지는 않는다고 명시합니다. 메모리 설정 한 줄, WAF 또는 요청 제한만으로 패치와 같은 상태가 됐다고 설명하면 중요한 한계가 빠집니다. 이 글은 운영 환경별 부작용을 평가하지 않았으므로 설정 변경 레시피나 자동 실행 명령을 제공하지 않습니다.

5. AI 발견 뉴스와 유지보수자의 수정을 구분해야 하는 이유

OpenAI의 글은 연구·기술 지원·공개 조율에 기여한 경위를 설명하면서도 수정과 릴리스는 PHP 유지보수자들이 주도했다고 적습니다. PHP Foundation의 설명에는 더 긴 이력이 있습니다. 재단과 연결된 개발자는 2024년 감사 후 OOM 문제의 초기 징후를 보았고, 2026년 추가 보고로 실제 영향이 분명해졌다고 설명합니다. AI가 단독으로 처음 발견하고 스스로 수리했다는 한 문장으로 줄이면 이 이력이 사라집니다.

재단은 AI 도구가 보고서 검증과 중복 분류를 도울 수 있어도 판단과 패치 작업은 사람이 맡는다고 설명합니다. 운영자에게 필요한 질문도 ‘어느 AI가 찾았나’에서 끝나지 않습니다. 유지보수자가 내놓은 수정이 공급자 패키지에 들어갔고, 그 패키지가 내 서비스를 처리하는 실행 환경에 적용됐는지가 남습니다.

시점도 구분해야 합니다. 재단의 기록상 사전 공지는 2026년 10월 20일 19:30 UTC에 나왔고, 릴리스는 10월 21일 14:00 UTC로 앞당겨졌습니다. OpenAI 글의 게시 시각을 패치의 실제 공개 시각으로 대신 쓰면 안 됩니다. 이 글은 원문에 기재된 UTC를 그대로 사용하며 별도 시각 환산을 하지 않았습니다.

6. 확인 범위와 참고 자료

공식 보안 공지와 검사기 한계를 읽어 작성한 AI 활용 해설입니다. 특정 서버의 패치·침해 여부를 판정한 감사 보고서, 도구 사용 후기, 취약점 재현 또는 독립 검증 결과가 아닙니다. 본문 도표는 출처의 사실을 바탕으로 새로 그린 설명 자료이며 실제 제품 화면이나 운영 로그가 아닙니다. 자료의 기준은 이번 선정에 보존된 2026년 10월 22일 수집 원문이며, 이후 공급자별 대응 상태는 별도 확인이 필요합니다.

• PHP 공식 보안 공지와 네 분기의 수정 릴리스: 수정 버전, 위험 대상, 공급자 확인 경로와 임시 완화책의 한계.
• PHP 버전 검사기 README: 결과 코드와 HTTP·CLI 관측 범위.
• PHP Foundation의 수정·발견 이력 설명: 초기 징후, 사람의 판단, 공개 일정 조정.
• OpenAI의 조율 공개 설명: 유지보수자 주도 수정과 연구·배포 조율의 역할.

결론은 단순합니다. 검사기의 표시는 확인 작업의 출발점이고, 완료 근거는 실제 웹 실행 환경과 공급자 수정 내역이 연결된 기록입니다.