공격 어렵다던 PHP 결함… AI는 일주일 만에 길을 냈다

3주 간격의 독립 발견과 엠바고 전야 유출, 웹 70%를 긴장시킨 긴급 패치 24시간

나무 책상 위에 ‘PHP 보안 권고: 원격 코드 실행’ 문서가 놓여 있고, 빨간색으로 ‘심각한 패치’ 도장이 찍혀 있다.
AI 생성 이미지
핵심 요약 AI 요약
1
엔진 결함 악용:PHP2Shell은 메모리 부족 오류 뒤 남은 오염된 상태를 악용해 인증 없이 원격 코드를 실행할 수 있는 두 결함으로, 각각 CVSS 9.2점을 받았다.
2
AI의 공격 검증:프런티어 AI는 오래전부터 알려졌지만 공격이 어렵다고 여겨진 결함을 서버 환경에 맞는 공격 코드로 구현하는 작업을 도와, 연구원 한 명이 일주일 만에 공격을 검증할 수 있게 했다.
3
독립적인 결함 발견:Calif와 위즈는 약 3주 간격으로 AI를 활용해 결함을 독립적으로 규명했으며, 비공개 정보 유출 뒤 PHP 보안팀은 패치 배포를 하루 앞당겼다.
4
구버전 패치 공백:PHP 8.2부터 8.5까지는 최신 릴리스에서 수정됐지만, 공식 바이너리 배포가 종료된 8.1 이하 버전은 지원 버전으로의 이전이 필요하다.
5
국내 침해 미확인:국내 일부 매체가 사이트 접속을 차단하고 비정상적인 로그인 시도를 보고했으나, 해당 시도가 PHP2Shell 악용이었는지와 실제 침해 여부는 확인되지 않았다.
기사 목차 펼치기 / 접기

웹서버에서 동적 페이지를 생성하는 프로그래밍 언어 PHP 보안팀이 10월 21일 오후 11시(한국시간) 긴급 보안 패치를 배포했다. 발견된 두 건의 치명적 결함에는 ‘PHP2Shell’이라는 이름이 붙었다. 네덜란드 국가사이버보안센터(NCSC)는 공격 위험을 선제적으로 차단하기 위해 공식 웹사이트를 일시 폐쇄했다.

결함은 PHP 엔진 내부에서 10년 넘게 방치돼 있었다. AI가 이번에 한 일은 완전히 새로운 버그를 찾아낸 것이라기보다, 공격 난도가 지나치게 높아 실현 불가능하다고 여겨져 잊혔던 결함을 실제로 작동하는 정밀한 공격 코드로 탈바꿈시킨 것이다.

급하게 나간 손님의 식탁… PHP2Shell의 작동 메커니즘

PHP는 웹 요청을 받아 처리하는 일꾼 프로세스인 ‘워커(Worker)’가 요청을 하나씩 차례로 처리하는 구조다. 특정 요청을 처리하던 중 할당된 메모리 한도를 넘어서는 메모리 부족(OOM) 오류가 발생하면, PHP는 해당 요청의 실행을 강제로 중단한다. 치명적인 위험은 바로 이 지점에서 시작된다.

강제 종료된 요청이 사용하던 내부 데이터 구조체가 반쯤 초기화된 상태로 메모리에 방치되거나, 시스템에 이미 반납한 메모리 주소를 가리키는 포인터 값이 미처 정리되지 않고 남는다. 같은 워커 프로세스가 다음 요청을 받아 처리할 때 이 오염된 포인터를 다시 참조하면서, 이미 해제된 메모리 영역을 재사용하는 해제 후 재사용(Use-After-Free) 결함이 발생한다.

손님이 급히 나간 식탁을 치우지 않고 다음 손님을 앉힌 식당과 같다.

두 결함 모두 외부 공격자가 인증 없이 서버 시스템 전체의 제어권을 탈취할 수 있는 원격 코드 실행(RCE)으로 직결된다. PHP 보안팀은 공식 보안 권고에서 각각 ‘OOM 손상을 통한 원격 코드 실행'(CVE-2026-109618), ‘남은 전역 상태를 통한 원격 코드 실행'(CVE-2026-109619)으로 명명했다. 취약점 심각도를 평가하는 공통 취약점 점수 시스템(CVSS v4.0) 기준 위험도는 두 건 모두 10점 만점에 9.2점에 달하는 최고 위험군이다.

