이것이 새로운 사이버 뉴노멀일까요?

AI 요약

최근 며칠 사이 PHP, GitLab, musl, LiteLLM, Railway, PingCAP 등에서 취약점과 침해 사고가 잇따랐습니다. 글쓴이는 사건들이 모두 AI로 발견되거나 공격된 것은 아니며, 현재의 보안 상황을 AI 하나로 설명하기 어렵다고 짚습니다. 다만 LLM이 취약점 분석과 익스플로잇 작성에 드는 시간을 크게 줄였고, 패치 발표 뒤 공격자가 코드 변경분을 분석해 취약점을 찾아내는 과정도 빨라졌다고 봅니다.

PHP2Shell과 공개 시점

PHP에서 두 건의 원격 코드 실행(RCE) 취약점이 발견됐습니다. Calif와 Wiz 연구진은 GPT-5.6 Sol과 Gemini 4 Argon을 활용해 취약점을 찾고 익스플로잇을 만들었다고 밝혔습니다. CVE-2026-109618은 PHP Foundation이 2024년 보안 감사에서 발견했지만 당시 실현 가능한 공격 방법을 찾지 못해 조치가 미뤄졌습니다. 글쓴이는 LLM이 이론적 취약점을 실제 익스플로잇으로 구체화하는 데 강점이 있다고 설명합니다.

패치 공개를 앞두고 정보가 유출되면서 PHP Group은 일정을 앞당겼지만, 패치는 발표 다음 날에야 공개됐습니다. 글쓴이는 여러 차례의 공개와 일정 변경이 겹쳐 약 17시간 사이에 상황이 악화됐다고 서술합니다. PHP2Shell은 인터넷의 70% 이상에 영향을 줄 수 있다는 추정이 나왔고, Wikimedia Foundation과 DeviantArt, 영국 정부 및 일본 은행 시스템 등이 영향을 받을 수 있다는 보도가 이어졌습니다. 다만 공격에 성공한 사례와 공개된 PoC의 실효성을 두고는 논쟁이 있습니다. 글쓴이는 패치가 나오기 전에 실제 공격이 진행됐다고 적었지만, 각주에서는 이를 둘러싼 의견 차이를 밝혔습니다.

인증서와 클라우드 계정 침해

Mozilla는 인도 인증기관 eMudhra가 발급한 중간 인증서 8개를 차단했습니다. 연구자 Wayne은 해당 인증서의 개인 키가 115, 56, 4처럼 매우 작은 수였다고 보고했습니다. Scott Helme는 Claude에 한 번 요청해 개인 키를 복구할 수 있었다고 전했지만, 글쓴이는 이 사건이 AI로 발견됐다는 증거는 없다고 구분합니다. eMudhra는 10월 23일 인증기관 사업에서 철수하겠다고 발표했습니다.

클라우드 제공업체 Railway는 공격자가 플랫폼의 환경 변수에 접근하고 이를 복호화한 정황을 공개했습니다. 환경 변수에는 데이터베이스 자격 증명과 API 키가 들어가는 경우가 많습니다. Railway는 AI 추론 서비스를 제공하는 회사를 겨냥한 조직적 공격일 가능성을 언급했지만, 글쓴이는 당시 공개된 정보만으로 공격 목적을 판단하기 어렵다고 씁니다.

GitLab, musl, LiteLLM 및 PingCAP

GitLab은 CI/CD 정규식 처리와 관련한 RCE 취약점 두 건을 공개했습니다. 각각 CVSS 10.0으로 발표됐으며, 앞서 공개된 경로 순회 취약점도 최고 심각도 점수를 받았습니다. 세 건 모두 HackerOne 버그 바운티 프로그램으로 제보됐습니다. 글쓴이는 GitLab 인스턴스를 VPN이나 방화벽 뒤에 두면 위험을 줄일 수 있다고 설명하지만, 일부 취약점이 성립하는 조건은 공개 정보만으로 확인하기 어렵다고 덧붙입니다. musl의 정규식 처리 취약점도 같은 시기에 공개됐지만 GitLab 취약점과 직접 연관됐다는 근거는 없다고 봅니다.

