Omniscience for the Masses: New Threats in the Metaverse's Democratized World Creation

• Source: arXiv cs.CR 2609.12554 / ACM CCS 2026
• Authors: Andrea Mengascini, Ryan Aurelio, Jason Polakis, Giancarlo Pellegrino
• Original URL: https://arxiv.org/abs/2609.12554
• Archived original: 원문.pdf
• SHA-256: eeed49aabcdda6565f4a04cbdd08d9fc0087886fc7b119f0e9a6dd28a8a7a791
• Tags: Metaverse, Authorization, Business Logic, Privacy, VR, User-Generated Content, Platform Security

본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.

한눈에 보기

이 논문은 Roblox, Horizon Worlds, VRChat처럼 일반 사용자가 직접 virtual world를 만들어 공개할 수 있는 metaverse 플랫폼에서 새로운 권한 경계를 지적한다.

기존 threat model은 흔히:

Developer = 높은 권한
User = 낮은 권한

으로 나뉜다.

하지만 world creator는 일반 사용자 계정이면서도 자신이 만든 world 안에서는:

• geometry
• visual rendering
• audio behavior
• avatar interaction
• game/event logic
• scripting 또는 visual programming

등을 광범위하게 제어한다.

연구진은 이 역할을 “개발자는 아니지만 다른 사용자의 감각 환경을 프로그래밍할 수 있는 제3의 권한 주체”로 본다.

핵심 발견은 소프트웨어 취약점을 exploit하지 않아도 공식 world-creation 기능만으로 사용자의 공간적·시각적·청각적 privacy expectation을 깨고 covert surveillance/manipulation이 가능하다는 것이다.

연구진은:

• world creation 지원 플랫폼 25개 조사
• 19개 creation tool 직접 탐색
• 14개를 완전히 분류
• 대표 5개 플랫폼에서 심층 분석
• 5개의 새로운 creator-capability attack 구현
• 기존 연구의 공격 5개를 creator 권한만으로 재현

했다.

연구 배경

Metaverse의 privacy는 단순 access-control dialog만으로 만들어지지 않는다.

사용자는 실제 공간과 비슷한 감각적 cue를 보고 privacy를 추론한다.

예를 들어:

• 벽이 있으면 반대편에서 보이지 않을 것
• 문이 닫혀 있으면 분리된 공간일 것
• 거리가 멀어지면 목소리가 들리지 않을 것
• private room에 들어가면 외부 사용자는 대화를 듣지 못할 것

이라고 기대한다.

플랫폼도 visual occlusion, spatial audio attenuation, private room 같은 기능을 통해 이런 mental model을 강화한다.

문제는 world creator가 바로 이 cue를 만드는 주체라는 점이다.

즉 사용자가 “플랫폼이 제공하는 privacy property”라고 생각한 것이 실제로는 creator가 작성한 world logic의 결과일 수 있다.

공격 모델 / 전제 조건

공격자는 malicious world creator다.

중요하게도 연구는 강한 공격 권한을 가정하지 않는다.

공격자가 할 수 있는 것:

• 일반 계정 생성
• 공식 world creation mode/editor/SDK 사용
• 자신의 world publish
• geometry/material/assets 구성
• platform이 허용하는 script 또는 visual logic 작성
• 필요하면 자신의 world에 일반 participant로 입장
• 복수 계정 사용

공격자가 할 수 없다고 가정하는 것:

• platform backend DB 접근
• platform-wide admin 권한
• low-level network interception
• client memory corruption
• authentication bypass
• unintended API 호출
• 다른 creator world 수정

즉 공격은 legitimate creator capability의 악의적 조합이다.

핵심 Root Cause

Root Cause는 “VR 플랫폼에 권한이 너무 많다”로만 보면 부족하다.

핵심은 세 층의 mismatch다.

1. Creator capability와 user mental model의 불일치

사용자는 wall/door/distance를 security boundary처럼 해석한다.

하지만 creator에게는 그것들이 단지 rendering/game-logic object일 수 있다.

따라서:

사용자가 보는 boundary
≠
플랫폼이 강제하는 confidentiality boundary

가 된다.

2. Content vetting과 behavior vetting의 불일치

많은 platform vetting은 다음을 잘 본다.

• 부적절한 asset
• prohibited text/image
• overtly malicious content

하지만 creator logic이 runtime에:

• 어떤 user state를 읽는지
• 누구의 audio/visual data를 어디에 전달하는지
• privacy cue를 어떻게 우회하는지

를 semantic하게 검증하지 못한다.

3. Creator 권한에 대한 runtime transparency 부족

강한 creator behavior가 있더라도 사용자에게:

• creator가 현재 관찰 중인지
• invisible observer가 존재하는지
• audio가 정상 범위를 넘어 전달되는지
• private-looking 공간이 실제로 private하지 않은지

를 알려주는 명확한 indicator/permission model이 부족하다.

따라서 본질적인 문제는:

world creator에게 다른 사용자의 감각·상호작용 환경을 프로그래밍할 권한을 주면서, 그 권한을 사용자에게 security-relevant privilege로 노출하거나 제한하지 않은 것