결함의 위치는 사용자가 작성한 웹 애플리케이션 코드보다 훨씬 앞단인 엔진 계층에 위치한다. PHP 보안팀은 로그인 절차를 거치지 않은 단순 HTTP 요청 하나만으로도 애플리케이션 코드가 실행되기 전에 엔진 레벨에서 침투가 가능하다는 점을 확인했다. 아파치(Apache) 웹서버 내부에 PHP 엔진을 모듈로 직접 결합하는 ‘mod_php’ 구동 환경이 가장 취약하다. 결함을 교차 검증한 클라우드 보안 기업 위즈(Wiz)는 단 한 줄의 “Hello World” 출력 스크립트만 구동되는 웹서버조차 공격에 노출될 수 있다고 경고했다.

PHP 버전패치 상태 및 대응 현황
8.5 · 8.4 · 8.3 · 8.28.5.12 · 8.4.27 · 8.3.36 · 8.2.35 최신 릴리스에서 수정 완료
8.1 · 8.0 · 7.4공식 바이너리 배포 종료. 보안팀이 최소한의 소스코드 백포트 패치만 제공
7.3 이하 레거시공식 업데이트 일체 없음 (전면 노출 위험)

AI가 바꾼 것은 발견보다 공격 가능성이었다

이러한 메모리 관리 결함의 존재 자체가 이번에 처음 알려진 것은 아니다. 보안 기업 Calif의 타이 두옹(Thai Duong) 최고경영자는 월스트리트저널 인터뷰에서 이러한 유형의 버그가 오래전부터 알려져 있었지만, “공격으로 실현하기에는 너무 어렵다(too difficult to exploit)”는 이유로 보안 업계에서 사실상 방치돼 왔다고 설명했다.

실제 공격이 극도로 어려웠던 까닭은 성립 조건이 까다로웠기 때문이다. 메모리가 정확히 어느 실행 시점에 고갈돼야 하는지, 그 순간 메모리 힙 블록이 어떻게 배치돼 있는지, PHP의 부버전마다 내부 바이너리 구조가 어떻게 달라지는지를 모두 사전에 수학적으로 계산해 맞춰야 했다. 위즈는 기술 분석 보고서에서 대규모 언어 모델(LLM)이 공격 코드를 PHP 버전과 개별 서버 설정, 동적 메모리 구조에 맞게 실시간으로 재구성하는 난제를 해결했다고 분석했다.

건물마다 제각각인 배관 도면을 대신 맞춰 주는 AI 조수가 생겼다.

위즈는 최첨단 AI 모델을 가리키는 ‘프런티어 AI’의 역할을 다음과 같이 규정했다.

“프런티어 AI 모델이 기술적 진입 장벽을 대폭 낮추면서, 오랫동안 잠들어 있던 결함이 실제 작동하는 공격 코드로 탈바꿈했다.”

위즈에 따르면 단 한 명의 연구원이 일주일 만에 완수한 공격 검증 작업은, 프런티어 모델의 보조가 없었다면 세계 최고 수준의 취약점 분석 연구팀이 수개월 동안 매달려야 했던 분량이다. 다만 표적을 지정하고 생성된 결과의 정합성을 검증해 PHP 개발팀에 전달한 주체는 사람이었으며, 사람의 개입이 전혀 없는 완전 자율 공격은 아니었다.

3주 간격으로 같은 결함에 도달한 두 연구팀

결함은 완전히 서로 다른 두 팀에 의해 독립적으로 규명됐다. Calif는 지난 8월 1일 오픈AI(OpenAI)의 GPT-5.6 솔(Sol)을 활용해 첫 번째 결함을 포착했다. 오픈AI가 비용을 지원한 PHP 소스코드 보안 감사 프로젝트에서 Calif의 라이언 오스틴(Ryan Austin) 연구원은 정교하게 설계된 수십 개의 HTTP 요청만으로 서버 메모리 내부의 명령 흐름을 원격 제어하는 기법을 입증했다.

이후 약 3주가 지난 8월 19일 위즈 연구팀 역시 자체 분석 도구 Wiz Atlas와 구글(Google) 제미나이(Gemini) 4 아르곤, 오픈AI GPT-5.6 솔을 병용해 동일한 결함을 독자적으로 재발견했다. 위즈는 드루팔(Drupal)과 워드프레스(WordPress) 환경에서 인증 없는 원격 코드 실행을 실증하고 8월 24일 PHP 보안팀에 제보했다.

