지난 10월 21일, 전 세계 웹사이트의 4분의 3을 움직이는 프로그래밍 언어 PHP에서 역대급 보안 취약점이 공개됐습니다. 네덜란드, 프랑스, 캐나다 등에서는 정부 웹사이트가 예방 차원에서 일시 중단됐고, 한국인터넷진흥원(KISA)도 긴급 대응 수칙을 배포했습니다. 보안 업계는 이 사태를 PHP2Shell이라고 부릅니다.
다행히 패치는 이미 나왔고, 이름 있는 호스팅 업체들은 대부분 조치를 마쳤습니다. 문제는 “우리 사이트는 누가 패치해 주는가”가 호스팅 방식마다 완전히 다르다는 것입니다. 이 글에서는 누가 당장 반응해야 하는지, 어떤 패치를 적용할 수 있는지, 그리고 주요 호스팅 업체들이 어떻게 해결했는지를 정리했습니다.
PHP2Shell이란?
PHP2Shell은 PHP 코어에서 발견된 원격코드실행(RCE) 취약점 2개를 묶어 부르는 이름입니다.
- CVE-2026-109618: 메모리 부족 상황을 악용한 메모리 손상 취약점
- CVE-2026-109619: 해제된 전역 상태를 재사용하는 취약점
두 취약점 모두 심각도 CVSS 9.2점(10점 만점)이며, 가장 무서운 점은 로그인 없이, 계정 없이 공격할 수 있다는 것입니다. 취약점이 워드프레스나 플러그인이 아니라 PHP 자체의 요청 처리 단계에 있어서, 사이트 코드가 실행되기도 전에 공격이 성립합니다. 워드프레스를 아무리 최신으로 유지해도 PHP가 패치되지 않으면 소용이 없습니다.
영향 범위는 PHP 5.4 이후 사실상 전 버전으로 추정되며, W3Techs 기준 서버 언어를 확인할 수 있는 웹사이트의 약 75%가 PHP를 사용합니다. 이번 취약점은 보안업체 Calif와 Wiz가 AI 모델(OpenAI GPT-5.6 Sol, Google Gemini 4 Argon)을 활용한 분석 과정에서 발견해 8월에 PHP 팀에 보고한 것으로, 패치 준비 도중 상세 정보가 유출되면서 공개 일정이 하루 앞당겨지는 소동이 있었습니다. 공개 당일부터 실제 공격 시도가 관측됐고, Cloudflare는 수백만 건의 공격 시도를 보고했습니다. 아직 성공한 대규모 침해는 확인되지 않았지만, 공격 도구가 계속 정교해지고 있어 “아직 안 당했으니 괜찮다”고 볼 단계는 아닙니다.
여기에 10월 23일, 같은 계열의 세 번째 취약점 CVE-2026-115560이 추가로 공개됐습니다. 이쪽은 특정 설정 조합에서만 성립해 PHP 팀이 긴급 패치 대신 임시 조치를 권고하고 있는데, 자세한 내용은 아래 패치 섹션에서 다룹니다.
누가 반응해야 하나?
핵심 질문은 하나입니다. “내 사이트의 PHP는 누가 관리하는가?” 그 답에 따라 할 일이 완전히 달라집니다.
| 상황 | 누가 패치하나 | 할 일 |
|---|---|---|
| VPS·전용 서버를 직접 운영 | 본인 (최우선) | 아무도 대신 해주지 않습니다. 지금 바로 PHP 업데이트 + PHP 서비스 재시작. 이 글의 패치 섹션을 그대로 따라 하세요. |
| 공유·관리형 호스팅 사용 (Hostinger, SiteGround 등) | 호스팅 업체 | 업체 공지를 확인하고, 내 사이트에 패치가 실제로 적용됐는지 버전·빌드 날짜로 검증. “알아서 했겠지”가 아니라 확인이 필요합니다. |
| PHP 8.1 이하를 쓰는 사이트 | 본인 + 호스팅 업체 확인 | 공식 패치가 아예 나오지 않는 버전입니다. 호스팅 업체가 자체 백포트 빌드를 제공했는지 확인하고, 아니면 PHP 8.3 이상으로 업그레이드 계획을 즉시 세워야 합니다. |
| 에이전시·프리랜서·유지보수 업체 | 본인 | 관리 중인 고객 사이트 전수 점검. 특히 오래전에 만들고 방치된 사이트, 테스트·스테이징 서버, 이벤트용 미니 사이트가 사각지대입니다. |
| 도커·자체 구축 서버 운영 | 본인 | 컨테이너 이미지를 패치된 베이스 이미지로 다시 빌드해 재배포. 호스트 OS만 업데이트해서는 안 됩니다. |
| PHP를 쓰지 않는 정적 사이트, 일반 방문자 | — | 해당 없습니다. 이 취약점은 서버 문제라 방문자 기기에서 할 일은 없습니다. |
어떤 패치가 나왔나?
공식 패치 (2026년 10월 21일)
| 사용 중인 PHP | 패치 버전 |
|---|---|
| PHP 8.5.x | 8.5.12 이상 |
| PHP 8.4.x | 8.4.27 이상 |
| PHP 8.3.x | 8.3.36 이상 |
| PHP 8.2.x | 8.2.35 이상 (단, 8.2는 2026년 12월 31일 지원 종료 — 8.3 이상으로 이전 권장) |
| PHP 8.1 이하 | 공식 릴리스 없음 (아래 백포트 참고) |
서버를 직접 운영한다면 배포판 패키지로 업데이트하는 것이 일반적입니다. Ubuntu, Debian, AlmaLinux, Amazon Linux 등은 패치된 패키지를 이미 배포했습니다.
# Debian / Ubuntu 예시
sudo apt update
sudo apt upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm재시작을 빼먹으면 패치가 적용되지 않습니다. 패키지만 올리고 PHP-FPM이나 Apache를 재시작하지 않으면, 메모리에 떠 있는 구버전 PHP가 계속 요청을 처리합니다. KISA 대응 수칙에서도 이 부분을 명시적으로 경고하고 있습니다. CentOS 계열에서 Remi 저장소를 쓰는 경우, 공개 당일 Remi에는 업데이트가 없었으니 배포판 기본 패키지나 직접 빌드를 검토해야 합니다.
PHP 8.1 이하라면: 백포트
PHP 8.1, 8.0, 7.4는 지원이 종료돼 공식 패치 릴리스가 없습니다. 다만 길이 없는 것은 아닙니다.
- PHP 팀이 7.4, 8.0, 8.1용 최소 소스 패치(백포트)를 공개했습니다. 직접 빌드하는 환경에서 적용할 수 있습니다.
- Ubuntu·Debian용 패키지(Ondřej Surý 저장소)는 5.6~8.1까지 백포트를 제공했습니다.
- 일부 호스팅 업체(Hostinger, 20i, xCloud 등)는 구버전을 포함한 자체 패치 빌드를 배포했습니다. 내 호스팅 업체가 백포트를 제공했는지 먼저 확인하세요.
다만 백포트는 임시 방편입니다. 이번 기회에 PHP 8.3 이상으로 올리는 것이 정답에 가깝습니다.
세 번째 취약점 CVE-2026-115560: 패치 전 임시 조치
10월 23일 공개된 세 번째 취약점은 PHP의 세션 업로드 진행률(session upload progress) 기능과 관련이 있습니다. 일반적인 설정에서는 성립하기 어려워 긴급 패치는 나오지 않고, 다음 정기 릴리스에 수정이 포함될 예정입니다. 그때까지의 공식 임시 조치는 하나입니다.
; php.ini 또는 PHP-FPM 풀 설정에 추가 후 PHP 재시작
session.upload_progress.enabled = 0업로드 진행률 표시줄을 쓰는 사이트가 아니라면 기능상 잃을 것이 거의 없습니다. 참고로 아래 호스팅 업체 조치 현황에서 보듯, 주요 업체들은 이미 이 설정을 서버 차원에서 꺼둔 상태입니다.
패치 전 임시 완화책 (완전한 해결책 아님)
- session.upload_progress 끄기: 위와 동일. CVE-2026-109619의 알려진 경로 하나를 막아줍니다.
- Cloudflare WAF 규칙: Cloudflare는 공개 직전부터 무료 플랜 포함 전 플랜에 긴급 규칙을 적용했습니다. 다만 Cloudflare 스스로 “임시 방어일 뿐 패치를 대체하지 않는다”고 밝히고 있고, 우회 시도가 이미 관측되고 있습니다.
- 호스팅 업체의 방화벽 규칙: ModSecurity 등 서버 앞단에서 공격 패턴을 차단하는 방식. 시간을 벌어줄 뿐 근본 해결은 아닙니다.
PHP 팀의 공식 입장은 명확합니다. “완전한 완화책은 없으며, 업데이트가 유일하게 안전한 선택이다.”
해결해 준 호스팅 업체들
다행히 이름 있는 호스팅 업체들은 빠르게 움직였습니다. 아래는 각 업체의 공식 발표 기준 조치 현황입니다. 공통점은 “패치 전에 방화벽·설정으로 먼저 막고, 패치가 나오자마자 전 서버에 배포했다”는 것입니다.
| 업체 | 조치 내용 | 고객이 할 일 |
|---|---|---|
| Hostinger | 공개 당일 방화벽 규칙으로 공격 차단 + session.upload_progress 비활성화. 10월 22일 06:44 UTC, VPS를 제외한 전 호스팅 서버에 패치 배포 완료. 세 번째 취약점도 동일 조치로 커버됨을 23일 확인 | 없음. 단, 관리형 호스팅은 버전 번호를 올리지 않고 빌드에 패치를 넣은 방식이라, 확실한 확인은 hPanel → PHP Info의 Build Date가 10월 21일 이후인지 보는 것 |
| SiteGround | 공식 릴리스 전에 서버 차원 완화 규칙을 전 서버에 선제 적용, 영향받는 기능을 전 지원 버전에서 비활성화 | 없음 (보호 적용 완료를 공지) |
| GoDaddy | 관리형 워드프레스·일반 웹호스팅·Windows 호스팅 모두 패치 완료(10월 22일). 일반 웹호스팅은 CloudLinux 백포트 빌드라 버전 번호가 그대로일 수 있음 | 없음. 일반 호스팅은 버전 번호 대신 Build Date가 10월 21일 이후인지로 확인. VPS는 EasyApache 4로 직접 업데이트 |
| WordPress.com / Pressable / WordPress VIP (Automattic) | PHP 팀과 사전 협력해 공개 전에 보호 적용 완료 | 없음 |
| WP Engine | CDN(Cloudflare·Fastly) 단에서 완화 조치를 먼저 걸고, 10월 22일 01:19 UTC 패치 배포 완료 | 없음 |
| Kinsta | Cloudflare 규칙으로 공격을 막으면서 버전별 검증 후, 10월 22일 23:25 UTC 전 PHP 버전 롤아웃 | 없음 |
| Cloudways, Pantheon, Flywheel, OVHcloud | 패치 적용 완료(업계 트래커 기준, 10월 22일). Pantheon은 PHP 8.2~8.5 기준 | 없음. 구버전 사용 시 업체 공지 확인 |
| Bluehost | 대부분의 서버 패치 완료. 작업 중 업로드 파일 크기 제한을 임시 적용 | 없음 |
| 20i | 구버전 백포트까지 포함해 10월 22일 20:01 UTC 롤아웃 완료 | 없음 |
| xCloud | 패치 빌드(8.2.35~8.5.12) 전 서버 배포. NGINX 서버는 구버전 백포트까지 적용 | OpenLiteSpeed의 구버전 등 일부 구성은 고객 조치 필요 |
| InstaWP | 10월 21일 관리형 서버에 패치 버전 설치, 구버전 백포트 빌드까지 적용 | 없음 |
| RunCloud | 전 서버 session.upload_progress 비활성화 + PHP 8.2 이상 자동 패치 | 8.1 이하는 패치를 제공하지 않으므로 8.2 이상으로 업그레이드 |
| cPanel (EasyApache 4) / CloudLinux | 10월 21~22일 패치 빌드 배포 | cPanel 서버 운영자는 WHM에서 업데이트 적용 |
| Cloudflare | 무료 포함 전 플랜에 긴급 WAF 규칙 적용 | 패치 대체재가 아님. 원본 서버 패치는 별도 |
업체별 최신 상태는 계속 바뀌므로, 내 호스팅 업체가 목록에 없거나 상태가 궁금하다면 업체의 상태 페이지와 공지를 직접 확인하는 것이 가장 정확합니다. 반대로 말하면, 아무 공지도 없이 조용히 있는 호스팅 업체를 쓰고 있다면 그 자체가 위험 신호입니다.
내 사이트 확인법 (3분)
- PHP 버전 확인: 워드프레스 관리자 → 도구 → 사이트 상태 → 정보 → 서버 항목에서 PHP 버전을 봅니다.
- 패치 버전과 비교: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 이상이면 패치된 것입니다.
- 숫자가 낮다고 단정하지 말 것: Hostinger처럼 버전 번호는 그대로 두고 빌드에 패치를 넣은 업체가 있습니다. 이 경우 호스팅 패널의 PHP Info에서 Build Date가 2026년 10월 21일 이후인지가 판정 기준입니다.
- 8.1 이하라면: 업체가 백포트를 제공했는지 공지·문의로 확인하고, 아니면 업그레이드 일정을 잡으세요.
- VPS·전용 서버라면: 터미널에서
php -v로 확인하고, 웹 서버가 실제로 쓰는 PHP(phpinfo 기준)와 같은지도 함께 보세요. 서버에 여러 버전이 공존하는 경우가 흔합니다.
패치가 끝이 아니다: 사후 점검
패치는 “앞으로의 공격”을 막을 뿐, 패치 전에 이미 침해가 있었다면 해결해주지 않습니다. 취약점 정보가 패치보다 먼저 유출됐고 공개 전부터 공격 시도가 있었기 때문에, KISA는 다음을 권고하고 있습니다.
- 로그 점검: 패치 이전 기간까지 포함해 웹 서버·PHP 로그에서 의심스러운 요청 흔적을 확인
- 웹셸 점검: 최근에 생성·수정된 PHP 파일, 모르는 관리자 계정, 낯선 크론 작업이 없는지 확인
- 인증 정보 교체: 노출됐던 서버는 DB 비밀번호, API 키, 관리자 비밀번호 교체 권장
- 백업 확보: 패치 적용 전후로 복원이 검증된 백업을 오프사이트에 보관
- 침해 흔적이 보이면 서버를 재시작하지 말고(메모리 증거가 사라집니다) 네트워크만 차단한 뒤 전문가에게 신고·의뢰
최종 체크리스트
- 내 사이트의 PHP 버전과 “누가 PHP를 관리하는지” 확인하기
- 패치 버전(8.5.12 / 8.4.27 / 8.3.36 / 8.2.35) 이상인지, 또는 빌드 날짜가 10월 21일 이후인지 검증하기
- VPS·전용 서버는 직접 업데이트하고 PHP 서비스를 반드시 재시작하기
- PHP 8.1 이하는 백포트 제공 여부를 확인하고 8.3 이상 업그레이드 계획 세우기
- 세 번째 취약점 대비 session.upload_progress 비활성화(호스팅 업체가 했는지 확인)
- 패치 전 기간 로그와 웹셸 흔적 점검하기
- 방치된 테스트·스테이징·이벤트 사이트까지 인벤토리에 포함하기
We Design Orange가 도와드립니다
여러 사이트를 운영하거나, 내 호스팅이 패치를 했는지 확신이 없다면 We Design Orange에 문의하세요. 사이트별 PHP 버전·빌드 확인부터 VPS 패치 적용, 침해 흔적 점검, PHP 버전 업그레이드 후 사이트 동작 검증까지 도와드립니다. Wix 같은 비PHP 플랫폼은 해당 사항이 없으니 안심하셔도 됩니다.
이 글은 2026년 10월 23일 기준 공개 정보를 정리한 기술 정보이며, 보안 진단이나 법률 자문이 아닙니다. 업체별 조치 현황은 각 사 공식 발표를 기준으로 했고 이후 달라질 수 있습니다. 침해가 의심되는 경우 보안 전문 업체나 KISA 보호나라에 상담하세요.