Imagine two halves of a treasure map. Each half, examined alone, looks like a perfectly ordinary doodle — random lines, nothing suspicious. But overlay them on a lightbox and the X-marks-the-spot appears. That's the core mechanism of LoRango: two LoRA adapters that are individually benign but, when loaded together into a diffusion model, activate a hidden behavior that neither reveals on its own. The committed claim is sharp: individual-adapter safety inspection is fundamentally insufficient for multi-LoRA personalization pipelines. The authors don't just argue this theoretically — they build a working attack that splits a malicious behavior across a Signature adapter and a Payload adapter. The Signature writes a pair-specific activation code into the model's intermediate representations. The Payload contains opposing signal and reference branches that approximately cancel during solo operation, but when the matching Signature's code arrives, code-selective alignment inside native GEGLU gating blocks breaks the cancellation and releases the programmed action. Matched-pair attack success rates hit 97.9% on Stable Diffusion v1.5 and 98.7% on SDXL. Solo loading? 2.8–4.6% false activation — indistinguishable from noise. The architectural cleverness is worth understanding. Both adapters export as ordinary static LoRA weight files. No prompt trigger. No modified pipeline. Standard community loaders (think: AUTOMATIC1111, ComfyUI) load them without complaint. The attack surface is the composition itself — the thing users do every day when they combine a style LoRA with a character LoRA. The Signature-Payload split exploits the mathematical structure of GEGLU (Gated Linear Units with GELU activation), where the gating mechanism naturally provides a code/reader channel that can be trained to be selective. On the ladder: there isn't a rich prior-art baseline for pair-conditioned LoRA attacks specifically. Existing LoRA backdoor work (BadNets-style prompt triggers, Rickrolling-style single-adapter attacks) operates on individual adapters with explicit triggers. LoRango's contribution is showing the trigger can be the identity of the partner adapter itself — no suspicious prompt token needed, no single adapter carrying detectable malicious weights. The authors compare against solo-loaded false positive rates and mismatched-pair rates to demonstrate selectivity, which is the right validation for this threat model, though it's mostly self-benchmarked. Integrity is mixed. The experiments span two major architectures (SD v1.5, SDXL), test pair selectivity, standalone fidelity, and robustness to deployment variations — a reasonably thorough protocol for a new attack category. But the validation is entirely same-team, the benchmarks are bespoke (no community red-teaming benchmark exists for this attack class yet), and there's no independent replication. The paper is honest about what it measures, but the absence of a defense evaluation is notable — the authors motivate auditing compositions but don't test whether any existing defense catches them. The milestone question is about the defense side. Today: 98% attack success, near-zero solo detection. The next number that matters isn't a bigger attack — it's a compositional auditing tool that can flag pair interactions without exhaustively testing every N-choose-2 combination. For a platform hosting 100,000 LoRAs, that's ~5 billion pairs. Any practical defense needs sub-quadratic screening or structural signatures that can be detected from weight inspection alone. That's the gap. The obvious experiment not run: a defense. The authors demonstrate the attack comprehensively but don't evaluate whether weight-space analysis (spectral signatures, activation clustering, or even simple cosine similarity between LoRA weight matrices) could detect Signature-Payload pairs. My read: this is a deliberate scope choice, not a gap they couldn't fill. The attack paper establishes the threat; the defense paper is the natural sequel, probably already in progress. This is standard responsible-disclosure pacing in adversarial ML — establish the threat model cleanly, then build the fix.
