AI가 발견한 PHP 취약점: ‘인터넷 70% 해킹’의 의미와 대응 방법

'인터넷 70% 해킹'이라는 표현에서 약 70%는 PHP 사용 비중을 가리킵니다. 인터넷의 70%가 실제로 해킹됐다는 피해 통계는 확인되지 않았어요. 이번 PHP 취약점에서 AI는 취약점을 찾고, 공격이 가능한지 확인하고, 대응을 돕는 데 쓰였습니다. AI가 인터넷 대부분을 공격해 장악했다는 뜻으로 읽으면 사건의 의미가 전혀 달라지죠.

그래서 운영자라면 자기 PHP 실행 환경에 패치가 적용됐는지부터 확인해야 합니다.

PHP를 쓴다는 사실만으로 침해 여부를 판단할 수는 없어요. 그렇다고 피해 통계가 없다는 이유로 대응을 미루는 것도 곤란합니다. 사용 중인 버전, 실행 구성, 패치 적용 여부를 차례로 살펴봐야 어떤 조치가 필요한지 판단할 수 있습니다.

'70%'는 사용률이지 침해율이 아닙니다

W3Techs가 제시한 2026년 10월 28일 PHP 사용률은 69.2%입니다. 여기서 흔히 놓치는 게 분모예요. 전체 인터넷이 아니라 '서버 측 프로그래밍 언어를 식별할 수 있는 웹사이트'가 기준이라서, 이 수치를 인터넷 기기나 트래픽, 해킹 피해 사이트의 비율로 바꿔 읽으면 안 됩니다.

피해 여부는 단계를 나눠서 봐야 합니다. PHP를 쓰는지에서 멈추지 말고 취약 버전인지, 공격 가능한 구성인지, 실제 침해가 발생했는지를 각각 확인해야 해요. Cloudflare가 관측한 공격 요청도 같은 방식으로 읽는 게 맞습니다. 공격 시도가 있었다는 사실만으로 서버에서 코드가 실행됐거나 정보가 유출됐다고 볼 수는 없으니까요.

두 PHP 취약점의 핵심 영향은 원격 코드 실행과 메모리 정보 노출입니다. 원격 코드 실행은 공격자가 원격으로 서버에서 자기 코드를 실행하는 상황을 뜻하고, 메모리 정보 노출은 PHP 프로세스가 가진 민감한 정보에 접근할 수 있게 되는 문제를 말해요.

발견 시점도 따로 떼어 볼 필요가 있습니다. PHP Foundation에 따르면 메모리 부족 문제의 초기 징후는 2024년에 알려졌지만, 당시에는 구체적인 공격 경로를 찾지 못했습니다. 이후 AI를 활용한 연구가 실제 공격 가능성을 구체화했고, 2026년 8월 11일 Calif의 원격 코드 실행 보고로 영향이 명확해졌어요. 수정과 배포는 PHP 유지관리자들이 맡았습니다.

버전보다 먼저, 누가 PHP를 업데이트하는지 확인하세요

가장 먼저 찾아야 할 사람은 PHP 업데이트 담당자입니다. 호스팅 업체가 관리하는 환경인지, 개발자가 서버를 직접 관리하는지에 따라 조치 경로가 갈려요. 담당자가 분명하지 않으면 버전을 확인해도 실제 패치 적용으로 이어지기 어렵습니다.

WordPress를 쓴다면 '도구 → 사이트 건강 → 정보 → 서버'에서 PHP 버전을 볼 수 있어요. 많이들 헷갈리는 부분이 여기인데, WordPress 업데이트와 PHP 업데이트는 별개입니다. WordPress 공식 공지도 이번 문제에는 PHP 자체를 업데이트해야 한다고 안내하고 있어요.

1. 호스팅 업체 또는 서버 관리 개발자에게 업데이트 담당 여부를 확인합니다.
2. 사용 중인 PHP 버전과 실행 구성을 확인하되, 특히 Apache의 mod_php 구성을 우선 점검합니다.
3. 담당자에게 수정 버전 적용 여부나 배포판의 백포트 패치 제공·적용 여부를 확인합니다.

10월 21일 공개된 수정 버전은 8.2.35·8.3.36·8.4.27·8.5.12입니다. 다만 버전 숫자만 보고 판단하면 안 돼요. 백포트는 기존 버전에 보안 수정 사항을 반영하는 방식이라, 숫자가 그대로여도 배포판의 패치 내역을 함께 확인해야 합니다.

mod_php를 우선 점검 대상으로 꼽는 이유는 애플리케이션 코드가 실행되기 전에 공격이 시연됐기 때문입니다. 다른 구성이라도 웹 요청을 처리한다면 PHP 공식 공지에 따라 점검해야 해요.

WAF를 켰더라도 패치와 후속 공지는 따로 확인하세요

웹 방화벽(WAF)은 패치 전까지 공격을 줄이기 위한 임시 방어 수단입니다. Cloudflare도 공격 요청의 변형을 관측했고, WAF를 쓰더라도 PHP 패치를 적용하라고 권고해요. 방화벽을 적용했는지와 PHP를 수정했는지를 따로 확인해야 대응이 끝났는지 판단할 수 있습니다.

당장 패치하기 어렵다면 서비스 중단의 영향과 외부 노출 위험을 함께 따져 봐야 해요. NHS 지침은 이런 위험 평가를 거쳐 패치 전까지 취약 시스템을 일시적으로 오프라인으로 전환하는 방안을 검토하도록 안내합니다.

10월 23일의 별도 취약점 설정 권고와 26일의 Brotli 취약점 수정을 위한 Windows 패키지 재빌드는 최초 두 취약점의 패치 실패와는 다른 사안이에요. 이 둘은 후속 공지에서 구분해 확인해야 합니다.