PHP CVE는 보통 8.3.0 ≤ v < 8.3.8처럼 브랜치별 영향 범위를 제시하며, 상한값이 첫 번째 수정 릴리스입니다. 사용 중인 정확한 버전을 해당 브랜치의 범위와 비교한 다음, 전제 조건을 확인해 실제 노출 여부를 판단하십시오.
CVE 레코드의 구성 요소
CVE(Common Vulnerabilities and Exposures) 레코드는 공개된 취약점에 고유 식별자를 부여해 모두가 같은 문제를 가리킬 수 있게 합니다. PHP의 경우 관련 정보가 여러 곳에 흩어져 있습니다.
| 출처 | 제공하는 정보 |
|---|---|
| CVE.org | 공식 ID와 짧은 설명 |
| NVD | 보강된 데이터: CVSS 점수, CWE 분류, 영향을 받는 구성 |
| php-src security advisories | PHP 프로젝트의 자체 설명, 영향 버전 및 패치 버전 |
| PHP ChangeLog | 어떤 릴리스가 어떤 문제를 수정했는지(CVE ID가 함께 기재되는 경우가 많음) |
| 배포판 추적 페이지 | 백포트를 포함한 패키지 버전별 상태 |
CVE ID
형식은 CVE-YEAR-NUMBER입니다. 연도는 ID가 예약된 해이며, 문제가 발견되거나 공개된 해와 반드시 같지는 않습니다. 번호는 고유성 외에 의미가 없습니다. 다섯 자리나 여섯 자리 번호가 네 자리 번호보다 “더 심각한” 것은 아닙니다.
설명
설명에서는 세 가지를 확인하십시오. 영향을 받는 구성 요소(예: CGI SAPI, 특정 확장 기능, 내장 함수), 결함 유형(메모리 손상, 주입, 정보 노출), 그리고 영향(원격 코드 실행, 서비스 거부, 데이터 노출)입니다.
CVSS 점수
FIRST가 관리하는 CVSS(Common Vulnerability Scoring System)는 0.0부터 10.0까지의 점수와 그 점수가 어떻게 산출되었는지 설명하는 벡터 문자열을 제공합니다. 같은 CVE에 대해 CVSS v3.1 점수와 CVSS v4.0 점수가 함께 표시될 수 있으며, 둘은 직접 비교할 수 없습니다. 또한 출처(PHP 프로젝트, NVD, 배포판)마다 서로 다른 점수를 부여할 수도 있습니다.
| 범위 | 정성적 등급 |
|---|---|
| 0.1 – 3.9 | 낮음(Low) |
| 4.0 – 6.9 | 보통(Medium) |
| 7.0 – 8.9 | 높음(High) |
| 9.0 – 10.0 | 치명적(Critical) |
점수는 일반적인 가정하에서의 기술적 심각도를 나타낼 뿐, 여러분의 구성은 알지 못합니다. 최종 답이 아니라 우선순위를 정하는 데 쓰는 하나의 입력값으로 다루십시오.
영향 버전 범위 읽기
PHP 취약점은 보통 여러 브랜치에 동시에 영향을 주므로, 보안 권고문은 브랜치마다 하나의 범위를 제시합니다. 같은 의미를 여러 표기법으로 나타내기도 합니다.
| 표기법 | 의미 |
|---|---|
8.3.0 ≤ v < 8.3.8 |
8.3.0부터 8.3.8 직전까지의 모든 8.3 릴리스(8.3.8은 미포함) |
>= 8.3.0, < 8.3.8 |
위와 같은 의미를 비교 연산자로 표기 |
< 8.2.20 |
8.2.20 미만의 모든 버전(문맥상 보통 8.2 브랜치 내) |
8.3.0 – 8.3.7 |
영향을 받는 릴리스를 포함 범위로 나열. 8.3.8이 첫 번째 수정 버전 |
<= 8.5.11 |
8.5.11까지(8.5.11 포함) |
| “fixed in 8.3.8” | 해당 브랜치에서 8.3.8 이전 릴리스가 영향을 받음 |
다음 세 가지 규칙을 알면 적용하기가 쉬워집니다.
- 배타적 상한값이 수정 버전입니다.
8.3.0 ≤ v < 8.3.8에서 첫 번째 안전한 릴리스는 8.3.8입니다. - 범위는 브랜치별입니다. 8.3.8의 수정은 8.2에 대해 아무것도 말해 주지 않습니다. 자신의 브랜치에 해당하는 수정 버전을 찾아보십시오.
- 문자열이 아니라 숫자로 비교합니다. 알파벳 순으로는 “10”이 “8”보다 앞에 오지만,
8.3.10은8.3.8보다 새로운 버전입니다. PHP의version_compare()는 이를 올바르게 처리합니다.
<?php
var_dump(version_compare('8.3.10', '8.3.8', '>=')); // bool(true)
예시: CVE-2024-4577
CVE-2024-4577은 특정 코드 페이지를 사용하는 Windows 환경의 PHP-CGI에서 발생하는 인자 주입(argument injection) 취약점입니다. 수정 릴리스는 8.1.29, 8.2.20, 8.3.8이었으며, 당시 지원되던 브랜치의 범위는 다음과 같습니다.
| 브랜치 | 영향 범위 | 첫 번째 수정 버전 |
|---|---|---|
| 8.3 | 8.3.0 ≤ v < 8.3.8 |
8.3.8 |
| 8.2 | 8.2.0 ≤ v < 8.2.20 |
8.2.20 |
| 8.1 | 8.1.0 ≤ v < 8.1.29 |
8.1.29 |
당시 이미 지원이 종료된 브랜치는 업스트림 수정을 받지 못했으므로, 수정 버전 없이 전체 범위가 영향을 받습니다.
예시: 2026년 10월 RCE
2026-10-21에 PHP는 8.5.12, 8.4.27, 8.3.36, 8.2.35를 릴리스해 두 개의 치명적인 원격 코드 실행 취약점인 CVE-2026-109618과 CVE-2026-109619를 수정했습니다. 두 취약점 모두 CVSS v4.0 기준 9.2점입니다. 보안 권고문에는 PHP 5.4부터 8.5.11까지가 영향을 받는다고 명시되어 있습니다. 브랜치별로 나누면 다음과 같습니다.
| 브랜치 | 영향 범위 | 첫 번째 수정 버전 |
|---|---|---|
| 8.5 | 8.5.0 ≤ v < 8.5.12 |
8.5.12 |
| 8.4 | 8.4.0 ≤ v < 8.4.27 |
8.4.27 |
| 8.3 | 8.3.0 ≤ v < 8.3.36 |
8.3.36 |
| 8.2 | 8.2.0 ≤ v < 8.2.35 |
8.2.35 |
| 8.1 이하(5.4까지) | 모든 릴리스 | 없음(지원 종료) |
“5.4부터 8.5.11까지”라는 요약 범위는 정확하지만 잘못 읽기 쉽습니다. 8.4.27이 숫자상 8.5.11보다 낮다고 해서 영향을 받는다는 뜻이 아닙니다. 비교 기준으로 삼아야 하는 것은 브랜치별 표입니다.
“영향 버전”에서 “실제 노출”까지
버전이 영향 범위 안에 있다는 것은 강력한 신호이지만, 실제 노출 여부는 버전 번호로는 파악할 수 없는 조건에도 좌우됩니다.
- SAPI와 플랫폼. CVE-2024-4577은 특정 코드 페이지를 사용하는 Windows의 PHP-CGI가 필요했습니다. 영향 범위에 해당하는 버전이라도 PHP-FPM을 실행하는 Linux 서버는 같은 방식으로 노출되지 않았습니다.
- 확장 기능과 함수. 일부 결함은 하나의 확장 기능에만 존재합니다. 해당 확장 기능이 컴파일되지 않았거나 로드되지 않았다면 취약한 코드도 없습니다.
php -m은 로드된 모듈 목록을,php --ri <name>은 특정 모듈의 상세 정보를 보여 줍니다. - 도달 가능성. 일부 버그는 애플리케이션이 공격자가 제어하는 데이터를 특정 함수에 전달해야만 발생합니다. 코드가 그렇게 동작하는지는 검토를 거쳐야 알 수 있습니다.
- 백포트된 수정. 배포판 패키지는 영향 범위에 속하는 업스트림 버전을 표시하면서도 수정을 포함하고 있을 수 있습니다. PHP 보안 패치 설치 여부 확인을 참고하십시오.
반대도 마찬가지입니다. 지금 전제 조건 하나가 충족되지 않는다고 해서 오래된 버전이 안전해지는 것은 아닙니다. 구성은 바뀌기 마련이며, 영향 범위 밖의 버전을 사용하는 것만이 지속적인 해답입니다.
실용적인 확인 체크리스트
새로운 PHP CVE가 발표되면 다음을 수행합니다.
- CVE ID와 브랜치별 수정 버전을 기록합니다.
- 자신의 브랜치에 해당하는 범위를 찾아 정확한 버전을 숫자로 비교합니다.
- 전제 조건(SAPI, OS, 확장 기능, 구성)을 읽습니다.
- CVSS 점수와 벡터, 그리고 어떤 CVSS 버전을 사용했는지 확인합니다.
- 배포판 패키지를 사용한다면 같은 CVE ID로 벤더의 추적 페이지를 확인합니다.
- 결정하고 기록합니다. 즉시 패치, 다음 작업 기간에 패치, 또는 서면으로 사유를 남긴 해당 없음 중 하나입니다.
PatchScope가 범위를 비교하는 방법
CVE 검사기와 PHP 버전 검사기는 입력한 업스트림 버전을 각 CVE에 기록된 영향 범위와 비교하며, 취약점 목록은 이러한 범위를 직접 보여 줍니다. 방법론 페이지에서는 데이터 출처와 함께, 백포트나 구성별 전제 조건처럼 비교 과정에서 고려하지 않는 사항을 설명합니다. 새로운 보안 권고문이 나온 뒤의 절차는 PHP 보안 권고문 발표 후 해야 할 일을 참고하십시오.