PHP2Shell 발견부터 긴급 배포까지 3대 분기점
위즈(Wiz) 일지 및 WSJ 종합
최초 발견
8월 1일 · Calif
GPT-5.6 솔
오픈AI 후원 코드 감사 중 라이언 오스틴 연구원이 OOM 메모리 조작을 통한 RCE 가능성을 최초 포착함.
독립 교차
8월 19일 · 위즈(Wiz)
제미나이 4 아르곤
자체 Atlas 도구와 복수 프런티어 모델을 결합해 드루팔·워드프레스에서 무인증 RCE 재현에 성공함.
긴급 배포
10월 21일 · PHP팀
CVSS 9.2 패치
20일 해커뉴스 유출 사태 직후 배포 일정을 24시간 앞당겨 긴급 릴리스 단행, 각국 정부망 선제 방어함.
[핵심 시사점] 방어 진영 연구팀 둘이 3주 만에 동일 결함에 도달했다면 공격자 역시 같은 AI 도구로 재현 가능함을 뜻하므로, 취약점 독점 유예 시간이 사실상 소멸했음에 유의해야 함.

같은 지도를 쥔 탐험대 둘이 3주 차이로 같은 동굴 앞에 섰다.

보안을 연구하는 두 팀이 3주 만에 같은 결함에 도달했다면, 동일한 성능의 도구를 쥔 악의적 공격자 역시 얼마든지 같은 지점에 도달할 수 있다. 한 해커가 숨겨 둔 버그를 AI 모델을 사용한 다른 연구자가 수 시간 만에 다시 찾아냈던 사례처럼, 취약점을 특정 주체만 홀로 쥐고 있을 수 있는 독점 시간은 급격히 소멸하고 있다. 이번에는 그 현상이 전 세계 웹 인프라 전반에서 벌어졌다.

엠바고 전야의 해커뉴스 유출… 패치 코드가 곧 공격 설계도로

당초 보안 업계와 합의된 공식 취약점 공개 일정은 10월 22일이었다. 그러나 10월 20일(현지시간) 유명 기술 커뮤니티 해커뉴스(Hacker News)에 취약점 식별 번호와 공개 일자가 포함된 비공개 정보가 유출됐고, 보안 기업 워치타워(watchTowr)가 해당 정보의 진위를 공식 확인했다. PHP 보안팀은 같은 날 오후 7시 33분(협정 세계시) 긴급 사전 공지를 올리고 공식 패치 배포일을 21일로 24시간 앞당겼다.

패치가 완성돼 배포될 때까지 결함의 세부 내용을 공개하지 않기로 약속한 ‘보안 엠바고’가 하루 먼저 깨진 것이다. 타이 두옹 CEO는 당시의 긴박한 위험을 경고했다.

“누군가 공개된 패치 코드를 가져다 AI 모델에 넣고 공격 스크립트를 만들어 유포하면, 그 즉시 통제 불능의 아수라장이 된다.”

공개된 패치 코드는 어떤 부분을 수선했는지 정확히 드러낸다.

금고를 고친다는 안내문이 도둑에게는 가장 정확한 침투 지도가 됐다.

클라우드플레어(Cloudflare)의 데인 넥트(Dane Knecht) 최고기술책임자는 포춘 인터뷰에서 패치 직후부터 초기 공격 징후가 감지되고 있다고 밝혔다.

각국 주요 기관은 사이트 폐쇄로 대응했다. 네덜란드 NCSC와 로테르담항, 공공 서비스 포털 Overheid.nl, 핀란드 정부 서비스, 프랑스 내무부 웹사이트가 접속을 일시 차단했다. 미국 연방수사국(FBI)과 국가안보국(NSA), 유럽연합 컴퓨터비상대응팀(CERT-EU)이 즉각적인 패치 적용을 강력히 권고했다.

패치 전야 웹사이트를 차단한 국내 인터넷 언론사들

국내에서도 인터넷 언론사 일부가 선제 방어에 나섰다. 한 인터넷신문 관계자는 10월 20일부터 비정상적인 로그인 공격 시도가 감지됐다고 전했다. 해당 매체는 국내 다수 언론사가 채택하고 있는 기사관리시스템(CMS)을 사용 중이다. 동일한 CMS를 사용하는 일부 매체는 사이트 접속을 선제적으로 차단했다. 관계자는 매체명이 알려질 경우 추가 표적 공격을 받을 수 있다며 익명을 요청했다.

도둑이 들었는지 확인하기도 전에 일단 문부터 걸어 잠갔다.

해당 공격이 PHP2Shell 결함을 악용한 것이었는지, 실제 서버 침해가 발생했는지는 공식 확인되지 않았다. 다만 공격 시점이 해커뉴스 유출일과 정확히 겹치며, 해당 CMS가 PHP 기반으로 구동된다는 정황이 있다. PHP2Shell 공격은 인증을 요구하지 않지만, 공격 요청이 로그인 화면과 같은 입력 폼으로 유입되면 시스템 관리자에게는 통상적인 로그인 대입 공격으로 관측될 수 있다.

