최근 PHP 보안 문제로 홈페이지 운영자들의 긴급 대응이 이어지고 있습니다. ‘PHP2Shell’로 불리는 취약점 2건이 공개됐으며, PHP 개발팀은 2026년 10월 21일 이를 수정한 보안 업데이트를 배포했습니다. 공격자가 로그인하지 않고도 취약한 서버에서 코드를 실행할 수 있는 문제로, 두 취약점 모두 CVSS v4.0 기준 심각도 9.2점을 받았습니다.

워드프레스나 홈페이지 프로그램을 최신 상태로 유지했더라도 서버에서 구동하는 PHP가 취약한 버전이면 별도의 조치가 필요합니다. 이번 문제는 특정 플러그인에 생긴 결함이 아니라, 웹사이트의 프로그램을 실행하는 PHP 자체에서 발견됐기 때문입니다.

AI 업계에서도 주목하는 사건입니다. 보안 연구진이 AI를 활용해 오래된 코드의 취약점을 찾고, 실제 악용 가능성을 검증했으며, 수정 사항을 확인하는 과정에도 AI를 사용했습니다. 홈페이지 운영자에게는 당장의 업데이트 문제이고, 보안 업계에는 AI가 취약점 연구의 속도를 어떻게 바꾸고 있는지 보여주는 사례입니다.

──────────────────
【 PHP2Shell, 어떤 보안 문제인가요? 】

PHP는 웹서버에서 홈페이지와 웹 애플리케이션을 실행하는 데 사용하는 프로그래밍 언어입니다. 방문자의 요청을 처리하고, 로그인 상태를 확인하거나 게시글을 불러오는 등 화면 뒤에서 여러 작업을 수행합니다.

이번에 공개된 취약점의 식별번호는 CVE-2026-109618과 CVE-2026-109619입니다. 두 문제는 PHP가 요청을 처리하다 오류를 만났을 때 메모리를 안전하게 정리하지 못하는 상황과 관련돼 있습니다.

CVE-2026-109618은 메모리 부족으로 작업이 중단될 때, 아직 준비가 끝나지 않은 내부 데이터를 정상 데이터처럼 취급할 수 있는 문제입니다. CVE-2026-109619는 요청이 끝나면서 메모리가 해제됐는데도 그 메모리를 가리키는 내부 상태가 남아, 같은 처리 프로세스의 다음 요청에 영향을 줄 수 있는 문제입니다.

쉽게 말하면, 서버가 요청 하나를 처리하다 실패한 뒤 정리하는 과정이나 다음 요청을 시작하는 과정에 빈틈이 생긴 것입니다. 공격자는 특수하게 구성한 요청으로 이 상황을 유도할 수 있습니다.

성공적인 악용은 서버 장애뿐 아니라 메모리 정보 노출이나 원격 코드 실행으로 이어질 수 있습니다. 원격 코드 실행은 외부에서 보낸 코드가 서버 안에서 실행되는 상황을 뜻합니다. 서버가 가진 권한과 접근 범위에 따라 홈페이지 변조나 정보 탈취 등으로 피해가 확대될 수 있습니다.

──────────────────
【 워드프레스만의 문제도, Windows만의 문제도 아닙니다 】

워드프레스 운영자가 이번 공지를 눈여겨봐야 하는 이유는 워드프레스가 PHP로 동작하기 때문입니다. 같은 이유로 Drupal, Joomla, MediaWiki 등 PHP를 사용하는 다른 서비스도 영향 여부를 확인해야 합니다.

Wiz 연구진은 워드프레스·Drupal·Joomla 환경에서 인증 없는 원격 코드 실행을 시연했다고 밝혔습니다. 이들 제품은 실제 영향을 설명하기 위한 사례이며, 해당 제품 목록에 없는 PHP 홈페이지라고 해서 안전하다는 뜻은 아닙니다.

서버 운영체제만으로도 안전 여부를 판단하기 어렵습니다. CERT-EU는 웹 요청을 처리하는 PHP 설치 환경을 폭넓게 위험 범위에 포함하고, PHP-FPM, Apache의 mod_php, php-cgi, FrankenPHP, LiteSpeed 등을 언급했습니다. 이 가운데 PHP 개발팀은 mod_php 구성을 특히 위험도가 높은 환경으로 보고 있습니다.

홈페이지에 파일 업로드 메뉴가 보이지 않는다는 이유로 대응을 건너뛰기도 어렵습니다. PHP는 일부 요청을 애플리케이션 코드가 실행되기 전에 처리합니다. 사이트 화면에서 제공하는 기능만으로 PHP 내부의 요청 처리 경로를 모두 판단할 수는 없습니다.

사이트 접속이 정상이라는 사실 역시 패치 여부를 알려주지는 않습니다. 보안 업데이트가 적용됐는지는 서버에서 실제 실행 중인 PHP와 공급업체의 수정 내역으로 확인해야 합니다.

