PHP 취약점 업데이트 방법과 영향 버전 확인 총정리

사진: Florian Olivo / Unsplash

PHP 취약점 2건(CVE-2026-109618, CVE-2026-109619)이 10월 21일 공개됐고, 로그인 없이 원격에서 코드를 실행할 수 있는 등급이라 한국인터넷진흥원(KISA)도 같은 날 보안 업데이트를 권고했습니다. 해결 버전은 8.2.35, 8.3.36, 8.4.27, 8.5.12이며, 이보다 낮은 버전으로 웹사이트를 돌리고 있다면 대상입니다. 워드프레스, 그누보드, 라라벨처럼 PHP 위에서 도는 사이트를 운영 중이라면 오늘 안에 서버의 PHP 버전부터 확인하세요. 이 글은 10월 22일 저녁 기준 PHP 공식 공지와 KISA 공지를 바탕으로 정리했습니다.

PHP 취약점, 이번에는 무엇이 문제인가요

핵심은 메모리를 다루는 과정에서 생긴 결함 두 개가 합쳐지면 서버 장악까지 갈 수 있다는 점입니다. PHP 개발팀은 두 건 모두 CVSS v4.0 기준 9.2점으로 분류했고, 인증 없이 원격 코드 실행(RCE)이 가능할 수 있다고 밝혔습니다.

사진: Taylor Vick / Unsplash

CVE-2026-109618: 메모리가 부족한 상황(OOM)에서 처리가 중간에 끊기면 요청 데이터가 반쯤만 초기화된 채 남습니다. 뒤이은 정리 단계가 이 데이터를 정상 값으로 믿고 쓰면서 문제가 시작됩니다.
CVE-2026-109619: 이미 해제한 메모리를 가리키는 내부 상태가 지워지지 않고 남는 해제 후 사용(Use After Free) 결함입니다. 같은 워커가 다음 요청을 받을 때 이 낡은 상태를 초기화 전에 건드릴 수 있죠.

무서운 대목은 공격 시점입니다. 공식 공지에 따르면 Apache에 PHP를 모듈로 붙인 mod_php 환경에서는 애플리케이션 코드가 실행되기도 전에 인증 없는 요청 하나로 공격이 동작하는 시연 익스플로잇이 이미 있습니다. 플러그인을 잘 관리하고 관리자 비밀번호를 길게 걸어 둬도 PHP 엔진 자체가 낡았다면 막아 주지 못한다는 뜻입니다.

해외 반응도 빨랐습니다. 한국경제와 아시아경제 보도에 따르면 네덜란드와 핀란드 일부 정부기관은 예방 차원에서 웹사이트를 잠시 내렸습니다. 실제 공격(in the wild) 피해가 확인됐다는 내용은 공식 공지에 아직 없습니다.

내 PHP 버전이 영향 대상인지 어떻게 아나요

아래 표에서 내 버전이 왼쪽 범위에 들어가면 업데이트 대상입니다. PHP 8.1 이하는 표에 없는데, 안전해서가 아니라 공식 보안 지원이 끝나 패치 버전 자체가 나오지 않기 때문입니다.

사용 중인 계열	영향받는 버전	해결 버전	비고
PHP 8.5	8.5.12 미만	8.5.12 이상	최신 계열
PHP 8.4	8.4.27 미만	8.4.27 이상	–
PHP 8.3	8.3.36 미만	8.3.36 이상	–
PHP 8.2	8.2.35 미만	8.2.35 이상	2026년 12월 31일 지원 종료
PHP 8.1 이하	전부 위험권	공식 패치 없음	지원 계열로 이전 필요

운영 환경별 확인 방법

워드프레스: 관리자 화면 도구 메뉴의 사이트 건강 → 정보 탭 → 서버 항목에서 PHP 버전을 볼 수 있습니다.
직접 관리하는 서버(VPS·클라우드): 웹 루트에 phpinfo() 한 줄짜리 파일을 잠깐 올려 버전과 Server API 항목을 확인하고, 확인 즉시 삭제하세요.
공유 호스팅: 호스팅 관리 패널의 PHP 버전 설정 화면이나 호스팅사 공지를 봅니다. 서버 PHP는 보통 호스팅사가 패치합니다.

여기서 흔한 실수가 하나 있습니다. 터미널에서 php -v만 치고 안심하는 경우인데, 이 명령은 CLI용 PHP 버전을 보여 줄 뿐입니다. 웹 요청을 처리하는 PHP-FPM이나 mod_php는 다른 패키지라 버전이 다를 수 있으니, 반드시 웹 쪽에서 phpinfo()나 사이트 건강 화면으로 교차 확인해야 합니다.

