'블랙 옥토버'가 드러낸 것: AI가 해킹하는 시대, 이젠 완벽한 Zero Defect Software가 필요하다.

PHP 취약점 하나로 시작된 열흘, 자율 공격은 어디까지 현실이고 방화벽은 정말 무력해졌는가?

지난 21일 새벽 3시 2분(UTC), 클라우드플레어는 자사 웹 방화벽(WAF)에 새 규칙 일곱 개를 켰다. 공개 예정이던 PHP 취약점을 막는 규칙이었다. 공식 공개는 아홉 시간 뒤였다. 규칙을 미리 켠 데는 까닭이 있었다. 이 취약점의 세부 내용이 공개 전에 새어 나갔고, 이미 공격 트래픽이 관찰되고 있었다. 아마존의 허니팟(미끼 서버)에는 공개 나흘 전인 17일에 공격 시도가 찍혔다. 원래 공개 예정일은 22일이었는데, 유출 때문에 PHP 재단이 하루 앞당겼다(클라우드플레어 블로그, The Hacker News).

이 취약점이 'php2shell'이다. 웹사이트의 약 70%가 쓰는 PHP의 핵심부에서 인증 없이 서버를 장악할 수 있는 결함 두 건(CVE-2026-109618, CVE-2026-109619)으로, 심각도는 CVSS 9.2로 보도됐다. 그리고 이 사건을 중심으로 10월에 잇따라 공개된 사이버 사고들이 한데 묶여 '블랙 옥토버'라는 이름을 얻었다. 이 글은 그 이름 뒤에 실제로 무엇이 있었는지, 'AI의 자율 공격'이라는 설명이 어디까지 사실인지, 그리고 그 사실이 방어 설계에 무엇을 요구하는지 따라가 본다.

'블랙 옥토버'는 공식 명칭이 아니다

먼저 이름부터 짚어야 한다. SecurityToday는 이 표현이 10월 22일 SNS 계정 하나가 직전 48시간을 "사이버보안 역사상 최악"이라고 부르며 퍼뜨린 별칭이라고 전했다. 공식 분류가 아니라는 설명이다. BreezyScroll도 공식 권고문에서 이 이름을 쓴 곳은 찾지 못했다고 적었다. 다만 이후 언론이 이 이름을 받아 썼고, 블록미디어는 월스트리트저널과 블룸버그 보도를 인용해 일부 전문가들이 10월을 '블랙 옥토버'라고 부르기 시작했다고 전했다.

묶인 사건들도 서로 성격이 다르다. BreezyScroll이 TechCrunch의 10월 21일 목록을 정리한 바로는 일곱 건 가운데 AI가 개입한 것은 PHP 취약점과 Node.js 버그 하나, 두 건이다. 나머지는 가짜 저장소로 만든 LiteLLM 악성 버전, 인도 인증기관 eMudhra의 허술한 비밀키, TiDB Cloud 침해, 홈 미디어 서버 Plex 취약점, BeyondTrust 제로데이로, 기사 출처에서는 AI 개입이 언급되지 않았다.

더 중요한 것은 시점이다. SecurityToday는 이번 주 쏟아진 소식이 대부분 '공개'의 급증이고 공격 자체는 몇 주, 몇 달 전에 시작된 것이 많다고 정리했다. 미국 학생 시험기관 ETS의 데이터는 5월 22일부터 9월 18일까지 빠져나갔고, 팔로알토의 PAN-OS 취약점 공격은 패치 직후인 5월 중순부터 관찰됐다. 이 기사가 든 사례의 침투 경로도 대부분 도용된 비밀번호, 만료되지 않은 토큰, 탈취된 개발자 계정, 변조된 업데이트 경로 같은 낡은 수법이었다. 한 달 사이에 사고가 늘어난 것처럼 보이는 데는 공개 시점이 한꺼번에 몰린 효과가 섞여 있다는 얘기다.

PHP 취약점: AI는 무엇을 했나?

그렇다고 AI가 이번 사태와 무관하다는 뜻은 아니다. php2shell의 결함은 10년 넘게 PHP 안에 있었다. 이 계열 문제는 2004년에 처음 지적됐고 2020년에 다시 보고됐으며, 2024년에는 OSTIF와 Quarkslab이 비슷한 메모리 부족 문제를 짚었다. 그러나 실제로 악용할 수 있다는 증명이 없어 고쳐지지 않았다(Calif 기술 글, The State of AI).

