CVE-2026-46581 in Mojarra's DefaultFaceletFactory is a design flaw, not merely a file read bug. The core issue is that DefaultFaceletFactory treats remote and local resources as interchangeable—when an attacker controls the URL parameter feeding into facelet resolution, they can load facelets from attacker-controlled HTTP endpoints, use file:// protocol to read server-side files as facelet templates, or pivot to internal network resources the server can reach but the attacker cannot.
The compounding risk that makes this critical: facelets are processed XHTML containing EL expressions. A maliciously crafted facelet loaded through this mechanism is not just displayed—it is parsed and executed with the server's full runtime context. This means ${...} expressions evaluate against whatever managed beans are in scope, potentially achieving arbitrary code execution. This is not hypothetical—facelets are designed to include and process content, not merely render static markup.
The CVSS classification as SSRF or file read is dangerous because it implies the fix is URL validation. But if Mojarra's facelet processing permits expression evaluation from loaded templates—and the CVE description explicitly states facelets are included and processed—then this crosses from information disclosure into remote code execution. The question is not whether file reads are possible; it's whether EL injection through loaded facelets works in practice.
Check your exposure: identify whether any web-accessible parameter or configuration routes through DefaultFaceletFactory, audit what managed beans are accessible to facelet resolution (particularly those with database connections, process execution capabilities, or sensitive data), and determine whether your Mojarra version includes any URL restrictions. If facelets can load from arbitrary URLs, treat this as RCE-equivalent until proven otherwise.
The immediate mitigation is to block external URL loading in facelet resolution at the application layer—verify whether your configuration exposes this attack surface—and audit managed beans in the facelet scope for sensitive operations. The deeper concern is architectural: this is the same pattern seen in Struts, Apache Tiles, and other JavaEE frameworks that assumed developer-controlled URLs. The fix at the framework level requires architectural changes, not regex URL filters.