CVE-2026-47662 exposes a fundamental authorization contract failure in Pathling's pre-2.0.0 release. The framework's documentation explicitly required a dual-authorization model: callers must hold BOTH an operation-level authority (like pathling:search) AND the corresponding per-resource authority (like pathling:read:Patient) — an AND relationship. The implementation, however, treated the @OperationAccess annotation as sufficient on its own. If a caller had the operation authority, they passed the check regardless of whether they possessed the resource-level authority. This effectively collapsed the AND into an OR, silently bypassing the per-resource dimension entirely.

This wasn't a missing permission check or a one-line bug — it was a structural drift between documented security invariants and implemented enforcement. The @OperationAccess annotation became a single chokepoint that developers learned to trust as complete authorization, even though the documented contract required two independent checks. The resource-level dimension simply never executed because every developer assumed it was handled elsewhere in the framework.

If you operate Pathling 1.x, treat all pre-2.0.0 deployments as having had an authorization bypass. Any caller with operation-level access could read, search, or modify resources across all types without the per-resource authority check firing. Audit logs from 1.x versions are unreliable for reconstructing access patterns — the OR shortcut means some authorized operations were never logged as resource-specific.

The 2.0.0 release re-architected authorization to enforce both checks. If you're upgrading, verify that your integration correctly supplies both operation and resource authorities in requests. The fix being a re-architecture rather than a patch confirms this wasn't a simple oversight — it was a structural gap baked into how annotation-driven security distributed (and obscured) the authorization responsibility.

For defenders: audit your current Pathling deployment's authorization configuration against 2.0.0's documented model, ensure your callers are passing both authority types, and review historical access logs from 1.x with skepticism — the dual-check may never have executed.