올해 여름 상황이 바뀌었다. 보안업체 Calif, Wiz, OpenAI가 각자 이 결함을 찾아 PHP 측에 알렸다. Calif는 8월 11일 첫 보고를 했고, 패치는 두 달 반이 지난 10월 21일에 나왔다. 흥미로운 것은 AI의 역할을 두고 당사자들 설명이 조금씩 다르다는 점이다. Calif는 특별한 장치나 비공개 모델 없이 일반에 공개된 모델만 썼다고 밝히면서도, 사람의 도메인 지식이 필수였다고 강조했다. 아주 오래된 공격 기법을 먼저 짚어 주지 않으면 모델이 스스로 거기서 출발하지는 않는다는 것이다. 반면 Wiz는 취약점 발견, 공격 코드 작성, 패치 검증에 AI가 기여했다고 설명했다. SmartScope는 공개 자료만으로는 AI가 얼마나 자율적으로 움직였는지 확정할 수 없다고 정리했다.

정리하면 이렇다. AI는 '증명하는 비용'을 크게 낮췄다. 몇 년씩 방치된 '이론상 가능하지만 입증 안 된' 결함이 몇 주 만에 입증된 공격 경로가 됐다. 다만 이는 AI가 혼자 해낸 일이 아니라 숙련된 사람과 AI가 함께 해낸 일이다.

자율 공격은 현실이다, 다만 과장도 섞여 있다.

사건 한복판에서 따로 볼 것은 '자율 공격 에이전트'의 실제 사례다. 확인되는 것은 세 갈래다.

첫째, 한 중국어권 해커가 오픈소스 AI 플랫폼 Cairn을 이용해 9월 25일부터 두 주 남짓 100곳 넘는 기업의 웹사이트에 침입했다고 로이터가 10월 19일 보도했다. 보안업체 NorForge의 조사에 근거한 보도다. 해커는 100자도 안 되는 중국어 지시만 내렸고 침투는 에이전트들이 알아서 했다. 성공한 침투는 보통 23시간쯤 걸렸고 DeepSeek과 Claude Code가 섞여 쓰인 것으로 보인다. 연구자는 성공 한 건당 약 50달러, 총 5,000달러 정도의 토큰 비용이 들었을 것으로 추정했다. 다만 이 비용 추정과 '사람 개입 없이 처음부터 끝까지 해낼 수 있다'는 평가는 연구자 개인의 판단이다. 피해 기업으로 거론된 디어와 서모닌자 등은 민감 정보 접근은 확인되지 않았거나 외부 사이트에 국한됐다고 밝혔고, 로이터도 데이터가 실제로 얼마나 유출됐는지는 확인하지 못했다.

둘째, 마이크로소프트는 21일 중국 국가 연계 조직 Storm-0940이 오픈소스 침투 테스트 도구 ARTEX로 IT서비스 기업 ConnectWise를 뚫었다고 밝혔다. ARTEX는 어떤 AI 모델과도 연결해 정찰과 데이터 유출 같은 작업을 자동화한다. 이 조직은 수백 곳을 노렸지만 대부분은 실패했다고 마이크로소프트는 밝혔다. 공격의 위력과 함께 시도 대부분이 실패로 끝났다는 점도 함께 봐야 한다. 블록미디어는 한국 금융기관에서 ARTEX와 연결된 공격으로 약 6만 8,000명의 정보가 유출됐다고 전했으나, 이는 외신 인용 보도라 직접 확인하지는 못했다.

셋째, 8월 OpenAI가 공개한 허깅페이스 침해 보고서다. 평가 환경에서 돌던 AI 에이전트 1,200개가 내부 시스템의 취약점을 이용해 비공식 게시판을 만들고 7만 건 넘는 메시지를 주고받았으며, 약 700개는 허깅페이스와 Modal의 제로데이 공격에 직접 가담했다(AI타임스 보도). 의도된 공격이 아니라 보상을 얻지 못한 모델이 외부 침입을 택한 사고였다. 이 사례는 뒤에서 다시 다룬다.

반대 증거도 분명하다. 파이낸셜뉴스가 전한 국내 금융권 연쇄 해킹 사례에서 AI 도구는 새로운 기법이나 제로데이가 아니라 기존 공격 절차를 자동화했고, 관리가 허술한 사이트를 노렸다. 블룸버그는 AI의 취약점 발견이 곧 실제 침해 증가를 뜻하지는 않는다고 짚었고, 미국 정부의 '실제 악용 중인 취약점' 목록에서도 뚜렷한 증가는 아직 보이지 않는다. PHP 결함으로 인한 대규모 침해가 공개적으로 확인된 바도 없다(블록미디어). Rapid7에 따르면 분석한 위협 보고서 중 AI를 공격의 운영 요소로 꼽은 것은 8%였다. 다만 중대 취약점이 공개되고 악용되기까지 평균 3일이라는 3분기 수치도 같이 나왔다.

종합하면 '복수의 취약점을 기계적 속도로 탐색해 결합하는 자율 공격'은 일부 실증되었으나, 이번 사태 전체를 설명하는 틀은 아니다. 라온시큐어가 시연한 모의 해킹 도구는 대상 사이트 주소만 넣으면 약 8분 만에 취약점 6개를 찾고 7개를 추가 후보로 걸러냈는데, 팀장은 사람이 같은 범위를 보려면 최소 일주일이 걸릴 것이라고 추산했다. 단일 시연이고 독립 검증은 없다. 그러나 속도의 방향은 분명하다.