──────────────────
【 수정된 PHP 버전은 무엇인가요? 】

PHP 개발팀이 10월 21일 공개한 수정 버전은 다음과 같습니다.

PHP 8.2 계열: 8.2.35
PHP 8.3 계열: 8.3.36
PHP 8.4 계열: 8.4.27
PHP 8.5 계열: 8.5.12

각 계열에서는 해당 수정 버전 이상으로 업데이트해야 합니다. 예를 들어 PHP 8.4를 사용한다면 8.4.27에 수정 사항이 들어 있으며, 이번 문제를 해결하기 위해 모든 사이트가 곧바로 8.5 계열로 전환해야 하는 것은 아닙니다.

PHP 8.1 이하의 오래된 환경은 지원 상태까지 함께 확인해야 합니다. 정규 보안 지원이 종료된 계열은 지원 중인 PHP로 이전하는 계획이 필요합니다. 다만 일부 Linux 배포판이나 장기지원 공급업체는 기존 패키지에 수정 사항을 별도로 반영하는 백포트 패치를 제공할 수 있습니다. CERT-EU는 PHP 7.4·8.0·8.1용 최소 소스 백포트도 안내했습니다. 오래된 버전이라고 모두 동일한 지원 상태인 것은 아닙니다.

따라서 버전 숫자가 낮아 보인다는 이유만으로 패치 미적용을 단정하기보다는, 해당 서버의 패키지를 공급하는 업체가 두 CVE의 수정 사항을 반영했는지 확인해야 합니다.

PHP 8.2 사용자는 이후 일정도 고려할 필요가 있습니다. PHP 공식 공지에 따르면 8.2 계열의 지원은 2026년 12월 31일 종료됩니다. 이번 패치를 적용한 뒤에도 지원 중인 상위 계열로 이전할 준비가 필요합니다.

──────────────────
【 AI는 취약점 발견에 어떻게 참여했나요? 】

이번 사건에서 AI는 보안 공지를 요약하는 역할보다 훨씬 깊은 단계에 참여했습니다.

OpenAI는 Calif가 ‘Patch the Planet’ 활동의 일환으로 GPT-5.6 Sol을 사용해 치명적인 결함을 발견했다고 밝혔습니다. Wiz 역시 두 취약점을 독립적으로 발견하고 보고했습니다. PHP 유지관리자들이 수정과 배포를 주도했고, 여러 연구기관과 인프라 업체가 연구·패치 검증·방어 준비를 지원했습니다.

Wiz는 연구에 Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol을 활용했다고 설명했습니다. Google Cloud도 Gemini 4 Argon이 취약점 발견, 악용 가능성 검증, 공격 탐지, 패치 검증에 기여했다고 발표했습니다. 어느 한 AI 서비스가 혼자 문제를 발견하고 해결한 형태와는 다릅니다.

오래된 코드에서 수상한 부분을 찾는 것과, 그 문제가 실제 서비스에서 어떤 피해를 낼 수 있는지 증명하는 것은 서로 다른 작업입니다. 특정 오류가 발생하는 조건을 찾고, 여러 요청과 메모리 상태의 관계를 분석하며, 수정 후에도 유사한 문제가 남는지 살펴봐야 합니다.

이번 연구는 AI가 이 복잡한 분석과 검증을 지원한 사례입니다. 동시에 방어 측이 활용하는 분석 능력을 공격자도 이용할 수 있다는 문제가 남습니다. OpenAI 역시 같은 AI 역량이 공격 도구와 악용 코드 개발을 빠르게 할 수 있다고 지적했습니다.

이에 따라 대응 과정에는 취약점 발견 이후의 협업도 포함됐습니다. 수정 코드를 만드는 동안 호스팅·클라우드·보안 업체가 방어 수단을 준비하고, 공개 이후에는 실제 운영 서버에 업데이트가 적용되도록 지원하는 방식입니다.

──────────────────
【 홈페이지 운영자는 누구에게 무엇을 확인해야 하나요? 】

웹호스팅을 이용하는 운영자라면 먼저 호스팅사에 PHP 보안 패치 적용 여부를 확인하는 것이 좋습니다. 홈페이지 제작업체가 서버까지 관리한다면 제작업체와 호스팅사 중 누가 PHP 업데이트를 담당하는지도 확인해야 합니다.

문의할 때는 “PHP 보안 문제 괜찮나요?”보다 확인 대상을 구체적으로 적는 편이 정확합니다.

“현재 제 사이트의 웹 요청을 처리하는 PHP에 CVE-2026-109618과 CVE-2026-109619 수정 사항이 적용됐는지 확인 부탁드립니다. 적용된 PHP 버전 또는 패키지 보안 패치 내역과 서비스 반영 여부도 알려주세요.”

