CVE-2026-73140

The patch for CVE-2026-73140 didn't introduce new authorization logic—it reused the existing can_see_comment() function that was already protecting comment retrieval. This is the vulnerability's most important tell. The authorization checks existed in the codebase, but report generation existed as a parallel code path where those protections simply weren't applied. The developers had already solved this problem once for comment display; they just didn't apply that solution to the export function. This reveals a structural weakness that goes beyond this single CVE. When authorization logic is scoped to specific entry points rather than treated as a universal gate, every new data access path becomes a potential gap. Retrieval endpoints get secured because that's where users interact with the system. Export and report functions—built later, often as convenience features—tend to inherit the assumption that 'this is just outputting what the main view shows.' That assumption is wrong, and it's persistent. What makes this worse is what's actually leaking. It's not just comment content—it's authorship. In evaluation or feedback systems, anonymous critical commentary is often a design feature. Exposing who said what defeats that protection entirely and could chill honest feedback if users know their identities aren't actually protected. This compounds the confidentiality impact in ways the CVSS score of 5.3 doesn't capture. If this is an educational or performance-review platform, private feedback represents exactly the kind of sensitive personal data where disclosure causes outsized harm, regardless of what the vector scores. There's also the export blast radius to consider. A retrieval vulnerability is contained—it requires active exploitation and the window closes when patched. An export vulnerability creates artifacts. The Markdown or PDF exists independently of the system, gets attached to emails, stored in folders, forwarded to stakeholders. The vulnerability is patched, but the document is already out. And critically, exported reports expose the authorization logic's shape: users can observe that comments 1-5 are present but 6-12 are missing, meaning metadata about what was suppressed is itself information leakage. The architectural question this CVE forces is straightforward: how do you ensure authorization logic governs all data access paths, not just the primary ones? The pattern of this vulnerability—authorization logic exists, works correctly, but isn't applied to export functions—has appeared in multiple CVEs across authorization-adjacent libraries. Each patch is structurally identical: call the existing authorization function from the new entry point. The fix works, but it doesn't prevent the next export function from replicating the same gap. What prevents this isn't better code review or developer awareness—it's architectural pressure that makes forgotten authorization hurt during development rather than after disclosure. Consider treating any function that aggregates or serializes data as requiring demonstration that it passes through the access-control layer. The path of least resistance should be correct by default, not an extra step developers must remember to add.

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