CVE-2026-72910 exposes five functions across four modules — account management, job processing, invoice handling, and utilities — that lack required write permission checks. The functions were added independently over time by different developers in different parts of the codebase, and all five landed on the same side of the security ledger. This isn't coincidence. It's the predictable output of a framework that treats permission checks as optional boilerplate developers must remember to write, rather than mandatory scaffolding the framework enforces automatically.
The critical distinction in this vulnerability class is between user-facing endpoints and internal utility functions. The job pause/trigger functions appear to be internal hooks that other functions call, not direct user endpoints. If those utilities omit permission checks, every caller that believes it's protected by its own permission context and then delegates to an unprotected utility has its permission chain silently bypassed. That's a different vulnerability shape than a user-facing function missing a decorator — it's a propagation depth problem invisible without interprocedural taint tracking.
This pattern has appeared before. CVE-2019-10085 in a similar Python web framework and CVE-2021-32815 in an ERP-adjacent system both exploited utility functions that bypassed decorator-based permission checks because the decorator only wrapped entry points, not the delegation chain beneath them. When frameworks rely on developer-applied permission decorators rather than mandatory middleware enforcement, this failure mode recurs approximately every 18-24 months across different codebases. The architecture makes forgetting structurally cost-free until exploitation occurs.
What you should check: examine the call graphs for any functions that delegate to these five utilities — if callers have permission checks but the utility they invoke does not, the permission chain is broken. More broadly, treat any function in ERPNext that performs write operations and lacks an explicit permission check as potentially vulnerable until proven otherwise. The absence of a check doesn't mean the function is safe; it means the framework provided no signal that a check was needed. Audit your modules for this pattern — there are almost certainly more than five functions with this gap.