공유 호스팅에서는 이용자가 PHP를 직접 설치하거나 서버 프로세스를 재시작할 수 없는 경우가 있습니다. 관리 화면에서 선택할 수 있는 PHP 계열만 바꾸면 되는지, 공급업체가 같은 계열에 패치를 적용했는지 안내를 받아야 합니다. Cloudflare 역시 PHP를 호스팅사가 관리하는 경우 해당 업체에 보안 업데이트 적용을 요청하도록 안내했습니다.

직접 서버나 클라우드를 운영한다면 실행 중인 서비스뿐 아니라 컨테이너 이미지와 재배포 경로도 확인해야 합니다. Google Cloud는 자체 컨테이너를 사용하는 서비스에 대해 패치된 PHP로 이미지를 다시 만들고 재배포하도록 안내합니다. 관리형 서비스도 자동 업데이트 설정과 실행 환경에 따라 필요한 조치가 달라집니다.

워드프레스 본체·테마·플러그인 업데이트는 계속 필요하지만, 이번 취약점의 수정 대상은 그 아래에서 실행되는 PHP입니다. 사이트 관리 화면의 “최신 버전” 표시와 서버의 PHP 보안 패치 적용 여부는 따로 확인해야 합니다.

──────────────────
【 WAF를 사용하거나 설정을 바꾸면 해결되나요? 】

웹 방화벽인 WAF는 패치를 적용하는 동안 위험을 줄이는 데 도움이 될 수 있습니다. 다만 PHP 코드에 있는 결함을 직접 수정하는 것은 아니므로, 방화벽을 사용한다는 이유로 업데이트를 생략할 수는 없습니다.

Cloudflare는 이번 취약점에 대응하는 WAF 보호 기능을 배포했고, 공격 시도와 방어 우회 목적의 요청 변형을 관측했다고 밝혔습니다. 또한 WAF 보호를 받는 고객에게도 PHP 패치를 적용하도록 권고했습니다.

온라인에서 언급되는 세션 업로드 진행 상태 기능 비활성화나 요청 크기 제한도 적용 범위가 있습니다. CERT-EU는 이런 조치가 특정 공격 경로의 노출을 줄일 수 있지만, 설치 환경 전체를 안전하게 만들지는 못한다고 설명합니다. 설정 하나를 바꾸는 방법을 완전한 해결책으로 받아들이기는 어렵습니다.

메모리 제한과 업로드 설정은 서비스의 자원 사용량과 정상 기능에도 영향을 줍니다. 공개된 설정값을 그대로 복사하기보다는 서버 관리자가 애플리케이션의 동작 조건과 공급업체 지침을 함께 검토해야 합니다.

즉시 패치가 불가능한 외부 공개 서비스에 대해서는 CERT-EU가 수정 적용과 검증이 끝날 때까지 공용 네트워크에서 격리하는 방안도 검토하도록 권고했습니다. 서비스 중단 여부는 운영 환경과 노출 범위를 바탕으로 판단할 사안입니다.

──────────────────
【 업데이트 후에는 적용 확인과 침해 점검이 남습니다 】

업데이트 파일을 내려받거나 패키지를 설치한 단계에서 대응이 끝나는 것은 아닙니다. 웹 요청을 처리하는 실행 환경에 수정된 PHP가 반영됐는지 확인해야 합니다. 컨테이너 환경에서는 새 이미지를 만들었더라도 기존 배포가 계속 동작하면 서비스 반영이 끝나지 않은 상태일 수 있습니다.

기존 서버가 이미 공격을 받았을 가능성에 대한 점검도 별도 작업입니다. 패치는 취약점의 재악용을 막는 조치이며, 이전에 발생한 침해를 되돌리는 기능은 아닙니다.

Wiz는 조사 단서로 비정상적인 multipart 요청 이후의 메모리 제한 오류나 반복적인 HTTP 500 응답, 설명하기 어려운 PHP 처리 프로세스의 반복 종료 등을 제시했습니다. 이런 현상만으로 침해를 확정할 수는 없지만, 요청 기록과 서버 상태를 함께 살펴볼 근거가 됩니다.

일반 방문자가 자신의 PC에서 PHP를 업데이트해 해결하는 유형의 문제는 아닙니다. 우선 대응 주체는 PHP로 웹사이트를 구동하는 서버의 운영자와 공급업체입니다.

홈페이지를 맡겨 운영하는 사업자라면 패치된 버전 또는 공급업체 수정 패키지가 실제 서비스에 반영됐는지 확인 기록을 받아두는 것이 실용적입니다. 직접 운영하는 서버라면 사용 중인 실행 환경과 배포 이미지까지 점검하고, 업데이트 이후 로그인·게시글 작성·파일 업로드처럼 주요 기능이 정상 동작하는지도 확인해야 합니다.​