CVE-2026-14237 is a compounding vulnerability that exposes a dual failure most defenders will miss if they only read the CVSS score. The 7.2 rating reflects a missing authorization check on a password reset API endpoint — technically accurate, but it obscures the architectural flaw underneath: the Outlet Manager role was granted a password reset capability it never should have possessed in the first place. In a point-of-sale system, an outlet manager has no legitimate business need to reset an administrator's password. That capability existed because someone copied a capability block from documentation or examples without auditing it against the principle of least privilege — a cognitive artifact of how developers write comprehensive example code that demonstrates 'everything a role might eventually need.'
The vulnerability required two simultaneous fixes: removing the over-broad default capability AND implementing per-target authorization checks on the API. If developers had scoped the capability to outlet-level users from the start — reset only users within your own outlet — the missing API check might never have been flagged because the attack surface would have been contained at the role level. Instead, the blast radius propagated to every user in the deployment, including admins, available to any authenticated user holding the Outlet Manager role.
The CVSS 7.2 underweights this. Full admin account takeover from a low-privilege authenticated role warrants a higher score; the scoring anchors to the technical mechanism (missing check) rather than the business impact (any user becomes any other user). This anchoring error is systemic in CVE scoring and can cause organizations to deprioritize patching based on a score that undersells actual impact.
What you should check: First, verify your current plugin version — patches landed in 3.6.0 and 3.5.0. Second, audit whether any custom roles in your deployment grant capabilities that exceed the role holder's legitimate functional scope — password reset is just one example, but the same pattern applies to user creation, role assignment, or settings modification. Third, treat capability grants as architectural decisions that require business context review, not just development-time copy-paste from documentation. Fourth, recognize that role-capability bloat creates blast radius beyond any single endpoint: once a capability exists, every future API that exercises it inherits the risk unless explicitly scoped. The fix that matters is one that addresses both layers — proper capability scoping AND runtime target validation — not merely the endpoint-level patch.