PHP 보안 업데이트는 어떻게 하나요

정답은 해결 버전 이상으로 올리고 PHP 프로세스를 재시작하는 것입니다. 공식 공지가 “완전한 완화책은 없고 업데이트만이 안전한 선택”이라고 못박았기 때문에, 설정 변경만으로 버티는 방법은 임시방편으로 봐야 합니다.

사진: Mohammad Rahmani / Unsplash

배포판 패키지를 쓰는 서버

Ubuntu, Debian, RHEL 계열처럼 OS 패키지로 PHP를 설치했다면 배포판 보안 업데이트를 받으면 됩니다. PHP 측은 배포판과 장기지원(LTS) 벤더에 패치를 미리 전달했다고 밝혔습니다. 다만 배포판은 버전 숫자를 그대로 올리지 않고 기존 번호에 패치만 덧붙이는 백포트 방식을 쓰는 경우가 많습니다. 그래서 숫자가 8.3.36이 아니라고 무조건 미적용은 아니니, 해당 배포판 보안 공지에서 두 CVE 번호가 반영된 패키지인지 확인하세요.

업데이트 후 꼭 할 일

PHP-FPM 사용 시 FPM 서비스 재시작, mod_php 사용 시 Apache 재시작
재시작 후 phpinfo()나 사이트 건강 화면에서 버전 재확인
FrankenPHP, LiteSpeed, php-cgi를 쓰는 경우에도 같은 원칙으로 런타임 교체
Docker 이미지라면 베이스 이미지 태그를 올려 다시 빌드하고 배포

예를 들어 PHP 8.2로 워드프레스 블로그 하나를 운영 중이라면 이번에 8.2.35로 올려도 두 달 뒤 연말에 다시 지원이 끝납니다. 테마와 플러그인 호환성을 점검할 여유가 있다면 이번 기회에 8.3 이상으로 한 번에 옮기는 편이 작업을 두 번 하지 않는 길입니다.

당장 업데이트가 어렵다면 임시로 무엇을 할 수 있나요

공식 공지가 제시한 완화책은 특정 공격 경로를 좁혀 줄 뿐 서버를 안전하게 만들지는 않습니다. 업데이트 일정이 잡히기 전까지 시간을 버는 용도로만 쓰세요.

대상 취약점	임시 조치	주의할 점
CVE-2026-109618	memory_limit = -1 을 php_admin_value 방식으로 고정	RLIMIT_AS·RLIMIT_DATA 제한은 오히려 취약한 실패를 부를 수 있어 쓰지 않음
CVE-2026-109618	post_max_size 축소(업로드 없으면 8M, 있으면 32M), upload_max_filesize는 그보다 작게	웹서버·프록시에서 요청 크기와 필드 수도 함께 제한
CVE-2026-109619	session.upload_progress.enabled = 0 후 모든 워커 재시작	ini_set()이나 .user.ini가 아니라 php.ini 또는 FPM 풀 설정에 적용
CVE-2026-109619	PHP 8.5는 fatal_error_backtraces = 0 추가	display_errors나 @로 오류를 숨기는 것은 효과 없음

memory_limit을 무제한으로 풀면 메모리 폭주 위험이 커집니다. 공지가 컨테이너나 cgroup 단위 제한을 가용성 경계로 함께 두라고 권하는 이유가 여기에 있습니다. 소스로 직접 빌드하는 7.4, 8.0, 8.1 사용자를 위해 PHP 보안팀이 최소 백포트 브랜치를 GitHub에 올려 두긴 했지만, 공식 지원 버전이 아니니 이전 계획과 함께 써야 합니다.

자주 묻는 질문

워드프레스 코어나 플러그인 업데이트로 해결되나요

해결되지 않습니다. 이번 문제는 워드프레스가 아니라 그 아래에서 도는 PHP 엔진에 있습니다. 워드프레스 버전이 최신이어도 서버 PHP가 해결 버전 미만이면 그대로 노출됩니다.

PHP를 명령줄 스크립트에서만 쓰면 괜찮은가요

공식 공지가 영향 범위로 꼽은 것은 웹 요청을 처리하는 설치 형태(PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed)입니다. 외부 요청을 받지 않는 CLI 전용 환경은 노출 경로가 다르지만, 같은 서버의 웹용 PHP가 함께 설치돼 있지 않은지 반드시 확인하세요.