대상 독자: PHP로 웹사이트를 운영하는 모든 분(자체 서버, VPS, 클라우드, Docker 또는 공유 호스팅)과 WordPress, Laravel, EC-CUBE 등으로 사이트를 만드는 분. 이 글은 PHP 보안팀의 공식 발표와 공공기관 및 사업자의 발표를 바탕으로 작성되었습니다. 공격 방법은 다루지 않습니다.
진행 중: 새로운 내용이 발표되면 이 페이지를 업데이트합니다
2026년 10월 25일(JST) 기준. 호스팅 업체 및 OS 패키지는 2026년 10월 23일 02:15 UTC 기준아직 확인되지 않음
- 세 번째 문제 CVE-2026-115560의 영향받는 버전, CVSS 점수, 수정 릴리스(다음 정기 릴리스에 포함 예정)
- 실제 환경에서의 악용(공식 입장)과 침해 사고 발생 여부
- 나머지 OS 패키지 계열(RHEL 9 php:8.4, Debian testing forky)
- 완료를 발표하지 않은 호스팅 업체(KAGOYA, 수정 버전이 없는 버전의 CPI, PHP 5.5 이하의 Xserver 등)
PHP 보안팀은 10월 21일 수정 버전을 출시했으며, 일본 IPA와 JPCERT/CC는 10월 22일 경보를 발표했습니다. 일본의 주요 공유 호스팅 업체 대부분은 수정이 적용되었다고 발표했습니다. 여러 회사가 악용 시도를 관찰했다고 밝혔지만, 확인된 침해 사고는 발표되지 않았습니다. 10월 23일에는 수정 버전에서 다루지 않은 세 번째 문제(CVE-2026-115560)가 공개되었습니다. PHP 팀은 실제로 발생할 가능성은 낮다고 평가하지만, 다음 정기 릴리스 전까지 session.upload_progress.enabled=0 설정을 권장합니다. 남은 OS 패키지와 업체의 상황이 확인되는 대로 이 페이지를 업데이트하겠습니다.
수정 버전과 취약점(php.net 기준)
2026년 10월 21일 PHP 보안팀은 php.net에 보안 권고문("Critical remote code execution vulnerabilities, update now")을 게시하고, 각 브랜치의 수정 릴리스를 발표했습니다.
- 수정 버전
- PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35
- CVE-2026-109618
- 메모리 부족 처리 과정에서 내부 요청 데이터가 부분적으로만 초기화된 상태에서 PHP가 중단될 수 있으며, 이후 요청 정리 과정이 잘못된 데이터를 유효한 것으로 처리할 수 있습니다. 원격 코드 실행(RCE)으로 이어집니다
- CVE-2026-109619
- 요청에 속한 내부 상태가 그 기반 메모리가 해제된 뒤에도 남아 있을 수 있으며, 같은 워커가 처리하는 이후 요청이 초기화 전에 이 잔존 상태를 사용할 수 있습니다. 원격 코드 실행(RCE)으로 이어집니다
- 심각도
- 둘 다 CVSS v4.0 9.2
- 위험 대상
- 웹 요청을 처리하는 모든 PHP 설치(PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). mod_php가 가장 위험하며, 애플리케이션 코드가 실행되기 전에 인증되지 않은 요청으로 공격이 시작되는 시연된 익스플로잇이 있습니다
- 8.1 이하
- PHP 프로젝트의 공식 업데이트 없음. 7.4, 8.0, 8.1에 대해 최소 소스 백포트가 제공되었습니다
- 배포판
- 리눅스 배포판과 LTS 벤더가 사전에 패치를 받았습니다. 업데이트된 패키지는 벤더에 확인하십시오
- 완화책
- 완전한 완화책은 없으며, 업데이트만이 유일하게 안전한 선택입니다(바로 업데이트할 수 없는 경우의 임시 조치는 아래 상자를 참고하십시오)
바로 업데이트할 수 없는 경우의 임시 조치(권고문 기준, 안전을 보장하지는 않습니다)
PHP 팀은 업데이트 전까지 특정 공격 경로를 줄이는 설정을 안내하지만, 어느 것도 설치를 안전하게 만들지는 못한다고 밝혔습니다. 주요 항목은 memory_limit과 post_max_size 같은 요청 크기 제한 검토, session.upload_progress.enabled 비활성화 및 워커 재시작, PHP 8.5에서 fatal_error_backtraces 비활성화입니다. 적용 조건이 중요하므로 무엇이든 변경하기 전에 공식 권고문을 읽고, 업데이트를 우선하십시오.
릴리스에서 수정되지 않은 세 번째 문제(CVE-2026-115560, 10월 23일 공개)
2026년 10월 23일 PHP 보안팀은 php.net에 "Informational advisory: Session upload progress"를 게시하여, 10월 21일 릴리스에서 수정되지 않은 문제를 공개했습니다. 이 문제는 앞선 두 건의 치명적 취약점과는 별개입니다.
- CVE
- CVE-2026-115560. 전체 권고문은 다음 릴리스와 함께 공개될 예정입니다(2026년 10월 25일 기준 CVE 레코드와 NVD에는 아직 항목이 없습니다)
- 조건
- 설정과 애플리케이션 코드의 특수한 조합에서만 영향을 받습니다. 설정에서 session.serialize_handler가 php_binary 또는 php_serialize로 지정되어 있고, 애플리케이션이 session_start() 호출 전에 ini_set()으로 런타임에 php로 전환하며, 세션 업로드 진행 상황(session.upload_progress)이 여전히 활성화되어 있어야 합니다. 런타임에 serialize 핸들러를 바꾸지 않는 애플리케이션은 해당 기능을 활성화한 상태로 둘 수 있습니다
- 영향
- 원격 코드 실행(RCE)으로 이어질 수 있습니다. 팀은 이 구성이 "실제로는 발생할 가능성이 낮다"고 밝혔습니다
- 완화책
- 다음 정기 릴리스 전까지 session.upload_progress.enabled=0으로 설정하십시오. 같은 설정은 10월 21일 권고문에서 CVE-2026-109619(GHSA-6wmf-4rv5-p3rp)의 완화책으로 이미 안내되었습니다. 그때 적용했다면 그대로 유지하면 되고, 추가 조치는 필요하지 않습니다
- 수정
- 이 구성은 발생 가능성이 낮아 정기 릴리스 주기에서 처리되며, 수정과 전체 권고문은 다음 릴리스에 포함됩니다. 날짜는 발표되지 않았습니다
- 아직 공개되지 않은 내용
- 영향받는 버전과 CVSS 점수
- 악용
- PHP 팀의 발표문은 악용에 대해 언급하지 않습니다
릴리스 이후(2026년 10월 23일 02:15 UTC 기준)
- 릴리스 시각
- GitHub 보안 권고는 약 13:34 UTC(22:34 JST)에 게시되었으며, 예정된 14:00 UTC보다 약 30분 앞섰습니다
- 영향받는 버전
- 공식 GitHub 권고에 따르면 8.2.35, 8.3.36, 8.4.27, 8.5.12 이전 버전. CVE 레코드는 8.2–8.5를 나열하며, 8.1 이하에 대해서는 언급하지 않습니다(팀은 7.4, 8.0, 8.1에 대해 소스 수정을 제공했습니다)
- 확인된 영향(권고 기준)
- CVE-2026-109618: mod_php에서 인증 없는 원격 코드 실행이 확인되었습니다. PHP-FPM은 소스 분석에 따라 영향을 받을 수 있지만, 완전한 익스플로잇은 시연되지 않았습니다. CVE-2026-109619: mod_php에서 원격 코드 실행이 확인되었습니다. 또한 PHP-FPM에서도 세션 업로드 진행 경로를 통해 검증되었으며, 이는 적합한 애플리케이션 동작에 따라 달라집니다
- 일본 공공기관
- 10월 22일 IPA는 10월 21일의 사전 공지에 이어 "PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)"(PHP 취약점 대응 방법, 일본어)를 발표했습니다. 수정 버전(8.2.35, 8.3.36, 8.4.27, 8.5.12)으로 업데이트할 것을 요청합니다. 수명이 다한 8.1 이하는 지원되는 PHP나 수정이 완료된 제품 또는 서비스로 옮길 것을 요청합니다. 효과적인 임시 조치가 어려운 경우, 기관이 외부 접근 차단 또는 서비스 일시 중단 여부를 판단하도록 권고합니다. 또한 연구에 참여한 한 보안 회사의 견해를 인용해 PHP 5.4 이상이 최소 한 가지 결함의 영향을 받는다고 밝혔습니다(이는 PHP 팀의 발표가 아닌 해당 회사의 견해입니다). JVN은 같은 날 10:30 JST(01:30 UTC)에 JVNVU#99905564를 공개해 패치 적용을 요청했습니다. JPCERT/CC도 같은 날 경보(JPCERT-AT-2026-0033)를 발표해 신속한 업데이트와 침해 징후 확인을 촉구했습니다. 침해 징후를 확인할 때 살펴볼 항목도 함께 제시했습니다
- CISA
- CISA는 10월 21일 즉시 패치를 촉구하는 경보를 발표했습니다. 게시 시점까지 "이 취약점들의 악용이 관찰되지 않았다"고 밝혔습니다. 즉시 업데이트할 수 없거나 여전히 PHP 8.1 이하를 사용하는 조직에는, 패치 또는 업데이트가 완료될 때까지 PHP 기반 시스템을 오프라인으로 전환할 것을 권고했습니다. 이 결함들은 알려진 악용 취약점(KEV) 카탈로그(10월 21일 판)에 포함되지 않았습니다
- 실제 환경에서의 악용
- PHP 팀의 발표는 없으며, CISA는 게시 시점까지 악용이 관찰되지 않았다고 밝혔습니다. CISA가 CVE 레코드에 추가한 악용 등급은 10월 22일 업데이트 후에도 "없음"으로 남아 있었습니다. 한 주요 클라우드 사업자의 위협 인텔리전스 팀은 10월 21일 허니팟에서 공개일 4일 전인 10월 17일에 악용 시도를 관찰했다고 발표했습니다(게시물). 이 회사는 이 결함들이 "현재 실제 환경에서 광범위한 악용 시도를 보이고 있다"고 하면서도, "이 시도들 중 실제 시스템에서 성공한 것이 있었는지는 불분명하다"고 밝혔습니다. 최소 10월 17일부터 조사할 것을 권고합니다. CDN 사업자와 여러 보안 회사도 공격 또는 탐색 트래픽을 관찰했다고 보고했습니다(CDN 사업자, 뉴스 요약). 또 다른 보안 회사는 10월 22일 업데이트에서 공개된 익스플로잇이 기본 PHP 설치에서는 작동하지 않으며, 대규모 악용은 처음 예상보다 가능성이 낮다고 밝혔습니다. 일본에서는 Lolipop과 Heteml이 10월 22일 취약점을 겨냥한 것으로 보이는 접근을 확인했다고 밝혔지만, 그로 인한 무단 접근이나 데이터 유출은 지금까지 확인되지 않았습니다. 2026년 10월 23일 02:15 UTC 기준으로 확인된 침해 사고는 발표되지 않았습니다
- OS 패키지
- Ubuntu는 나열된 26.10, 26.04, 24.04, 22.04 릴리스에 수정을 제공합니다. 20.04와 18.04의 수정에는 Ubuntu Pro가, 16.04와 14.04의 수정에는 Legacy Support 추가 기능이 필요합니다(USN-8948-1, USN-8948-2). Debian은 13(DSA-6574-1)과 12(DLA-4848-1)를 수정했으며, sid에는 수정된 8.4.27-1이 있지만 testing(forky)은 아직 수정되지 않은 8.4.26-1입니다. Red Hat은 RHEL 8–10의 여러 스트림을 수정했고(중요도 Important, access.redhat.com), 10월 21일 RHEL 8 php:8.2를 추가했습니다(RHSA-2026:87073). RHEL 9 php:8.4는 아직 수정되지 않았습니다(10월 22일 업데이트에서 "Affected"). RHEL 6은 "지원 범위 밖"으로 표시되어 수정 계획이 없으며, RHEL 7은 CVE-2026-109619의 영향을 받고 아직 수정되지 않았습니다. Alpine은 8.5, 8.4, 8.3을 수정했습니다. PHP를 OS 패키지로 설치했다면 지금 벤더의 업데이트를 적용하십시오
- Docker 공식 이미지
- latest, 8.5, 8.4, 8.3, 8.2 태그(-apache, -fpm 변형 포함)는 모두 수정 버전(8.5.12, 8.4.27, 8.3.36, 8.2.35)을 가리킵니다(hub.docker.com). 수명이 다한 8.1 이하 태그는 업데이트되지 않았습니다. 수정은 이미지를 다시 받아 컨테이너를 재생성한 뒤에야 적용됩니다
- NVD
- NVD 자체 점수는 두 건 모두 CVSS 3.1 9.8(Critical)이며, PHP 팀의 점수는 CVSS v4.0 9.2입니다(nvd.nist.gov)
- 수정이 불완전하다는 주장
- 한 취약점 메일링 리스트 게시물은 8.5.12 수정이 "불완전할 수 있다"고 주장했습니다. PHP 보안팀을 대신해 발표문을 게시한 개발자는 10월 22일(09:11 UTC) 같은 리스트에서 이것이 "영향이 미미한 무관한 문제"(가능성이 낮은 시나리오에서 한 구성 요소의 크래시)이며 "RCE와는 아무 관련이 없다"고 답변했습니다(답변). php.net 발표문은 변경되지 않았습니다
- Windows
- 수정 버전의 Windows 빌드를 이용할 수 있습니다
- remirepo
- PHP 팀은 자원봉사로 운영되는 rpms.remirepo.net이 오늘 업데이트를 제공하지 않을 것이라며, 배포판 패키지로 전환하거나 소스에서 직접 빌드할 것을 권고했습니다
사전 공지(10월 20일)
하루 전인 2026년 10월 20일 PHP 보안팀은 php.net에 "Upcoming Critical PHP Security Release"라는 공지를 게시했습니다. 내용은 다음과 같습니다.
- 릴리스 시각
- 2026년 10월 21일 수요일 14:00 UTC(일본 시간 23:00)
- 범위
- 치명적 취약점 2건
- 심각도
- 둘 다 CVSS v4.0 9.2
- 요청
- 모든 PHP 사용자는 릴리스가 나오면 즉시 업그레이드할 수 있도록 지금 준비하도록 권장됩니다
- 조기 릴리스
- 어느 한 취약점의 세부 내용이 공개되거나 실제 악용의 증거가 나타나면 팀이 더 일찍 릴리스할 수 있습니다
- 아직 공개되지 않은 내용
- 전체 세부 내용, 영향받는 버전과 수정 버전. 모두 릴리스와 함께 공개될 예정입니다
- 당시 최신 버전
- 8.5.11, 8.4.26, 8.3.35, 8.2.34(2026년 9월 24일 보안 릴리스)
CVSS는 취약점의 심각도를 0에서 10까지로 평가하며, 9.0 이상은 최상위 "Critical" 등급입니다(CVSS란 참고). 일본 IPA도 10월 21일 조직에 PHP를 사용하는 프로그램을 목록화할 것을 요청하는 "사전 준비 요청" 공지를 발표했습니다. IPA는 PHP가 웹 애플리케이션뿐 아니라 소프트웨어 제품과 네트워크 장비 내부에서도 실행될 수 있다고 지적했습니다.
PHP 업데이트 담당자: 환경에 따라 다릅니다
PHP로 동작하는 모든 사이트가 영향을 받을 수 있지만, 실제로 누가 PHP를 업데이트하는지는 환경마다 다릅니다. 이를 잘못 파악하면 "업체가 했을 줄 알았다"거나 "사이트를 제공하는 PHP가 아닌 다른 버전을 업데이트했다"는 식의 공백이 생깁니다.
자체 서버, VPS, 클라우드
직접 업데이트합니다(패키지 업그레이드 후 재시작)
Docker(공식 이미지)
새 태그가 나온 뒤 이미지를 다시 빌드합니다
배포판 패키지(Debian, Ubuntu, RHEL 등)
배포판이 수정을 백포트하고, 사용자가 적용합니다. 버전 번호는 업스트림과 다릅니다
공유 호스팅
업체가 PHP를 업데이트합니다. 사용자는 선택한 버전을 확인합니다
| 환경 | PHP 업데이트 담당 | 사용자가 할 일 |
|---|---|---|
| 자체 서버, VPS, 클라우드 서버 | 본인 | 수정 버전(또는 배포판의 수정 패키지)을 설치하고 PHP-FPM 또는 Apache를 재시작합니다 |
Docker 공식 이미지(php:8.4-fpm 등) | 이미지 관리자와 본인 | 수정 태그가 게시되면 이미지를 받아 다시 빌드하고 컨테이너를 교체합니다. 캐시된 이전 기본 이미지를 재사용하지 마십시오 |
| 배포판 패키지(Debian, Ubuntu, RHEL 계열) | 배포판과 본인 | 배포판의 보안 공지에서 수정 패키지를 확인하고 적용합니다. 배포판은 수정 사항만 백포트하므로 버전 번호가 PHP 업스트림 번호와 일치하지 않습니다 |
| 공유 호스팅 | 업체 | 제어판에서 각 사이트의 PHP 버전을 확인하고, 8.1 이하라면 전환을 계획하며, 업체 공식 웹사이트의 공지를 확인합니다 |
| 제품이나 장비에 내장된 PHP | 벤더 | 벤더의 보안 공지를 확인합니다(내부 PHP는 보이지 않을 수 있습니다) |
WordPress나 Laravel의 업데이트 버튼은 PHP 자체를 업데이트하지 않습니다. 애플리케이션 업데이트와 PHP 업데이트는 별개의 작업입니다.
PHP 버전을 안전하게 확인하는 방법
서버에 로그인할 수 있다면 명령줄을 사용하십시오
셸 접근 권한이 있다면 다음 명령으로 PHP 버전을 확인할 수 있습니다.
php -v다만 이는 명령줄(CLI) PHP의 버전입니다. 웹사이트를 제공하는 PHP(PHP-FPM 또는 Apache 모듈)는 다른 버전일 수 있습니다. 한 서버에 8.2와 8.4가 함께 설치되어 있는 경우도 흔합니다. 웹 쪽은 아래 방법이나 PHP-FPM 서비스 이름(예: php8.4-fpm)으로 확인하십시오.
WordPress에서는 사이트 상태 검사를 사용하십시오
WordPress 대시보드에서 도구, 사이트 상태, 정보 탭을 열고 "서버"를 펼치십시오. 여기에는 실제로 사이트를 실행 중인 PHP 버전이 표시되므로, 서버에 로그인하지 않아도 관리자 권한이 있는 사람이라면 확인할 수 있습니다.
공유 호스팅에서는 제어판을 사용하십시오
공유 호스팅에서는 제어판의 PHP 버전 설정에서 도메인별로 선택된 버전을 볼 수 있습니다. 많은 업체가 도메인별로 다른 버전을 고르도록 하므로, 모든 도메인을 확인하십시오.
phpinfo() 페이지를 온라인에 방치하지 마십시오
버전을 확인하는 한 방법은 공개 디렉터리에 phpinfo()를 호출하는 파일을 두는 것이지만, 이 페이지에는 PHP 버전, 설정, 내부 서버 정보가 나열됩니다. 공격자에게 유용한 표적 정보를 주므로, 확인이 끝나면 즉시 삭제하십시오. 위의 세 가지 방법으로 충분하다면 아예 만들지 마십시오. 잊힌 파일을 찾는 방법은 공개 디렉터리에 남겨진 비밀 파일에서 다룹니다.
업데이트 전에 할 일
사이트와 서버를 목록화하십시오
사이트마다 어느 서버에 있는지, PHP 버전(CLI와 웹), PHP 업데이트 담당자(본인, 업체 또는 외주 업체), 소유자 연락처를 하나의 표에 적으십시오. 스테이징 사이트와 아직 공개 상태인 잊힌 사이트도 포함하십시오. 업데이트가 빠지기 쉬운 곳이 바로 잊힌 사이트입니다. 방법은 보안 자산 목록 점검표에서 다룹니다.
백업을 만드십시오
업데이트로 사이트가 깨질 경우 되돌릴 수 있도록 파일과 데이터베이스를 백업하십시오. 백업은 서버 밖에 보관하고, 복원이 가능한지 확인하십시오(백업과 복구의 기본).
점검 시간과 절차를 정하십시오
언제 업데이트할지(심야 시간대 포함), 누가 할지, 사람들에게 어떻게 알릴지 정하십시오. 자체 서버라면 업데이트 명령, 재시작할 서비스, 결과 확인 방법을 적어 두십시오. 외주 업체나 대행사가 서버를 관리한다면, 오늘 중으로 누가 언제 업데이트하는지 확인하십시오.
수명이 다한 브랜치라면 이전 계획을 세우십시오
php.net에 따르면 PHP 8.1의 지원은 2025년 12월 31일에 종료되었으며, 8.0 이하도 마찬가지입니다. PHP 프로젝트의 지원 정책에 따라 수명이 다한 브랜치는 보안 릴리스를 받지 않습니다. 이번에도 공식 릴리스는 없었고(7.4, 8.0, 8.1에 대한 최소 소스 백포트만 제공), 지원되는 버전, 즉 8.2–8.5로의 이전을 계획하십시오. 8.2의 보안 지원도 2026년 12월 31일에 종료되므로, 지금 옮긴다면 8.3 이상이 더 안전한 목표입니다.
공식이 아닌 '수정' 플러그인이나 설정 우회법에 서두르지 마십시오
수정이 나오기 전에는 해당 문제를 차단한다고 주장하는 비공식 플러그인과 설정 변경이 돌아다니기 쉽습니다. 공식 권고에 없는 방법은 검증할 수 없습니다. 유일한 실질적 해결책은 PHP의 수정 릴리스(또는 배포판의 수정 패키지)입니다. WAF(웹 애플리케이션 방화벽) 규칙은 시간을 벌어줄 수 있지만, WAF를 거치지 않고 서버에 도달하는 트래픽에는 효과가 없습니다.
수정 버전으로 업데이트하기
수정 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35입니다(2026년 10월 21일 출시). PHP를 OS 패키지로 설치했다면, 배포판이 제공하는 업데이트 패키지를 사용하십시오.
사용 중인 브랜치의 수정 버전으로 업그레이드하십시오
php.net 릴리스 공지와 ChangeLog에서 사용 중인 브랜치(8.2, 8.3, 8.4 또는 8.5)의 수정 버전을 확인하고, 그 버전 이상으로 업데이트하십시오. 배포판 패키지를 쓴다면 배포판의 보안 공지(Debian, Ubuntu, Red Hat 등)에서 수정 패키지 버전을 확인하십시오. Docker는 수정 태그가 게시되면 이미지를 받아 다시 빌드하십시오.
PHP-FPM과 Apache를 재시작하십시오
패키지를 업그레이드해도 이미 실행 중인 PHP 프로세스는 바뀌지 않습니다. 새 PHP를 적용하려면 PHP-FPM(예: php8.4-fpm)을 재시작하고, Apache의 PHP 모듈을 쓴다면 Apache도 재시작하십시오.
세 번째 문제(CVE-2026-115560)를 위해 세션 설정을 확인하십시오
이 문제는 10월 21일 릴리스로 옮긴 뒤에도 남아 있습니다. 두 가지를 확인하십시오.
- 설정(php.ini 등)에서 session.serialize_handler가 php_binary 또는 php_serialize로 지정되어 있고, 애플리케이션 코드가 ini_set()으로 이를 php로 바꾸는지(코드에서
session.serialize_handler를 검색하면 빠르게 찾을 수 있습니다) - session.upload_progress.enabled가 여전히 켜져 있는지(기본값은 켜짐입니다. CLI의
php -i결과는 웹 쪽과 다를 수 있으므로, PHP-FPM 풀과 사이트를 제공하는 PHP의 설정도 함께 확인하십시오)
두 조건이 모두 해당하거나 판단이 어렵다면, 다음 정기 릴리스 전까지 session.upload_progress.enabled=0으로 설정하십시오. 설정은 php.ini, PHP-FPM 풀, 웹 서버 설정처럼 시작 시 읽히는 위치에 두고, 모든 워커를 재시작하십시오(10월 21일 권고문도 session.upload_progress.enabled=0을 관리 설정으로 지정하고 모든 워커를 재시작하라고 안내합니다). 이 기능은 파일 업로드의 진행 상황을 보여주므로, 사이트에서 업로드 진행 표시를 사용한다면 설정 후에도 정상 동작하는지 확인하십시오. 10월 21일 권고의 임시 조치로 이미 비활성화했다면 그대로 두십시오. 일본의 공유 호스팅 중에서는 Heteml과 Lolipop이 이미 이 기능을 비활성화했습니다.
CLI와 웹 양쪽에서 버전을 확인하십시오
php -v와 함께 WordPress 사이트 상태 검사 또는 PHP-FPM 서비스 상태를 사용해, 웹사이트를 제공하는 PHP가 지금 수정 버전인지 확인하십시오. 여러 PHP 버전이 설치된 서버라면 모두 확인하십시오.
사이트가 정상 동작하고 이상이 없는지 확인하십시오
주요 페이지, 로그인, 문의 양식, 결제를 점검하십시오. 수정 전에 사이트가 공격받았을 수도 있다고 걱정된다면, 알 수 없는 파일, 추가된 관리자 계정, 페이지 변조를 확인하십시오. 한 주요 클라우드 사업자는 공개일 4일 전인 10월 17일에 악용 시도를 관찰했으며, 최소 그 날짜부터 조사할 것을 권고합니다. JPCERT/CC의 경보에도 확인할 항목이 나와 있습니다. 확인 방법은 웹사이트나 서버가 침해되었는지 확인하는 방법에서 다룹니다.
공유 호스팅 사용자를 위한 안내
공유 호스팅에서는 업체가 서버에 PHP를 설치하고 관리합니다. 사용자가 직접 수정 버전을 설치할 수는 없습니다.
업체가 하는 일
- 서버에 설치된 PHP를 수정 버전으로 업데이트
- 필요하면 임시 보호 조치 또는 긴급 점검 적용
- 공식 웹사이트와 소셜 미디어에 상태 공지 게시
사용자가 할 일
- 제어판에서 도메인별로 선택된 PHP 버전 확인
- 8.1 이하라면 테스트 후 최신 버전으로 전환
- 이메일 링크가 아닌 공식 웹사이트에서 업체 공지 확인
- WordPress 코어, 플러그인, 테마도 최신 상태로 유지
업체 측 긴급 점검으로 한동안 제어판을 사용할 수 없을 수 있습니다. 그 시간대에 PHP 버전을 바꿔야 하는 상황을 피하도록, 미리 점검을 끝내 두십시오.
사업자 대응 현황(이 사이트가 2026년 10월 23일 02:15 UTC 기준으로 확인한 내용)
많은 업체가 수정 적용을 마쳤다고 밝혔습니다. 2026년 10월 23일 02:15 UTC(일본 시간 11:15) 기준으로 KAGOYA는 완료를 발표하지 않았습니다. CPI는 수정 버전이 없는 버전을 사용하는 고객에게 완화 조치를 적용하거나 패치된 버전으로 전환할 것을 요청했습니다. Rakko Server와 WADAX에서는 PHP 관련 공지를 찾지 못했습니다. 아래 시각은 모두 일본 시간(JST)입니다.
| 업체 | 공식 공지 | 내용 |
|---|---|---|
| Xserver(일본) | 예방적 안전 조치로 공식 웹사이트 및 제어판을 일시 중단한다는 공지(10월 22일 20:10 기준 상태, 일본어) | 제공하는 각 PHP 버전에 공식 수정 또는 자체 수정을 적용했습니다. PHP 8.2–8.5는 10월 22일 06:45에, 7.4–8.1은 12:00에, 5.6–7.3은 14:00에 대상 서버 전체 적용을 마쳤습니다. PHP 5.5 이하는 패치를 "작성 및 검증 중"입니다. 20:10부터 서비스 사이트를 순차적으로 재개했으며, 공식 웹사이트, 제어판, 웹메일, API/MCP, 문의 양식이 복구되었습니다(구 웹메일 등 일부 기능은 아직 점검 중입니다). 이용 상황에 따라 일부 고객에게 추가 조치를 요청할 수 있습니다. 무단 접근이 원인이 아니라고 밝혔습니다 |
| Sakura Rental Server(일본) | PHP 취약점 대응 현황(10월 22일, 일본어) | 제어판에서 선택할 수 있는 모든 PHP 버전에 수정을 적용했으며, 고객의 긴급 조치는 필요하지 않습니다. 최신 지원 PHP로 옮길 것도 권장합니다. 일부 서비스의 웹메일은 10월 22일 13:45에, phpMyAdmin은 15:15에 복구되었습니다(점검 공지). 10월 21일의 긴급 점검(n-2697)은 10월 21일 22:30에 끝났습니다 |
| mixhost(일본) | [완료] 치명적 PHP 취약점 대응(10월 22일, 일본어) | 10월 22일 약 10:18에 모든 서버에 수정 패키지를 적용했으며, PHP 5.2–8.5가 대상입니다. 버전 번호는 바뀌지 않습니다(예: 8.4.26은 그대로 8.4.26). 고객의 조치는 필요하지 않습니다. 10월 21일 22:10부터 진행된 마이페이지 점검도 끝났습니다 |
| ColorfulBox(일본) | 공지(10월 22일, 일본어) | 사전 보호 조치와 수정 버전 적용을 10월 22일 오전까지 모든 서버(공유, 비즈니스, 다다 서버, 전용)에서 완료했으며, 7.4, 8.0, 8.1도 포함됩니다. 사용 중인 PHP 버전을 유지한 채 제자리에서 업데이트했으며, 고객의 조치는 필요하지 않습니다 |
| XREA, VALUESERVER, CORESERVER, One Rental Server(일본) | XREA, VALUESERVER, CORESERVER V1 / V2, One(일본어) | 다섯 곳 모두 완료했습니다. XREA, VALUESERVER, CORESERVER V1은 10월 22일 00:50에 완료되었으며, 갱신된 공지에 따르면 제공 중인 모든 PHP 버전(5.3–8.5)이 수정되었습니다. One Rental Server는 10:20(5.6–8.5), CORESERVER V2는 11:13(5.2–8.5)에 완료되었습니다. 사용자가 PHP 버전을 바꿀 필요는 없습니다 |
| Heteml(일본) | PHP 취약점 점검 완료 및 경과, [완료] 점검 공지(10월 22일 18:05, 일본어) | 고객 사이트는 10월 22일 11:24에 복구되었고, 18:05에 모든 서비스가 복원되었습니다. PHP 8.2–8.5는 공식 수정 릴리스를, 7.4, 8.0, 8.1은 수명이 다한 브랜치에 대한 PHP 팀의 수정을, 5.6–7.3은 공식 수정을 바탕으로 한 업체 자체 수정을 적용받았습니다. 모든 버전에서 이 조치로 한 기능(session.upload_progress)이 비활성화되며, 고객은 사이트 정상 동작을 확인하고 8.2 이상으로 옮길 것을 요청받았습니다. 수정이 적용되기 전인 10월 22일 약 03:05부터 일부 서버의 사이트를 중단했습니다 |
| Lolipop(일본) | PHP 취약점 점검 완료 및 경과, [완료] 점검 공지(10월 22일 16:57 갱신, 일본어) | 고객 사이트는 10월 22일 약 13:00에 복구되었고, 16:57에 모든 점검이 완료되었습니다. PHP 8.2–8.5는 공식 수정 릴리스를, 7.4, 8.0, 8.1은 수명이 다한 브랜치에 대한 PHP 팀의 수정을, 5.3–7.3은 공식 수정을 바탕으로 한 업체 자체 수정을 적용받았습니다. 모든 버전에서 한 기능(session.upload_progress)이 비활성화되며, 고객은 사이트를 확인하고 8.2 이상으로 옮길 것을 요청받았습니다. 수정이 적용되기 전인 10월 22일 약 03:09부터 일부 서버의 사이트를 중단했습니다 |
| KAGOYA(일본) | PHP 취약점이 서비스에 미치는 영향(10월 22일 18:15 갱신, 일본어) | 렌털 서버(PHP 7.4 및 8.1–8.5)는 수정 버전으로의 업데이트가 진행 중이며, 10월 22일 24:00에 완료될 것으로 예상한다고 밝혔습니다. 2026년 10월 23일 11:15 기준 완료 공지는 찾지 못했습니다. 매니지드 전용, 공유, WordPress 플랜은 영구 수정이 아직 준비 중이며, 임시 조치로 사이트를 오프라인(점검 페이지로 전환)하거나 접근을 제한하는 것을 고객에게 검토하도록 요청했습니다. 10:35 업데이트에서는 공격이나 데이터 유출 등의 피해가 확인되지 않았다고 밝혔습니다. 10월 22일 14:15부터 웹메일, 회원 사이트, 제어판에 대한 보안 점검도 진행 중이며, 종료 시각은 밝히지 않았습니다 |
| ConoHa WING(일본) | PHP 취약점 대응 완료(최종 보고)(10월 22일, 일본어) | 10월 22일 20:45 기준 모든 서버에 보안 패치가 적용되었고, 긴급 점검도 이때 끝났습니다. 패치는 버전을 올리지 않고 수정만 반영하는 방식으로 제공 중인 모든 PHP 버전에 적용되었으므로, WordPress 사이트 상태 검사 등 화면에는 이전 번호(예: 8.5.11)가 계속 표시될 수 있습니다. 고객은 버전을 바꿀 필요가 없습니다. 웹메일과 파일 관리자는 약 18:30에 복구되었으며, phpMyAdmin도 복구되었습니다 |
| Onamae.com 렌털 서버(일본) | PHP 취약점 대응 완료(10월 22일, 일본어) | ConoHa WING과 같은 내용입니다. Basic, RS 플랜, AI 홈페이지 팩 모두 10월 22일 20:45 기준 패치가 적용되었습니다. 제공 중인 모든 PHP 버전에 수정만 반영했으므로 표시되는 버전 번호는 바뀌지 않을 수 있습니다. 고객은 버전을 바꿀 필요가 없습니다. 웹메일과 파일 관리자는 약 18:30에 복구되었으며, phpMyAdmin도 복구되었습니다 |
| CPI(일본) | PHP 취약점으로 서비스 사이트 및 제어판 일시 중단 안내(10월 23일 09:55 갱신, 일본어) | 최신 패치가 제공되는 버전은 완료되었습니다(예: SV-Basic의 8.2, 8.3, Business Standard의 8.2–8.4). 그 밖의 버전은 고객에게 완화 조치 적용과 패치된 PHP 버전으로의 전환을 검토할 것을 요청했습니다(구형 플랜은 완화 조치 적용을 검토). 서비스 사이트는 10월 22일 21:00에, 제어판은 약 17:00에 재개되었으며, 보안 파일 관리자 등 일부 도구는 10월 30일 이후로 예상됩니다. 취약점을 악용한 무단 접근이나 공격은 확인되지 않았다고 밝혔습니다 |
| Rakko Server(일본) | 공식 웹사이트(일본어) | 예방 차원에서 10월 21일 19:00부터 서비스 사이트를 중단했습니다(무단 접근은 발견되지 않았다고 밝힘). 사이트는 복구되었지만, 2026년 10월 23일 11:15 기준 PHP 관련 공지는 찾지 못했습니다 |
| WADAX(일본) | 공식 웹사이트(일본어) | 10월 22일 확인 시점에 안전이 확보될 때까지 전체 사이트가 보안을 이유로 중단되어 있었습니다. 2026년 10월 23일 11:15 기준 웹사이트는 복구되었지만, PHP 관련 공지는 찾지 못했습니다 |
업체마다 완료 공지의 표현이 다릅니다. 업체 공지에서 어떤 PHP 버전이 포함되는지, 사용자가 무언가 해야 하는지 확인하십시오. ConoHa WING, Onamae.com, mixhost 등 일부 업체는 수정만 반영했으므로 PHP 버전 번호가 바뀌지 않습니다. 버전 번호만 보고 사이트가 패치되지 않았다고 판단하지 마십시오. 업체 공지를 확인하십시오. 다른 업체의 공지는 확인되는 대로 추가하겠습니다.
호스팅 업체를 사칭한 가짜 이메일을 조심하십시오
취약점이나 긴급 점검이 뉴스에 나오면, 호스팅이나 도메인 업체를 사칭한 가짜 이메일("긴급 점검을 위해 다시 로그인하십시오", "계정이 정지됩니다")이 늘어납니다. 이메일의 링크로 로그인하지 마십시오. 직접 북마크해 둔 공식 웹사이트나 업체의 공식 소셜 미디어 계정으로 확인하십시오. 가짜 이메일을 구분하는 방법은 피싱이란에서 다룹니다. 업체 자체가 침해되었을 때의 대비는 호스팅 업체가 침해되었을 때에서 다룹니다.
릴리스 이전 보고
2026년 10월 21일의 공식 발표는 CVE ID(CVE-2026-109618, CVE-2026-109619)와 두 건 모두 원격 코드 실행(RCE) 취약점이라는 점을 확인했습니다. 아래 표는 릴리스 이전에 보고된 내용을 보여주며, 실제 환경에서의 악용은 여전히 공식적으로 확인되지 않았습니다.
릴리스 이전에 언론과 보안 회사가 여러 주장을 전했습니다. 어느 것도 PHP 보안팀의 공식 발표가 아니었습니다. 이 사이트는 이를 근거로 권장 조치를 바꾸지 않았습니다.
| 주장 | 출처 | 상태 |
|---|---|---|
| 예정된 릴리스 이전에 결함 세부 내용이 유출되었다 | 한 보안 회사(언론사와의 인터뷰) | 확인되지 않음 |
| 둘 다 원격 코드 실행(RCE) 결함이다 | 보안 회사, 그리고 CERT-EU(EU 기관용 CSIRT) | 10월 21일 발표로 확인됨 |
| CVE ID(CVE-2026-109618, CVE-2026-109619) | 보안 회사, 언론, CERT-EU | 10월 21일 발표로 확인됨 |
| PHP 5 이후의 넓은 범위가 영향을 받는다 | 보안 회사, CERT-EU | 확인되지 않음(GitHub 권고는 각 수정 릴리스 이전 버전을 대상으로 하며 하한은 명시하지 않았습니다. 7.4/8.0/8.1에 백포트가 제공되었습니다). IPA의 10월 22일 경보는 연구에 참여한 한 보안 회사를 인용해 PHP 5.4 이상이 영향을 받는다고 밝혔습니다 |
| 악용이 관찰되지 않았다 | 한 보안 회사(언론사와의 인터뷰) | 해당 출처의 견해 |
| 공격 징후가 관찰되었다 | CDN 사업자의 임원, 다른 보안 회사(호스팅 파트너의 보고 인용), 그리고 한 주요 클라우드 사업자 | CDN 사업자는 13:56 UTC 게시물에서 공격 트래픽을 관찰했다고 밝혔고, 한 주요 클라우드 사업자는 10월 17일부터 악용 시도를 관찰했다고 밝혔습니다("릴리스 이후" 항목 참고). 어떤 공공기관도 이를 확인하지 않았습니다 |
악용에 대한 견해는 출처마다 다릅니다. 10월 21일의 사전 공지에서 IPA는 그 시점에 결함을 악용한 공격이 확인되지 않았다고 밝혔습니다. CISA도 10월 21일 경보에서 게시 시점까지 악용이 관찰되지 않았다고 밝혔습니다. 반면 한 주요 클라우드 사업자는 공개 이전인 10월 17일에 악용 시도를 관찰했다고 밝혔습니다. 악용이 시작되었는지와 상관없이 해야 할 일은 같습니다. 지금 수정 버전으로 업데이트하십시오.
이 사이트의 견해: 오늘 결정할 것은 누가, 언제 업데이트할지입니다
수정 버전은 이미 나왔습니다. 남은 일은 누가, 언제 업데이트할지 정하고 실행하는 것입니다. 흔한 공백은 기술 문제보다 책임 주체의 문제입니다. 대행사가 만든 사이트, 이미 떠난 사람이 설정한 VPS, 아무도 기억하지 못하는 테스트 서버 등 명확한 담당자가 없는 PHP가 가장 오래 낡은 상태로 남습니다. 심각도 판단 방법은 취약점 우선순위 정하기(CVSS, EPSS, KEV)에서, 공개 이후의 절차는 취약점이 공개되었을 때 할 일에서 다룹니다.
타임라인
2026년 9월 24일
PHP 8.5.11, 8.4.26, 8.3.35, 8.2.34가 보안 릴리스로 출시되었습니다(공지 당시 최신 버전).10월 17일(10월 21일 발표)
한 주요 클라우드 사업자의 허니팟에서 공개 4일 전 악용 시도가 관찰되었습니다.10월 20일
PHP 보안팀이 php.net에서 10월 21일 14:00 UTC 보안 릴리스를 예고합니다. 두 취약점 모두 CVSS v4.0 9.2로 평가되었습니다. 같은 날 한 보안 회사가 세부 내용이 유출되었다고 언론사에 밝힌 것으로 보도되었습니다.10월 21일
IPA가 "사전 준비 요청" 공지를 발표합니다. Xserver는 16:00 JST부터 공식 웹사이트와 제어판 접근을 중단합니다.10월 21일
PHP 보안팀이 8.5.12, 8.4.27, 8.3.36, 8.2.35와 보안 권고를 출시합니다. CVE-2026-109618과 CVE-2026-109619는 모두 인증되지 않은 원격 코드 실행을 허용할 수 있으며, 모든 사용자에게 즉시 업데이트를 권고한다고 밝혔습니다.10월 21일
CISA가 즉시 패치를 촉구하는 경보를 발표하며, 게시 시점까지 악용이 관찰되지 않았다고 밝힙니다.10월 22일
Xserver(8.2–8.5), Sakura, mixhost, ColorfulBox, Value Domain 그룹 서비스, Heteml, Lolipop 등이 수정 적용을 발표합니다. JVN이 JVNVU#99905564를 공개하고, IPA가 PHP 취약점 대응 경보를, JPCERT/CC가 경보(JPCERT-AT-2026-0033)를 발표합니다.10월 22일(저녁, JST)
ConoHa WING과 Onamae.com은 20:45 JST 기준 패치가 적용되었다고 밝힙니다. Xserver는 14:00 JST까지 PHP 5.6–8.5를 마쳤고, 20:10 JST부터 공식 웹사이트를 재개합니다. KAGOYA는 렌털 서버가 24:00 JST에 완료될 것으로 예상한다고 밝힙니다.10월 23일
PHP 보안팀이 10월 21일 릴리스에서 수정되지 않은 세 번째 문제(CVE-2026-115560)를 공개합니다. 실제로 발생할 가능성은 낮다고 평가하며, 다음 정기 릴리스 전까지 session.upload_progress.enabled=0 설정을 권장합니다.
출처(공개 기록)
이 글의 사실은 아래 공개 정보에 기반합니다. PHP가 공식적으로 발표하지 않은 내용(실제 환경의 악용 등)은 언론이나 보안 회사의 주장으로 표시하고 미확인으로 구분했습니다.
- PHP 보안팀, "Security advisory: Critical remote code execution vulnerabilities, update now"(2026년 10월 21일) — php.net
- PHP 보안팀, "Informational advisory: Session upload progress"(CVE-2026-115560, 2026년 10월 23일) — php.net
- CVE-2026-109618 GitHub 보안 권고 — github.com
- CVE-2026-109619 GitHub 보안 권고 — github.com
- ChangeLog(8.5.12, 8.4.27, 8.3.36, 8.2.35) — php.net
- PHP, "Upcoming Critical PHP Security Release"(2026년 10월 20일) — php.net
- PHP 홈페이지(당시 최신 버전: 8.5.11, 8.4.26, 8.3.35, 8.2.34) — php.net
- PHP, "Supported Versions" — php.net
- PHP, "Unsupported Branches"(8.1 지원 종료: 2025년 12월 31일) — php.net
- php-src 보안 권고(GitHub) — github.com
- IPA, PHP 보안 릴리스에 대비한 사전 준비 요청 공지(2026년 10월 21일, 일본어) — ipa.go.jp
- IPA, "PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)"(2026년 10월 22일, 일본어) — ipa.go.jp
- JVN, 임의 코드 실행을 허용하는 여러 PHP 취약점 JVNVU#99905564(2026년 10월 22일, 일본어) — jvn.jp
- JPCERT/CC, 여러 PHP 취약점(CVE-2026-109618, CVE-2026-109619) 경보(JPCERT-AT-2026-0033, 2026년 10월 22일, 일본어) — jpcert.or.jp
- CISA, "Critical Vulnerabilities in PHP Require Immediate Patching"(2026년 10월 21일) — cisa.gov
- Xserver Inc., 예방적 안전 조치로 한 일시 중단 공지(2026년 10월 22일, 20:10 JST 기준 상태, 일본어) — xserver.ne.jp
- 한 주요 클라우드 사업자의 위협 인텔리전스 팀: 공개 이전인 10월 17일부터의 악용 시도(2026년 10월 21일) — aws.amazon.com
- 수정이 불완전하다는 주장에 대한 PHP 보안팀 개발자의 답변(2026년 10월 22일) — openwall.com
- 호스팅 업체의 완료 공지: ConoHa WING / Onamae.com / Lolipop / Heteml(모두 2026년 10월 22일, 일본어)
- CERT-EU, "Security Advisory 2026-018: Critical Vulnerabilities in PHP"(미확인 주장의 출처) — cert.europa.eu
- 언론 보도: 한 보안 회사가 밝힌 유출 경위와 악용이 관찰되지 않았다는 견해(BleepingComputer, 2026년 10월 20일) — bleepingcomputer.com
- 언론 보도: 세 번째 문제(CVE-2026-115560)의 완화 방법(BleepingComputer, 2026년 10월 23일) — bleepingcomputer.com
- 보안 회사 경보: 호스팅 파트너로부터 보고된 공격(2026년 10월 21일) — patchstack.com
- CDN 사업자 임원의 게시물: 초기 공격과 WAF 규칙(2026년 10월 21일, 위 경보에 인용) — x.com
- 보안 회사 긴급 대응: 파트너 시스템에서 실제 환경의 악용이 관찰되지 않음(2026년 10월 21일 기준) — huntress.com
- 보안 회사 분석 자료(보고된 CVE ID, 유형, 범위) — sansec.io / tenable.com
- 배포판 보안 공지: Debian security-tracker.debian.org / Ubuntu ubuntu.com / Red Hat access.redhat.com(RHEL 8 php:8.2: RHSA-2026:87073)
- Docker 공식 이미지(php) — hub.docker.com
업데이트 기록
2026-10-25: PHP 보안팀이 10월 23일 공개한 세 번째 문제(CVE-2026-115560, 10월 21일 릴리스에서 미수정)를 추가했습니다. 조건, 완화 조치(session.upload_progress.enabled=0), 예정된 수정, 관리자가 설정을 확인하는 단계를 포함했습니다. 요약, 상태 상자, FAQ, 타임라인, 출처를 갱신했습니다.
2026-10-23 (02:15 UTC): 10월 17일부터의 악용 시도에 대한 한 주요 클라우드 사업자의 보고(어떤 시도가 성공했는지는 불분명), 취약점을 겨냥한 것으로 보이는 접근에 대한 일본 호스팅 업체의 보고(피해 미확인), 확인된 침해 사고가 발표되지 않았다는 내용을 추가했습니다. 10월 17일 이후 로그를 확인하라는 조언을 추가했습니다. "수정 불완전" 보고가 무관하다는 PHP 보안팀 개발자의 답변을 추가했습니다. OS 패키지(Debian sid 수정, RHEL 9 php:8.4 미수정, RHEL 6 수정 계획 없음)와 호스팅 현황(ConoHa WING, Onamae.com, Lolipop, Heteml 완료, Xserver PHP 5.6–7.3 완료, Value Domain 그룹 서비스의 대상 버전, KAGOYA와 CPI 상태)을 갱신했습니다.
2026-10-22 (04:45 UTC): 제목을 속보 형식으로 바꾸고, IPA 경보, JPCERT/CC 경보(JPCERT-AT-2026-0033), JVNVU#99905564, CISA 경보를 추가했습니다. 악용 보고(여전히 확인된 침해 사고 없음), OS 패키지(RHEL 8 php:8.2 추가, RHEL 9 php:8.4와 Debian 개발 브랜치는 대기), Docker 공식 이미지, 공유 호스팅 완료 현황(Xserver, Sakura, mixhost, ColorfulBox, Value Domain 그룹 서비스, Heteml 등)을 갱신했습니다.
2026-10-21 (21:30 UTC): 악용 보고(시도 관찰, 확인된 침해 사고 없음), OS 벤더의 수정 패키지, Docker 공식 이미지 수정 완료, NVD 점수, 수정이 불완전하다는 미확인 주장, 호스팅 업데이트(Xserver 수정 적용 시작, WADAX 추가)를 갱신했습니다.
2026-10-21 (14:30 UTC): CDN 사업자의 공격 트래픽 관찰 보고, Ubuntu 수정 패키지(USN-8948-1), NVD 항목, Docker 공식 이미지 현황을 추가했습니다.
2026-10-21 (14:10 UTC): 릴리스 이후 현황(릴리스 시각, 영향받는 버전, 권고에서 확인된 영향, 악용에 대한 공식 입장 없음, OS 패키지, Docker 공식 이미지, remirepo)과 21:00 JST 이후의 호스팅 업데이트(CPI와 mixhost 추가, Xserver FAQ, Sakura 완료)를 추가했습니다.
2026-10-21 (릴리스 이후): PHP 보안팀의 10월 21일 발표(수정 버전, CVE ID, 결함 내용, 위험 대상, 8.1 이하 처리 방식, 임시 조치)를 반영하고 제목과 핵심 요약을 다시 작성했습니다.
2026-10-21: 최초 버전. PHP 보안팀의 10월 20일 공지, IPA의 사전 준비 공지, Xserver의 공지를 바탕으로 작성했습니다. CVE ID, 영향받는 버전, 수정 버전 번호는 릴리스 이후 추가할 예정입니다.
다음으로 읽을거리
- 사이트가 공격받았는지 확인: 웹사이트나 서버가 침해되었는지 확인하는 방법
- 호스팅 업체가 침해되었을 때: 호스팅 업체가 침해되었을 때 / ConoHa WING 무단 접근
- 공유 호스팅 설정: 공유 호스팅에서 .env 보호하기
- WordPress와 Laravel: WordPress 보안 / Laravel 보안
- 사전 준비: 백업과 복구의 기본 / 보안 자산 목록 점검표
- 같은 주의 또 다른 치명적 수정: GitLab CVE-2026-110264(Ruby 정규식 수정 포함)
- 용어: RCE(원격 코드 실행)란 / CVSS란