Mythos가 찾은 HFS 취약점, AI는 문제를 어디까지 따라갈까

AI가 찾아낸 보안 문제가 실제 공격에서도 관측됐습니다. 보안기업 Horizon3가 Anthropic의 Mythos를 활용해 발견한 HFS 취약점입니다. 파일을 공유하는 서버에서 관리자인 것처럼 행동하고, 서버에 코드를 실행할 수 있는 문제였습니다. VulnCheck는 10월 1일부터 이 취약점의 악용을 관측했다고 밝혔습니다.

수정 버전은 이미 7월 13일에 나왔습니다. 9월 30일 공개된 것은 Horizon3가 Mythos로 이 문제를 어떻게 찾아냈는지 설명한 상세 연구입니다. 그 다음 날 공격이 관측됐지만, 패치가 없던 취약점이 갑자기 등장한 상황은 아니었습니다.

이 소식에서 눈여겨볼 부분은 AI가 문제를 따라간 과정입니다. 코드에서 이상한 부분 하나를 발견하고 끝낸 것이 아니라, 다른 곳에 있는 문제와 연결하고 실제로 어떤 일이 가능한지까지 확인했습니다. AI에게 코드를 읽히는 일이 어디까지 이어질 수 있는지 보여주는 사례입니다.

파일을 공유하는 서버에서 무슨 일이 있었을까

HFS는 다른 사람과 파일을 주고받을 수 있게 해주는 오픈소스 서버입니다. 이번 문제의 이름은 CVE-2026-61500입니다. 긴 번호는 보안업체와 개발자가 같은 취약점을 가리킬 때 쓰는 식별표라고 생각하면 됩니다.

문제는 서버가 로그인한 사용자를 알아보는 방식에 있었습니다.

웹사이트에 로그인하면 페이지를 옮길 때마다 비밀번호를 다시 입력하지 않습니다. 서버가 로그인 상태를 알아볼 수 있도록 세션 정보를 사용하기 때문입니다. 여기에 서명을 붙이면 그 정보가 중간에 바뀌지 않았는지 확인할 수 있습니다. 출입증에 위조 방지 표시를 붙여두는 것과 비슷합니다.

그런데 그 표시를 만드는 비밀 키를 다른 사람이 알아낼 수 있다면 어떻게 될까요. 위조한 출입증도 정상적으로 발급된 것처럼 보일 수 있습니다.

VulnCheck의 권고문에 따르면 취약한 HFS는 서명 키를 만들 때 암호학적으로 안전하지 않은 난수 생성 방식을 사용했습니다. 같은 난수 생성기에서 나온 값 일부가 로그인 과정에서 외부에 드러나는 문제도 있었습니다. 이 두 가지가 연결되면서 관리자의 세션을 위조하고, 서버의 코드 실행 기능에 접근할 수 있게 됐습니다.

비밀번호를 알아맞히는 공격과는 출발점이 다릅니다. 서버가 누군가를 관리자로 믿게 만드는 근거를 건드린 것입니다.

Mythos가 연결한 두 가지 문제

코드를 검토하다 보면 의심스러운 부분을 발견할 수 있습니다. 하지만 그 지적만으로 실제 피해를 설명할 수 있는 것은 아닙니다. 외부에서 그 부분에 접근할 수 있는지, 필요한 정보를 얻을 수 있는지, 다른 기능과 연결했을 때 무엇이 가능한지를 더 살펴봐야 합니다.

Horizon3의 연구에서 흥미로운 대목이 여기에 있습니다.

연구팀은 Mythos가 안전하지 않은 난수 사용을 발견하는 동시에, 다른 코드 경로에서 관련 정보가 새어나오는 부분도 찾아냈다고 설명했습니다. 그리고 두 문제가 함께 있을 때 비밀 키를 알아낼 수 있다는 점을 연결했습니다.

이 과정에는 수학적 조건을 푸는 도구도 쓰였습니다. 여러 조건을 만족하는 값을 찾는 도구를 이용해 가능성을 확인하고, 실제로 작동하는 검증 코드를 만들어 명령 실행까지 시연했다는 것이 Horizon3의 설명입니다.

개별 문제를 따로 보면 지나칠 수 있는 관계를 끝까지 따라간 셈입니다. 문에 약점이 있다는 사실을 아는 것과, 그 문으로 어디까지 들어갈 수 있는지 확인하는 일 사이에는 여러 단계가 있습니다. 이번 연구는 AI가 그 중간 과정을 얼마나 맡을 수 있는지 생각하게 합니다.

보안 연구에서 AI에게 맡길 일이 달라질까

물론 Mythos가 혼자 대상을 정하고 모든 연구를 수행한 것은 아닙니다. Horizon3는 자체 연구 시스템 안에서 여러 전문 에이전트가 취약점 유형별로 코드를 살피고, 다른 에이전트가 발견 내용을 검증하도록 구성했습니다. 사람이 만든 연구 환경에서 나온 결과입니다.