한국인터넷진흥원(KISA)은 10월 21일 PHP 보안 긴급 권고를 발표했다. 안랩은 취약한 PHP 버전을 구동 중인 국내 서버 규모를 약 11만대로 추산했다. 보안 기업 티오리의 박세준 대표는 국내에 여전히 PHP 5와 7 기반의 그누보드 게시판과 레거시 쇼핑몰이 광범위하게 잔존해 있어 심각한 피해가 우려된다고 경고했다.

프런티어 AI와 보안의 미래… 엠바고가 무너진 시대의 방어

이번 사태에서 방어 진영은 한 발 앞섰다. 오픈AI는 공식 발표를 통해 프런티어 AI 모델이 악의적 공격자보다 먼저 결함을 식별했다고 밝혔다. 두 달 동안 PHP 보안팀과 연구진, 보안 기업들이 공조하여 200여 개 파일과 1만 줄이 넘는 코드를 개편하는 방대한 패치를 완성했다. 클라우드플레어는 무료 고객을 포함한 전체 도메인에 가상 방화벽 규칙을 즉시 배포했다.

경찰과 도둑이 같은 망원경을 쥐었고, 이번에는 경찰이 먼저 봤다.

그러나 방어자의 우위는 엠바고가 유지되는 동안에만 유효했다. 유출 사태로 인해 대응 일정은 급박하게 당겨졌고, 최신 패치를 적용할 수 없는 레거시 서버도 다수 방치돼 있다. 웹 기술 분석 플랫폼 W3Techs의 실측 집계 결과, 전 세계 PHP 기반 웹사이트의 34.7%는 공식 보안 패치가 중단된 7.x 이하 레거시 버전에 머물러 있다.

시장 일각의 ‘전 세계 웹사이트 70% 위험’이라는 표현도 실체를 분별할 필요가 있다. W3Techs 기준 서버 프로그래밍 언어가 확인된 웹사이트 중 PHP의 점유율이 69.3%인 것은 사실이나, PHP를 사용하는 모든 사이트가 취약점에 노출된 것은 아니다. 글로벌 관리형 호스팅을 운영하는 오토매틱(Automattic)의 워드프레스닷컴과 텀블러(Tumblr) 등 주요 클라우드 플랫폼은 취약한 구성 요소를 사용하지 않아 안전한 것으로 확인됐다.

국내 웹 환경을 두드린 위협의 실체가 PHP2Shell이었는지는 아직 조사 중이다. 다만 방어 패치가 공식 배포되기 전날 밤, 서버의 전원을 내리고 문을 닫아야 했던 사이트들이 존재했다는 사실은 AI 시대 보안 방어선이 얼마나 가파른 속도전에 직면해 있는지를 생생하게 보여 준다.

AI가 촉발한 취약점의 속도전 앞에서, 이제 영원한 안전지대는 없다.

자주 묻는 질문 (FAQ)
Q. 운영 중인 웹서버가 PHP2Shell 결함에 취약한지 어떻게 확인하나?
A.서버의 구동 PHP 버전부터 점검해야 한다. 8.5.12, 8.4.27, 8.3.36, 8.2.35 이상 릴리스라면 취약점 수정이 완료된 상태다. CMS 소프트웨어 업데이트와 PHP 런타임 업데이트는 별개이므로, 워드프레스나 그누보드가 최신 버전이더라도 하부 PHP 엔진이 구버전이면 침투 위험에 그대로 노출된다. 8.1 이하 버전을 사용 중이라면 지원 버전으로 신속히 마이그레이션해야 한다.
Q. 최신 버전으로 즉시 패치할 수 없다면 어떤 임시 조치를 취해야 하나?
A.PHP 보안팀은 설정 파일(php.ini)에서 session.upload_progress.enabled = 0으로 비활성화하고 모든 워커 프로세스를 재시작하는 우회 완화책을 제시했다. 다만 이는 임시방편일 뿐 완전한 방어책이 아니므로 가상 패치나 웹 방화벽(WAF) 규칙 적용을 병행하고 조속히 공식 패치를 단행해야 한다.
Q. 워드프레스닷컴 등 클라우드 관리형 호스팅 서비스도 위험한가?
A.오토매틱이 운영하는 워드프레스닷컴과 텀블러 등 대규모 관리형 서비스는 결함 유발 구성(mod_php 등)을 쓰지 않거나 선제적인 런타임 보호 조치가 완료되어 안전한 것으로 확인됐다. 실제 위험도가 높은 환경은 사용자가 서버 설정을 직접 관리하지 못하는 저가형 공유 웹호스팅이나 보안 지원이 중단된 자체 구축 서버다.

RELATED ARTICLES

RECOMMENDED STORIES