CVE-2026-85491
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-85491 is a high-severity Use of Incorrectly-Resolved Name or Reference (CWE-706) vulnerability. Its CVSS base score is 8.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Path Interception by Search Order Hijacking (T1574.008); ranked at the 27th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-24 (Access Control Decisions) and AC-3 (Access Enforcement) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-86474
Vulnerability Data
Catalyst::Seal versions before 0.03 for Perl allow one request to disable a path or route a later one past an authorization check via a dispatch memo keyed on the request path alone. Catalyst::Seal replaces the dispatcher's prepare_action with a version…
more
that memoises how a path resolved: which dispatch type matched, at which level, and what was left over as arguments. The key is the request path and nothing else. Action roles that match on the method, content type, scheme or query make that resolution depend on state the key does not carry, so the memo answers for a request it was not built from. A path that resolves to no action is memoised as well, and replaying that entry returns without consulting any dispatch type, so no action is set and the request fails. A GET of a path whose action is declared POST-only therefore disables that path for every later request, the correct POST included. An entry that did resolve replays the level the earlier descent reached. Where a POST-only action sits below a shallower action on the same path, a GET memoises the shallow route, and a later POST is dispatched there with an auto() guarding the deeper controller never running. The memo is cleared only when an action is registered, which happens at setup, so an entry lasts for the life of the process, and its cap of 2048 entries bounds how many paths one caller can disable. In the configuration measured, the misroute lands on the less privileged action, so it is an authorization check not running rather than a privilege gain.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V6.3.4V6.3.5V6.1.3V6.5.7
Mitigating Controls (NIST 800-53 r5) AI
Mandating that access-control decisions apply the full set of required rules to each request structurally eliminates missing-factor comparisons.
Access enforcement applies authorization checks to the resolved resource, blocking access outside the intended sphere.
Information flow enforcement can constrain flows that result from an incorrectly resolved name or reference.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Authentication decisions often rely on multi-factor comparisons; incomplete comparisons directly weaken this control.
Enforced authorization boundaries limit damage from an incorrectly resolved reference.
Logical segmentation and access controls reduce the chance an out-of-sphere resolution succeeds.
Hardened configuration baselines can constrain allowable name-to-resource mappings.
Secure-development practices directly prevent incorrect name/reference resolution bugs during coding.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Network segmentation and routing policies reduce the chance that a mis-resolved name leads to an unintended external resource.
Segregated networks limit the blast radius when a name or reference resolves outside the intended control sphere.
Secure SDLC practices include design reviews that can catch incorrect name or reference handling before deployment.
Application security requirements can mandate validation of all external references and names used at runtime.
Secure architecture principles discourage reliance on ambient or globally-resolvable names without explicit scoping.
Secure-coding standards directly address canonicalization, input validation and safe name resolution, mitigating CWE-706.