LLM 멀티 에이전트 워크플로우로 오픈소스 제로데이를 찾은 후기

LLM 에이전트 워크플로우를 만들게 된 계기

그동안 대학교에 와서 했던 보안 공부는 주로 워게임이나 CTF에 집중되어 있었습니다. 정해진 환경에서 취약점을 찾고 익스플로잇에 성공하는 것도 좋았지만, Real World의 취약점을 찾고 싶다는 생각이 있었습니다.

그러다 BoB 14기 취약점 분석 트랙에 합류하면서 보안 업계의 패러다임이 변하고 있다는 걸 느꼈습니다. 멘토님들의 AI가 해킹도 잘하고 미래에는 보안에서 많은 부분을 담당하게 될 거고 AI를 잘 다루는 능력이 해커에게 매우 중요하다는 말과 AIxCC(AI Cyber Challenge) 대회를 보고 "AI for Security"가 조만간 보안에서의 주류가 될 것이라는 생각이 들었습니다. 그리고 AI가 단순히 웹 UI에서 챗봇과 대화하는 수준을 넘어, Claude Code나 Codex 같은 CLI 기반 툴, 그리고 MCP가 등장하고 버그바운티 사이트에서 AI가 1등을 하는 것을 보며 이 생각이 점점 확신하게 됐습니다.

이 워크플로우는 BoB 교육 기간 중 틈틈이 설계하고 구축해 두었습니다. 다만 팀 프로젝트 기간에는 팀 프로젝트에 집중하느라 워크플로우로 발견한 취약점들을 일일이 리포팅할 여유가 없었습니다. 프로젝트가 마무리된 12월 말부터 그동안 쌓인 데이터들을 하나씩 검증하고 보고서를 써서 제보하기 시작했고, 그중 일부가 Accept 되어 CVE와 바운티를 받을 수 있었습니다.

타겟 설정

초기에는 메모리 취약점이나 블랙박스 모의해킹도 고려했지만, 현실적인 이유로 노선을 틀었습니다.

• 메모리 취약점은 메모리 취약점 전용 워크플로우를 만들어서 OOB나 Stack Overflow 크래시를 몇 개 찾긴 했지만, 구글 OSS 바운티 같은 곳은 단순 크래시만으로는 인정받기 어렵습니다. 무결성이나 기밀성을 완전히 터트리는 익스플로잇 체이닝이 필요한데, 현재 AI로 이 과정을 자동화하는 건 보안 정책/가이드라인 때문에 쉽지 않고, 지금까지 포너블보다 웹 해킹을 위주로 공부를 해왔기 때문에 강점이 있지 않다고 봤습니다.
• 블랙박스 서버 버그바운티는 AI가 안전하게 취약점 진단을 하지 못하고 페이로드를 날리다 서버를 크래시시키거나 망가트릴 리스크가 존재하기 때문에 일단은 우선순위를 미뤘습니다. (티오리의 Xint나 미국의 xbow같은 경우 안전하게 하는 노하우가 있겠지만 아직은 잘 모르겠네요)

결국 제가 가장 잘 아는 분야이면서 코드 규모가 압도적인 Nextcloud, matomo, Grafana 같은 웹 오픈소스를 타겟으로 정했습니다. 코드가 투명하게 공개되어 있고, 도커로 올려서 로컬에서 쉽게 취약점을 재현할 수 있으며, 사람 눈으로 놓치기 쉬운 복잡한 비즈니스 로직 버그를 찾는 데 LLM의 문맥 이해 능력이 가장 잘 먹힐 거라 생각했습니다.

아키텍처

여러 종류의 워크플로우를 시도해 봤지만, 현재 주력으로 사용하는 2가지 워크플로우는 공통적으로 '취약점 발굴'과 '오탐 검증' 단계가 철저히 분리된 구조를 갖고 있습니다. 핵심은 모든 과정에 고가의 모델을 쓰지 않고, 단계별로 적절한 모델을 효율적으로 라우팅하는 것입니다.

