AI가 찾은 PHP 취약점, 왜 고치는 데 2년이 걸렸을까?
송찬우 10분 분량
10월 21일(미국 시간) PHP가 8.5.12, 8.4.27, 8.3.36, 8.2.35를 한꺼번에 내놓았습니다. 로그인 없이 서버에서 코드를 실행할 수 있는 취약점 2건(CVE-2026‑109618, CVE-2026‑109619)을 고친 보안 업데이트입니다. 위험도 점수(CVSS)는 9.2점이에요. 이 취약점을 찾은 보안 업체들은 둘을 묶어 PHP2Shell이라고 부릅니다. 해커뉴스에서는 PHP 8.2.35 릴리스 글이 1,077점, 댓글 558개를 받았고, 한국에서도 과학기술정보통신부가 10월 22일 12시부로 민간 분야 사이버위기 경보를 ‘관심’에서 ‘주의’로 올렸습니다.
이번 취약점은 AI가 찾았다는 이야기로 널리 알려졌습니다. 그런데 PHP 재단의 글을 읽어 보면 같은 문제의 첫 신호는 2024년에 이미 나왔어요. AI가 찾은 버그를 왜 2년 가까이 고치지 못했을까요? PHP 재단, 보안 업체 Calif와 Wiz, OpenAI, Amazon이 낸 글을 함께 뜯어 봤습니다.
결론부터 말하면, 찾는 일은 AI로 빨라졌지만 고치는 일은 여전히 사람의 몫이었습니다.
문제의 뿌리는 메모리 부족(OOM) 처리입니다. 요청이 PHP 메모리 한도(memory_limit)에 하필 나쁜 순간에 닿으면, 반쯤 만들어진 내부 데이터가 남고 PHP가 나중에 이걸 정상 데이터로 다루면서 메모리가 망가집니다. 두 번째 취약점은 치명적 오류가 난 뒤에도 이전 요청의 메모리를 가리키는 내부 상태가 남아, 같은 작업 프로세스가 처리하는 다음 요청이 이미 해제된 메모리를 쓰는 문제예요. Apache와 mod_php 조합에서는 애플리케이션 코드가 돌기도 전에, 로그인 없는 요청 하나로 공격이 시작될 수 있습니다.
두 문제 모두 메모리 관리와 오류 처리처럼 거의 모든 요청이 지나가는 곳에 있습니다. PHP 재단은 바로 그래서 위험했고, 호환성을 깨거나 성능을 떨어뜨리지 않고 고치기도 어려웠다고 설명했습니다.
첫 신호는 2024년에 나왔습니다.
2024년 PHP는 독일 Sovereign Tech Agency의 지원으로 오랜만에 외부 보안 감사를 받았습니다. 감사에서 나온 다른 문제를 고치던 PHP 코어 개발자가 이 OOM 문제의 첫 신호를 찾았어요. 다만 실제 공격으로 이어지는 경로는 찾지 못했고, 영향이 더 분명한 다른 문제들에 밀렸습니다.
보안팀은 고칠 방법을 여러 개 만들었지만 모두 대가가 있었습니다. 하위 호환성이 깨지거나, 새로운 서비스 거부 공격의 여지가 생기거나, 수많은 서드파티 확장 모듈을 함께 고쳐야 했어요. 합의로 움직이는 보안팀은 어느 쪽도 고르지 못했고, 엔진을 깊이 아는 소수의 코어 개발자는 다른 일로 바빴습니다. 수정 작업은 몇 달씩 멈췄다가 다시 시작하기를 반복했습니다. PHP 재단은 이 지연을 보안팀의 의사 결정 방식과 자원 부족이 만든 “구조적 실패”라고 직접 밝혔습니다.
Calif가 정리한 계보는 더 깁니다. 2004년 보안 연구자 Stefan Esser가 PHP 메모리 한도를 이용한 원격 취약점을 처음 찾았고, 2020년에는 긴 변수가 메모리 부족을 일으킨다는 버그 리포트(#78876)가 올라왔지만 크게 다뤄지지 않았어요.
AI는 2026년 8월에 이 버그를 다시 꺼냈습니다.
OpenAI는 오픈소스 보안 지원 프로그램 Patch the Planet에 Calif를 초대했고, Calif는 7월 30일 PHP 감사를 시작했습니다. OpenAI에 따르면 Calif는 GPT-5.6 Sol을 썼어요. 8월 11일 Calif의 연구원 Ryan Austin이 2024년의 OOM 문제와 뿌리가 같은 원격 코드 실행을 PHP에 보고했고, OpenAI도 같은 원인을 따로 보고했습니다. 이어 8월 24일 Wiz가, 9월 18일 OpenAI가 공격 경로를 더 보고했습니다.
Wiz는 자체 도구 Wiz Atlas와 Gemini 4 Argon, GPT-5.6 Sol을 썼고, 그중 Gemini 4 Argon이 취약점 발견과 수정 검증에 특히 크게 기여했다고 밝혔습니다. Wiz는 연구원 한 명이 프런티어 AI와 함께 일주일 만에, 예전 같으면 세계 최고 수준의 팀이 몇 달 걸렸을 일을 끝냈다고 썼어요. PHP 재단도 올해 Alpha-Omega와 함께 Anthropic의 Claude Mythos로 PHP를 훑었고, 지금은 OpenAI의 Daybreak Red로 보고와 공격 코드를 검증한다고 밝혔습니다.
흥미로운 건 Calif의 설명입니다. 처음 버그를 찾을 때 특별한 도구나 일반에 공개되지 않은 모델은 쓰지 않았다고 합니다. 대신 PHP의 20년 된 취약점 역사를 알고 있었기에 그 방향으로 질문할 수 있었다고 해요. Calif는 AI 모델이 스스로는 최근의 유명한 버그부터 살피고, 20년 된 낡은 공격 기법에서 출발하지는 않는다고 적었습니다. 모델이 빨라도, 어디를 파야 하는지는 그 분야를 아는 사람이 정했습니다.
고치는 일은 사람이 주말도 없이 했습니다.
8월 11일 이후 이 버그는 PHP 재단 보안 인력 모두의 최우선 과제가 됐습니다. 재단 지원으로 여러 명이 전업으로 붙었고, 주말과 밤낮 없이 일했다고 해요. 그래도 첫 보고부터 수정 릴리스까지 약 70일이 걸렸습니다. 지원 중인 모든 버전에 맞춘 수정을 만들고, 리눅스 배포판과 장기 지원 업체에 미리 패치를 넘기는 데까지 걸린 시간입니다.
AI는 이 일을 돕기도 했고 늘리기도 했습니다. PHP 보안팀은 7월 1일 이후 CVE 15건을 냈고, 무효, 중복, 재현 불가로 판명된 보고 100건 이상을 처리했어요. AI가 보고를 검증하고 같은 원인의 보고를 묶는 걸 돕지만, 판단과 패치는 모두 사람이 한다고 재단은 밝혔습니다.
공개 나흘 전에 이미 공격 시도가 있었습니다.
원래 계획은 10월 22일 14:00 UTC 공개였습니다. 그런데 10월 20일 15:00 UTC쯤 두 CVE 번호가 해커뉴스와 SNS에 먼저 돌았어요. 틀린 공개 시각과 틀린 점수 10.0까지 함께였습니다. PHP는 공개를 10월 21일 14:00 UTC로 하루 당겼습니다. 그 사이 Calif가 공격 시연 영상을 실수로 올렸다가 지웠고, 10월 21일 07:41 UTC에는 Chainguard가 공개 6시간여 전에 수정된 이미지를 먼저 배포했습니다. 재단은 이를 엠바고(공개 유예 약속)를 혼자 깬 일이라고 비판했어요.
Amazon의 발표는 더 무겁습니다. Amazon 위협 인텔리전스는 공격자를 끌어들이려 만든 미끼 서버(허니팟) MadPot에서 10월 17일, 그러니까 공개 나흘 전의 PHP2Shell 공격 시도를 찾았다고 밝혔습니다. 익명화 네트워크에서 온 공격이었고, 공격자가 어떻게 미리 정보를 얻었는지는 모른다고 했어요. 공개 당일에도 엠바고가 풀리기 전부터 여러 공격자의 시도가 이어졌습니다.
패치가 나온 뒤에는 몇 시간 만에 새 공격 코드가 나와 바로 쓰였습니다. Amazon은 AI 덕분에 패치 차이(diff)나 권고문을 공격 코드로 바꾸는 비용이 싸졌다며, 인터넷에 열린 시스템의 심각한 취약점은 패치 기한을 7일, 30일이 아니라 시간 단위로 잡아야 한다고 했습니다. 지난번 ‘OpenCode Console 해킹, 코딩 에이전트에 맡긴 API 키는 안전할까?’에서 소개했던, 공격하는 쪽이 AI 에이전트를 쉬지 않고 돌리는 바로 그 흐름입니다.
그렇다고 공격 코드가 쉬운 건 아닙니다.
반대 의견도 있습니다. 개발자 Elias Taylor는 ‘There isn’t an easy exploit for this PHP vulnerability’라는 글에서, 깃허브에 올라온 수천 개의 공격 시험 코드(PoC) 대부분이 평범한 PHP 서버에서는 돌지 않는다고 주장했습니다. 상당수가 서버에 이미 파일 포함(LFI) 같은 다른 취약점이 있어야 동작한다는 겁니다. 그는 사람들이 LLM이 만든 가짜 공격 코드를 믿고 있다고 꼬집었고, 이 글도 해커뉴스에서 609점, 댓글 439개를 받았어요. 과기정통부도 인터넷에 도는 공격 시험 코드 가운데 악성코드가 숨은 가짜가 많다고 경고했습니다.
다만 Calif와 Wiz는 워드프레스, 드루팔, 줌라에서 로그인 없는 원격 코드 실행을 직접 시연했습니다. 쉽지 않다는 것과 불가능하다는 건 다른 이야기입니다.
한국에서는 관리 목록에서 빠진 서버가 먼저입니다.
과기정통부와 KISA는 워드프레스, 그누보드처럼 국내에서 많이 쓰는 누리집 도구도 PHP로 돈다며 즉시 업데이트를 당부했습니다. 특히 오래전에 만들어 두고 관리하지 않는 누리집, 외주로 만든 쇼핑몰, 장비 관리 화면에도 PHP가 숨어 있을 수 있다고 했어요. PHP 8.1 이하는 공식 업데이트가 없어서 지원되는 버전으로 올려야 하고, 업데이트 뒤에는 웹 서비스를 재시작해야 적용됩니다. 배경훈 부총리 겸 과기정통부 장관은 “수동 점검 후 수일 내 패치라는 통상적 취약점 관리 주기로는 공격을 방어할 수 없다”고 말했습니다.
FDE로 고객사 시스템을 만지다 보면 이 말이 와닿습니다. 새로 만든 서비스는 배포 파이프라인이 있어 하루 안에 올릴 수 있지만, 몇 년 전 외주로 만든 이벤트 페이지나 관리자 화면은 누가 관리하는지조차 모르는 경우가 많아요. AI가 취약점을 찾고 공격 코드를 만드는 속도가 빨라질수록, 먼저 필요한 건 회사 안에 PHP가 어디에서 어떤 버전으로 돌고 있는지 아는 일입니다.
찾는 속도와 고치는 속도의 차이는 더 벌어질 겁니다.
OpenAI는 이번 버그가 이미 찾아서 고치고 있는 여러 심각한 취약점 가운데 일부일 뿐이라며, 앞으로 몇 달 동안 비슷한 발견이 급증할 것이라고 밝혔습니다. 방어자를 위해 Daybreak 이용에 10억 달러(약 1조 3천억 원) 규모의 보조금도 약속했어요. PHP 재단은 사람을 이야기합니다. 도구는 그 어느 때보다 빨리 버그를 찾지만, 엔진의 오래된 설계를 어떻게 고칠지 정하고 호환성을 따지고 패치를 검토하는 건 PHP 코드 전체를 아는 엔지니어의 일이고, 그런 사람이 너무 적다는 겁니다.
AI가 버그를 찾는 속도는 계속 빨라질 듯싶습니다. 그 차이를 메우는 건 결국 고칠 수 있는 사람과, 고친 것을 몇 시간 안에 올릴 수 있는 운영 체계일 것 같습니다.