XR / Spatial Computing

CAESAR Attacks Its Own Users to Find Out What Breaks Them

An ISMAR 2026 testbed for collaborative mixed reality that builds four classes of perceptual attack into a shared search-and-rescue scenario — and measures what added latency does to a team.

Mixed reality security has a problem that ordinary software security does not. If an attacker corrupts a spreadsheet, you get a wrong number and you can check it. If an attacker corrupts a headset’s view of the room, you get a wrong perception, and the instrument you would use to check it is the thing that has been corrupted.

CAESAR: Mixed Reality Search-and-Rescue Platform for Cognitive Attack Evaluation (arXiv:2610.27654) is a testbed for studying that properly. Posted 20 October 2026, with a long author list — Mingyu Zhu, Jiangong Chen, Yu Liu, Hillmer Chona, Zifan Zhou, Jianan Jiang, Jonathan Dodge, Feng Qian, Mahdi Imani, Tian Lan, Gang Tan and Bin Li — and accepted to IEEE ISMAR 2026, selected for publication in the IEEE TVCG special issue.

What a cognitive attack is

The paper’s definition is the useful part: attacks that “subtly distort visual feedback, virtual content, or system synchronization.”

Note all three nouns. Visual feedback is the obvious one — change what the user sees. Virtual content is the next step — change the annotation, the waypoint, the label on the hazard. System synchronisation is the one that only exists in collaborative XR, and it is the interesting one: leave every user’s view individually correct, and simply make them disagree about when. Nobody sees anything false. The team still falls apart.

The word “subtly” is load-bearing. An attack that blacks out the display is a denial of service, and the user knows. An attack that shifts a waypoint two metres is a lie the user will act on.

Why a shared testbed, and why search-and-rescue

The authors’ stated gap is that prior MR security work examined individual attacks, usually in isolated or single-user settings, and lacked standardised collaborative testbeds. That is a familiar pattern in young security subfields: a series of one-off demonstrations that each prove an attack is possible and none of which can be compared with each other.

CAESAR is an end-to-end, multi-user framework with a modular architecture that integrates four classes of cognitive attack into one synchronised collaborative scenario, plus a multimodal pipeline collecting behavioural, performance and subjective data.

Collaborative search-and-rescue is a well-chosen scenario rather than a decorative one. It is safety-critical, so the stakes justify the framing. It requires spatial coordination, so synchronisation attacks have somewhere to bite. It has a measurable objective — did you find the thing, how long did it take — so performance degradation is quantifiable rather than impressionistic. And it is a domain where MR training is genuinely deployed, so the threat model is not hypothetical.

The first study

A controlled user study analyses a latency-based attack in depth, reporting measurable effects on task performance and user behaviour, and characterising users’ subjective experience under adversarial conditions.

Latency is the right first target, because it is the attack with the best deniability. Networks are slow. Headsets drop frames. A user who experiences 200 ms of added delay does not conclude they are under attack; they conclude the equipment is bad, and they adapt — moving more slowly, double-checking, waiting for their teammate. Those adaptations are the damage. The team’s tempo drops and its trust in the system drops, and nothing anywhere logs an error.

For anyone building collaborative XR with no adversary in mind at all, that is the transferable finding: your system’s behaviour under degraded synchronisation is a design surface, not an edge case. The same mechanisms a security researcher induces deliberately occur naturally on a congested venue Wi-Fi network, which is where most multi-user XR art actually runs.

What the entry withholds

The arXiv abstract gives no headset or hardware specifics, no participant numbers, no study conditions and no quantitative results. For a paper whose contribution is partly a reusable testbed, the most important unanswered question is whether CAESAR itself is being released — nothing in the listing says so, and a standardised testbed that nobody else can run does not standardise anything.

The venue is real, though, and that distinguishes this from most of what we read on /new: ISMAR 2026 acceptance plus a TVCG special issue is about as solid as XR publication gets. The full paper should carry the numbers the abstract does not.

Sources