CVE-2026-72585 is a Grafana authorization bypass affecting the delete endpoint for contact points. An Editor can delete a protected notification receiver even though creating one requires the elevated 'alert.notifications.receivers.protected:write' permission. The CVSS of 6.5 reflects the need for Editor access, but the severity score obscures the actual operational risk.
The concerning detail isn't that a check was missed — it's that the 'protected' permission was deliberately designed and documented. Someone defined a security boundary, presumably argued for it in review, and then the delete path simply didn't enforce it. This is the spec-drift pattern: the authorization model exists in documentation while code follows an older mental model. The delete endpoint likely predated the protected concept, and when that feature was added, the check wasn't retrofitted across all affected endpoints.
More troubling is the asymmetry: the permission is called 'protected:write' — the mental model centers on preventing unauthorized creation of sensitive channels (PagerDuty, Slack webhooks, incident management integrations). But the same permission isn't required to destroy those channels. An Editor who couldn't have created a protected contact point can delete one, silently severing alerting chains that incident responders depend on. The blast radius isn't just the deleted receiver — it's every alert rule that references it and every incident that goes unnotified while you debug why the pager didn't fire.
Check your own systems with this lens: whenever you add a permission controlling who can create something, ask whether the same permission should govern its destruction. If your authorization model treats DELETE as the boring inverse of CREATE — assumed to follow automatically from write access — you've got a structural blind spot. The fix isn't just adding the missing check to this endpoint. It's auditing your permission model for creation-deletion symmetry across all sensitive resources, and establishing a process that flags new permissions against all pre-existing CRUD routes. The next feature that adds a 'protected' boundary will have the same gap unless your development workflow catches it.