PHP2Shell은 PHP의 치명적인 취약점 두 건인 CVE-2026-109618과 CVE-2026-109619를 묶어 부르는 이름입니다. 두 취약점은 인증 절차 없이도 취약한 서버에서 원격 코드 실행을 허용할 수 있어 위험합니다. PHP는 2026년 10월 21일 수정 버전을 공개했고, 대응 과정에서 예방 차원으로 서비스를 일시 중단한 조직도 있었습니다. 다만 공격 시도나 취약점 스캔이 관측됐다는 사실만으로 실제 침해가 확인된 것은 아닙니다.
4
7
18
PHP2Shell 취약점은 무엇을 하는가
이 취약점은 특정 웹사이트 플러그인이나 애플리케이션이 아니라 PHP 실행 환경 자체에 영향을 줍니다. 한 취약점은 메모리 부족 상황을 처리하는 과정과, 다른 하나는 오래된 전역 상태를 다루는 문제와 관련돼 있습니다. 특정 조건에서 조작된 요청이 원격 코드 실행으로 이어질 수 있으며, 한 취약점은 프로세스 메모리의 민감한 정보가 노출될 가능성도 있습니다.
4
11
PHP는 널리 쓰이는 프로그래밍 언어로, 일부 보도는 웹사이트의 최대 70%가 PHP를 사용한다고 추정합니다. 그렇다고 PHP 기반 사이트가 모두 취약하거나 같은 수준의 위험에 노출됐다는 뜻은 아닙니다. 실제 위험은 PHP 버전과 설정, 취약한 코드 경로에 외부에서 접근할 수 있는지에 따라 달라집니다.
45
46
AI를 활용한 발견과 앞당겨진 공개
취약점을 발견하고 대응한 과정에는 Wiz, Calif, OpenAI의 연구자와 팀이 참여한 것으로 보도됐습니다. 일부 보도는 연구 과정에서 AI가 활용됐다고 설명합니다. 다만 공개된 자료만으로는 특정 WordPress 공격 기법을 Drupal에 적용하다 취약점을 발견했다는 이야기나, 각 CVE를 누가 어떤 역할로 발견했는지까지 모두 확인되지는 않습니다.
14
45
보도에 따르면 관련 메모리 처리 문제는 원격 코드 실행 가능성이 입증되기 전에 먼저 주목받은 적이 있습니다. 의심스러운 결함을 발견하는 것과 현실적인 공격 경로를 입증하는 것은 서로 다른 단계입니다.
22
38
예정된 공개 전에 취약점 세부 정보가 유출되면서 대응 일정에 압박이 더해졌고, 패치 작업도 서둘러 진행됐습니다.
6
23 공개와 검증, 패치 배포가 짧은 시간 안에 몰리면 보안 문제가 곧바로 서비스 운영 문제로 이어질 수 있다는 점을 보여준 사례입니다.
패치와 공격 보고가 의미하는 것
10월 21일 공개된 PHP 수정 버전은 8.2.35, 8.3.36, 8.4.27, 8.5.12입니다. 관리자는 호스팅 업체나 운영체제 공급업체의 보안 공지도 확인해야 합니다. 일부 업체는 PHP 버전 번호를 그대로 올리는 대신 기존 버전에 수정 사항을 적용하는 백포트 방식으로 패치를 제공할 수 있습니다.
4
39
보안 업체들은 취약점 공개 전후로 스캔이나 악용 시도를 관측했다고 보고했습니다. Cloudflare 관련 보도에서도 시도 건수가 빠르게 늘어난 것으로 전해졌습니다. 다만 이런 수치는 특정 서비스가 관측한 요청이나 시도를 나타낼 뿐, 실제로 침해된 시스템이 몇 개인지를 보여주지는 않습니다.
5
36
성공적인 공격이 확인됐는지에 대해서는 보도 시점과 평가가 달랐습니다. BBC는 10월 22일 기준 성공한 공격 사례가 보고되지 않았다고 전했고, 이후 Beazley는 광범위한 시도는 보고됐지만 대규모 침해가 확인된 것은 파악하지 못했다고 밝혔습니다. Sansec도 대규모 악용 가능성이 공개 당일 예상했던 것보다 낮아 보인다고 평가를 수정했습니다. 이런 판단은 각 발표 시점의 상황을 반영합니다. 그렇다고 패치하지 않은 서버가 안전하다는 뜻은 아닙니다.
7
9
18
일부 서비스가 오프라인이 된 이유
일부 조직은 노출 범위를 확인하고 업데이트를 준비하는 동안 서비스를 일시 중단하거나 접근을 제한했습니다. 보도에 따르면 영국 정부는 서비스 32개를 오프라인으로 전환했습니다. 한 서비스 상태 추적 사이트는 패치가 나오기 전에 100개가 넘는 서비스가 장애·점검 공지나 PHP2Shell 관련 경고를 게시했다고 집계했습니다. 이런 조치는 긴급 대응에 따른 서비스 차질을 보여주지만, 해당 서비스가 공격받았다는 증거는 아닙니다.
22
34
다른 나라 정부와 기관의 대응도 보도됐지만, 공개된 자료만으로는 영향을 받은 서비스를 빠짐없이 독립적으로 확인한 목록이나 언급된 각 서비스의 중단 사유를 모두 확정하기 어렵습니다.
20
25
웹사이트 운영자가 할 일
- PHP가 설치된 곳을 모두 파악하세요. 주 웹사이트뿐 아니라 운영 서버, 컨테이너, 보조 시스템, 관리형 호스팅도 확인해야 합니다.
- 해당 환경에 맞는 패치를 신속히 적용하세요. 수정된 PHP 버전이나 업체가 확인한 백포트 패치를 설치하고, 필요한 경우 PHP 작업자 프로세스나 서비스를 재시작한 뒤 실제 구동 버전을 확인하세요. PHP 애플리케이션이나 플러그인만 업데이트하는 것으로 PHP 실행 환경의 취약점이 해결되지는 않습니다.
14
39
- 즉시 패치할 수 없다면 노출을 줄이세요. 서비스의 외부 노출 정도와 업무상 영향을 고려해 공개 접근을 제한하거나 일시 중단하는 방안을 검토할 수 있습니다. 방화벽 규칙 등 네트워크 차단은 임시 조치이지 패치를 대신하지 않습니다.
- 침해 흔적을 확인하세요. 관련 로그를 살피고 예상하지 못한 파일·프로세스·관리자 계정이 있는지 점검하세요. 침해가 의심되면 증거를 보존하고 조사해야 합니다. 패치를 설치했다고 기존 침입까지 해결된 것으로 간주해서는 안 됩니다.
- 서비스 제공업체에 적용 범위를 확인하세요. 호스팅이나 관리형 서비스를 이용하는 조직은 의존 중인 모든 PHP 환경에 조치가 완료됐는지 구체적으로 확인하는 것이 좋습니다.
미국 국가안보국(NSA)은 중요 보안 패치를 권고하고 PHP2Shell 악용을 시도할 수 있는 악성 행위자를 식별하는 데 우선순위를 두고 있다고 밝혔습니다. 연방수사국(FBI)도 PHP 설치 환경을 업데이트하라고 촉구했습니다. 다만 확인 가능한 자료는 패치가 불가능할 때 모든 조직에 시스템을 종료하라고 지시한 FBI·NSA·CISA 공동 명령이 있었다는 점까지 뒷받침하지 않습니다.
17
28
개인 사용자가 할 수 있는 일과 한계
개인 기기와 애플리케이션, 공유기의 업데이트를 유지하고 다중 인증과 서비스별 고유 비밀번호를 사용하는 것은 기본적인 보안 수칙입니다. 하지만 이런 조치가 웹사이트 서버의 PHP를 패치해 주지는 않습니다. 서버 업데이트는 웹사이트 운영자나 호스팅 업체가 해야 합니다.
PHP2Shell이 주는 실질적인 교훈은 신속하고 검증된 패치, 그리고 짧아진 대응 시간을 대비할 준비입니다. 취약점 연구와 공격 시도가 빠르게 이어질 수 있다는 우려는 타당하지만, 공격 시도 집계를 대규모 침해의 확인으로 해석하거나 인터넷 보안이 전면 붕괴했다고 단정할 근거는 없습니다.