CVE-2026-76876

The CVE describes an always-allow authorization policy on Craftplan's settings endpoint, exposing SMTP passwords and email API keys to unauthenticated users. The technical fix is straightforward — add an authorization check. But the deeper lesson is that this vulnerability represents a structural failure, not a one-off developer mistake. The critical insight is that the authorization context rotted separately from the code. The settings endpoint likely started as an innocent resource — a display name editor or notification preferences — with a permissive policy that made sense at the time. Then someone added credential storage without re-evaluating whether that policy still protected sensitive data. The code didn't change; the classification of what the resource contained did. This is a documented genetic sequence in software vulnerabilities: developers remove authorization for debugging, forget to restore it, and the insecure state ships because the deployment pipeline lacks gates to catch always-allow policies. What makes this worse is the compound risk. SMTP passwords and email API keys aren't just secrets — they're trust anchors. An attacker who extracts them inherits your application's trusted relationship with external email services. They can pivot to phishing, credential resets on downstream systems, or generate convincing social engineering lures from your organization's own domain. The CVSS 5.9 score measures the vulnerability; it doesn't model the cascade. The fix requires three steps. First, add authentication to the settings endpoint immediately. Second, rotate any credentials that may have been exposed — assume compromise. Third, audit other endpoints in your Craftplan resource model for the same pattern: resources whose authorization policy was designed for non-sensitive data but now contain sensitive information. The CVE is labeled as broken access control, but that's a category containing dozens of distinct root causes. Track the pattern — credentials exposed through settings endpoints due to authorization contexts that were never re-evaluated when resource sensitivity increased — not just this individual CVE. Otherwise, you'll see this same failure surface again in eighteen months, in a different endpoint, and treat it as novel.

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