Meta Muse에 파일 시스템을 요청하자 6.8GB가 왔습니다

AI 요약

작성자는 Meta의 AI 비서 Muse에 접근 가능한 파일을 보관해 Google Drive로 보내 달라고 요청했습니다. Muse는 요청을 수행했고, 압축 파일은 약 2.7GB, 압축을 푼 뒤에는 6.8GB였습니다. 자료에는 세션에 배정된 Linux 환경의 루트 파일 시스템으로 보이는 내용이 들어 있었습니다. Ubuntu 시스템 파일 외에도 Muse 내부 문서와 통합 코드, 앱 템플릿, 메모리 파일, 에이전트 로그, SSH 키 파일이 포함됐습니다. 작성자는 아카이브와 키, 세션 로그를 공개하지 않고 Meta 버그 바운티 프로그램에 신고했습니다. Meta는 신고를 “Not Applicable”로 분류했습니다.

런타임에 들어 있던 자료

파일 대부분은 /home/hatch, /opt/hatch, /opt/hatch-image 아래에 있었습니다. Hatch는 Muse 런타임 파일에 쓰인 Meta의 내부 명칭입니다. 에이전트 홈 디렉터리에는 SOUL.md, IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, TOOLS.md 같은 지침 및 메모리 파일이 있었습니다. 대화 중 기록하는 날짜별 메모리와, 상황·경험·선호로 내용을 정리하는 memory/bank도 발견됐습니다. 에이전트 하위 작업 기록 113개에는 JSONL 추적 자료가 포함됐습니다.

약 20개의 Markdown 문서는 브라우저 사용, 커넥터, 결제, 인증 정보, 데이터 처리, 파일 생성, 음성, 목표, 일정 등을 설명했습니다. WhatsApp, 페어링된 Mac, Tailscale, 기기 통합에 관한 안내도 따로 있었습니다. 문서와 코드에서 약 68개 스킬 디렉터리를 확인했습니다. Google Workspace와 Meta 소셜 앱부터 Outlook, 여행, 쇼핑, 건강 서비스, 홈 기기, 미디어 생성까지 여러 기능을 다뤘습니다. 설정 파일에는 Slack, Dropbox, Polymarket, Canva, Klaviyo 등의 커넥터 이름도 등장했지만, 이것만으로 실제 출시 여부를 확인할 수는 없습니다.

컨테이너와 앱 구성

/opt/hatch/runtime-cell에는 루트 파일 시스템을 만들고 systemd-nspawn으로 실행하며 시작 스크립트와 데몬을 구동하는 파일 18개가 있었습니다. 별도의 runtime-cell.kdl 매니페스트는 이미지의 패키지와 systemd 유닛을 기술했습니다. 작성자는 이 자료로 배정된 Linux 환경이 구성되는 방식을 살펴봤지만, 전체 서비스를 감사하거나 해당 환경 바깥의 인프라를 확인하기에는 자료가 충분하지 않다고 설명했습니다.

가장 큰 코드 프로젝트는 Muse가 앱을 만들고 제공하는 데 쓰는 Spaces 프레임워크였습니다. TypeScript 시작 템플릿에는 React 클라이언트, 서버 액션, Drizzle SQLite 스키마, SQL 마이그레이션, Bun 설정이 들어 있었습니다. 문서·PDF·프레젠테이션·스프레드시트·Markdown 생성기도 있었고, 카드와 영상을 만드는 기능에는 브라우저 캡처 스크립트와 글꼴, 브랜드 에셋이 포함됐습니다.

이미지에는 Codex CLI 0.149.0도 설치돼 있었습니다. 다만 작성자는 Muse가 이를 코딩 에이전트로 사용한다는 증거를 찾지 못했습니다. 확인된 용도는 Codex에 포함된 bubblewrap 샌드박스 바이너리였습니다. Muse는 이를 이용해 ffmpeg와 ffprobe를 네트워크와 추가 권한 없이, nobody 사용자로 실행하고 /input과 /output만 노출했습니다. Codex 관련 임시 파일은 버전 확인 과정에서 생겼으며, Hatch 바이너리의 codex와 gpt-5.5 문자열도 공급자 목록 항목으로 보였다고 설명했습니다.

메모리와 기기 통합

Muse는 메모리를 일반 Markdown 파일로 기록하고 PostgreSQL로 검색합니다. memory.entries에는 텍스트 조각과 줄 참조가, memory.embeddings에는 384차원 벡터가, memory.claims에는 근거와 신뢰도, 상태가 저장됩니다. 새 주장이 이전 주장을 대체할 때는 supersedes_claim_id를 씁니다. 시간 단위 작업은 새 주장을 원래 메시지와 대조하고, 인용문과 메시지 ID를 남깁니다. 기억 삭제도 메모 한 파일을 지우는 데 그치지 않습니다. 관련 주장과 연결 자료를 제거하고 검색 인덱스를 다시 만듭니다.

문서에는 ESP32-C5와 Wi-Fi, Bluetooth LE를 이용하는 실험적 통합 기능 Meta Home Link도 나옵니다. 기기 페어링과 로컬 네트워크 탐색, 별도 승인 단계를 거치는 프록시 접근을 설명합니다. Brother 프린터의 IPP 연결과 Lutron 브리지 안내도 있었습니다. 작성자는 이것이 내부 시제품인지, 제한된 실험인지, 출시 예정 기능인지는 알지 못한다고 밝혔습니다.

