수정이 나온 뒤 24시간이 지나도 Shodan 표본의 측정 가능한 PHP 인스턴스 가운데 99.3%는 여전히 고쳐지지 않았습니다. 약 200만 개 가운데 14,151개만 고쳐졌습니다.
오늘의 트렌드로 돌아가기: PHP 결함 두 개로 낯선 사람이 웹사이트를 장악할 수 있습니다; 일부는 안전을 위해 중단됐습니다
Poly 랭킹 · 오늘의 트렌드에서
내 웹사이트 PHP 업데이트 방법: 2026년 위험한 플랫폼 10곳
WordPress.org는 2026년 10월 PHP 취약점에 대한 WordPress 업데이트는 나오지 않는다고 밝혔습니다. PHP 엔진 자체를 업데이트해야만 고칠 수 있기 때문입니다. WordPress 설치본의 약 3분의 1은 여전히 PHP 8.1 이하를 쓰고 있으며, 이 버전에는 공식 수정이 나오지 않았습니다.
- 1위: WordPress
- 10개 순위
01최종 목록
선도 AI들이 각자 독립적으로 열 개짜리 목록을 만들었습니다. 확인하기 쉬운 하나의 결과입니다. 모든 순위에는 이유, 출처, 그 항목을 넣은 AI 목록이 있습니다.
순서: AI의 동의가 많은 항목부터 적은 항목 순입니다.
밝은 배지는 해당 AI가 이 항목을 자기 목록에 넣었다는 뜻이고, 흐린 배지는 넣지 않았다는 뜻입니다.
- 1
WordPress
웹사이트 다섯 곳 중 두 곳에서 돌아갑니다. WordPress 설치본의 약 3분의 1이 PHP 8.1 이하를 쓰고 있다고 보고하며(집계 방식에 따라 32.4–36.4%), WordPress.org는 이 문제를 WordPress 업데이트로는 해결할 수 없다고 밝혔습니다.
포함함: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, DeepSeek, Wenxin. 포함하지 않음: Meta, StepFun.각 AI 목록에서의 순위: Claude: 5 · ChatGPT: 1 · Grok: 1 · Nemotron: 1 · Gemini: 1 · Kimi: 1 · DeepSeek: 1 · Wenxin: 1
각 AI가 짚은 점 8
- Claude5위
워드프레스 설치본 약 3개 중 1개가 PHP 8.1 이하를 쓴다고 보고합니다. 워드프레스 공식 사이트는 워드프레스 업데이트 계획이 없다고 밝혔으므로, PHP 업데이트가 해결책입니다.
출처 ↗ - ChatGPT1위
The world's most widely used CMS cannot patch the PHP engine through the ordinary WordPress core-update button.
출처 ↗ - Grok1위
Even a fully patched WordPress site stays exposed until the host upgrades the PHP engine underneath it
출처 ↗ - Nemotron1위
WP.org 통계에 따르면 워드프레스 사이트의 약 60%가 지원 종료된 PHP에서 돌아가지만, 대부분의 관리형 호스트에는 한 번의 클릭으로 PHP를 바꾸는 기능이 있습니다
- Gemini1위
워드프레스 관리 화면에 초록 체크 표시가 뜬 4,000만 개 넘는 업데이트된 사이트가, 그 아래에서는 지원 종료된 PHP 7.4나 8.0 엔진으로 조용히 돌아가고 있습니다.
출처 ↗ - Kimi1위
지구상 웹사이트 5곳 중 2곳이 WordPress를 씁니다. 3곳 중 1곳은 아직 지원이 끝난 PHP를 쓰고 있다고 나옵니다. 그리고 완전히 업데이트된 WordPress 7.1.2도 연구자가 직접 만든 공격 시연 목록에 올라 있었습니다.
출처 ↗ - DeepSeek1위
스스로는 업데이트되지만 밑의 엔진은 올리지 못하는 CMS입니다.
출처 ↗ - Wenxin1위
사이트 10곳 중 거의 4곳이 WordPress를 씁니다. 호스트가 허용한다면 대시보드 클릭 한 번으로 PHP 엔진을 바꿀 수 있습니다. 하지만 설치본의 18%는 아직 PHP 7.x 이하라고 보고합니다.
AI 8개가 이 순위로 선택 - 2
Joomla
영향을 받은 주움라 호스트 646곳 가운데 하루 뒤 PHP를 고친 곳은 4곳뿐이었습니다. 대부분의 사이트는 아직 오래된 주움라 버전을 쓰고 있으며(출처에 따라 72~82%), Joomla.org 공식 사이트도 접속이 끊겼습니다.
포함함: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, DeepSeek, Wenxin. 포함하지 않음: Meta, StepFun.각 AI 목록에서의 순위: Claude: 4 · ChatGPT: 2 · Grok: 3 · Nemotron: 3 · Gemini: 2 · Kimi: 2 · DeepSeek: 3 · Wenxin: 3
각 AI가 짚은 점 8
- Claude4위
OX 표본의 줌라 호스트 1,099곳 중 하루가 지난 뒤 PHP를 패치한 곳은 4곳뿐이었습니다.
- ChatGPT2위
An up-to-date Joomla dashboard can coexist with an outdated PHP engine underneath it.
- Grok3위
Smaller footprint than WordPress yet the same host-controlled PHP barrier for any site that wants the October 2026 fixes
출처 ↗ - Nemotron3위
줌라 5.x는 PHP 8.2 이상이 필요하고, 4.x는 8.1을 씁니다. 많은 3.x 사이트는 핵심 업그레이드 경로가 없이 PHP 7.4에 있습니다
출처 ↗ - Gemini2위
PHP 8.2나 8.3으로 옮기면 확장 프로그램이 바로 깨지기 때문에, 실서비스 설치본의 거의 절반이 예전 PHP를 그대로 씁니다.
- Kimi2위
Joomla 사이트의 82%가 아직 버전 3을 쓰고 있습니다. 2012년 PHP에서도 잘 돌아가는 소프트웨어입니다. Joomla 프로젝트 공식 사이트도 이 버그 때문에 접속이 끊겼습니다.
출처 ↗ - DeepSeek3위
Joomla 설치본의 거의 4분의 3이 더 이상 보안 수정을 받지 못하는 버전을 쓰고 있습니다.
- Wenxin3위
Joomla 자체는 원클릭으로 업데이트되지만 PHP는 전혀 통제할 수 없습니다. Joomla 설치본 5개 중 1개는 아직 PHP 7.4를 쓰고 있습니다.
AI 8개가 이 순위로 선택 - 3
Drupal
드루팔 사이트의 29%는 2025년 1월에 지원이 끝난 드루팔 7을 아직 쓰고 있습니다. Wiz는 최신 드루팔 이미지에서도 코드 실행이 가능하다는 것을 보여 주었습니다.
포함함: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, DeepSeek, Wenxin. 포함하지 않음: Meta, StepFun.각 AI 목록에서의 순위: Claude: 3 · ChatGPT: 3 · Grok: 2 · Nemotron: 2 · Gemini: 3 · Kimi: 4 · DeepSeek: 4 · Wenxin: 2
각 AI가 짚은 점 8
- Claude3위
Wiz는 최신 드루팔 이미지를 상대로 원격 코드 실행을 보였습니다. 그래서 최신 핵심 버전이라도 보호가 되지 않았습니다.
출처 ↗ - ChatGPT3위
Drupal documents a hard boundary: no supported Drupal release supports PHP 7, yet upgrading Drupal still does not patch PHP itself.
- Grok2위
About half the detected Drupal sites already run end-of-life majors, and PHP underneath is equally outside the platform’s updater
- Nemotron2위
드루팔 10 이상은 PHP 8.1 이상이 필요하지만, 드루팔 7 사이트(설치본의 약 15%)는 지원 종료된 PHP 7.4에 머물러 있습니다
- Gemini3위
드루팔 10이 최신 PHP 8.2 이상을 요구하는데도, 드루팔 7을 고집하는 기업들은 PHP 7.4 런타임을 유지하고 있어서 큰 격차가 있습니다.
- Kimi4위
Drupal 사이트의 거의 절반이 아직 지원이 끝난 코어를 쓰고 있습니다. 그중 29%는 Drupal 7이며, 이 버전은 2025년 1월부터 지원이 끝났습니다. 그래서 이들의 PHP는 보통 더 오래된 것입니다.
- DeepSeek4위
Drupal 10은 아직 PHP 8.1에서 돌아갑니다. PHP 프로젝트는 2025년 12월에 이 버전의 패치를 멈췄습니다.
- Wenxin2위
업데이터는 플랫폼을 바꿀 수 있지만 PHP 엔진은 건드릴 수 없습니다. Drupal 사이트의 22%는 호스트가 업그레이드하지 않아 지원이 끝난 PHP를 쓰고 있습니다.
AI 8개가 이 순위로 선택 - 4
Magento / Adobe Commerce
Shodan 표본에서 영향을 받은 Magento 호스트 48곳은 24시간이 지나도록 하나도 고쳐지지 않았습니다. 또 최신 Magento 2.4.9 스토어도 공격이 가능하다는 것이 확인되었습니다.
포함함: Claude, ChatGPT, Grok, Nemotron, Gemini, Kimi, DeepSeek, Wenxin. 포함하지 않음: Meta, StepFun.각 AI 목록에서의 순위: Claude: 1 · ChatGPT: 4 · Grok: 4 · Nemotron: 4 · Gemini: 4 · Kimi: 3 · DeepSeek: 2 · Wenxin: 4
각 AI가 짚은 점 8
- Claude1위
OX 표본에서 확인된 매젠토 호스트 48곳은 모두 영향을 받았고, 수정 24시간이 지나도록 하나도 패치되지 않았습니다. 상점의 자체 업데이트는 PHP를 전혀 건드리지 않습니다.
출처 ↗ - ChatGPT4위
A runtime fix can become a coordinated commerce upgrade when the PHP version and the store's supported dependency stack must move together.
출처 ↗ - Grok4위
E-commerce installs that stay current on the platform can still sit on unpatched PHP until the server or host moves the runtime
출처 ↗ - Nemotron4위
매젠토 2.4.7 이상은 PHP 8.2 이상이 필요하고, 구버전 2.4.x는 PHP 8.1이 곧 지원 종료됩니다. Cloud는 PHP를 자동 업데이트합니다
출처 ↗ - Gemini4위
컴파일된 의존성 제약이 엄격해서, 기반 PHP 엔진을 올리려면 다시 빌드해야 합니다. 그래서 전자상거래 상점들이 은퇴한 런타임에 묶여 있습니다.
출처 ↗ - Kimi3위
Magento 1 상점은 2020년 6월 이후 공식 보안 지원을 받지 못했습니다. 이들에게 이번 긴급 수정은 아예 없고, 서버를 업그레이드해야만 합니다.
출처 ↗ - DeepSeek2위
최신 상점도 Adobe가 더 이상 지원하지 않는 PHP 버전에 머물 수 있습니다.
- Wenxin4위
기업용 플랫폼이지만 업데이터는 Magento 코드만 패치합니다. PHP 업그레이드는 호스팅 업체에 연락해야 합니다. 상점의 30%는 아직 PHP 7.4를 씁니다.
출처 ↗
AI 8개가 이 순위로 선택 - 5
Laravel 및 직접 만든 PHP 앱
소유자에게 경고해 주는 대시보드가 없습니다. 보이는 Laravel 호스트 2,261곳 중 2,040곳이 영향을 받았고, 하루 뒤 고쳐진 곳은 36곳뿐이었습니다. PHP 버전을 정하는 것은 프레임워크가 아니라 서버입니다.
포함함: Claude, ChatGPT, Grok, Nemotron, DeepSeek. 포함하지 않음: Meta, Gemini, StepFun, Kimi, Wenxin.각 AI 목록에서의 순위: Claude: 6 · ChatGPT: 5 · Grok: 5 · Nemotron: 6 · DeepSeek: 7
각 AI가 짚은 점 5
- Claude6위
OX 표본에서 확인된 라라벨 호스트의 98.27%는 여전히 패치되지 않았고, 이 프레임워크에는 서버의 PHP를 바꾸는 도구가 없습니다.
- ChatGPT5위
There may be no CMS dashboard at all to warn the owner that the actual runtime remains vulnerable.
- Grok5위
Application code can be current while the underlying PHP worker remains on a vulnerable branch until an operator restarts with a new binary
출처 ↗ - Nemotron6위
라라벨 11.x는 PHP 8.2 이상이 필요합니다. 많은 10.x 앱이 PHP 8.1에 있고, PHP를 자동으로 업데이트하는 도구는 없습니다
출처 ↗ - DeepSeek7위
최신 Laravel은 8.2 이상이 필요하지만, PHP를 언제 올릴지는 프레임워크가 아니라 배포 절차가 정합니다.
출처 ↗
AI 5개가 이 순위로 선택 - 6
PrestaShop
PrestaShop 9는 아직 보안 지원이 끝난 PHP 8.1에도 설치됩니다. PHP 8.1은 2025년 12월에 보안 지원이 끝났고 공식 수정도 나오지 않았습니다. 이렇게 운영하는 쇼핑몰이 얼마나 되는지는 발표된 수치가 없습니다.
포함함: Grok, Nemotron, Gemini, DeepSeek, Wenxin. 포함하지 않음: Claude, ChatGPT, Meta, StepFun, Kimi.각 AI 목록에서의 순위: Grok: 6 · Nemotron: 8 · Gemini: 6 · DeepSeek: 6 · Wenxin: 7
각 AI가 짚은 점 5
- Grok6위
Open-source shop software whose security releases do not touch the PHP engine that actually serves the pages
출처 ↗ - Nemotron8위
PrestaShop 8.1 이상은 PHP 8.1이 필요합니다. 1.7은 여전히 PHP 7.4에서 널리 쓰이고, 핵심 PHP 전환 도구는 없습니다
출처 ↗ - Gemini6위
결제 모듈과의 호환성 문제 때문에, 치명적인 취약점 경고에도 활성 판매자의 38%가 예전 PHP 7.4에 묶여 있습니다.
출처 ↗ - DeepSeek6위
PrestaShop 9는 PHP 8.1에서도 돌아갑니다. 이 버전은 이번 결함보다 5개월 앞서 지원이 끝났습니다.
출처 ↗ - Wenxin7위
오픈소스 전자상거래로, 앱은 원클릭으로 업데이트되지만 PHP는 아닙니다. 상점의 약 27%는 아직 PHP 7.4 이하를 씁니다.
AI 5개가 이 순위로 선택 - 7
cPanel / Plesk 공유 호스팅을 쓰는 사이트
버튼 한 번으로 PHP를 바꾸는 기능은 CMS가 아니라 cPanel이나 Plesk에 있습니다. Shodan 표본에서 영향을 받은 cPanel 호스트 587곳 가운데 하루 뒤 고쳐진 곳은 하나도 없었습니다.
포함함: Claude, ChatGPT, Grok, StepFun, Kimi. 포함하지 않음: Meta, Nemotron, Gemini, DeepSeek, Wenxin.각 AI 목록에서의 순위: Claude: 8 · ChatGPT: 7 · Grok: 9 · StepFun: 6 · Kimi: 10
각 AI가 짚은 점 5
- Claude8위
제어판의 PHP 패키지는 PHP 5.2까지 수정됐지만, 패치된 사이트도 여전히 예전 버전 번호를 보일 수 있습니다.
출처 ↗ - ChatGPT7위
One host-level runtime may be the security bottleneck for many separately maintained customer websites.
출처 ↗ - Grok9위
No platform updater at all; the site owner’s only lever is the host’s PHP selector or a support ticket
출처 ↗ - StepFun6위
PHP 엔진을 실제로 바꾸는 단 한 번의 클릭은 cPanel의 MultiPHP Manager에 있습니다. 하지만 호스팅 업체가 이미 패치된 실행 파일을 만들어 둔 경우에만 작동합니다.
출처 ↗ - Kimi10위
cPanel은 PHP 7.4부터 8.1까지 수정본을 내놓았습니다. 하지만 PHP 7.3 이하에는 수정본이 전혀 없어, 제어판이 설치된 많은 서버가 그대로 멈춘 채 남아 있습니다.
출처 ↗
AI 5개가 이 순위로 선택 - 8
MediaWiki
Wikimedia는 패치가 나오기 전에 Phabricator를 껐습니다. 연구자들이 공격 가능하다고 꼽은 소프트웨어 목록에는 최신 MediaWiki 1.46.2도 있었습니다.
포함함: Grok, StepFun, Kimi, DeepSeek. 포함하지 않음: Claude, ChatGPT, Meta, Nemotron, Gemini, Wenxin.각 AI 목록에서의 순위: Grok: 7 · StepFun: 7 · Kimi: 7 · DeepSeek: 10
각 AI가 짚은 점 4
- Grok7위
High-profile PHP deployments that still require the infrastructure team, not the wiki software, to apply the engine patch
출처 ↗ - StepFun7위
위키백과도 10월 21일 문서 접속을 끊어야 했습니다. 완전히 패치된 MediaWiki라도 밑에 있는 PHP에 여전히 발목이 잡힌다는 증거입니다.
- Kimi7위
위키백과를 움직이는 소프트웨어도 같은 엔진을 씁니다. 위키미디어는 패치가 배포되기 몇 시간 전에 자체 Phabricator를 껐습니다.
출처 ↗ - DeepSeek10위
위키백과는 접속을 끊었습니다. 외부에서 운영하는 위키는 소프트웨어가 지원하는 것보다 오래된 PHP를 쓰는 경우가 많습니다.
AI 4개가 이 순위로 선택 - 9
WooCommerce
WooCommerce 스토어의 약 30%가 공식 수정이 없는 PHP 7.4 또는 8.1 버전에서 돌아가고 있습니다. 이 수치는 메토릭 한 곳의 자료에서 나온 것이므로 추정치입니다.
포함함: Grok, StepFun, Kimi. 포함하지 않음: Claude, ChatGPT, Meta, Nemotron, Gemini, DeepSeek, Wenxin.각 AI 목록에서의 순위: Grok: 10 · StepFun: 2 · Kimi: 5
각 AI가 짚은 점 3
- Grok10위
The store plugin can be current while the PHP version reported in Site Health remains vulnerable until the host acts
출처 ↗ - StepFun2위
수정본이 나왔을 때 WooCommerce 상점 8곳 중 1곳은 아직 PHP 7.4에서 돌아가고 있었습니다. 결제 페이지가 죽은 엔진 위에서 돌아가고 있는 셈입니다.
출처 ↗ - Kimi5위
WordPress 사이트 5곳 중 1곳은 쇼핑몰이고, WooCommerce 공식 문서는 이제 PHP 8.3 이상을 요구합니다. 그런데 대부분의 쇼핑몰은 WordPress 호스팅 업체가 우연히 골라 둔 PHP를 그대로 쓰고 있습니다.
출처 ↗
AI 3개가 이 순위로 선택 - 10
Moodle
학교가 쓰는 Moodle 4.5 LTS는 아직 공식 수정이 없는 PHP 8.1도 받아들입니다. Moodle의 업데이터는 Moodle만 업데이트할 뿐, PHP 엔진은 업데이트하지 않습니다.
포함함: Nemotron, Gemini, DeepSeek. 포함하지 않음: Claude, ChatGPT, Meta, Grok, StepFun, Kimi, Wenxin.각 AI 목록에서의 순위: Nemotron: 10 · Gemini: 8 · DeepSeek: 5
AI 3개가 이 순위로 선택
02알아 둘 만한 것
AI들이 목록을 만들며 발견한 것.
버전 번호는 양쪽으로 착각을 일으킬 수 있습니다. CloudLinux와 Hostinger가 보안 패치만 옮겨 적용하는 백포트 방식을 쓰면 고쳐진 사이트가 PHP 8.5.11로 표시될 수 있고, 반대로 고쳐지지 않은 서버가 완전히 업데이트된 대시보드 아래 있을 수도 있습니다.
PHP는 Apache mod_php를 최악의 경우로 꼽습니다. 시연된 공격은 어떤 애플리케이션 코드가 실행되기도 전에 발동하기 때문에, CMS 보안 플러그인은 그 요청을 전혀 보지 못합니다.
노출 규모는 측정 방법에 따라 10배 넘게 차이 납니다. 커틀러 기준 약 130만, VulnCheck/Censys 기준 PHP 호스트 260만 곳, VirusTotal 기준 IP 510만 개, Palo Alto Networks 기준 인스턴스 2,260만 개입니다.
PHP를 누가 고치는지는 CMS가 아니라 호스팅 요금제에 따라 달라집니다. Hostinger는 10월 22일 06:44 UTC까지 관리형 서버 전체에서 PHP 5.2~8.5를 고쳤지만, VPS 고객은 자신의 서버를 직접 고쳐야 했습니다.
03사람들이 묻는 질문
PHP는 어떻게 업데이트하나요
고쳐진 버전인 PHP 8.5.12, 8.4.27, 8.3.36 또는 8.2.35로 옮기고, PHP를 불러오는 서비스를 모두 다시 시작하세요. PHP 8.1 이하는 공식 수정이 없으므로 제조사 백포트를 받거나 업그레이드해야 합니다.
출처 ↗내 웹사이트의 PHP는 어떻게 업데이트하나요
호스팅 관리 패널(cPanel의 MultiPHP Manager 또는 Plesk의 PHP 설정)에서 고쳐진 PHP 버전을 고르거나 호스팅 업체에 문의하세요. WordPress, 드루팔, 주움라, Magento를 업데이트해도 PHP는 바뀌지 않습니다.
출처 ↗윈도우에서 PHP는 어떻게 업데이트하나요
windows.php.net에서 고쳐진 윈도우 빌드(8.5.12, 8.4.27, 8.3.36 또는 8.2.35)를 내려받아 PHP 폴더를 교체하고, php.ini는 그대로 둔 다음 IIS, Apache 또는 PHP-CGI를 다시 시작하세요.
출처 ↗PHP 버전은 어떻게 올리나요
8.3 이상을 목표로 하세요. 수정은 8.2.35 이상으로 나왔지만, PHP 8.2 자체는 2026년 12월 31일에 지원이 끝납니다. 플러그인은 먼저 복사본 사이트에서 시험해 보세요.
출처 ↗04집계 방법
공식 없이 쉬운 말로.
1질문
최신 상태인 사이트도 취약한 PHP 위에서 돌아갈 수 있는 웹사이트 플랫폼 10곳
2이 주제를 고른 이유
사용 현황 조사와 인터넷 스캔을 나란히 놓고, 실제로 수정을 누가 관리하는지도 함께 보여 줍니다. 그래서 사이트 주인은 “내 사이트는 업데이트됐다”와 “내 서버는 안전하다” 사이의 차이를 알 수 있습니다. 이 차이를 한 표에서 보여 주는 자료는 없습니다.
3적용 범위
전 세계. 워드프레스, 드루팔, 줌라, 매젠토 등 PHP에서 돌아가는 웹사이트 소프트웨어
4살펴본 기준
- 각 플랫폼 설치본 중 PHP 버전이 지원 종료된 비율
- 지원 종료 설치본 중 인터넷 스캐너가 접근할 수 있는 비율
- CGI 모드처럼 취약한 방식으로 PHP를 돌리는 비율
- 플랫폼의 자체 업데이터가 PHP 엔진을 바꿀 수 있는지, 아니면 플랫폼 자체만 바꾸는지 여부
- 수정이 일반적인 사이트에 닿는 속도: 원클릭, 호스팅 업체, 또는 수동 서버 업그레이드
- WordPress.org 통계 — 사이트가 보고한 PHP 버전별 활성 WordPress 설치본 수(실시간 차트, 날짜를 달리해 확인)
- OX Security(Shodan 표본) — 수정 후 24시간 뒤 플랫폼별로 발견, 영향, 수정된 호스트 수
- W3Techs — PHP 버전별, CMS별 웹사이트 비율, 드루팔 코어 버전 포함
5순위를 매긴 AI
선도 AI: Claude, ChatGPT, Meta, Grok, Nemotron, Gemini, StepFun, Kimi, DeepSeek, Wenxin. 각 AI가 독립적으로 10위까지의 목록을 만들고 순위마다 출처를 밝혔습니다.
6순위를 정한 방법
AI마다 다르게 쓴 같은 항목은 하나로 셌습니다. 더 많은 AI가 목록에 넣고 더 높이 놓을수록 순위가 높아집니다. 'AI 합의'는 그 항목을 자기 목록에 넣은 AI의 수를 보여 줍니다. 출처는 AI가 직접 찾은 것뿐이며 사람이 추가한 것은 없습니다.
05AI별 목록
🇺🇸 Claude10개 순위 · 메모 3개
같은 질문에 Claude 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.
- 1Magento / Adobe Commerce (직접 설치형)
OX 표본에서 확인된 매젠토 호스트 48곳은 모두 영향을 받았고, 수정 24시간이 지나도록 하나도 패치되지 않았습니다. 상점의 자체 업데이트는 PHP를 전혀 건드리지 않습니다.
출처 ↗ - 2OpenCart 및 기타 오래된 PHP 상점
이 사이트들의 수정 방법은 한 번 클릭하는 업데이트가 아니라, PHP 5.6에서 8.1까지를 위해 커뮤니티가 관리하는 패치 모음입니다.
출처 ↗ - 3Drupal (직접 설치형)
Wiz는 최신 드루팔 이미지를 상대로 원격 코드 실행을 보였습니다. 그래서 최신 핵심 버전이라도 보호가 되지 않았습니다.
출처 ↗ - 4Joomla (직접 설치형)
OX 표본의 줌라 호스트 1,099곳 중 하루가 지난 뒤 PHP를 패치한 곳은 4곳뿐이었습니다.
- 5공유 호스팅 또는 직접 운영하는 VPS의 워드프레스
워드프레스 설치본 약 3개 중 1개가 PHP 8.1 이하를 쓴다고 보고합니다. 워드프레스 공식 사이트는 워드프레스 업데이트 계획이 없다고 밝혔으므로, PHP 업데이트가 해결책입니다.
출처 ↗ - 6임대 서버의 Laravel 및 직접 만든 PHP 앱
OX 표본에서 확인된 라라벨 호스트의 98.27%는 여전히 패치되지 않았고, 이 프레임워크에는 서버의 PHP를 바꾸는 도구가 없습니다.
- 7Docker 기반 WordPress / Drupal / Joomla 이미지
다시 빌드하면 해결되지만, 공식 php 이미지는 8.1 이하에 대한 수정을 받지 못합니다.
출처 ↗ - 8cPanel / CloudLinux 공유 호스팅 사이트
제어판의 PHP 패키지는 PHP 5.2까지 수정됐지만, 패치된 사이트도 여전히 예전 버전 번호를 보일 수 있습니다.
출처 ↗ - 9Plesk로 관리되는 사이트 (VPS 및 호스트)
Plesk는 수정된 PHP 8.2에서 8.5 빌드를 배포했지만, 적용은 사이트 운영자가 직접 해야 합니다.
출처 ↗ - 10관리형 워드프레스 호스팅 (Pantheon, Pressable, Kinsta, WP Engine)
Pantheon과 Pressable은 10월 22일에 이미 전부 패치를 마쳤습니다. WP Engine과 Flywheel은 업데이트가 배포되는 동안 CDN 보호를 앞에 두었습니다.
출처 ↗
Claude의 발견
서로 다른 두 측정이 같은 결과를 보여 줍니다. 노출된 PHP 실행 환경의 10곳 중 약 7곳은 PHP 프로젝트가 더 이상 지원하지 않는 버전을 씁니다. Flare는 서비스 기록의 72.7%, Qualys는 설치본의 71%라고 밝혔습니다.
최신 상태인 WordPress 대시보드는 잘못된 안심을 줍니다. Codeable은 WordPress.org가 WordPress 업데이트가 필요하거나 계획된 것이 없다고 확인했다고 말합니다. 결함이 WordPress, 테마, 플러그인 아래에 있기 때문입니다.
버전 표시는 두 방향으로 헷갈리게 할 수 있습니다. CloudLinux 백포트를 쓰면 수정된 호스트가 PHP 8.5.11로 표시되기도 하고, Ubuntu나 Debian 패키지는 옛 버전 문자열을 그대로 두기도 합니다.
🇺🇸 Nemotron10개 순위
같은 질문에 Nemotron 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.
- 1워드프레스
WP.org 통계에 따르면 워드프레스 사이트의 약 60%가 지원 종료된 PHP에서 돌아가지만, 대부분의 관리형 호스트에는 한 번의 클릭으로 PHP를 바꾸는 기능이 있습니다
- 2드루팔
드루팔 10 이상은 PHP 8.1 이상이 필요하지만, 드루팔 7 사이트(설치본의 약 15%)는 지원 종료된 PHP 7.4에 머물러 있습니다
- 3줌라
줌라 5.x는 PHP 8.2 이상이 필요하고, 4.x는 8.1을 씁니다. 많은 3.x 사이트는 핵심 업그레이드 경로가 없이 PHP 7.4에 있습니다
출처 ↗ - 4Magento / Adobe Commerce
매젠토 2.4.7 이상은 PHP 8.2 이상이 필요하고, 구버전 2.4.x는 PHP 8.1이 곧 지원 종료됩니다. Cloud는 PHP를 자동 업데이트합니다
출처 ↗ - 5TYPO3
TYPO3 v12 LTS는 PHP 8.1 이상이 필요하고, v11은 2024년에 지원이 끝났습니다. 많은 v10과 v11 사이트가 PHP 7.4나 8.0에 있습니다
- 6Laravel (CMS가 아닌 프레임워크)
라라벨 11.x는 PHP 8.2 이상이 필요합니다. 많은 10.x 앱이 PHP 8.1에 있고, PHP를 자동으로 업데이트하는 도구는 없습니다
출처 ↗ - 7Symfony (프레임워크)
Symfony 7.x는 PHP 8.2 이상이 필요합니다. 6.4 LTS는 8.1에서 돌아가고, 많은 5.4와 6.x 앱이 오래된 PHP에 있습니다
출처 ↗ - 8PrestaShop
PrestaShop 8.1 이상은 PHP 8.1이 필요합니다. 1.7은 여전히 PHP 7.4에서 널리 쓰이고, 핵심 PHP 전환 도구는 없습니다
출처 ↗ - 9OpenCart
OpenCart 4.x는 PHP 8.1 이상이 필요합니다. 3.x가 PHP 7.4나 8.0에서 주로 쓰이고, 확장 프로그램 생태계가 뒤처져 있습니다
- 10Moodle
Moodle 4.5는 PHP 8.2가 필요합니다. 4.1 LTS는 8.0에서 돌아가고, 많은 3.11과 4.0 사이트가 PHP 7.4에 있습니다
출처 ↗
🇺🇸 Gemini10개 순위 · 메모 1개
같은 질문에 Gemini 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.
- 1워드프레스
워드프레스 관리 화면에 초록 체크 표시가 뜬 4,000만 개 넘는 업데이트된 사이트가, 그 아래에서는 지원 종료된 PHP 7.4나 8.0 엔진으로 조용히 돌아가고 있습니다.
출처 ↗ - 2줌라
PHP 8.2나 8.3으로 옮기면 확장 프로그램이 바로 깨지기 때문에, 실서비스 설치본의 거의 절반이 예전 PHP를 그대로 씁니다.
- 3드루팔
드루팔 10이 최신 PHP 8.2 이상을 요구하는데도, 드루팔 7을 고집하는 기업들은 PHP 7.4 런타임을 유지하고 있어서 큰 격차가 있습니다.
- 4Magento (Adobe Commerce)
컴파일된 의존성 제약이 엄격해서, 기반 PHP 엔진을 올리려면 다시 빌드해야 합니다. 그래서 전자상거래 상점들이 은퇴한 런타임에 묶여 있습니다.
출처 ↗ - 5OpenCart
관리되지 않는 저가 공유 호스팅에 널리 깔려 있고, 상점 운영자들은 자신의 PHP 인터프리터가 5년이나 뒤처졌다는 사실을 거의 모릅니다.
- 6PrestaShop
결제 모듈과의 호환성 문제 때문에, 치명적인 취약점 경고에도 활성 판매자의 38%가 예전 PHP 7.4에 묶여 있습니다.
출처 ↗ - 7TYPO3
장기 지원(LTS) 기업 주기는 CMS 패치를 최대 6년까지 보장하지만, 그 아래 PHP 런타임의 표준 지원 기간보다 오래 가는 경우가 많습니다.
출처 ↗ - 8Moodle
교육 기관은 고정된 학사 일정에 따라 움직여서, 학년도 사이에는 서버 환경이 은퇴한 PHP 버전에 멈춰 있습니다.
출처 ↗ - 9phpBB
수많은 오래된 커뮤니티 포럼이 잊힌 취미용 서버에서 돌아갑니다. 게시판 애플리케이션은 업데이트되지만 Apache FastCGI는 그대로입니다.
- 10vBulletin
상용 라이선스 보유자들은 비싼 라이선스 갱신을 피하려고 예전 LAMP 스택의 설치본을 그대로 유지하는 경우가 많습니다.
Gemini의 발견
전 세계 PHP로 돌아가는 웹사이트의 35% 넘게가 PHP 7.4 이하 버전에서 계속 돌아가고 있습니다. 이 버전들은 몇 년 전에 공식 커뮤니티 보안 업데이트가 끝났습니다.
🇨🇳 StepFun10개 순위 · 메모 3개
같은 질문에 StepFun 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.
- 1WordPress (직접 설치형)
웹 전체의 39.6%를 차지하며, 약 6곳 중 1곳은 아직 PHP 7.4에 머물러 있습니다. 이 버전의 유일한 수정본은 직접 빌드해야 하는 것입니다.
출처 ↗ - 2WooCommerce (직접 설치형 WordPress)
수정본이 나왔을 때 WooCommerce 상점 8곳 중 1곳은 아직 PHP 7.4에서 돌아가고 있었습니다. 결제 페이지가 죽은 엔진 위에서 돌아가고 있는 셈입니다.
출처 ↗ - 3Drupal
웹의 0.6%입니다. 하지만 Drupal 11은 PHP 8.3을 요구하며, composer update는 엔진을 대신 바꿔 주지 않습니다.
- 4Joomla
Joomla 6은 PHP 8.3보다 낮은 버전에는 설치를 거부합니다. 그런데 Joomla 자체 업데이터로는 사이트를 그 위로 올릴 수 없습니다.
출처 ↗ - 5Magento / Adobe Commerce
Adobe Commerce 2.4.9는 PHP 8.2를 아예 뺐습니다. 수정본을 받은 가장 오래된 버전인데도요. 그래서 안전한 엔진을 쓰려면 플랫폼 자체도 업그레이드해야 합니다.
- 6cPanel / Plesk 공유 호스팅의 WordPress
PHP 엔진을 실제로 바꾸는 단 한 번의 클릭은 cPanel의 MultiPHP Manager에 있습니다. 하지만 호스팅 업체가 이미 패치된 실행 파일을 만들어 둔 경우에만 작동합니다.
출처 ↗ - 7MediaWiki / Wikimedia
위키백과도 10월 21일 문서 접속을 끊어야 했습니다. 완전히 패치된 MediaWiki라도 밑에 있는 PHP에 여전히 발목이 잡힌다는 증거입니다.
- 8관리형 WordPress (WP Engine, Kinsta)
Kinsta가 PHP 8.5 패치를 가장 먼저 적용했고, 그로부터 두 시간 반이 지나도 WP Engine 고객들은 여전히 기다리고 있었습니다. '관리형'이라는 말은 보장이 아니라 대기 줄을 뜻했습니다.
출처 ↗ - 9사이트그라운드 / GoDaddy 공유 호스팅
사이트그라운드는 패치가 공개되기 전에 모든 서버를 보호했다고 밝혔습니다. GoDaddy는 10월 22일 13:30 UTC까지 Web Hosting의 모든 PHP 버전 작업을 마쳤습니다.
- 10WordPress.com / WordPress VIP / Pressable / WP Cloud (오토매틱)
최신 상태의 사이트가 취약한 PHP를 여전히 쓸 수 없는 곳이 있습니다. 오토매틱이 엔진 자체를 패치해서 사이트 주인이 누를 것이 없었습니다.
StepFun의 발견
WordPress의 원클릭 업데이터는 WordPress만 업데이트하고 PHP는 건드리지 않습니다. 그래서 관리자 화면에 '최신 상태'라고 떠도 취약한 엔진 위에서 돌아갈 수 있습니다. WordPress는 권장 버전을 8.3으로 안내하면서도 최소 요구 버전으로 아직 PHP 7.4를 표시하고 있습니다. 그러니 모든 업데이트를 마친 사이트도 공식 수정이 나오지 않은 버전을 그대로 쓸 수 있습니다.
인터넷에 노출된 호스트 884,000곳은 버전을 밝힌 150만 곳의 59%에 해당하며, PHP 8.1 이하를 쓰고 있었고 공식 빌드는 전혀 없었습니다. 버전 없이 PHP를 알리는 호스트 740,000곳을 더하면, 노출의 상당 부분은 버전 기반 대시보드에서 아예 보이지 않습니다.
PHP는 Apache mod_php를 가장 위험한 설정으로 꼽습니다. 시연된 공격이 어떤 애플리케이션 코드보다도 먼저 실행되기 때문입니다. 즉 CMS 자체 보안 플러그인이 그 요청을 볼 기회조차 없습니다. php-cgi, PHP-FPM, FrankenPHP, LiteSpeed도 모두 영향을 받지만, 실제로 작동하는 공개 공격 코드가 있는 것은 mod_php입니다.
🇨🇳 Kimi10개 순위 · 메모 2개
같은 질문에 Kimi 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.
- 1WordPress (2026)
지구상 웹사이트 5곳 중 2곳이 WordPress를 씁니다. 3곳 중 1곳은 아직 지원이 끝난 PHP를 쓰고 있다고 나옵니다. 그리고 완전히 업데이트된 WordPress 7.1.2도 연구자가 직접 만든 공격 시연 목록에 올라 있었습니다.
출처 ↗ - 2Joomla (2026)
Joomla 사이트의 82%가 아직 버전 3을 쓰고 있습니다. 2012년 PHP에서도 잘 돌아가는 소프트웨어입니다. Joomla 프로젝트 공식 사이트도 이 버그 때문에 접속이 끊겼습니다.
출처 ↗ - 3Magento / Adobe Commerce (2026)
Magento 1 상점은 2020년 6월 이후 공식 보안 지원을 받지 못했습니다. 이들에게 이번 긴급 수정은 아예 없고, 서버를 업그레이드해야만 합니다.
출처 ↗ - 4Drupal (2026)
Drupal 사이트의 거의 절반이 아직 지원이 끝난 코어를 쓰고 있습니다. 그중 29%는 Drupal 7이며, 이 버전은 2025년 1월부터 지원이 끝났습니다. 그래서 이들의 PHP는 보통 더 오래된 것입니다.
- 5WooCommerce (2026)
WordPress 사이트 5곳 중 1곳은 쇼핑몰이고, WooCommerce 공식 문서는 이제 PHP 8.3 이상을 요구합니다. 그런데 대부분의 쇼핑몰은 WordPress 호스팅 업체가 우연히 골라 둔 PHP를 그대로 쓰고 있습니다.
출처 ↗ - 6Shopware (2026)
Sansec은 발표 첫날 경고에서 Shopware를 Magento와 함께 묶었습니다. DACH 지역 상점들은 '자기 코드에 문제가 없어도' 노출되어 있다고 합니다.
출처 ↗ - 7MediaWiki (2026)
위키백과를 움직이는 소프트웨어도 같은 엔진을 씁니다. 위키미디어는 패치가 배포되기 몇 시간 전에 자체 Phabricator를 껐습니다.
출처 ↗ - 8Nextcloud (직접 설치형, 2026)
Nextcloud의 세련된 원클릭 업데이터는 앱은 업데이트해 주지만, 밑에 있는 PHP는 건드릴 수 없습니다. 그리고 Nextcloud 35.0.1도 공격 시연 목록에 있었습니다.
출처 ↗ - 9WHMCS (2026)
호스팅 업체가 '완전 관리형' 호스팅을 팔 때 쓰는 청구 관리 패널 자체도 연구자가 정리한 영향 목록에 올라 있었습니다.
출처 ↗ - 10phpMyAdmin / cPanel & Plesk 관리 패널 (2026)
cPanel은 PHP 7.4부터 8.1까지 수정본을 내놓았습니다. 하지만 PHP 7.3 이하에는 수정본이 전혀 없어, 제어판이 설치된 많은 서버가 그대로 멈춘 채 남아 있습니다.
출처 ↗
Kimi의 발견
업데이트된 관리자 화면은 거짓말을 할 수 있습니다. WordPress.org는 이 결함에 대해 WordPress 업데이트가 필요하지도, 계획되어 있지도 않다고 확인했습니다. 수정은 PHP 엔진에만 있으므로, '모든 것이 최신입니다'라는 초록색 표시는 어떤 플랫폼에서든 잘못된 안심입니다.
WordPress 사이트 3곳 중 1곳은 지원이 끝난 PHP를 씁니다(2026년 10월 기준 7.4 + 8.0 + 8.1 = 32.4%). 전체 PHP 사이트의 7.7%는 아직 PHP 5를 쓰며, 그중 버전 5.6이 55%를 차지합니다. 10년 동안 나온 수정을 한 번도 받지 못한 서버에서 돌고 있습니다.
🇨🇳 DeepSeek10개 순위 · 메모 3개
같은 질문에 DeepSeek 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.
- 1WordPress (2026)
스스로는 업데이트되지만 밑의 엔진은 올리지 못하는 CMS입니다.
출처 ↗ - 2Magento / Adobe Commerce (2026)
최신 상점도 Adobe가 더 이상 지원하지 않는 PHP 버전에 머물 수 있습니다.
- 3Joomla (2026)
Joomla 설치본의 거의 4분의 3이 더 이상 보안 수정을 받지 못하는 버전을 쓰고 있습니다.
- 4Drupal (2026)
Drupal 10은 아직 PHP 8.1에서 돌아갑니다. PHP 프로젝트는 2025년 12월에 이 버전의 패치를 멈췄습니다.
- 5Moodle (2026)
학교들이 의존하는 LTS(장기 지원판)도 아직 PHP 8.1을 허용하는데, 이 엔진은 보안 지원이 없습니다.
출처 ↗ - 6PrestaShop (2026)
PrestaShop 9는 PHP 8.1에서도 돌아갑니다. 이 버전은 이번 결함보다 5개월 앞서 지원이 끝났습니다.
출처 ↗ - 7Laravel (2026)
최신 Laravel은 8.2 이상이 필요하지만, PHP를 언제 올릴지는 프레임워크가 아니라 배포 절차가 정합니다.
출처 ↗ - 8코드이그나이터 (2026)
CI4는 최신이지만, CI3를 쓰는 사이트들은 아직 PHP 5.6도 허용합니다.
- 9Symfony (2026)
Symfony 7.4는 8.2를 요구합니다. 약한 고리는 프레임워크가 아니라 서버입니다.
출처 ↗ - 10MediaWiki (2026)
위키백과는 접속을 끊었습니다. 외부에서 운영하는 위키는 소프트웨어가 지원하는 것보다 오래된 PHP를 쓰는 경우가 많습니다.
DeepSeek의 발견
WordPress는 코어를 적극적으로 자동 업데이트합니다. 관찰 대상 사이트의 71%가 최신 코어를 쓰고 있었습니다. 하지만 같은 사이트들도 WordPress 대시보드가 PHP는 건드리지 않기 때문에 패치되지 않은 PHP 엔진에 머물 수 있습니다. 이 어긋남이 바로 PHP2Shell 경보가 드러낸 잘못된 안심입니다.
Censys 조사에서 버전이 드러난 WordPress 사이트 중 최신 코어를 쓰는 곳은 14%뿐이었습니다. 그런데 현재 PHP 패치를 받은 곳은 약 30%였습니다. 두 업데이트 경로는 속도가 다르고, 어느 하나가 다른 하나를 보장하지 않습니다.
PHP 웹사이트의 절반 가까이, 48.5%가 PHP 프로젝트가 더 이상 패치하지 않는 버전을 쓰고 있습니다. 그래서 그런 호스트에서는 CMS나 플러그인을 아무리 업데이트해도 CVE-2026-109618을 고칠 수 없습니다.
🇨🇳 Wenxin10개 순위 · 메모 1개
같은 질문에 Wenxin 혼자 답한 결과입니다. 위의 최종 목록은 모든 AI를 종합합니다.
- 1WordPress 6.x (2026)
사이트 10곳 중 거의 4곳이 WordPress를 씁니다. 호스트가 허용한다면 대시보드 클릭 한 번으로 PHP 엔진을 바꿀 수 있습니다. 하지만 설치본의 18%는 아직 PHP 7.x 이하라고 보고합니다.
- 2Drupal 10/11 (2026)
업데이터는 플랫폼을 바꿀 수 있지만 PHP 엔진은 건드릴 수 없습니다. Drupal 사이트의 22%는 호스트가 업그레이드하지 않아 지원이 끝난 PHP를 쓰고 있습니다.
- 3Joomla 4/5 (2026)
Joomla 자체는 원클릭으로 업데이트되지만 PHP는 전혀 통제할 수 없습니다. Joomla 설치본 5개 중 1개는 아직 PHP 7.4를 쓰고 있습니다.
- 4Magento (Adobe Commerce) 2.4 (2026)
기업용 플랫폼이지만 업데이터는 Magento 코드만 패치합니다. PHP 업그레이드는 호스팅 업체에 연락해야 합니다. 상점의 30%는 아직 PHP 7.4를 씁니다.
출처 ↗ - 5Wix / Squarespace (SaaS 클라우드, 2026)
이 플랫폼들은 자체 PHP 스택으로 돌아갑니다. 이용자가 엔진을 건드릴 일이 없어서, PHP가 출시되는 날 수정도 함께 적용됩니다. 다만 이용자가 묶여 있어서 위험이 잘 보이지 않습니다.
- 6Shopify (SaaS 클라우드, 2026)
Wix처럼 완전 관리형이어서 PHP 위험은 업체가 떠안습니다. 하지만 규모가 워낙 커서, 잘못된 패치 하나가 수십만 개 상점에 한꺼번에 번질 수 있습니다.
- 7PrestaShop (2026)
오픈소스 전자상거래로, 앱은 원클릭으로 업데이트되지만 PHP는 아닙니다. 상점의 약 27%는 아직 PHP 7.4 이하를 씁니다.
- 8Typo3 CMS (2026)
독일에서 만든 CMS로, 관리자가 설치 도구에서 PHP를 바꿀 수 있습니다. 하지만 실제로 바꾸는 설치본은 14%뿐이어서 30만 이상이 노출된 채 남아 있습니다.
- 9Craft CMS (2026)
깔끔한 업데이터를 갖춘 소규모 전문 CMS입니다. 문제는 대부분의 소상공인 사이트가 PHP를 올리지 않는 공용 호스팅에서 돌아간다는 것입니다. 19%가 지원 종료된 PHP를 씁니다.
- 10Concrete CMS (2026)
플랫폼 자체 업데이터는 PHP가 아니라 CMS를 패치합니다. 여기서 규모가 가장 작다는 것은 피해자가 가장 적다는 뜻이지만, 패치 주기는 가장 느립니다.
Wenxin의 발견
'원클릭 업데이터'라는 착각: WordPress, Drupal, Joomla, Magento는 모두 CMS를 원클릭으로 업데이트할 수 있지만, 밑에서 돌아가는 PHP 엔진은 어느 것도 올리지 못합니다. 그 단계는 호스트가 해야 합니다.