결함은 10년을 묵었고, 패치는 500번 빌드되었다

AI 오디오북결함은 10년을 묵었고, 패치는 500번 빌드되었다

0:00

0:00

2026년 10월 21일, 그리니치표준시 기준 오후 2시. PHP 개발팀이 8.5.12, 8.4.27, 8.3.36, 8.2.35 네 개의 버전을 동시에 내놓습니다. 인증 없이 서버 명령을 실행할 수 있는 결함 두 건, 위험도 9.2. 이름은 PHP2Shell이었죠.

그로부터 몇 시간 안에 네덜란드 정부 포털 MijnOverheid가 내려갔고, 영국에서는 정부 서비스 32개가 오프라인이 됐습니다. 핀란드 행정 IT 기관 발토리가 공공 네트워크 서비스를 멈췄고, 로테르담 항구와 헤이그 의사당 홈페이지도 함께 사라졌습니다. 일본에서는 ANA와 노무라증권, 미쓰비시UFJ가 일부 서비스를 멈췄죠.

사람들이 세는 숫자는 공격이었습니다. 클라우드플레어의 매슈 프린스는 공개 전 10시간 동안 수천 건이던 시도가 45분 만에 수만 건, 두 시간 만에 수십만 건, 그날 저녁에는 수백만 건이 됐다고 적었습니다. 70퍼센트라는 숫자도 함께 돌았습니다. 전 세계 웹사이트의 그만큼이 PHP로 돌아간다는 겁니다.

그런데 그날 인터넷을 실제로 붙잡아 둔 것은 공격 카운터가 아니었습니다.

마지막 1킬로미터

패키지였습니다.

PHP 재단이 내놓는 것은 소스 코드입니다. 서버에서 실제로 도는 것은 그것을 컴파일하고, 서명하고, 배포판에 맞게 묶은 물건이죠. 그 사이에는 이름이 잘 붙지 않는 노동이 있습니다. 컴파일할 줄 모르는 운영자에게는 이 계층이 있어야 패치가 적용됩니다.

체코의 Ondřej Surý가 그 일을 합니다. 2000년부터 데비안 개발자였고, PHP 5 시절부터 데비안과 우분투용 PHP 패키지를 만들어 왔습니다. 본업은 Internet Systems Consortium(ISC)의 DNS 엔지니어링 디렉터입니다. PHP 재단에서 월급을 받는 사람이 아니죠.

10월 21일, 그의 저장소 packages.sury.org와 우분투 PPA에는 PHP 5.6부터 8.5까지 모든 계열의 수정 빌드가 올라왔습니다. PHP 프로젝트가 공식적으로 고치지 않는 버전까지 백포트한 겁니다. 그가 속한 팀이 이번에 돌린 빌드가 대략 500개였다고 합니다. 12개 PHP 버전, 10개 데비안·우분투 릴리스, 최대 4개 아키텍처를 포괄하는 숫자였죠.

이 대목이 중요한 이유는 따로 있습니다. PHP 프로젝트는 8.2부터 8.5까지만 수정판을 냈습니다. 8.1 이하는 소스 패치만 나옵니다. 직접 컴파일해서 쓰라는 겁니다. 서버를 빌려 쓰는 사람에게 그건 해결책이 아니라 숙제입니다. 누군가 그 숙제를 apt upgrade 한 줄로 바꿔야 합니다.

이야기가 알려진 뒤 24시간 동안 그에게 들어온 후원금이 지난 1년치와 맞먹었다고 합니다. 여기까지 읽으면 '한 명의 자원봉사자가 인터넷을 구했다'는 문장이 자연스럽게 따라붙죠.

그런데 그 문장은 사실이면서 동시에 정확하지 않습니다.

Surý 본인이 그렇게 말했습니다. 진짜 영웅은 수정을 준비하고 공개 일정을 조율한 업스트림 엔지니어들이라고. 그리고 500이라는 숫자도 그의 개인 기록이 아니라 팀의 기록입니다. 소스 코드와 돌아가는 서버 사이, 마지막 1킬로미터를 메우는 사람들. 그 계층은 평소에 보이지 않고, 사고가 터진 날에만 이름을 얻습니다.

알고도 고치지 못한 2년

그런데 이 사건에서 가장 이상한 숫자는 공격 횟수도, 70퍼센트도 아닙니다. 2년입니다.

2024년, 독일 정부 산하 Sovereign Tech Agency가 자금을 대고 OSTIF가 주관해 보안 기업 Quarkslab이 PHP 엔진을 감사했습니다. 57일 동안 전문가 다섯 명이 투입됐고, 27개 발견 사항 중 17개가 보안 관련이었습니다. 그 과정에서 코어 개발자 한 명이 다른 결함을 고치다가 메모리 부족 상황에서 생기는 이상한 패턴을 목격합니다. 훗날 CVE-2026-109618의 뿌리가 된 지점이었죠.

