PHP2Shell: 내 서버 PHP 버전 확인하고 패치하는 법

무엇이 고쳐졌나

2026년 10월 21일 PHP 개발팀이 8.5.12, 8.4.27, 8.3.36, 8.2.35를 긴급 보안 릴리스로 내놓았습니다. 고친 결함은 두 가지입니다.

• CVE-2026-109618: 요청을 처리하다 메모리가 모자라 멈출 때, 반쯤 만들어진 내부 데이터가 다음 요청에서 다시 쓰입니다.
• CVE-2026-109619: 치명적 오류가 난 뒤 남은 상태 때문에 같은 종류의 문제가 생깁니다.

둘을 엮으면 로그인 없이 서버에서 원하는 코드를 실행할 수 있습니다. 결함이 애플리케이션이 아니라 PHP 엔진 자체에 있어서, WordPress든 직접 만든 사이트든 PHP 위에서 돌면 대상입니다. Sansec 분석에 따르면 다음과 같습니다.

• 기본 설정의 Apache mod_php와 PHP-FPM이 모두 해당합니다.
• 문제의 코드는 PHP 5.4(2012년)부터 있었습니다.
• 알려진 공격 요청은 모두 파일 업로드 형식(multipart/form-data)입니다.

이번 공지가 급했던 이유는 따로 있습니다. 내용이 예정보다 이틀 먼저 새어 나갔고, 공격 도구가 공개됐습니다. Cloudflare는 패치가 나오기 전인 10월 21일 07:43(UTC)에 이미 공격 시도를 봤습니다. php.net의 표현은 짧습니다. 완전한 임시 조치는 없고, 업데이트만이 안전하다는 것입니다.

내 서버는 해당하나

쓰고 있는 버전대	고쳐진 버전	할 일
8.5	8.5.12	8.5.12 이상으로
8.4	8.4.27	8.4.27 이상으로
8.3	8.3.36	8.3.36 이상으로
8.2	8.2.35	8.2.35 이상으로 (8.2는 2026년 12월 31일 지원 종료)
8.1 이하(7.x, 5.x 포함)	없음	8.2 이상으로 옮기기

배포판 패키지를 쓰고 있다면 이 표만으로는 판단할 수 없습니다. 아래 2단계를 보세요.

확인하기

1. 웹 서버가 실제로 쓰는 PHP 보기

명령줄의 php -v는 웹 서버가 쓰는 PHP와 다를 수 있습니다. 한 서버에 여러 버전이 깔려 있는 경우가 흔하기 때문입니다. PHP-FPM이면 실행 중인 서비스의 버전을 직접 보세요.

php -v
php-fpm8.3 -v          # 배포판에 따라 php-fpm, php83-php-fpm 등
systemctl list-units --type=service | grep -i php

여러 사이트를 한 서버에서 돌린다면 사이트마다 연결된 PHP-FPM 풀을 따로 확인해야 합니다. phpinfo()로 확인할 때는 작업이 끝나는 즉시 그 파일을 지우세요. 그 페이지는 공격자에게도 같은 정보를 줍니다.

2. 배포판 패키지라면 패키지 버전과 보안 공지를 보기

Ubuntu·Debian·RHEL 계열은 버전 숫자를 올리지 않고 수정만 넣는 일이 많습니다. 8.1.2라고 나와도 이미 고쳐졌을 수 있고, 반대로 고쳐지지 않았을 수도 있습니다.

dpkg -l | grep -E '^ii +php'      # Debian·Ubuntu
rpm -qa | grep -i '^php'          # RHEL·Rocky·Alma

나온 패키지 버전을 배포판 보안 공지(Ubuntu USN, Debian DSA, Red Hat RHSA)에 적힌 수정 버전과 비교하세요. 이때 CVE-2026-109618과 CVE-2026-109619를 둘 다 확인해야 합니다.

3. 웹호스팅을 쓴다면 호스팅 업체에 묻기

공유 웹호스팅에서는 PHP를 직접 올릴 수 없는 경우가 많습니다. 관리 화면에서 PHP 버전을 고를 수 있으면 수정된 버전으로 바꾸고, 고를 수 없으면 업체에 수정 일정을 물어보세요.

4. 밖에서 보이는 것 확인하기

일부 서버는 X-Powered-By: PHP/7.4.33처럼 응답 머리글에 버전을 그대로 내보냅니다. HTTP 보안 점검은 이 머리글을 읽어, 수정 전 버전이면 ‘주의’로, 배포판 빌드이면 ‘확인 필요’로 알려 줍니다. 다만 버전을 숨긴 서버가 대부분이라, 여기서 아무것도 안 보인다고 해서 안전하다는 뜻은 아닙니다. 확인은 1~3단계로 서버 안에서 하세요.

고치기

1. 수정된 버전으로 업데이트합니다. 공식 패키지, 배포판 저장소, 직접 빌드 중 지금 쓰는 경로로 올리세요.
2. PHP를 쓰는 프로세스를 모두 다시 시작합니다. 패키지만 바꾸면 이미 떠 있는 PHP-FPM 워커와 Apache는 옛 코드를 계속 실행합니다. systemctl restart php8.3-fpm이나 systemctl restart apache2(또는 httpd)처럼, 실제로 쓰는 서비스를 재시작하세요.
3. 컨테이너는 이미지를 다시 만듭니다. 기반 이미지(php:8.3-fpm 등)를 새로 받아 빌드하고 배포하세요. 태그가 같아도 예전에 받아 둔 이미지는 그대로입니다.
4. 8.1 이하라면 버전대를 옮깁니다. 수정판이 나오지 않습니다. 옮기기 전까지는 그 서버를 인터넷에서 떼어 두는 것이 가장 확실합니다.

머리글에서 버전을 숨기는 것(php.ini의 expose_php = Off)도 해 두면 좋습니다. 다만 이것은 결함을 고치는 조치가 아니라, 다음에 비슷한 일이 생겼을 때 표적이 덜 되게 하는 조치입니다.

업데이트한 뒤

• 다시 확인합니다. 1단계 명령을 다시 실행해, 웹 서버가 실제로 새 버전을 쓰는지 보세요.
• 로그를 봅니다. 공격은 업로드 형식의 요청으로 메모리 부족 오류를 일으키는 방식입니다. 10월 20일 이후 로그에서 다음을 찾아보세요.
  • 평소와 다른 경로로 들어온 multipart/form-data POST 요청
  • Allowed memory size ... exhausted 오류가 몰려 있는 구간
• 침해가 의심되면 패치로 끝내지 않습니다. 이상한 요청 뒤에 새 파일·새 계정·예약 작업이 생겼다면, 그 서버는 이미 뚫렸다고 보고 사고 대응 절차를 따르세요. 업데이트는 새로 들어오는 것만 막습니다.

2026년 10월 22일 기준으로 이 두 결함은 미국 CISA의 ‘실제 악용 취약점(KEV)’ 목록에 아직 오르지 않았습니다. 하지만 공격 도구가 공개된 이상, 목록에 오를 때까지 기다릴 이유는 없습니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

진단