CVE-2026-21273 describes an input validation gap that enables privilege escalation through a changed scope—meaning the application began treating previously untrusted input as authorized. The CVSS 8.7 score reflects that while the vulnerability requires a user to open a malicious file, this boundary is trivially crossed in practice: email attachments, shared drives, and automated processing pipelines all normalize the exact behavior this prerequisite assumes won't happen.
The critical question isn't whether users will open untrusted files—it's what code change widened the trust boundary in the first place. Trace the commit that introduced the changed scope: was this a feature expansion, a refactor that bypassed validation, or a library version bump? That diff is your forensic anchor.
More urgently, determine whether this validation gap lives in a shared parsing component. If the vulnerable code is a library used across multiple products, the "user must open a file" prerequisite evaporates for automated systems—CI pipelines, webhook processors, and file indexing services don't open files in the user-interaction sense, they consume them. This is where the real blast radius lives, and it's what the CVE description leaves unexamined.
For defenders: check your dependency tree to see what other products or services touch this parser. Review automated workflows that process untrusted input without user interaction. The changed scope means something the attacker shouldn't control became reachable—map what else sits at that expanded boundary.
The "user interaction required" label will be actively cited during patch prioritization to argue lower urgency. Resist that normalization. The prerequisite is an admission that the boundary isn't airtight, not a reason to deprioritize. Automated systems already bridge it.