EN View in English

PHP2Shell, 어떤 PHP 버전이 고쳐졌고 언제까지 지원될까요

수정 7분 분량

핵심 요약

  • PHP2Shell(CVE-2026-109618, CVE-2026-109619)은 2026년 10월 21일(UTC, 한국 시간으로도 21일) PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35에서 고쳐졌고, PHP 8.1 이하는 PHP 프로젝트의 공식 업데이트가 없어요.
  • W3Techs 10월 23일 집계로는 PHP를 쓰는 웹사이트의 약 48.3%가 공식 수정이 없는 버전이고, 18.0%는 고쳐졌지만 올해 12월 31일에 보안 지원이 끝나는 8.2예요.
  • 사이트를 운영한다면 8.2~8.5는 8.2.35, 8.3.36, 8.4.27, 8.5.12 이상으로, 8.1 이하는 지원되는 버전으로 옮긴 다음 PHP 재시작, 10월 17일 이후 기록 점검, 서버 비밀번호와 키 교체까지 하세요.
  • 사이트를 쓰기만 한다면 휴대폰이나 PC에서 할 일은 없고, 집에 NAS가 있다면 제조사 보안 공지를 확인하세요.

PHP2Shell로 불리는 PHP 취약점 두 개는 2026년 10월 21일(UTC 오후, 한국 시간 21일 밤) PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35에서 고쳐졌고, PHP 8.1과 그 이전 버전에는 PHP 프로젝트의 공식 업데이트가 나오지 않았어요. 고쳐진 버전의 보안 지원은 8.2가 2026년, 8.3이 2027년, 8.4가 2028년, 8.5가 2029년 12월 31일까지예요. W3Techs의 10월 23일 집계로 계산해 보니 PHP를 쓰는 웹사이트의 약 48%가 공식 수정이 없는 버전을 쓰고 있었어요.

두 취약점과 지금까지의 공격

php.net 공지에 따르면 두 취약점(CVE-2026-109618, CVE-2026-109619)은 인증 없이 원격에서 코드를 실행할 수 있게 해요. php.net은 사전 공지에서 둘 다 심각도를 10점 만점에 9.2점(CVSS v4.0)으로 매겼어요. php.net의 릴리스 공지는 "완전한 완화책은 없고 업데이트만이 안전한 선택"이라고 적었어요. PHP2Shell은 보안 업계와 기관이 쓰는 이름이에요. php.net 공지에는 이 이름이 없으니 CVE 번호로 찾아야 해요.

공격이 어디까지 왔는지는 발표마다 달라요. 보안 업체 watchTowr는 10월 21일(UTC) 글에서 공격을 끌어들이려고 운영하는 미끼 서버(허니팟)에서 두 취약점이 모두 악용되는 걸 관찰했다고 밝혔어요. 미국 CISA는 10월 21일(미국 시간) 경보를 낼 때까지 실제 환경에서 악용에 성공한 사례는 관찰하지 못했다고 했어요. 아마존은 10월 21일(미국 시간, 한국 시간 22일) 블로그에서 공개 나흘 전인 10월 17일에 이미 자사 미끼 서버(MadPot)를 노린 악용 시도를 봤고, 공개 뒤에는 실제 환경에서 악용 시도가 널리 보인다고 밝혔어요.

PHP 버전별 수정 여부와 지원 종료일

아래 그림에는 버전별 수정 여부와 보안 지원 종료일을 한 시간축에 놓았어요. 막대는 각 버전의 출시일(7.3 이하는 그림 왼쪽 끝)부터 10월 21일 수정 발표일인 점선까지 이어져요. 보안 지원을 받던 기간은 보라색, 지원이 끝난 뒤는 빨간색으로 칠했어요. 8.1 이하는 이미 지원이 끝나 있었어요. 짧은 세로 막대는 보안 지원 종료일이고, 점선 뒤 회색 구간은 남은 지원 기간이에요.

PHP 7.3 이하부터 8.5까지 버전별 수정 여부와 보안 지원 종료일을 한 시간축에 그린 막대 그림 (원본 이미지 열기)
출처: php.net(지원 버전, 지원 종료일, 보안 공지).

8.1, 8.0, 7.4의 "소스 패치"는 설치해서 쓰는 정식 버전이 아니에요. 취약점이 심각해서, PHP를 직접 빌드하거나 장기 지원 업체를 쓸 수 없는 사람을 위해 PHP 보안팀이 따로 낸 최소한의 수정 코드예요. 호스팅 업체나 리눅스 배포판 패키지로 PHP를 쓴다면 이 코드를 직접 적용할 일은 없고, 업체나 배포판의 업데이트를 확인하면 돼요.