이런 구조를 짠 이유는 AIxCC에서 티오리의 '로보덕(RoboDuck)’ 사례를 참고했기 때문입니다. 물론 퍼징이라서 토큰이 더 많이 들었던 점도 있겠지만 로보덕은 토큰 소모가 극심해서 시간당 1,000달러 이상의 비용이 깨지기도 한다는 것을 보고 지속 가능성을 확보하려면 제일 좋은 모델만을 사용하는 것이 아니라 필요에 따라 모델을 섞어서 사용해야 한다고 생각했습니다.

이때 여러 가지 저가 LLM의 벤치마크를 찾아보고 비교하는 글을 보다가 geeknews에 있는 glm에 대한 글을 보고 glm이라는 LLM이 성능도 괜찮고 가격도 좋은 것 같아서 사용하게 되었습니다. glm의 모델 중에서도 최근 나온 GLM-5가 glm 4.7보다 성능은 20% 정도 더 좋지만 토큰 소모량이 3배 정도 많습니다. 웹 취약점은 고난도 추론보다 IDOR 같은 로직 버그 탐지가 많기 때문에, 20% 정도 좋은 모델을 쓰는 것보다 저렴한 모델의 호출 횟수를 늘려 효율적으로 사용하는 게 더 취약점을 잘 찾을 수 있을 것이라는 생각으로 저렴한 4.7을 주력으로 활용했습니다.

각 모델의 Coding Index 벤치마크

• Finding (GLM-4.7): 취약점 후보를 찾습니다. 여러 가지 워크플로우를 만들 때 Finding 부분에서의 변주를 줘서 여러 가지 워크플로우를 만들었습니다
• Semi-Triage (GLM-5): 1단계에서 올라온 후보들 중 명백한 오탐을 glm-4.7보다 좋은 성능의 glm-5로 1차로 걸러냅니다.
• Triage (Codex 5.3): 살아남은 데이터만 최상위 모델인 Codex 5.3에게 넘겨 최종 검증을 진행합니다.

Triage까지 끝난 확실한 취약점들은 Discord를 통해 알림이 가고 Notion에 취약점 보고서가 업로드됩니다.

업로드된 보고서를 확인한 뒤, 제보 전에는 항상 직접 재현하고 검증합니다. Codex로 검증해도 오탐이 남을 수 있어 최종 리포트는 재현 결과를 기반으로 작성합니다.

프롬프트

워크플로우를 돌리던 초반에 오탐이 꽤나 많았어서 이를 해결하기 위해서 여러 가지 프롬프트를 시도해보고 개선해 나갔습니다

• 대부분의 오탐은 아래 3가지 중에 한 요소에서 문제가 생겨 오탐이 발생했습니다. 그래서 이 3가지를 검증할 때 고려하게 해야 했습니다.
  • 공격자 조건: 이 공격이 성립하기 위해 공격자가 어떤 위치(내부망/외부망)에 있어야 하며, 어떤 권한(Unauth/Admin/Guest)을 가지고 어떤 입력을 넣어야 하는지
  • 서버 조건: 특정 플러그인이 켜져 있어야 하는지, 기본 설정값은 무엇인지, 특정 OS나 환경에서만 발생하는지 등 서버의 전제 조건
  • 보안 임팩트: 단순히 '위험함'이 아니라, 이 취약점을 통해 데이터 탈취가 가능한지, 서비스 거부(DoS)가 일어나는지, 아니면 단순 정보 노출인지 CIA를 기준으로 기술
