AI가 오래 묻힌 PHP 허점을 공격 도구로 바꿨다, 사이트를 지킨 건 업데이트였다

워드프레스로 홈페이지를 띄워 두고 상담 신청과 결제를 받는 분이라면, 플러그인 업데이트 알림은 챙겨도 그 아래에서 사이트를 돌리는 PHP 버전까지 확인하는 일은 드뭅니다. 호스팅 회사가 알아서 해 주겠거니 하고 넘어가지요. 그런데 10월 21일, 바로 그 PHP 자체에서 로그인 없이 남의 서버에서 코드를 실행할 수 있는 허점 두 개가 공개됐고, 공개 전날부터 공격용 시연 코드가 돌기 시작했습니다.

내 코드에 문제가 없어도 PHP 엔진이 뚫리면 사이트가 넘어갑니다

PHP 프로젝트는 이날 PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35를 내놓으며 모든 사용자에게 즉시 업데이트하라고 공지했습니다. 고친 허점은 두 가지입니다. 하나는 요청이 PHP의 메모리 한도에 하필 나쁜 순간에 닿으면 덜 만들어진 내부 데이터를 정상으로 착각해 메모리가 망가지는 문제이고, 다른 하나는 치명적 오류가 난 뒤 이전 요청이 쓰던 메모리를 다음 요청이 그대로 집어 쓰는 문제입니다. 둘 다 거의 모든 요청이 지나가는 메모리 관리와 오류 처리 부분에 있습니다.

이 허점을 찾은 보안 회사 Wiz는 PHP가 전 세계 웹사이트의 70%를 움직인다고 소개하며, 최신 워드프레스·드루팔·줌라 컨테이너 이미지에서 로그인 없이 원격으로 코드를 실행하는 데 성공했다고 밝혔습니다. 중요한 대목은 공격이 앱의 코드 실수에 기대지 않는다는 점입니다. Wiz는 간단한 ‘Hello World’ 앱도 영향받는 PHP 버전 위에서는 취약할 수 있다고 적었고, 코드 실행까지 가지 않아도 PHP 프로세스 메모리에서 비밀번호·토큰·API 키를 읽어 낼 수 있음을 따로 보였습니다. 플러그인을 아무리 깔끔하게 관리해도 바닥의 엔진이 낡았으면 소용없다는 뜻입니다. 심각도 점수는 CVSS 9.2로 매겨졌습니다.

오래 묻혀 있던 허점을 공격 가능한 무기로 바꾼 것은 AI였습니다

이 문제는 갑자기 생긴 것이 아닙니다. PHP 재단에 따르면 2024년 몇 년 만의 첫 외부 보안 감사 과정에서 재단 소속 개발자가 메모리 한도 문제의 첫 징후를 발견했습니다. 그때도 공격 가능성은 이론으로 거론됐지만 구체적인 공격 경로는 찾지 못했고, 고치는 방법마다 호환성이 깨지거나 수많은 외부 확장 기능을 바꿔야 하는 부담이 있어 작업이 몇 달씩 멈췄다 다시 시작되기를 반복했습니다. 재단은 이 지연을 두고 결정 방식과 인력 부족이 만든 구조적 실패였다고 스스로 인정했습니다.

상황을 바꾼 것은 AI를 쓴 보안 연구였습니다. 8월 11일 보안 회사 Calif의 연구자와 OpenAI가 같은 날 각각 같은 근본 원인을 보고했고, 8월 24일에는 Wiz가 다른 공격 경로를 보고했습니다. Wiz는 이 허점이 아주 오래 코드 속에 있었지만 실제 공격으로 만들려면 여러 버그를 엮고 서버마다 다른 메모리 배치에 맞춰 시험과 수정을 반복해야 해서 사람 연구자가 현실적으로 해낼 수 있는 한계에 가까웠다고 설명합니다. 최신 AI 모델이 그 장벽을 크게 낮춰, 여러 앱에 맞는 공격 코드를 몇 시간 만에 만들고 고칠 수 있었다는 것입니다. 이 말은 거꾸로 읽어야 합니다. ‘너무 복잡해서 아무도 못 쓸 허점’이라는 안전장치가 이제는 잘 통하지 않는다는 뜻입니다.

제보는 폭증했고, 비밀 유지는 공개 이틀 전에 무너졌습니다

AI는 지키는 쪽의 일도 늘렸습니다. PHP 재단은 7월 1일 이후 보안 취약점 번호를 15건 발표했고, 그 사이 무효이거나 중복이거나 재현되지 않는 제보를 100건 넘게 처리했다고 밝혔습니다. AI가 제보를 검증하고 같은 원인끼리 묶는 데 도움을 주지만, 모든 판단과 패치는 사람이 맡는다고 덧붙였습니다. 도구는 버그를 빨리 찾아도 오래된 설계를 어떻게 고칠지 정하고 패치를 검토하는 일은 엔진 전체를 아는 소수의 개발자에게 몰려 있습니다.

공개 과정도 매끄럽지 않았습니다. 원래 발표 예정일 이틀 전인 10월 20일, 취약점 번호가 틀린 공개 시각과 틀린 점수 10.0을 달고 온라인에 퍼졌습니다. PHP 프로젝트는 출시를 하루 앞당겼고, 그 직후 제보 회사 한 곳이 실수로 시연 영상을 올렸다가 지웠지만 복사본이 퍼지면서 공격 코드 개발이 빨라졌습니다. 출시 몇 시간 전에는 패치를 미리 받은 배포사 한 곳이 약속을 깨고 수정본을 먼저 내놓기도 했습니다. 재단은 공개 시점까지 실제로 작동하는 공격 코드는 확인하지 못했다고 했지만, 고친 내용이 공개된 지금부터는 패치를 거꾸로 분석한 공격이 나올 시간이 시작된 셈입니다.

사장님이 할 일은 버전 확인과 업데이트, 그리고 호스팅에 묻기입니다

PHP 프로젝트의 안내는 분명합니다. 위험한 대상은 웹 요청을 처리하는 모든 PHP 설치이며 PHP-FPM, 아파치 mod_php, LiteSpeed 등이 모두 포함되고, 그중에서도 mod_php를 가장 위험하게 봅니다. 해결책은 고친 버전으로 올리는 것 하나이고, 설정을 바꾸는 임시 방법은 일부 공격 경로만 줄일 뿐 설치를 안전하게 만들지는 못한다고 못 박았습니다. PHP 8.1과 그 이전 버전은 더 이상 공식 업데이트를 받지 못하므로, 오래된 호스팅 상품을 쓰고 있다면 지원되는 버전으로 옮기는 일이 먼저입니다.

직접 서버를 관리하지 않는 분도 할 일은 있습니다. 워드프레스 관리자 화면의 사이트 상태 메뉴에서 PHP 버전을 확인하고, 호스팅 회사에 10월 21일 보안 업데이트가 적용됐는지 묻는 것만으로도 충분히 의미가 있습니다. 여러 사이트를 운영한다면 버전과 담당자를 한 장에 적어 두는 습관이 이번 같은 일에서 몇 시간을 아껴 줍니다. 다만 이 사건의 세부 숫자는 발견한 회사와 PHP 재단이 공개 당일 밝힌 내용이고, 실제 피해 규모는 아직 알려지지 않았습니다.

AI가 복잡한 허점을 공격 도구로 바꾸는 시간이 짧아질수록, 내 사이트를 지키는 가장 확실한 방법은 빠른 업데이트입니다.