아직 공식 수정이 없는 버전을 쓰는 사이트는 얼마나 될까요

W3Techs는 웹사이트가 쓰는 서버 언어와 버전을 매일 집계해요. 10월 23일 기준으로 서버 언어가 알려진 웹사이트의 69.3%가 PHP를 썼어요. 그 PHP 사이트를 100곳으로 놓고 PHP2Shell 수정 여부로 나누면 이래요.

PHP 사이트 100곳을 한 칸씩 그려 PHP2Shell 수정 여부로 묶고 PHP 버전별 비율을 적은 그림 (원본 이미지 열기)
출처: W3Techs, 2026년 10월 23일(PHP 버전, PHP 8 세부 버전). 정확한 값은 48.3%, 18.0%, 33.6%예요(버전별 값은 따로 반올림했어요). W3Techs는 PHP 8 세부 버전을 PHP 8 사이트 기준으로 보여 줘서, PHP 8 비율 65.3%를 곱해 PHP 사이트 전체 기준으로 바꿨어요(예: 8.1은 15.1% × 65.3% ≈ 9.9%). 버전을 숨긴 사이트는 세지 않아요.

PHP 사이트 두 곳 중 한 곳 가까이가 공식 수정이 없는 버전을 쓰고, 다섯 곳 중 한 곳 가까이는 두 달 뒤 지원이 끝나는 8.2를 써요. 그러니 내 사이트 PHP 버전부터 확인해 보세요.

다만 버전 번호만 보고 취약하다고 단정할 수는 없어요. 리눅스 배포판이나 장비 제조사는 버전 번호를 그대로 둔 채 수정을 넣기도 해요. 시놀로지는 10월 22일(UTC+8, 한국 시간으로도 22일) 보안 공지에서 PHP 7.4, 8.0, 8.1 패키지에도 수정본을 냈어요. 그래서 버전이 8.1 이하로 나오더라도 단정하기 전에 패키지 변경 이력을 확인하세요(아래 3단계).

사이트를 운영하거나 호스팅을 쓰고 있다면

1. PHP 버전을 확인하세요.

  • 워드프레스: 관리자 화면의 도구 → 사이트 건강 → 정보 → 서버에 PHP 버전이 나와요.
  • 호스팅 관리 화면: cPanel을 쓰는 호스팅이라면 MultiPHP Manager에서 도메인별 PHP 버전을 볼 수 있어요. 화면에서 찾기 어렵다면 호스팅 업체에 물어보세요.
  • 서버에 직접 접속할 수 있다면 php -v를 실행하세요. 다만 명령줄 PHP와 웹사이트가 쓰는 PHP가 다를 수 있으니, 웹 서버 설정에 연결된 버전(PHP-FPM 등)도 함께 확인하세요.

2. 호스팅 업체나 장비 업체가 PHP를 관리한다면 패치 적용과 4단계의 설정, 재시작은 업체 몫이에요. 이렇게 물으면 돼요. "제 사이트가 쓰는 PHP 버전과, 10월 21일 PHP2Shell(CVE-2026-109618, CVE-2026-109619) 보안 업데이트가 적용됐는지 알려 주세요." 8.1 이하라면 더 높은 버전으로 바꿀 수 있는지도 함께 물어보세요. 사이트 관리자 비밀번호처럼 내가 관리하는 비밀번호는 6단계대로 직접 바꾸세요.

3. 버전에 맞춰 조치하세요.

내 버전할 일
8.3, 8.4, 8.58.3.36, 8.4.27, 8.5.12 이상으로 업데이트
8.28.2.35 이상으로 업데이트하고, 12월 31일 지원 종료 전에 8.3 이상으로 옮길 일정 잡기
8.1 이하지원되는 버전(8.2 이상, 가능하면 8.3 이상)으로 이전. 그 전까지는 배포판·장기 지원 업체의 패치 적용

배포판 패키지라면 변경 이력에 두 CVE가 있는지 보세요. 예를 들어 데비안·우분투에서는 apt changelog <패키지 이름> | grep -E 'CVE-2026-10961[89]'처럼 찾을 수 있어요.

8.1 이하를 바로 옮길 수 없고 적용할 패치도 없다면, KISA는 대응 수칙에서 요청 크기를 앞단(웹 방화벽·웹 서버·프록시 등 PHP 앞에 놓인 장비)에서 제한하는 것 같은 임시 조치를, 그것도 어려우면 외부 접속 차단이나 서비스 일시 중단을 검토하라고 해요.

