2026년 10월 PHP 긴급 보안 취약점 사태 – 대응 방법 그리고 버전 업데이트 후 검증 방법
PHP로 서비스를 운영하고 있다면, 먼저 실제 웹 요청을 처리하는 PHP에 보안 패치가 적용됐는지 확인하세요.
2026년 10월 21일 공개된 CVE-2026-109618과 CVE-2026-109619는 조건에 따라 로그인이나 인증 없이 원격 코드 실행을 허용할 수 있는 취약점입니다. 애플리케이션 코드만 수정해서 해결할 수 있는 문제가 아니므로 PHP 실행 환경을 업데이트해야 합니다. PHP 공식 공지
1. 사용 중인 PHP 버전부터 확인하세요
서버 터미널에서 다음 명령으로 PHP 버전을 확인할 수 있습니다.
php -v
다만 이 결과는 명령줄에서 실행되는 PHP의 버전입니다. 웹서버가 사용하는 PHP-FPM이나 호스팅에 설정된 PHP 버전과 다를 수 있습니다.
운영 방식에 맞춰 실제 서비스 환경도 확인하세요.
- PHP-FPM: 웹서버가 연결한 FPM 서비스와 해당 패키지 버전
- Docker: 서비스 중인 컨테이너 내부의 PHP 버전과 배포 이미지
- 웹호스팅: 관리 화면에 표시된 사이트별 PHP 버전과 업체의 패치 안내
- 여러 서버 운영: 트래픽을 처리하는 모든 서버의 적용 상태
버전 확인을 위해 phpinfo() 페이지를 인터넷에 공개해 두는 방식은 피하세요. 운영 환경 정보가 함께 노출될 수 있습니다.
2. 현재 사용 중인 계열에서 수정 버전으로 올리세요
이번 두 취약점의 수정 기준은 다음과 같습니다.
| 사용 중인 계열 | 패치가 포함된 버전 |
|---|---|
| PHP 8.2 | 8.2.35 이상 |
| PHP 8.3 | 8.3.36 이상 |
| PHP 8.4 | 8.4.27 이상 |
| PHP 8.5 | 8.5.12 이상 |
예를 들어 PHP 8.3을 사용한다면, 우선 8.3.36 이상의 수정 버전으로 업데이트하는 방식으로 대응할 수 있습니다. 위 표는 이번 취약점의 수정 기준이며, 설치 시에는 공급처의 최신 보안 업데이트도 확인하세요. PHP 릴리스 안내
리눅스 배포판이 기존 버전에 보안 수정만 반영하는 백포트 패치를 제공하는 경우도 있습니다. 이때는 php -v의 숫자만으로 판단하지 말고, 배포판 보안 공지에서 해당 CVE의 수정 여부와 설치된 패키지 릴리스를 대조해야 합니다.
PHP 8.1 이하는 PHP 프로젝트의 공식 지원이 종료된 상태입니다. 일부 공급업체의 백포트와 PHP 측의 제한적인 소스 패치는 있지만, 장기 운영을 위해서는 지원 중인 계열로 이전하는 것이 좋습니다. PHP 업데이트 지침
3. 패키지를 설치한 뒤 실제 서비스에도 반영하세요
업데이트 명령이 성공했다고 바로 작업을 끝내면 안 됩니다. 기존 프로세스나 컨테이너가 계속 요청을 처리하고 있지는 않은지 확인해야 합니다.
환경별로 다음 작업까지 진행하세요.
| 운영 환경 | 적용 시 확인할 작업 |
|---|---|
| PHP-FPM | 업데이트 후 해당 FPM 서비스를 재시작하고 정상 기동 확인 |
| Apache + mod_php | Apache 재시작 후 PHP 적용 상태 확인 |
| Docker | 수정 버전이 포함된 이미지로 빌드·배포하고 기존 컨테이너 교체 |
| 관리형 호스팅 | 업체에 패치 적용 여부와 사이트 반영 여부 확인 |
여러 서버를 운영한다면 순차적으로 교체하면서 상태를 확인하세요. 배포 이미지나 자동 확장 설정도 함께 수정해야 이후 생성되는 서버에 구버전이 다시 배포되는 일을 막을 수 있습니다.
4. 업데이트 후에는 주요 기능과 오류 로그를 확인하세요
실무에서는 다음 항목까지 확인하는 것을 권장합니다.
- 실제 웹 요청을 처리하는 환경에 수정 버전 또는 공급업체 패치가 적용됐는지
- 로그인과 세션 유지가 정상적으로 동작하는지
- 파일 업로드, DB 연결, 주요 API가 정상인지
- 배포 이후 HTTP 500 오류나 PHP 오류 로그가 늘지 않았는지
- 모든 서버와 컨테이너에 동일하게 반영됐는지
특히 PHP의 상위 계열로 이동했다면 사용 중인 프레임워크, 확장 모듈, Composer 의존성의 호환성도 확인해야 합니다.
5. 바로 업데이트하기 어렵다면 외부 노출부터 줄이세요
호환성 문제로 패치가 지연된다면, 패치가 완료될 때까지 취약한 서비스의 외부 접근 제한이나 일시 중단을 검토하세요. ENISA도 인터넷에 공개된 시스템을 우선 조치하고, 즉시 수정하기 어려운 경우 공개 네트워크에서 격리하는 방안을 권고했습니다. ENISA 대응 권고
PHP 공식 공지의 임시 설정 변경은 특정 공격 경로를 줄이기 위한 조치입니다. 임시 조치만 적용하고 업데이트를 생략해서는 안 됩니다. PHP 공식 보안 공지
이번 대응의 완료 기준은 모든 운영 인스턴스에 수정 사항이 반영되고, 실제 서비스가 정상 동작하는 것으로 잡으세요. 적용 버전, 작업 시각, 검증 결과를 기록해 두면 다음 긴급 업데이트 때도 빠르게 대응할 수 있습니다.
2026년 10월, 웹사이트와 업무 시스템을 운영하는 조직들에 긴급한 보안 과제가 떨어졌다. 널리 사용되는 서버용 프로그래밍 언어 PHP에서 인증 없이 원격으로 코드를 실행할 수 있는 중대 취약점 두 건이 공개된 것이다. ‘PHP2Shell’로 알려진 이번 문제는 특정 사이트의 개발 실수를 넘어, 여러 서비스가 공통으로 사용하는 실행 환경의 결함이라는 점에서 파장이 컸다. 유럽연합 집행위원회와 유럽 사이버보안청(ENISA) 등은 공동 성명을 내고 즉각적인 대응을 촉구했다. ENISA 공동 성명
PHP 보안팀은 10월 20일 긴급 보안 업데이트를 예고했고, 21일 수정 버전을 공개했다. 대상은 CVE-2026-109618과 CVE-2026-109619로, 두 취약점 모두 심각도 평가 체계인 CVSS v4.0에서 9.2점을 받았다. 첫 번째는 메모리 부족 상황을 처리하는 과정에서 내부 데이터가 불완전한 상태로 사용되는 문제이고, 두 번째는 해제된 메모리를 가리키는 내부 상태가 남아 이후 요청 처리에 영향을 주는 문제다. 두 결함 모두 조건이 충족되면 외부 공격자의 코드 실행으로 이어질 수 있다. PHP 공식 보안 공지
이번 사태가 특히 심각했던 이유는 로그인이나 애플리케이션 자체의 보안 장치만으로 방어하기 어려웠기 때문이다. PHP 측은 PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed 등 웹 요청을 처리하는 PHP 환경을 위험 점검 대상으로 제시했다. 특히 mod_php에서는 애플리케이션 코드가 실행되기도 전에 인증되지 않은 요청으로 공격을 유발하는 사례가 시연됐다고 밝혔다. 사이트의 로그인 절차가 견고하더라도, 그 아래에서 요청을 처리하는 기반 소프트웨어가 취약하면 위험이 남을 수 있다는 뜻이다. PHP 공식 보안 공지
그렇다고 취약한 PHP를 사용하는 모든 사이트가 이미 해킹됐다는 의미는 아니다. 취약점의 존재, 공격 성공 가능성, 실제 침해 여부는 구분해야 한다. 영국 NHS England는 10월 29일 갱신한 경보에서 두 취약점이 미국 CISA의 실제 악용 취약점 목록에 등재됐으며, 연구자들이 PHP 기반 제품에서 원격 코드 실행을 시연했다고 설명했다. 동시에 자체 보안관제 조직이 당시 대규모 악용의 증거를 관측하지는 않았다고 명시했다. 위험은 현실적이지만, 이를 곧바로 인터넷 전반의 대규모 피해로 확대 해석해서는 안 된다. NHS England 보안 경보
대응의 중심은 보안 패치 적용이었다. 10월 21일 배포된 수정 버전은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12다. NHS England는 해당 버전 또는 그 이후의 수정된 지원 버전으로 업데이트하도록 안내했다. 즉시 패치할 수 없는 경우에는 위험을 평가하고, 패치를 마칠 때까지 취약한 시스템을 외부에서 접근할 수 없도록 하는 방안도 검토하도록 했다. 임시 조치만으로 대응을 끝내기에는 결함의 영향이 컸기 때문이다. NHS England 대응 지침
운영 현장에서 중요한 질문은 “우리 회사가 PHP로 개발하는가”보다 “우리 서비스 어디에서 PHP가 실행되는가”였다. ENISA는 PHP를 직접 사용하는 것처럼 보이지 않는 상용 제품이나 오픈소스 제품도 내부적으로 PHP에 의존할 수 있다고 지적했다. 따라서 직접 운영하는 웹서버뿐 아니라 호스팅 서비스와 외부 공급업체가 관리하는 시스템까지 확인해야 했다. 인터넷에 공개된 시스템을 우선 점검하고, 공급업체와 패치 적용 여부를 확인하는 일이 대응의 출발점이었다. ENISA 대응 권고
이번 사건이 남긴 운영상의 교훈은 분명하다. 평소 사용 중인 소프트웨어와 버전, 관리 책임자를 파악해 두지 않으면 긴급 업데이트가 나와도 적용 대상을 찾는 데 시간을 잃는다. 업데이트 절차가 준비돼 있지 않으면 보안 위험과 서비스 중단 위험 사이에서 판단도 늦어진다. PHP2Shell 사태는 웹서비스의 안전이 애플리케이션 개발 단계에서 끝나지 않으며, 그 기반을 지속적으로 파악하고 신속하게 수정하는 운영 역량에 달려 있음을 보여줬다.