• 이때 많은 사람이 이 문제를 해결하기 위해서 프롬프트를 짤 때 "공격자의 권한을 고려해서 분석해줘"라거나 "서버 설정을 염두에 둬"라는 식으로 '부탁'을 합니다. 하지만 LLM은 기본적으로 게으릅니다. '고려'라는 모호한 명령은 추론 과정에서 쉽게 생략되거나 대충 훑고 지나갈 때가 많기 때문에 이 3가지 요소를 응답에 출력하게 해 AI가 반드시 이 3요소를 분석하게 강제하여 이 3가지로 인한 오탐은 줄어들었습니다.
• 위 3가지 오탐이 해결되니 이제는 소스코드만 보면 취약점이지만 해당 오픈소스의 보안 모델상에서는 취약점이 아닌 오탐이 발생하였습니다. 따라서 해당 오픈소스의 공식 보안 문서와 정책을 검색해서 오탐인지 취약점인지 검증하게 프롬프트를 짜니 해당 문제로 인한 오탐이 줄어들었습니다.

이 과정을 통해 bug와 Vulnerability를 명확히 구분할 수 있었고 취약점 분석 워크플로우의 false positive 확률이 확연하게 줄어들었습니다.

발견한 취약점

개인적으로 이번 프로젝트를 통해 느낀 건, AI가 IDOR나 비즈니스 로직 취약점을 생각보다 잘 찾는다는 점입니다. 전통적인 스캐너들은 단순히 코드의 흐름만 쫓지만, AI는 해당 API가 어떤 목적을 가졌고 어떤 보안 모델 위에서 작동해야 하는지 그 '문맥'을 이해하기 때문입니다.

특히 이런 분석은 사람이 직접 하려면 수만 줄의 API 라우팅 코드와 복잡하게 얽힌 권한 엔진의 상호작용을 하나하나 대조해야 합니다. 물리적으로 시간이 엄청나게 소요될 뿐만 아니라, 수천 개의 인자 중 단 하나가 누락된 것을 찾아내는 과정에서 사람은 집중력이 흐려져 결정적인 단서를 빼먹기 쉽습니다. 하지만 AI는 지치지 않고 모든 API 정의를 보안 모델과 체계적으로 대조하기 때문에, 사람이 놓치기 쉬운 미세한 논리적 공백을 잡아내는 데 압도적인 성능을 보여줍니다.

가장 대표적인 사례가 이번에 LLM 워크플로우로 찾은 Grafana의 대시보드 권한 관리 API에서 발견한 권한 상승 취약점(CVE-2026-21721)입니다.

Description

Grafana는 대시보드마다 개별적인 권한(읽기/쓰기/관리)을 설정할 수 있습니다. 정상적인 보안 모델이라면, 사용자는 본인이 '권한 관리자'로 지정된 특정 대시보드에 대해서만 권한 제어 API를 호출할 수 있어야 합니다.

하지만 AI가 찾아낸 허점은 Grafana의 대시보드 권한 관련API(GET/POST/api/dashboards/uid/<uid>/permissions)가 대상 대시보드의 범위(Scope)를 검증하지 않는다는 것이었습니다.

• Root Cause: 내부 권한 검증 로직인 ac.EvalPermission 호출 시, 요청된 대시보드의 UID 스코프를 인자로 전달하지 않고 dashboards.permissions:read/write라는 액션 권한 보유 여부만 확인합니다. 이로 인해 시스템 내에서 단 하나의 대시보드에 대해서라도 Admin 권한을 가진 사용자는 dashboards.permissions:write 액션을 수행할 수 있는 유효한 권한을 얻게 됩니다. 서버는 이 권한이 '어떤 대시보드'를 향하는지 체크하지 않기 때문에, 공격자는 본인에게 접근 권한이 없는 다른 모든 대시보드의 권한 정보를 읽거나 수정할 수 있게 됩니다.

Impact

이 취약점은 특정 대시보드의 관리 권한을 가진 사용자가 조직 내 다른 민감한 대시보드 제어권을 임의로 탈취할 수 있는 심각한 권한 상승(Privilege Escalation) 결함입니다. 공격자는 자신을 다른 대시보드의 Admin으로 등록함으로써 원래 접근 불가했던 데이터에 완전히 접근할 수 있습니다.

