CVE-2026-28158 is an unauthenticated XSS in Do Lasso, and the 'unauthenticated' qualifier is the detail that should keep you up at night. This isn't a case where an attacker needed compromised credentials or insider access — any external actor can trigger the payload by reaching a reflection point that shipped across 358 versions without detection. That span isn't evidence of bad luck; it's evidence of a development pipeline that treats security scanning as a compliance checkbox rather than a functional gate.
The CVSS 7.1 is technically accurate but analytically incomplete. The EPSS of 0.00118 suggests narrow observed exploitability, but that score reflects current attacker interest and published weaponization chains, not inherent code properties. Low EPSS for unauthenticated XSS in production software typically means no one has yet published a reliable exploitation path — not that conditions don't exist. Attackers build weaponization privately before sharing. The absence of public EPSS signal is weak evidence against practical exploitability.
What should drive your response is the blast radius of the underlying failure. A codebase where XSS prevention depends entirely on developer discipline almost certainly has this flaw replicated across dozens of output contexts. The CVE names one reflection point; the process failure that allowed it almost certainly spans many more. XSS in presentation layers follows predictable genealogical patterns — display names, error messages, search results, uploaded filenames rendered back to the user. The next vulnerability in this codebase will likely emerge from the same category of data flow, not a random new vector.
Three architectural questions determine whether patching this CVE prevents the next fifty similar flaws or just this one: First, does your development pipeline have automated XSS detection, and if not, what would it take to add it? Second, is your framework enforcing context-aware output encoding by default, or does every developer have to consciously apply it at every template? Third, what deprecated endpoints, abandoned API routes, and legacy template fragments are still shipping in production but no one actively maintains — the sediment layers that don't get static analysis runs?
The compounding risk doesn't stop at disclosure. Between CVE publication and widespread patch deployment, you have maximum exposure: the vulnerability is public, weaponization guidance is circulating, but remediation in a codebase without automated safeguards requires human intervention across potentially dozens of locations. The organization that shipped 358 versions without catching this flaw is now racing against adversaries who know exactly where to look.
Finally, watch for organizational rationalization that normalizes the risk: 'No one's ever exploited it,' 'the CVSS is only 7.1,' 'we'd need to refactor the entire templating layer.' That normalization is its own form of systemic debt — it makes the next 358-version vulnerability not just possible but probable.