LiteLLM에서는 PyPI 패키지와 Docker 이미지가 변조돼 자격 증명을 훔치는 악성 코드가 배포됐습니다. 악성 코드는 Python 시작 시 실행되는 .pth 파일과 sitecustomize.py를 이용했습니다. Wiz는 코드에 LLM 보조 개발의 흔적이 있다고 분석했지만, LiteLLM은 공격자가 GitHub CLI 자격 증명을 확보해 CI 작업을 실행했다고 밝혔습니다. 글쓴이는 Claude Code가 응답 본문에 GitHub CLI OAuth 토큰을 넣을 수 있고, 이 토큰이 LiteLLM 로그에 남았을 가능성을 언급합니다.

PingCAP은 자사 클라우드 자원에 무단 접근이 있었지만 TiDB에 저장된 데이터가 영향을 받았다는 증거는 없다고 발표했습니다. 반면 갈취 조직 FulcrumSec은 10.6TB를 유출했다고 주장하고 200GB 분량의 데이터를 공개했습니다. 공개된 자료에는 Jira 티켓에 AWS 비밀 키를 넣거나 로그에 AI 서비스 API 키를 노출한 정황이 포함됐다고 글쓴이는 전합니다. 다만 공격 조직의 주장이 확인된 사실과 같지는 않으며, PingCAP의 발표는 TiDB 인스턴스 내부 데이터에 관한 입장으로 한정해 읽어야 합니다.

공개 지연과 대응 속도

글쓴이는 소스 코드를 비공개로 돌리는 방안이 취약점 분석을 어렵게 만들 수는 있어도, 과거 코드의 복사본이나 디컴파일을 막지 못하고 공개 검토의 이점도 없앤다고 지적합니다. AI로 모든 코드를 먼저 검사하자는 접근 역시 비용과 취약점 수정 부담, 전문성 부족 문제를 해결하지 못합니다. 취약점 공개와 패치 배포의 절차를 개선하는 방안도 제시하지만, 이번 사건에서는 정보 유출과 일정 조정이 겹쳐 공개 전에 패치할 수 없었습니다. AWS는 PHP 취약점 공격 시도가 10월 17일부터 관측됐다고 밝혔습니다.

글쓴이는 AI가 취약점 발견과 공격 준비 시간을 주 또는 달 단위에서 시간 또는 분 단위로 줄일 수 있다고 봅니다. 동시에 AI가 생성한 익스플로잇 가운데 잘못된 가정에 기대거나 작동하지 않는 사례도 많아, 실제 공격과 허술한 PoC를 가려낼 전문 지식이 필요하다고 강조합니다. 근본적인 대응으로는 공개 전 보안 검증, 빠른 패치 적용, 더 나은 취약점 공지 절차를 들지만, 모든 조직이 이를 갖추기 어렵다는 한계도 인정합니다.

Hacker News 반응

• @roenxi — 지금은 확장 가능한 초인적 개발자가 등장해 오래 쌓인 버그를 찾아내는 "짧은" 과도기입니다. 비슷한 시스템이 코드 대부분을 작성하게 되면 중대한 버그가 발견되는 물결은 잦아들 것입니다. 다만 안정될 때까지는 시간이 걸릴 수 있습니다.
  • @ninkendo — AI가 버그를 찾는다고 해서 버그 없는 코드를 작성한다는 결론이 따라오지는 않습니다. AI가 코드를 쓰게 한 뒤 보안 감사를 시켜도 취약점을 발견하는 경우를 계속 봅니다.
• @thomascgalvin — 제가 읽은 내용으로는 그렇습니다. 제가 이야기하는 보안 전문가들은 Mythos가 처음 발표됐을 때 크게 놀랐습니다. 제 업무의 상당 부분은 이제 AI가 생성한 익스플로잇의 영향을 완화하는 일입니다. AI가 생성하는 코드의 양도 상황을 악화시킬 것입니다. AI 생성 코드는 보안 면에서 형편없기로 악명이 높습니다.
  • @silveraxe93 — AI 생성 코드가 보안 면에서 형편없다는 말이 맞습니까? 제 경험으로는 AI 코드가 상당히 방어적이고 뻔한 실수를 줄이는 데 능합니다. 예전 모델을 말하는 건가요, 아니면 Mythos급 모델을 말하는 건가요?