최종적으로 이 결함은 CVE-2026-21721 (CVSS 8.1)로 할당되었습니다. 거대한 코드베이스에서 모든 권한을 체크하면서 "여기서 왜 UID 스코프를 검증 인자로 넘기지 않았지?"라는 의문을 갖는 일은 보안 담당자가 실수로 빼먹고 넘어갈 수도 있는 작업이지만, AI는 보안 엔진과의 논리적 불일치를 정확히 짚어냈습니다.

 

전체 보고서는 CVE-2026-21721 에 있습니다.

Other 0-days 

Bug Bounty & CVEs

• CVE-2025-66514 | cvss 5.4 / xss in nextcloud mail | (Bounty Awarded)
• CVE-2025-66558 | cvss 3.1 / Improper Authentication in nextcloud twofactor_webauthn | (Bounty Awarded)
• CVE-2026-0994 | cvss 8.2 / dos in protobuf
• CVE-2026-21721 | cvss 8.1 / Privilege Escalation in grafana | (Bounty Awarded)
• CVE-2026-22922 | cvss 6.5 / Incorrect Use of Privileged APIs in airflow | (Bounty Awarded)
• pending CVEs….

Bug Bounty (No CVE issued)

• Nextcloud Contacts (pre-release) | cvss 6.5 / idor in nextcloud contacts | (Bounty Awarded)
• Matomo | Security issue reported via HackerOne | (Bounty Awarded)
• Matomo Official plugins | Security issue reported via HackerOne | (Bounty Awarded)
• Matomo Official plugins | Security issue reported via HackerOne | (Bounty Awarded)
• Matomo Official plugins | Security issue reported via HackerOne | (Bounty Awarded)
• Grafana | Security issue reported via Intigriti | (Bounty Awarded, pending CVE)
• Owncloud | Security issue reported via YesWeHack | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)
• Discourse | Security issue reported via HackerOne | (Bounty Awarded, pending CVE)

발견한 0-day는 블로그의 about me에서 업데이트됩니다

앞으로의 미래

AI 워크플로우로 취약점을 직접 찾아보면서, 한편으로는 "AI가 이렇게 잘하면, 나중에 내가 설 자리가 있을까?"라는 고민이 깊어졌습니다. 취업까지는 아직 3년 넘게 남았는데, 그때쯤이면 지금보다 훨씬 발전한 AI가 세상을 채우고 있을 테니까요.

보안 업계에 대해 아직 전부 아는 것은 아니지만, 제가 개인적으로 생각하는 미래는 레드팀의 단순 발굴 업무가 꽤 많이 줄어들 것 같습니다. 개발 워크플로우 단계에서 AI가 실시간으로 보안 진단을 수행하며 취약점이 발생할 여지를 미리 차단하고 AI 취약점 분석 에이전트로 취약점을 찾아내는 흐름이 주류가 될 것 같기 때문입니다. 모든 레드팀이 없어지지는 않겠지만 사람이 수동으로 하던 레드팀 업무 중 상당 부분을 AI가 가져가게 될 거라고 생각합니다.

하지만 그렇다고 해서 사람의 역할이 아예 사라지지는 않을 거라고 생각합니다. 발견된 취약점을 비즈니스 상황에 맞춰 어떻게 고쳐야 하는지 전략을 짜거나, 회사의 고유한 보안 정책을 수립하고 운영하는 일은 AI가 아무리 뛰어나도 결국 사람과 함께 논의하며 결정해야 할 영역이라고 봅니다.

그래서 저는 앞으로 두 가지 방향으로 공부를 할 것 같습니다

• 이번 프로젝트처럼 취약점을 찾아내는 AI 워크플로우 자체를 설계하고 만들어내는 AI for Security 공부
• 단순히 취약점을 찾는 레드팀쪽 공부가 아니라 실제 현업 회사에서의 보안 정책과 어떤 구조인지에 대한 블루팀적인 공부

물론 현직자도 아니고 보안을 공부하는 학생의 개인적인 추측일 뿐이지만, 앞으로 올 AI라는 거대한 흐름을 거스르기보다 그 도구를 누가 더 잘 다루느냐가 해커에게 중요한 요소가 될 거라고 생각합니다.