The CVSS 5.3 rating on this 'unauthenticated broken access control' finding deserves scrutiny before you allocate remediation resources. Here's why: registration is definitionally an unauthenticated operation—it's the mechanism by which unauthenticated actors become users. When scanners flag 'no auth check' on a registration endpoint, they're applying a pattern designed for authenticated-to-authorized flows to a function that must accept unauthenticated input by design. This is a known taxonomic drift issue in vulnerability scanning that has propagated through CVE archives for over a decade.
What should concern you less is the CVSS score and what should concern you more is the EPSS of 0.00214—this is the lowest probability tier, indicating that threat intelligence systems aren't seeing active exploitation or even significant scanning interest. The two likely explanations are that either this endpoint is genuinely low-risk in practice, or it's "sediment code"—orphaned registration functionality that survived as products pivoted to SSO, invite systems, or admin-provisioned flows but nobody removed the old endpoint because removing features feels risky.
The version ceiling at 5.2.6 with no patch commit reference is a red flag for disclosure hygiene. Mature vendors specify what was fixed; this vague boundary suggests either lazy documentation or an organizational fix (endpoint removal) rather than a technical patch. Before you task engineers to 'fix the broken access control,' verify whether that registration endpoint is even still active in your deployment and what it actually provisions—role assignment, SSO linking, password reset flows? If it's active and connected to sensitive provisioning chains, the blast radius potential exceeds what a 5.3 CVSS captures. If it's orphaned dead code, your remediation is removal, not patching.
Prioritize investigation over remediation until you know which category you're in.