이 구성을 보면 AI를 보안 연구에 쓰는 방식도 조금 다르게 보입니다. 코드 전체를 넣고 위험한 부분을 표시해 달라는 요청에서 한 걸음 더 나아갈 수 있기 때문입니다. 발견한 문제가 실제로 성립하는지 확인하고, 그 결과를 다시 검토하는 작업까지 하나의 흐름으로 묶는 것입니다.

이런 방식이 유용하려면 설명을 그럴듯하게 만드는 능력만으로는 부족합니다. 앞에서 세운 가정이 맞는지 확인해야 하고, 검증 결과가 예상과 다르면 다시 살펴봐야 합니다. 사람이 결과를 받아봤을 때 왜 위험한지 따라갈 수 있어야 합니다.

보안 검토를 받는 개발팀 입장에서도 차이가 있습니다. ‘이 코드가 위험할 수 있다’는 지적보다 ‘이 기능과 연결되면 이런 권한을 얻을 수 있다’는 설명이 수정의 우선순위를 정하는 데 도움이 됩니다. 문제의 위치와 함께 영향까지 이해할 수 있기 때문입니다.

이번 한 사례로 모든 프로젝트에서 같은 결과를 낼 수 있다고 보기는 어렵습니다. 다만 AI의 보안 연구 능력을 볼 때, 몇 개를 찾아냈는지에 더해 발견 이후의 검증을 어디까지 이어갔는지도 중요한 기준이 될 수 있습니다.

패치는 연구 공개보다 먼저 나와 있었습니다

이번 사건의 시간표를 다시 보면 또 다른 부분이 보입니다.

VulnCheck의 최초 권고문과 HFS 3.2.1 수정 버전은 7월 13일 공개됐습니다. 영향을 받는 범위는 HFS 3.0.0부터 3.2.0까지입니다. 이 버전을 사용 중이라면 3.2.1 또는 해당 수정이 포함된 이후 버전으로 업데이트할 필요가 있습니다.

Horizon3의 상세 연구는 9월 30일 나왔고, VulnCheck의 10월 2일 보고서는 10월 1일부터 악용을 관측했다고 전했습니다. 연구 공개일과 최초 취약점 공지일은 서로 다릅니다.

최초 공개와 수정 버전은 7월 13일, 상세 연구는 9월 30일에 나왔습니다. 10월 1일은 VulnCheck의 악용 관측 시작일입니다.

출처: 자료 VulnCheck·Rejetto HFS·Horizon3. 편집·도식 VECTORLOG.

공개된 자료로 공격 대상 서버의 업데이트 이력까지 알 수는 없습니다. 공격자가 Mythos나 다른 AI를 사용했다는 근거도 제시되지 않았습니다. 여기서 확인되는 AI의 역할은 Horizon3의 취약점 연구입니다.

VulnCheck 공식 보고서의 해당 취약점 제목. 아래 한국어 문구는 보고서의 관측 내용을 요약한 것입니다.

출처: 제목 화면 캡처 VulnCheck, 한국어 요약·편집 VECTORLOG. 2026년 10월 5일 확인.

그래도 패치가 먼저 나와 있었다는 사실은 이 소식을 조금 다르게 읽게 합니다. 새 취약점을 발견하는 기술이 발전하더라도, 이미 확인된 문제를 운영 환경에서 고치는 일은 계속 남습니다. 수정 버전이 배포됐다는 소식과 실제 서비스가 그 버전으로 바뀌었다는 확인은 별개의 단계이기 때문입니다.

잘 찾아내는 AI 다음에 남는 일

AI가 코드 속 문제를 더 깊게 살필 수 있다면 방어하는 쪽에도 기회가 생깁니다. 이전에는 충분히 검토하지 못했던 부분을 살펴보고, 따로 보았던 문제 사이의 관계를 확인할 수 있습니다. 이번 HFS 연구는 그 가능성을 구체적인 소프트웨어에서 보여줬습니다.

동시에 발견된 문제를 받아 처리하는 과정도 중요해집니다. 연구 결과가 개발팀의 수정으로 이어지고, 그 수정이 실제 서비스에 반영되어야 위험을 줄일 수 있습니다. AI가 찾아낸 내용이 보고서에 남는 데서 끝나면 그 뒤의 일은 그대로 남습니다.

앞서 살펴본 AI Agent 실행 환경의 안전장치도 모델의 능력과 실제 운영을 함께 생각하게 하는 소식이었습니다. AI가 더 많은 일을 할 수 있게 될수록, 그 결과를 받아들이는 시스템도 같이 갖춰져야 합니다.

Mythos의 HFS 연구에서 관심을 둘 부분은 AI가 취약점을 하나 찾았다는 사실만이 아닙니다. 떨어져 있는 문제를 연결하고, 가능한 결과를 검증하는 과정까지 들어왔다는 점입니다. 이제 그 발견을 실제 수정과 적용으로 이어가는 일도 함께 봐야 할 것 같습니다.