LLM 에이전트 침입 113초, Marimo RCE가 연 내부 DB

Sysdig Threat Research Team이 2026년 5월 26일 공개한 보고서는 AI 보안 뉴스에서 흔한 과장과 조금 다릅니다. 제목은 자극적이지만, 본문이 제시하는 증거는 좁고 구체적입니다. 2026년 5월 10일 공격자는 인터넷에 노출된 marimo notebook을 CVE-2026-39987로 침해했습니다. 그 뒤 후속 행동에서 LLM 에이전트가 AWS credential, Secrets Manager, SSH bastion, 내부 PostgreSQL database까지 네 번의 pivot을 실시간으로 구성했다는 것이 Sysdig의 판단입니다.

이 사건을 "AI가 해커를 대체했다"로 읽으면 분석이 흐려집니다. 초기 침투는 이미 알려진 marimo pre-auth RCE였습니다. GitHub advisory는 /terminal/ws WebSocket endpoint가 인증 검증을 하지 않아 unauthenticated attacker가 full PTY shell을 얻고 arbitrary command를 실행할 수 있었다고 설명합니다. 영향 버전은 <= 0.20.4, 패치 버전은 0.23.0입니다. Sysdig가 새롭게 본 지점은 exploit payload가 아니라, shell 이후의 post-exploitation이 target-specific playbook처럼 고정되지 않았다는 점입니다.

Sysdig의 핵심 수치는 네 가지입니다. 전체 chain은 marimo compromise에서 내부 PostgreSQL dump까지 1시간 이내에 끝났습니다. SSH bastion 단계는 database schema와 full contents를 2분 미만에 빼냈습니다. AWS 쪽에서는 22초 동안 12개 cloud API call이 11개 distinct IP로 분산됐습니다. egress에는 Cloudflare Workers가 쓰였습니다. 이 구조는 한 IP에서 반복 호출하는 흔적을 약하게 만들고, cloud provider 로그에서 source-IP correlation만 보는 탐지를 흐립니다.

보고서가 LLM 에이전트라고 판단한 근거는 "빠르다" 하나가 아닙니다. 빠른 공격은 오래전부터 있었습니다. 핵심은 113초짜리 bastion 구간에서 네 가지 신호가 같이 보였다는 점입니다. 첫째, 공격자는 host 안에서 application identifier를 확인하지 못한 상태였는데도 AI workflow database처럼 보이는 table 이름을 추정해 dump했습니다. 둘째, command stream 안에 중국어 planning comment가 섞였습니다. 셋째, 명령은 사람이 읽기보다 다른 프로세스가 다시 파싱하기 쉽게 만들어졌습니다. 넷째, 이전 출력에서 password, secret id, SSH key path를 골라 다음 명령에 대입했습니다.

이 네 가지는 각각 따로 보면 자동화나 숙련된 shell operator로도 설명할 수 있습니다. 그러나 한 구간 안에서 함께 나타나면 해석이 달라집니다. echo '---' separator는 flat output을 다음 단계에서 쪼개기 좋게 만듭니다. head -N은 schema나 credential table dump의 출력량을 context window에 맞춰 자릅니다. HEREDOC은 여러 SQL 문을 한 번의 psql 호출로 묶습니다. 2>/dev/null은 실패한 probe의 noise를 버립니다. Sysdig는 이런 command shape를 tool-use loop의 observation consumer, 즉 LLM 에이전트를 위한 형태로 봤습니다.

개발팀이 먼저 확인해야 할 항목은 marimo 버전입니다. advisory 기준으로 0.23.0 이상이 패치 버전입니다. 패치가 바로 어렵다면 /terminal/ws 접근을 네트워크에서 제한하거나 terminal 기능을 꺼야 합니다. 이 조치는 marimo를 연구용 내부 도구로만 쓰는 팀에도 해당됩니다. notebook server가 한 번 공개 인터넷에 노출됐고 process 환경에 cloud key, DB password, API token이 있었다면, 이미 RCE 이후의 attack surface는 application server가 아니라 credential broker가 됩니다.

두 번째 항목은 secret 회전입니다. Sysdig의 권고는 공개 marimo instance에 닿을 수 있었던 environment variable, .env file, AWS credential, API key, database password, SSH key를 감사하고 rotate하라는 것입니다. 이 권고가 넓어 보이는 이유는 공격 chain이 넓었기 때문입니다. 초기 WebSocket shell에서 읽은 값이 AWS Secrets Manager 호출로 이어지고, 거기서 얻은 SSH key가 bastion 접속으로 이어지고, bastion의 .pgpass가 PostgreSQL dump로 이어졌습니다. 하나의 secret만 막는 대응은 중간 pivot 하나만 닫습니다.

세 번째 항목은 "인터넷 노출 자산만 보면 된다"는 가정을 버리는 것입니다. Sysdig의 timeline에서 실제 data loss는 내부 PostgreSQL에서 일어났습니다. 외부에 보인 것은 marimo 하나였지만, 내부망에서는 bastion, Docker host, SSH key, .pgpass, database가 연결돼 있었습니다. 에이전트형 공격은 예상과 다른 schema나 실패한 명령을 읽고 다음 시도를 바꿀 수 있습니다. 따라서 edge asset inventory와 internal runtime telemetry를 분리해서 운영하면, 공격이 가장 위험해지는 시점에는 이미 관측이 끊길 수 있습니다.

이 사례가 AI 개발자에게 직접적인 이유는 marimo가 AI/데이터 개발 도구이기 때문입니다. notebook, RAG pipeline builder, agent orchestration UI, local coding agent server는 모두 파일과 shell과 credential에 가깝습니다. Langflow, PraisonAI, LiteLLM, ComfyUI, Ray Dashboard처럼 빠르게 실험에서 운영으로 넘어간 도구도 같은 범주에 들어갑니다. 개발자는 이런 도구를 "내부 생산성 앱"으로 보지만, 공격자에게는 cloud credential과 model API key가 모이는 runtime입니다.