확인된 우려와 한계

작성자가 신고한 우려는 일반 대화와 연결된 내보내기 목적지를 거쳐 내부 런타임 파일과 민감 자료가 환경 밖으로 나갈 수 있다는 점입니다. SSH 키 파일이 실제로 활성 상태였는지, 어떤 접근 권한을 제공했는지는 확인하지 못했습니다. 컨테이너 경계를 벗어나도록 가볍게 시험했을 때는 탈출에 성공하지 못했습니다. 프로덕션 시스템에서 발견한 소켓 80개를 더 조사하려다 중단했다고도 밝혔습니다.

Lobsters 댓글에서는 이를 보안 취약점으로 봐야 하는지 의견이 갈렸습니다. 일부는 샌드박스 안의 파일을 내보낸 것만으로는 탈출이나 침해를 입증하지 못하며, 서버리스 런타임의 파일 시스템을 보는 것과 비슷하다고 지적했습니다. 반면 샌드박스 안의 내용은 유출될 수 있다고 가정해야 한다는 의견과, SSH 키가 있었다면 권한을 확인해야 한다는 우려도 나왔습니다. 토론에서는 AI가 사용자 입력을 실행하는 구조에서 입력 검증과 권한 경계를 어떻게 설계할지도 제기됐습니다.

Lobsters 반응

• @FedericoSchonborn — 이 업계는 정말이지 존나 진지하지가 않네요…
• @refi64 — 이게 정말 민감한 정보인가요? 이미지 빌드가 전반적으로 허술해 보이기는 하지만, 실제 악용이나 유출이라는 증거는 없는 것 같습니다. 이런 LLM 클라이언트는 보통 완전히 격리된 VM 안에서 코드를 실행합니다. 그래야 접근 제한이 작업을 방해하지 않으니까요. 컨테이너나 VM 밖으로 나왔다는 증거가 있다면 이야기가 달라지겠지만, 그런 증거는 첨부된 Muse 메시지뿐이고 그건 환각일 수도 있습니다.
  • @Helithumper — 저도 같은 생각입니다. AWS Lambda 함수의 파일 시스템을 가져온 것과 비슷합니다. OpenClaw나 Hermes처럼 샌드박스를 최대한 활용하도록 만든 거잖아요. 원하는 대로 들여다볼 수 있다는 점이 흥미로울 뿐, 비밀은 없는 것 같습니다.
  • @thombles — 그럴 법하지만, 아래에 링크된 마이크로블로그 글에서는 쇼핑 선호도를 파악하고 기록하는 방식 같은 비공개로 보이는 세부 내용까지 더 찾아냈습니다. LLM을 사용자에게 적대적이지 않게 설계했다면 걱정할 일이 별로 없을 수도 있겠네요.
  • @equeue — 동의합니다. 여기서 문제가 뭔지 잘 모르겠습니다. @simonw도 자신이 쓰는 AI 시스템의 도구와 인프라를 “추출”하는 글을 여러 번 썼지만, 보안 조사 결과처럼 취급하지는 않았습니다. SSH 키가 포함된 건 좋지 않지만, 위험도는 그 키가 어떤 권한을 갖는지에 달렸습니다. 어쨌든 이런 시스템은 기능과 견고성을 평가할 수 있도록 인프라를 투명하게 공개해야 합니다.
• @kaimac — 이걸 확인해 준 재미있는 페디버스 글입니다: https://neuromatch.social/@jonny/117324790823856750
• @mandeep — 제대로 된 위협 모델이라면 샌드박스 VM 안의 콘텐츠가 전부 유출될 수 있다고 가정해야 합니다. 비슷한 제품을 만드는 경쟁자에게 도움을 준다는 점 말고는, 보안상 손해가 별로 없어 보입니다. 물론 비밀 키가 잔뜩 들어 있었다면 다른 문제지만, 그럴 것 같지는 않습니다. Meta에서도 확인했다고 합니다: https://x.com/natfriedman/status/2103205193492115903
• @jjdh — JavaScript가 크게 떠오르던 때와 비슷합니다. 사람들이 클라이언트 측 JavaScript에 로그인 로직 같은 걸 넣었다가, 사용자가 코드를 직접 바꿀 수 있다는 사실에 놀랐죠. 여기서는 입력을 정제하기가 훨씬 어려워서 다를까요? 꼭 그렇지는 않을 것 같습니다. 입력란에 u32만 허용하고, 파싱할 수 없는 값은 거부하면 됩니다. 그러면 LLM이 실행하는 텍스트를 포함한 후속 코드가 안전하게 u32라고 가정할 수 있죠. 하지만 우리가 입력을 정제하고 싶어 하지 않는 게 문제입니다. 사용자가 텍스트를 LLM에 주는 방식이 매력적인 기능을 잔뜩 제공하니까요. 모두가 원래 SQL로 말하는 세상에서 SQL을 말하는 데이터베이스가 발명됐다고 생각해 보세요. 사용자가 원하는 결과를 얻도록 SQL을 그대로 입력하게 두고 싶겠지만, 그러면 관리자 비밀번호도 물어볼 수 있습니다.

원문: Mouse.dev / 번역·요약: Trawling