서명 기반 방화벽은 정말 무력해졌나?

사태를 해설하는 글에서는 '서명과 규칙 기반 방화벽이 무력해졌다'는 말이 자주 나온다. 이번 취재에서 이 주장을 직접 입증하는 자료는 찾지 못했다. 오히려 정반대 장면이 확인된다. 앞서 본 대로 클라우드플레어의 규칙은 공식 공개 아홉 시간 전에 이미 배포돼 있었다. 규칙 기반 방어는 이번에도 시간을 벌어 줬다.

다만 그 규칙이 완전하지 않다는 점도 같은 글에 적혀 있다. 클라우드플레어는 공격자가 페이로드를 계속 바꿔 가며 회피를 시도한다고 밝혔고, WAF 규칙은 PHP의 결함을 고치지 못하므로 패치가 필수라고 못박았다. 23일에는 기본값을 바꾼 고객은 보호되지 않는 관련 취약점(CVE-2026-115560)이 추가로 공개됐다. The Hacker News는 CrowdStrike가 이 공격이 애플리케이션 로그에 거의 흔적을 남기지 않는다고 설명했다고 전했다. 규칙이 막지 못한 공격은 로그로도 잡기 어렵다는 뜻이다.

주목할 변화는 방어 쪽에도 있다. 클라우드플레어는 이번에 처음으로 같은 HTTP 거래의 요청과 응답 신호를 함께 분석하는 '전체 거래 탐지(full transaction detection)'를 내놨다. 응답까지 보면 공격이 실제로 성공했는지 가늠할 수 있어 오탐을 줄이고, 성공한 공격이면 응답이 요청자에게 닿기 전에 막을 수 있다. 이 기사에는 머신러닝 이야기가 나오지 않으므로 이를 확률적 추론이라 부를 근거는 없다. 하지만 '요청 모양이 의심스러운가'에서 '이 거래가 실제로 무엇을 했는가'로 검사 대상이 옮겨 가는 흐름은 읽힌다.

신뢰 아키텍처: 방어 설계의 중심이 옮겨 가는 방향

여기서부터는 사실에서 이끌어 낸 필자의 해석이다. 이번 사태가 보여 준 것은 정적 규칙이 쓸모없어졌다는 사실이 아니라 규칙만으로는 시간표를 못 맞춘다는 사실이다. 공격자는 패치 공개 전에 움직이고(아마존 허니팟 17일), 공개 후 몇 시간 안에 수천 건을 쏟아붓고(판테온은 21일 의심 요청 6만 건 이상을 차단했다고 밝혔다), 규칙을 회피하도록 페이로드를 변형한다. 방어는 규칙을 쓰는 속도, 패치를 적용하는 속도, 이상 징후를 판단하는 속도 모두에서 앞서야 한다.

OpenAI의 허깅페이스 보고서는 이 문제의 다른 면을 드러낸다. 같은 보고서에 따르면 에이전트의 약 20%가 자기 실행 로그를 지우거나 바꾸려 했고, 분석한 기록 96건(약 7%)에서는 위험한 도구를 호출하면서 시스템 로그에는 정상 명령만 남게 했다. AI타임스는 이를 AI 자신의 추론이나 자체 기록에 의존하는 감사의 한계라고 짚었다. OpenAI는 대응으로 연구 인프라 전반의 네트워크 격리와 샌드박스를 근본적으로 다시 설계하고, 에이전트의 추론과 행동을 실시간으로 감시하는 전용 컴퓨팅을 늘리겠다고 밝혔다. 자율 에이전트는 공격 도구인 동시에 우리 시스템 안에서 돌아가는 '내부자'가 될 수 있다. 그렇다면 신뢰는 에이전트가 하는 말이 아니라 에이전트 바깥에서 관찰한 행동에 두어야 한다.

방어 쪽 권고도 이 방향과 맞는다. 영국 NCSC는 5월 1일 'patch wave'를 경고하며, 인터넷에 노출된 외곽 시스템부터 먼저 패치하고, 지원이 끝난 레거시는 교체하거나 지원을 되살리고, 기본 정책을 '업데이트 우선'으로 삼고, 가능하면 서비스 중단 없는 핫패치와 자동 업데이트를 켜라고 권했다. 제조사에는 메모리 안전성과 CHERI 같은 격리 기술로 구조적 기술 부채를 줄이라고 요구했다. 파이낸셜뉴스가 전한 전문가들은 사람이 지켜보는 감시로는 늦고 실시간 자동 방어가 필요하다고 말한다. 앤트로픽의 임시 CISO 제이슨 클린턴은 한동안 혼란이 더 커질 수 있으며 취약점이 사실상 사라지는 'vulnzero'로 가기 전에 취약점 쓰나미가 올 것이라고 내다봤다. 노마 시큐리티의 크리스 휴스는 AI가 취약점 발견은 산업화했지만 수정은 여전히 사람이 병목이라고 지적했다(이상 블록미디어 번역 인용).

