PHP2Shell은 PHP에서 발견된 두 가지 치명적 취약점, CVE-2026-109618과 CVE-2026-109619를 가리킵니다. 악용에 성공하면 공격자가 로그인하지 않고도 취약한 서버에서 코드를 실행할 수 있습니다. 수정판은 2026년 10월 21일 공개됐고, 보안업체들은 취약점을 노린 공격 시도를 보고했습니다. 다만 공격 시도가 있었다는 사실만으로 서버 침해가 확인된 것은 아닙니다.
11
14
19
PHP2Shell은 무엇을 위협하나
이번 문제는 특정 웹사이트나 콘텐츠관리시스템(CMS)이 아니라 PHP 런타임, 즉 서버에서 PHP 코드를 실행하는 기반 소프트웨어에 영향을 줍니다. Red Hat에 따르면 한 취약점은 요청을 처리하는 중 메모리 할당에 실패했을 때 상태를 제대로 정리하지 못하는 문제와 관련이 있고, 다른 취약점은 치명적 오류로 정리 작업이 중단된 뒤 오래된 상태가 남을 수 있는 문제입니다.
7
이런 결함은 원격 코드 실행(RCE)으로 이어질 수 있습니다. 쉽게 말해 공격자가 서버에 로그인하지 않고도 취약한 시스템에서 명령이나 코드를 실행할 가능성이 있다는 뜻입니다.
11
13 두 취약점은 CVSS v4.0 기준 각각 9.2점을 받아 ‘치명적’ 등급으로 분류됐습니다.
4 서버 장악, 데이터 노출, 서비스 중단 등이 가능한 결과지만, 취약점이 존재한다는 사실이 모든 PHP 사이트가 공격받았거나 침해됐다는 뜻은 아닙니다.
13
왜 긴급 대응이 필요했나
보도에 따르면 이 결함은 공개되기 전까지 PHP에 수년간 존재했습니다.
42 다만 오래된 취약점이라는 사실만으로 공격자들이 그 기간 내내 이를 알고 있었거나 악용했다고 단정할 수는 없습니다.
이번 취약점 발견 과정에서는 AI를 활용한 보안 연구도 주목받았습니다. 보도에 따르면 Calif와 Wiz는 조사에 AI 도구를 사용했고, OpenAI도 연구 및 공개 과정에 참여했습니다.
34
44 AI는 소프트웨어를 분석하는 연구자에게 도움을 줄 수 있지만, 이번 발견만으로 공격자들이 비슷한 도구를 얼마나 빨리 활용할지, 어느 쪽이 우위에 설지까지 알 수는 없습니다.
PHP가 웹사이트의 약 70%에서 사용된다는 추정치도 여러 보도에 등장했습니다.
20 이는 PHP의 사용 범위를 설명하는 수치이지, 취약한 서버나 실제 침해된 웹사이트의 숫자는 아닙니다. 실제 노출 여부는 PHP 버전과 설정, 배포 방식, 수정판 적용 여부에 따라 달라집니다.
패치와 공격 시도, 확인된 사실은
PHP 프로젝트는 10월 21일 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12에서 수정 사항을 공개했습니다.
19 이 목록은 PHP 8.2부터 8.5까지의 공식 릴리스에 해당합니다. 이전 버전을 운영한다면 패치가 없다고 단정하거나 제공된다고 가정하지 말고, 운영체제 배포판이나 호스팅 업체의 보안 공지를 확인해 검증된 수정판 또는 백포트가 있는지 살펴야 합니다.
취약점을 노린 시도도 보고됐습니다. SecurityWeek는 Amazon이 패치 공개 나흘 전인 10월 17일 공격 시도를 관측했다고 전했습니다.
14 Cloudflare도 취약점 공개 뒤 공격 시도 트래픽이 급증해 이후 수백만 건에 이르렀다고 보고했습니다.
27
38 이 수치는 관측된 시도 건수이며 성공한 침입 건수를 뜻하지 않습니다.
실제 공격 규모에 대한 평가는 일치하지 않습니다. 일부 보도는 공격 시도가 이어지고 있다고 전했고, 다른 분석은 예상보다 대규모 악용 가능성이 낮아 보인다고 했습니다.
3
4 현재 확인 가능한 자료만으로는 광범위한 성공적 침해가 있었다고 단정하기 어렵습니다. 신뢰할 만한 공격 보고는 गंभीर하게 받아들이되, 스캔이나 공격 시도와 특정 서버의 침해 증거는 구분해야 합니다.
2
3
서비스 중단은 침해의 증거가 아니다
대응 과정에서 일부 기관과 기업은 외부에 공개된 서비스를 일시적으로 중단하거나 점검 상태로 전환했습니다. 일본, 프랑스, 핀란드, 네덜란드에서 이런 조치가 있었다는 보도가 나왔고, 미국과 유럽의 기관들도 조직에 대응을 촉구했습니다.
18
20
35 노출을 줄이기 위해 서비스를 잠시 내리는 것은 대응 방안이 될 수 있지만, 그 자체가 해당 서비스가 침해됐다는 증거는 아닙니다.
한편 제공된 자료만으로는 쾰른 행사에서 마이크로소프트 CEO 사티아 나델라가 했다고 전해진 발언의 문구나 맥락을 독립적으로 확인하기 어렵습니다. 확인되지 않은 인용을 이번 대응의 배경이나 사건의 성격을 설명하는 근거로 삼아서는 안 됩니다.
PHP 운영자가 지금 할 일
- 애플리케이션뿐 아니라 PHP 런타임을 확인하세요. PHP2Shell은 PHP 자체의 취약점입니다. CMS나 플러그인만 업데이트했다고 해서 서버의 PHP가 수정됐다고 볼 수 없습니다.
13
- 검증된 수정판을 적용하세요. 적절한 수정 버전으로 업그레이드하거나, 사용 중인 배포판·호스팅 업체가 안내한 백포트 패치를 적용하세요. 운영 환경에서 실제로 실행 중인 버전도 확인해야 합니다.
19
- 침해 흔적을 점검하세요. 패치는 취약점을 막지만, 서버가 이전에 접근당하지 않았다는 뜻은 아닙니다. 관련 로그와 의심스러운 활동을 살펴보고, 필요한 조사를 마친 뒤 서비스를 정상화하세요.
- 임시 완화책은 공식 지침에 따라 적용하세요. PHP 유지관리자나 공급업체의 최신 안내를 확인하세요. 설정 하나를 바꾸거나 웹 애플리케이션 방화벽(WAF)을 사용하는 것만으로 검증된 PHP 수정판을 대신할 수는 없습니다.
15
27
- 계정 보안은 추가 방어층으로 활용하세요. 계정마다 다른 비밀번호를 쓰고 다중 인증(MFA)을 설정하면 계정 보호에 도움이 됩니다. 그러나 인증 없이 악용될 수 있는 서버 측 코드 실행 취약점 자체를 해결해 주지는 않습니다.
운영팀이 취약점, 공격 시도, 확인된 침해를 구분하는 것은 중요합니다. 그래야 긴급 패치를 서두르면서도 아직 확인되지 않은 피해를 사실처럼 단정하지 않을 수 있습니다.