그리고 2년이 흘렀습니다.

이유는 게으름이 아니었습니다. 수정안들은 하나같이 대가를 달고 있었습니다. 하위 호환성을 깨뜨리는 안, 오히려 새로운 서비스 거부 공격 경로를 만드는 안, 수천 개 서드파티 확장 기능을 전부 손봐야 하는 안. PHP 보안팀은 합의로 결정하는 구조였고, 합의는 이 세 가지 사이에서 번번이 멈췄습니다. 2024년 시점에 구체적인 공격 경로가 증명되지 않았다는 점도 우선순위를 밀어냈습니다.

PHP 재단은 이 지연을 두고 '구조적 실패'라고 표현했습니다. 그 표현은 한 팀의 변명이 아니라 업계 전체의 이력에 가깝습니다.

2014년 Heartbleed가 터졌을 때 OpenSSL을 관리하던 인력은 손에 꼽았고, 재단에는 돈이 거의 없었습니다. 2021년 Log4Shell 때는 자원봉사자들이 관리하던 자바 로깅 라이브러리 하나가 전 세계를 흔들었고, 미국 국토안보부는 취약한 사례를 전부 찾아 고치는 데 최소 10년이 걸릴 것이라고 말했습니다. 2024년 xz 사건에서는 오랜 세월 홀로 라이브러리를 지켜온 관리자가 사회공학 공격에 거의 넘어갈 뻔했죠.

패턴은 같습니다. 발견에는 상금과 조명이 붙고, 수정에는 월급이 붙지 않습니다. 발견의 예산은 늘었는데 수정의 예산은 그대로인 구조. 그 구조가 만든 부채는 결국 문서로 남고, 문서는 어느 날 달력이 됩니다.

유출이 만든 폭발

그럼 AI는 무엇을 했을까요.

2026년 8월 1일, 보안 기업 Calif가 OpenAI의 'Patch the Planet' 프로그램 아래 GPT-5.6 Sol을 써서 첫 번째 결함을 찾아냅니다. 8월 21일 두 번째. 8월 24일에는 구글 산하 Wiz가 자체 도구와 Gemini 4 Argon으로 독립적으로 같은 지점을 보고합니다. 두 달 남짓 조용한 조율이 이어졌습니다.

Wiz 쪽은 이렇게 말했습니다. 과거에 세계 최정상급 팀이 수개월에 걸쳐 하던 작업을 연구원 한 명이 일주일 만에 끝냈다고. 다만 이건 벤더의 표현이고, 독립적으로 검증된 벤치마크는 아닙니다. 확인 가능한 사실은 더 좁습니다. 모델이 오래된 코드의 예외 처리 구멍을 짚어냈고, 사람이 그것이 실제 공격인지 검증하고 조율했습니다.

그런데 그날의 폭발은 AI가 만든 것이 아니었습니다.

10월 17일, 아마존의 허니팟이 공개 나흘 전부터 공격 시도를 감지합니다. 10월 20일 오후 3시 20분 무렵, 취약점 상세가 온라인에 유출됩니다. PHP 팀은 예정된 22일 발표를 21일로 앞당깁니다. 10월 21일 오전 7시 41분, 보안 기업 Chainguard가 공식 배포보다 여섯 시간 이상 앞서 패치가 들어간 컨테이너 이미지를 올립니다. 재단은 수주간 준비한 공조 공개가 깨졌다고 비판했죠.

패치 코드를 새 코드와 옛 코드로 나란히 놓고 비교하면, 어디를 찔러야 하는지가 드러납니다. 패치 디핑이라는 옛 기법입니다. AI가 이 작업을 빠르게 만들 수 있다는 건 맞습니다. 그러나 방아쇠를 당긴 것은 유출과 조기 배포였습니다.

패치는 방어책이면서 동시에 공격자에게 주는 참고서입니다. 그 참고서가 예정보다 일찍 서점에 깔린 셈이었죠.

패치 비용의 외부성

한국의 숫자를 봅시다.

안랩은 국내에서 취약한 버전의 PHP가 깔린 서버를 약 11만 2천 대로 추정했습니다. 전 세계 6위 규모입니다. 쇼던 기반으로 8.2~8.5, 그러니까 공식 패치가 나온 범위의 서버만 추려보니 약 5,500대였습니다. 패치 공개 36시간 뒤 그중 3.8퍼센트, 210여 대가 수정판으로 바뀌었습니다. 19시간 시점에는 0.6퍼센트였으니 상승 속도는 빠른 편이었습니다. 그래도 96퍼센트는 그대로였죠.

해외도 다르지 않았습니다. 보안 기업 OX Security가 공개된 PHP 인스턴스 약 220만 개를 24시간 추적했더니, 수정판을 쓰는 비율은 0.7퍼센트였습니다.