이다.

핵심 공격 원리

논문이 구현한 새로운 공격들은 세 범주로 이해하면 좋다.

Spatial constraint violation

사용자가 room/wall/distance로 분리됐다고 믿는 공간 관계를 creator logic이 무시하고 다른 위치의 상태를 수집하거나 전달한다.

Visual constraint violation

정상적인 line-of-sight/occlusion과 별개로 creator가 정의한 object/camera/rendering logic을 이용해 사용자가 “보이지 않는다”고 믿는 상황의 정보를 creator 측에 노출하거나 사용자에게 보이는 장면을 조작한다.

Auditory constraint violation

spatial audio의 거리 감쇠나 room separation이 confidentiality boundary라고 사용자가 생각하지만 creator logic은 audio-related interaction primitive를 다른 방식으로 연결할 수 있다.

중요한 것은 이 공격들이 platform sandbox 탈출이 아니라 sandbox가 원래 허용한 기능 안에서 일어난다는 것이다.

공격 흐름

일반화하면 다음과 같다.

일반 사용자 → world creator 전환
→ 정상 editor/SDK로 world 제작
→ privacy를 연상시키는 공간/visual/audio cue 구성
→ 동시에 creator-only logic으로 cue와 실제 정보 흐름을 분리
→ 피해 사용자가 world에 입장
→ 사용자는 정상 공간적 privacy를 기대
→ creator logic은 covert observation / manipulation 수행
→ 사용자에게 별도 경고 없음

이 공격 모델은 phishing과도 비슷한 면이 있다.

공격자는 platform 자체를 깨지 않고 platform이 정상적으로 제공하는 표현력과 사용자의 trust model 사이의 차이를 이용한다.

성공 조건 / 실패 조건

성공 조건

• 일반 사용자가 비교적 쉽게 world creator가 될 수 있음
• creator tool이 충분한 scripting/logic expressiveness를 제공
• user/avatar/audio/visual state에 접근 가능한 primitive 존재
• 해당 primitive 사용이 별도의 privileged permission으로 표시되지 않음
• publish-time vetting이 behavior까지 충분히 분석하지 못함
• runtime에 사용자-facing indicator가 부족

실패/완화 조건

• creator가 민감한 user state를 읽을 때 명시적 permission 필요
• private room/audio zone을 platform runtime이 creator script와 독립적으로 enforce
• creator observation capability 사용 시 participant에게 indicator 제공
• behavior-level static/dynamic vetting
• risky API에 capability declaration 적용
• world 실행 중 data flow audit 및 정책 enforcement
• private mode에서는 creator script가 다른 participant sensory stream에 접근하지 못하게 제한

연구진의 실험 환경

연구진은 25개 후보 플랫폼을 조사했다.

selection 기준은 대략:

• VR 지원
• multiplayer
• 일반 사용자 접근 가능
• user-created world 기능 존재

였다.

두 연구자가 documentation/tutorial/manual을 독립적으로 검토했고:

• 25개 후보 조사
• 19개 creation tooling 직접 탐색
• 14개 완전 categorization
• 대표적인 5개 플랫폼에서 공격 구현/심층 분석

을 수행했다.

논문에서 반복적으로 언급되는 대표 ecosystem에는:

• Horizon Worlds
• Roblox
• VRChat

등이 포함된다.

단, “25개 플랫폼 모두에서 모든 공격이 그대로 된다”는 의미는 아니다.

주요 실험 결과

연구진은 creator capability를 이용한 신규 공격 5개를 설계·구현했고, 기존 연구가 더 강한 client/developer capability를 가정했던 기존 공격 5개도 표준 world-creation 기능만으로 재현 가능함을 보였다.

이 결과의 중요한 의미는 공격 기술 하나하나보다 공격 비용의 하락이다.

이전에 어떤 attack이:

client modification
또는
developer-level privilege

를 필요로 했다면, 이제는:

일반 계정
→ world creator
→ 공식 editor

수준으로 내려올 수 있다.

즉 exploit sophistication보다 권한 위임 모델의 민주화 자체가 threat surface를 확장한다.

실제 발견된 취약점 / 사례

이 연구는 CVE를 나열하는 논문이 아니다.

오히려 platform design에서:

• ordinary user가 creator가 될 수 있음
• creator가 매우 표현력 높은 runtime logic을 제어
• users는 creator를 admin/developer 수준의 privileged actor로 인식하지 않음
• vetting/permission/UI가 그 권한 수준을 반영하지 않음

이라는 systemic issue를 보여준다.

따라서 “Roblox의 특정 버그 5개” 식으로 이해하면 틀리다.

연구의 공격들은 정상 제공 기능의 policy/authorization design 문제에 가깝다.

저자 주장 vs 실제 증명 범위

증명한 것

• 대표 플랫폼들의 creation tool이 공격에 필요한 강한 runtime capability를 제공
• 공식 creator tooling만으로 신규 surveillance/manipulation attack 구현 가능
• 기존 공격 중 일부의 권한 요구 수준을 creator 수준으로 낮출 수 있음
• 현재 content vetting 및 runtime warning/permission만으로 충분히 막기 어려운 사례 존재