4. 다음 정기 릴리스 전까지 업로드 진행률 기능을 끄세요. php.net은 10월 23일(UTC)에 흔치 않은 설정에서만 쓰일 수 있는 다른 공격 경로(CVE-2026-115560)까지 막으려면 이 기능을 꺼 두라고 권했어요. 아래 설정은 10월 21일 공지대로 php.ini나 FPM 풀처럼 요청을 읽기 전에 적용되는 곳에 넣고, ini_set()이나 .user.ini에는 기대지 마세요.

session.upload_progress.enabled = 0

5. PHP를 쓰는 서비스를 모두 다시 시작하세요. KISA는 대응 수칙에서 재시작하지 않으면 메모리에 남은 이전 버전이 계속 돈다고 설명해요. 컨테이너라면 새 이미지로 다시 배포하세요. 이미 침입 흔적이 보인다면 다시 시작하기 전에 6단계대로 기록과 실행 중인 프로그램 목록부터 보존하세요.

6. 10월 17일 이후 기록을 점검하고, 서버의 비밀번호와 키를 바꾸세요. KISA는 취약점 정보가 유출된 날로 꼽은 10월 20일 이후 기록은 최소한 모두 보고, 가능하면 그 전 기록도 확인하라고 해요. 아마존은 10월 17일에 이미 악용 시도를 봤다며 공개일부터 악용이 시작됐다고 보지 말라고 했으니, 기록이 남아 있다면 10월 17일부터 보세요. 점검 항목은 이래요.

  • 비정상적으로 큰 PHP 요청 뒤에 이어진 서버 오류(HTTP 500)
  • 원인 모를 PHP 재시작, 비정상 종료, 메모리 부족 오류
  • 웹 서버가 셸이나 다운로드 도구를 실행한 흔적
  • 웹·업로드·임시 폴더에 새로 생기거나 바뀐 PHP 파일
  • 페이지에 몰래 추가된 외부 스크립트
  • 서버에서 알 수 없는 외부 주소로 나간 연결

이 취약점은 서버 메모리에 있던 비밀번호나 API 키를 빼낼 수도 있어요. 그래서 KISA는 기록에 이상이 없어도, 업데이트 전까지 인터넷에 노출됐던 서버라면 DB 비밀번호, 외부 서비스 연동 키, 관리자 비밀번호를 바꾸라고 해요. 침입 흔적이 보이면 그때부터는 서버를 끄거나 다시 시작하지 마세요. 외부 접속만 막고 보호나라에 신고한 뒤, 기록과 실행 중인 프로그램 목록을 보존하세요.

인터넷에 도는 공격 코드(PoC)로 직접 시험하지는 마세요. KISA는 떠도는 PoC 중에 악성코드를 숨긴 가짜가 많다고 경고했어요. 취약 여부는 버전 확인과 로그 점검으로 판단하라고 해요.

사이트를 쓰기만 한다면

PHP는 웹사이트 서버에서 돌아가요. 그래서 휴대폰이나 PC에서 따로 업데이트할 것은 없어요.

내가 가입한 서비스가 이 취약점으로 피해를 봤는지는 밖에서 알 수 없고 그 회사의 유출 통지로 알게 돼요. 나중에 유출 통지를 받으면 유출 점검에서 그 회사를 찾아보세요. 목록에 있는 사고라면 무엇이 나갔고 무엇부터 하면 되는지 볼 수 있어요.

집에 NAS가 있다면

제조사 보안 공지를 확인하고 NAS의 PHP 패키지나 펌웨어를 업데이트하세요. 시놀로지, ASUSTOR, QNAP별로 할 일은 NAS 대응 글에 따로 정리했어요. NAS로 웹사이트를 운영하고 있다면 위의 "사이트를 운영하거나 호스팅을 쓰고 있다면"도 함께 보세요.

출처

날짜는 각 기관이 공지에 적은 날이에요. php.net과 watchTowr는 UTC, KISA는 한국 시간, 시놀로지는 UTC+8 기준이에요. CISA는 미국 시간 기준으로 경보 주소에 적힌 게시일이고(23일 개정), W3Techs는 집계 페이지에 적힌 날짜예요. 아마존은 블로그에 적힌 게시일(미국 태평양 시간)이에요. php.net의 수정 릴리스는 UTC 21일 13~14시께(한국 시간 21일 밤 10~11시께) 공개됐어요(php.net 웹사이트 저장소 기록, 아마존 블로그). php.net 공지 피드에 찍힌 0시께(UTC)는 공지를 쓴 시각이에요.

공유하기

블로그로 돌아가기