왜 이렇게 느릴까요. 게을러서가 아닙니다.

한국인터넷진흥원은 국정감사에서 개별 공공기관 시스템을 직접 스캐닝할 권한이 없다고 답했습니다. 정부는 정보보호최고책임자 2만 8천 명과 주요 기반시설 111곳에 패치를 요청했습니다. 그런데 2019년 시행령 개정으로 소상공인과 소기업은 CISO 지정·신고 의무에서 빠져 있습니다. 외주로 만든 쇼핑몰을 호스팅에 얹어 쓰는, 가장 위험한 쪽이 정확히 안전망 밖에 있는 겁니다.

그들에게 주어진 조언은 '이용 중인 호스팅 업체에 확인해 보라'였습니다. 카페24와 가비아는 자기 층위에서 할 일을 했습니다. 카페24는 8.2 이상에 공식 패치를, 지원 종료된 7.4와 8.1에는 별도 조치를 적용했고, 가비아도 밤새 작업했습니다. 다만 호스팅사가 관리하는 것은 서버 런타임이고, 그 위의 사이트는 고객 것입니다.

Surý의 말이 여기에 정확히 들어맞습니다. 잘 관리되는 웹서버는 걱정하지 않는다. 걱정스러운 건, 오래전에 누군가 외주로 뭔가를 만들어 놓고 그 뒤로 패치 한 번 안 된 PHP와 워드프레스가 그대로 돌아가는 서버들이라고.

경제학에는 이 구조에 붙은 이름이 있습니다. 외부성입니다. 런타임이 안전할 때 이익은 사이트 주인, 방문자, 결제망, 그리고 인터넷 전체가 나눠 갖습니다. 비용은 그걸 우연히 알아차린 사람이 혼자 냅니다. 외부성이 있을 때 처방은 훈계가 아니라 지불, 책임, 규제입니다. '각자 알아서 하세요'는 처방이 아니라 방치에 가깝죠.

그리고 8.2의 지원 종료일은 2026년 12월 31일입니다. 이번에 겨우 패치한 서버 상당수가 두 달 뒤 다시 미지원 구간으로 넘어갑니다.

70퍼센트의 분모

이제 모두가 인용한 숫자를 뜯어봅시다.

W3Techs 기준 PHP 점유율은 69.3퍼센트입니다. 그런데 이 숫자의 분모는 '전체 웹사이트'가 아니라 '서버 측 언어를 식별할 수 있는 웹사이트'입니다. 정적 HTML로만 된 사이트는 분모에서 빠집니다. 틀린 숫자는 아니지만, 재난 영화 자막에 쓰기 좋은 숫자죠.

워드프레스 43퍼센트도 비슷합니다. 크롤러가 탐지한 설치 사례를 세는 방식이라, 방치된 블로그와 테스트용 스테이징 사이트까지 포함됩니다.

팔로알토 네트웍스가 내놓은 '2,260만 개 노출 인스턴스'는 취약 가능성이 있는 노출 규모의 추정치입니다. 실제 공격 가능한 시스템을 센 값이 아니고, 산출 방식도 공개되지 않았습니다. 바이러스토탈 집계를 보면 인터넷에서 PHP를 돌리는 IP가 약 510만 개, 그중 버전을 공개하는 건 약 110만 개. 버전을 밝힌 서버 가운데 지원 종료 계열이 약 75만 8천, 지원 계열이 약 27만 2천이었습니다.

무서운 숫자는 70퍼센트가 아니었습니다. 75만 8천과 27만 2천이었습니다. 결함에 이름이 붙기도 전에, 이미 대다수가 지원 창 밖에 있었던 겁니다.

남는 것

이번 사건에서 실제 침해가 확인된 사례는 아직 공개되지 않았습니다. 미국 CISA는 공개 시점에 악용을 관측하지 못했다고 밝혔고, 두 CVE는 '알려진 악용 취약점' 목록에도 오르지 않았습니다. 확인된 것은 대규모 시도와 예방적 중단, 그리고 그 사이에서 밤을 새운 사람들의 기록입니다.

그래서 다음에 어떤 결함이 터질 때 우리는 또 같은 질문을 하게 될 겁니다. AI가 찾았느냐, 아니냐. 그런데 그 질문에는 답이 있어도 달라지는 게 별로 없습니다. 갈림길은 다른 곳에 있으니까요. 누군가 밤새 빌드를 돌릴 때, 그 시간을 누가 지불하는가.

만약 다음번에 필요한 빌드가 500개가 아니라 5,000개라면, 그리고 그게 충분히 가능한 일이라면, 그때도 우리는 같은 사람의 저녁 시간을 기다리게 될지도 모르겠습니다. 달력은 코드 안에 있지 않으니까요.