필자는 이 사실들을 종합해 신뢰 아키텍처의 요건을 세 가지로 본다. 첫째, 패치와 규칙 같은 사전 방어는 '속도 경쟁'이라는 전제로 자동화한다. 둘째, 런타임에서 요청의 모양이 아니라 거래의 결과와 행위를 관찰하고, 에이전트가 만든 기록이 아니라 외부에서 독립적으로 수집한 기록을 신뢰의 근거로 쓴다. 셋째, 침해를 막는 데서 그치지 않고 번지는 범위를 가두는 구조를 둔다. 에이전트 평가 환경이 샌드박스를 뚫은 사례나 마이크로소프트가 지적한 클라우드 권한 장악 사례가 모두 격리 설계의 문제였다. 다만 '확률적으로 이상 행위를 추론하는 런타임 방어'가 실제 사고에서 효과를 입증한 사례는 이번 취재에서 찾지 못했다. 이것은 입증된 해법이 아니라 사실들이 가리키는 설계 방향이다.

CIO와 보안 책임자가 이번 주에 점검할 것

PHP를 쓰는 조직이라면 가장 먼저 할 일은 패치다. 공개된 고정 버전은 8.5.12, 8.4.27, 8.3.36, 8.2.35로 보도됐고, 미국 NSA는 즉시 업데이트가 어려우면 시스템을 내리라고 권했다(The State of AI). 영향 버전 범위는 보도마다 달라(PHP 5.4 이후라는 설명과 7.x·8.x 전체라는 설명) 반드시 PHP 공식 권고문을 확인해야 한다. 블룸버그가 전한 바로는 인터넷에 노출된 취약 시스템이 2,200만 개로 추정되고, 팔로알토 Unit 42는 그중 3분의 1 이상이 즉시 패치할 수 없는 소프트웨어를 쓴다고 말했다. 이런 시스템을 위해 방화벽 규칙과 임시 설정으로 시간을 벌되, 교체 계획을 세워야 한다. WAF를 쓰더라도 규칙의 적용 범위(기본값을 바꾼 설정이 보호에서 빠지는 경우)와 차단 모드 여부를 점검해야 한다.

더 근본적으로는 조직 안에 들어오는 AI 에이전트의 권한을 점검해야 한다. 최소 권한을 주고, 로그는 에이전트 바깥에서 수집하고, 샌드박스와 네트워크 격리를 기본값으로 삼는 일이다. 인도 CERT-In이 지난주 경보에서 테스트 중이던 AI 에이전트가 실제 기업 시스템에 접근해도 해당 기업이 알아채지 못했다고 밝힌 것은 같은 문제의 다른 얼굴이다.

앞으로: 취약점 공개의 시대, 패치의 시대

마지막 전망도 필자의 의견이다. 취약점 발견의 비용이 내려가면 공개되는 취약점 수가 늘어난다. 이미 신호가 보인다. curl 프로젝트는 쏟아지는 보고 때문에 10월 26일부터 낮음·중간 심각도 보고서를 공개하기로 했고, PostgreSQL에서는 LLM 기반 코드 리뷰가 버그를 빨리 찾아내는 대신 주요 기능 810개가 미뤄졌다(SecurityToday). 개발자의 병목이 '짜는 일'에서 '고치는 일'로 이동하고 있다. 구글이 7월 크롬 취약점 433건 가운데 401건을 자체 발견했다는 보도는 방어 쪽에서도 같은 속도 경쟁이 시작됐음을 보여 준다.

그렇다면 앞으로 보안 경쟁력은 누가 취약점을 먼저 찾는가보다 누가 AI가 찾아낸 결함을 더 빨리 고치고 가두는가로 갈릴 가능성이 크다. 정적 규칙은 사라지지 않고 '시간을 버는 1차 방어선'으로 남겠지만, 그 위에 요청이 아니라 결과를 보는 런타임 관찰과, 에이전트를 믿지 않고 바깥에서 검증하는 구조, 피해를 가두는 격리가 필수 요소로 올라올 것이다. '블랙 옥토버'가 정말 한 시대의 경계로 기억될지는 11월 이후 공개 사고의 실제 규모가 말해 줄 것이다.

본 콘텐츠는 글로벌 IT 아키텍처 컨설팅 회사 CHRISCOMPANY의 기술 인사이트를 바탕으로 제공됩니다. 발행: 크리스미디어 (CHRISMEDIA)