• @dotdi — "이미 실제 환경에서 악용되고 있다"는 대목은 해당 익스플로잇을 감지했다고 자랑하는 상업 블로그를 출처로 듭니다. 글을 읽어도 실제 악용은 보이지 않습니다. 스캔이나 탐색을 실제 악용과 같은 것으로 취급하는 건가요?
• @leftouterjoins — 대부분 과장입니다. 며칠이 지났는데도 PHP 취약점을 악용한 사람이 없습니다. 시들하네요.
  • @ishouldnotbutk8 — PoC 영상이 실제로 있었고 여러 분석 글도 나왔습니다. 이 취약점은 모든 PHP 설치에 통하는 단일 익스플로잇이 아닙니다. ASLR을 우회해야 하는 저수준 취약점이라 아키텍처와 시스템, 설정에 맞게 조정해야 하고 표적도 꽤 알아야 합니다. 대응은 과장됐지만 반대로 무시하는 태도도 지나칩니다.
  • @zkldi — 안녕하세요. 블로그 글을 쓴 사람입니다. 제가 방금 쓴 표현을 그대로 썼어야 했습니다. 실험실 PoC에는 실제 환경에서 보기 어려운 조건이 들어가는 경우가 많습니다. 그래도 나쁘지 않은 취약점입니다. 운과 통계는 진지한 보안 장벽이 아닙니다. 서버를 패치하세요.
• @thaumaturgy — 두 가지 문제가 있습니다. 지금 중대한 취약점과 익스플로잇이 더 빠르게 발견되는 점, 그리고 발견에서 대규모 공격까지 걸리는 시간이 훨씬 짧아졌다는 점입니다. LLM이 버그를 찾아 고치면 발견 속도는 안정될 거라고 말할 수 있습니다. 그렇다고 짧아진 시간 간격이 사라지지는 않습니다. 저는 이번에 큰 업체들이 문제를 발견하고 다른 큰 업체에 알린 뒤, 충분한 공개 정보를 흘리고는 나머지 사람들에게 거의 아무 정보도 주지 않은 채 알아서 대처하라고 하는 동안 하루를 통째로 잃었습니다.
• @shevy-java — 공개를 늦추는 전략이 마음에 들지 않습니다. 제 생각에는 보안 문제를 발견하면 지체 없이 모두에게 알려야 합니다. 악의적인 행위자가 악용하지 못하게 숨긴다는 발상은 다른 사람들에게 불공정합니다. 취약점이 LLM 하나로 발견된다면 다른 LLM도 찾을 수 있는데, 왜 공개를 미루나요?
  • @karussell — 지연의 취지는 조직적으로 대응할 시간을 확보하는 것입니다. 예를 들어 PHP뿐 아니라 여러 Docker 이미지도 수정해야 합니다. 하지만 LLM 시대에도 그 이점이 남아 있는지는 의문입니다.
• @DCKing — 질문은 심각한 취약점의 뒷물결이 얼마나 깊은지입니다. PHP에 이런 RCE가 몇 개나 있을까요? 과거에는 없다고 생각한 사람도 많았을 겁니다. 수정 뒤에는 다시 0개일 수도 있고, 수천 개나 86개, 4개일 수도 있습니다. 아직 관리 가능한 누적분인지, 사실상 끝이 없는 양인지는 열린 질문입니다.
• @betterunix2 — 새로운 일상이라기보다 예전의 일상에 가깝습니다. 25년 전 일을 기억하는 사람에게는 웜 관련 뉴스가 매주 나왔고 회사들은 취약점 제보를 무시하곤 했습니다. 당시보다 지금은 이런 상황에 대응할 준비가 더 돼 있습니다.