보안팀의 탐지 설계도 바뀝니다. Sysdig가 지적한 대로 pre-built playbook은 같은 User-Agent, 같은 명령 순서, 같은 오타, 같은 fallback을 남깁니다. LLM 에이전트가 target output을 읽고 다음 명령을 구성하면 그런 fingerprint는 매번 달라집니다. 살아남는 신호는 명령 문자열 자체보다 목적입니다. credential file read 뒤 secret manager 접근이 이어지는지, secret retrieval 뒤 SSH 접속이 생기는지, bastion session 안에서 DB schema enumeration과 table dump가 붙는지를 연결해야 합니다.

이 변화는 방어 제품의 마케팅 문구로만 다루기 어렵습니다. 목적 기반 탐지는 로그 보존, identity mapping, runtime event, cloud API trail, database access log가 이어져야 작동합니다. 예를 들어 /terminal/ws shell에서 ~/.aws/credentials를 읽은 process와 48분 뒤 sts:GetCallerIdentity를 호출한 access key, 그리고 4분 뒤 bastion에서 열린 SSH session을 같은 사건으로 묶어야 합니다. 이 연결이 없으면 각 이벤트는 낮은 심각도의 흔적으로 흩어집니다.

Cloudflare Workers fan-out도 정책 질문을 만듭니다. Workers 자체가 악성이라는 뜻은 아닙니다. 문제는 per-request egress pool이 source IP 기반 rate limit과 anomaly detection을 약하게 만든다는 점입니다. 22초 동안 11개 IP에서 12개 AWS API call이 발생하면, 한 IP의 burst를 찾는 규칙은 놓칠 수 있습니다. 반대로 identity와 API action 중심으로 보면 같은 access key가 짧은 시간에 ListSecrets와 GetSecretValue를 반복한 사실이 남습니다. AI agent 시대의 탐지는 network origin보다 credential behavior에 더 무게를 둬야 합니다.

기사 제목에 들어간 113초는 "AI가 사람보다 빠르다"는 홍보용 숫자가 아닙니다. 113초는 bastion 단계에서 schema enumeration, credential-table probe, multi-table dump가 이어진 구간입니다. 여기서 의미 있는 점은 속도보다 적응입니다. 공격 chain은 unknown internal database를 보고도 table 이름을 추정하고, .pgpass에서 password를 들어 올리고, 한 번의 psql 호출에 여러 query를 묶었습니다. playbook author가 미리 알지 못한 환경에서도 다음 명령을 만들어 냈다는 것이 비용 구조를 바꿉니다.

Sysdig는 이 변화를 capability보다 cost의 문제로 봅니다. 숙련된 공격자가 target별 playbook을 직접 만들면 새 target을 추가할 때 engineering time이 듭니다. LLM 에이전트를 붙이면 operator는 application class에 대한 일반 prior와 inference budget을 들고 들어갑니다. target에서 나온 출력이 다음 probe를 결정합니다. 성공률이 완벽하지 않아도, 충분히 싼 비용으로 많은 환경에 맞춤형 후속 명령을 만들어 낼 수 있다면 공격 규모는 달라집니다.

물론 이 보고서 하나만으로 모든 post-exploitation이 LLM agent로 이동한다고 결론내리면 안 됩니다. Sysdig도 command stream과 네 가지 signature를 바탕으로 판단했습니다. 외부 독자는 raw telemetry 전체를 직접 검증할 수 없습니다. 그래서 이 글의 실무 결론은 "모든 공격은 이제 AI"가 아닙니다. 더 좁게는 "LLM agent가 끼어든 공격을 전통적 script fingerprint만으로 구분하기 어려워진다"입니다. 이 결론만으로도 보안 설계는 충분히 바뀝니다.

개발 조직의 즉시 점검표는 네 줄입니다. marimo는 0.23.0 이상인지 확인합니다. 공개 notebook과 agent UI는 인증, VPN, allowlist, reverse proxy 정책을 다시 봅니다. AI/데이터 runtime에 들어간 .env, cloud key, model API key, DB password는 host 단위가 아니라 task 단위로 줄입니다. 마지막으로 shell command, cloud API, secret manager, SSH, DB access log를 같은 incident timeline으로 묶을 수 있는지 확인합니다.

이 사건은 AI 에이전트 보안의 초점을 prompt injection에서 runtime authority로 옮깁니다. prompt가 위험하지 않다는 뜻이 아닙니다. 다만 marimo RCE 이후의 chain에서는 prompt보다 shell, environment, AWS credential, SSH key, PostgreSQL permission이 공격을 움직였습니다. 에이전트가 명령을 더 잘 고를수록, 운영체제와 cloud IAM과 secret boundary가 더 중요해집니다. 모델 안전성만으로는 /terminal/ws shell이 읽을 수 있는 .env를 막지 못합니다.

Sysdig의 보고서는 AI 보안팀과 플랫폼팀 사이에 놓인 문서를 하나 더 늘렸습니다. AI tool을 운영하는 팀은 "이 서버가 모델을 부르는가"보다 "이 서버가 어떤 권한을 들고 있는가"를 먼저 답해야 합니다. 보안팀은 "이 명령 문자열이 알려진 악성인가"보다 "이 session이 credential을 읽고 다른 trust boundary로 넘어가고 있는가"를 봐야 합니다. LLM 에이전트 침입의 첫 교훈은 요란한 미래 예측이 아닙니다. 노출된 AI 개발 런타임 하나가 1시간 안에 내부 DB까지 이어질 수 있다는 현재형 운영 리스크입니다.