증명하지 않은 것

• 모든 metaverse world가 악성 creator에 취약
• 모든 25개 플랫폼에서 동일 attack이 성공
• platform sandbox escape가 가능
• creator가 platform-wide user data를 열람 가능
• 서버 DB나 다른 world까지 침해 가능

공격 범위는 creator가 제어하는 world/instance 안이다.

기존 공격 / 기존 점검 방식과의 차이

기존 VR/metaverse 보안 연구는 흔히:

• malicious app/developer
• malicious client
• sensor side channel
• memory/network manipulation
• platform vulnerability

을 본다.

이번 연구는 공식 UGC creator role 자체를 threat actor로 본다는 차이가 있다.

웹 보안에 비유하면:

“관리자 권한 탈취”가 아니라 “정상 tenant admin이 자기 tenant의 다른 사용자에게 어디까지 보이지 않는 영향을 줄 수 있는가”를 보는 multi-tenant authorization 문제

와 가깝다.

연구의 한계와 주의해서 볼 부분

• 실제 피해자 규모를 측정한 longitudinal abuse study는 아니다.
• 공격 practicality는 플랫폼별 editor/API 표현력에 따라 크게 달라진다.
• world에 사용자를 유인하는 방법은 연구 범위 밖이다.
• creator world 내부 capability에 초점을 두며 platform backend compromise는 다루지 않는다.
• 사용자 privacy expectation에 관한 가정은 기존 user-study 근거를 활용하지만 모든 사용자에게 동일하지 않을 수 있다.
• 플랫폼은 빠르게 API/editor/policy를 변경하므로 attack surface도 변할 수 있다.

공개 PoC / Exploit / Tool / Artifact 분석

이번 확인 범위에서 별도의 범용 exploitation framework나 자동 공격 tool repository는 확인하지 못했다.

논문은 platform 공식 editor/SDK를 이용해 attack prototype을 구현한 연구다.

따라서 공개 artifact를 평가할 때는:

• 공격 아이디어와 구현 결과: 논문에서 상세 기술
• platform-specific world project/source 전체 공개 여부: 별도 확인 필요
• 범용 자동화 exploit tool: 확인되지 않음

으로 구분하는 것이 안전하다.

이 연구의 재현 포인트는 “exploit 코드를 실행”하는 것보다 world creator에게 노출된 API/capability를 inventory하고 privacy boundary와 비교하는 데 있다.

레드팀 / 모의해킹에서 어떻게 활용할까

이 논문의 방식은 metaverse뿐 아니라 UGC / low-code / workflow / tenant scripting platform 점검에 매우 유용하다.

핵심 질문은:

일반 사용자가 “creator” 역할을 얻었을 때, 다른 사용자의 security expectation을 깨는 기능 조합이 생기는가?

이다.

예를 들어:

• 협업 플랫폼의 custom app
• game mod/map creator
• low-code dashboard
• workflow automation
• plugin marketplace
• tenant admin scripting
• browser extension builder

에도 같은 질문을 적용할 수 있다.

점검 전략

1. creator role을 “일반 사용자보다 조금 높은 편집자”가 아니라 별도 threat actor로 정의
2. creator가 읽을 수 있는 다른 사용자 state inventory
3. creator가 조작할 수 있는 UI/notification/sensory cue inventory
4. user가 믿는 boundary와 실제 runtime enforcement 비교
5. publish-time review와 runtime behavior가 같은 것을 보고 있는지 확인
6. 민감 capability 사용 시 사용자에게 visible signal이 있는지 확인

실무 가치 평가

★★★★☆ — 높음

직접적인 웹 침투 PoC는 아니지만 권한 설계와 trust boundary 점검 사고방식이 매우 좋다.

특히 “버그가 없어도 취약할 수 있다”는 점이 중요하다.

정상 권한만 이용해도 사용자가 기대하는 confidentiality/integrity를 깨는 구조라면 그것은 security design issue다.

레드팀에서는 앞으로 creator/admin/plugin/workflow 같은 중간 권한 역할을 만났을 때:

이 역할이 정상적으로 갖는 기능을 조합하면
다른 사용자의 security boundary를 조용히 넘을 수 있는가?

를 별도 시나리오로 추가할 가치가 있다.

결론

이 논문이 보여주는 핵심은 metaverse 특유의 VR 공격 그 자체보다 “민주화된 생성 권한”이 새로운 privileged role을 만든다는 점이다.

사용자는 일반 사용자로 보이는 creator를 신뢰하지 않지만, 플랫폼은 creator에게 사실상 환경 관리자 수준의 표현력을 줄 수 있다.

그리고 그 권한이 UI/permission/runtime policy에 제대로 드러나지 않으면, software exploit 없이도 surveillance와 manipulation이 가능해진다.

UGC 플랫폼을 점검할 때는 기능 목록보다 creator capability → 다른 사용자 관찰/조작 → 사용자에게 보이는 경계/경고의 연결을 보는 것이 핵심이다.