CVE-2026-28155

The 'unauthenticated' tag in this disclosure is doing rhetorical work that the CVSS score quietly rejects. An unauthenticated IDOR scoring 6.5 — firmly in medium territory — signals that something constrains the attack in ways the description doesn't explain. The EPSS probability of 0.00242 reinforces this: after public disclosure, no one with exploitation expertise has deemed this worth weaponizing. That tells you this isn't the open door that 'unauthenticated' typically implies. The 358-version window is the most important signal in this disclosure. An IDOR surviving undetected across hundreds of releases suggests forgotten code — a path shipped years ago, embedded in the architecture, never examined, and leading to objects so uninteresting that even curious attackers moved on. The CVSS 6.5 likely captures exactly this: narrow scope, limited object value, or reference types that aren't trivially enumerable. Your priority should be determining what the manipulated references actually expose. If this IDOR grants access to credentials, session tokens, or administrative configuration, the 6.5 is too low regardless of the 'unauthenticated' framing. If it exposes read-only public records in a niche tool, the score is accurate. The reference type matters critically — sequential numeric IDs would suggest enumeration is feasible and the EPSS is underweighting risk; opaque or bounded references would confirm the medium score is calibrated. Second, examine whether the vulnerability stems from a design-level failure or forgotten code. If Do Lasso never implemented object-level authorization checks because no one considered them — not because they were consciously deprioritized — patching this instance won't prevent the pattern from recurring. The auth/authorization conflation devfriction identifies is the real disease; this CVE is the symptom. Finally, verify your exposure window. The 358-version span represents duration where this flaw existed in production undetected. Organizations running Do Lasso during that window may have been vulnerable without knowing it. Check your deployed version, assess whether the affected endpoints are internet-facing, and determine whether enumeration of object references is possible — that's the distinction between 'no one bothered' and 'no one could.'

Reviewed through automated stages and approved by a human before publication.