GHSA-FP43-VJ7G-PG92: Multi-Vector Security Vulnerabilities in OmniFaces JSF Utility Library

The vulnerability advisory GHSA-FP43-VJ7G-PG92 covers multiple security boundary bypasses and unhardened code pathways within the OmniFaces utility library for JavaServer Faces (JSF). These weaknesses exist across several core handlers: the combined resource handler, the source-map handler, the hash parameter AJAX component, and the push/WebSocket message endpoint. These flaws expose applications to unauthorized file disclosure, unauthenticated denial of service (DoS) via memory exhaustion, cross-site scripting (XSS), and session hijacking.

An external client can interact with these unauthenticated HTTP and WebSocket endpoints to read internal configuration templates or trigger uncontrolled resource consumption on the application server. The weaknesses were analyzed and subsequently resolved in OmniFaces version 2.7.33.

The primary weakness in the CombinedResourceHandler stems from the reconstruction of resource identifiers from user-controlled parameters. OmniFaces serializes a collection of resources into a single, URL-safe, compressed Base64 identifier. When parsing requested identifiers, CombinedResourceInfo.get(String id) deserialized client-supplied data without validating the file extensions or directories of the requested files. This allows an attacker to construct a valid resource ID containing path-traversal strings and target non-CSS or non-JS files such as internal .xhtml templates.

Additionally, the decompression utility Utils.unserializeURLSafe did not constrain the output stream length during inflation. A small, compressed payload could be crafted to expand into a massive array of resource names in memory, causing a Zip Bomb denial of service. The caching of reconstructed client-side identifiers also introduced an unbounded growth vector, as every unique request permanently populated the static CACHE map.

Similarly, the SourceMapResourceHandler used an unbounded map lookup mechanism. When a client requested a non-existent source map, computeIfAbsent inserted the key paired with an empty string. An attacker could flood the handler with unique, randomized paths, resulting in memory exhaustion. Finally, the WebSocket handler failed to verify the owning session of view-scoped or session-scoped channel IDs, allowing unauthorized connection handshakes.

OmniFaces version 2.7.33 resolved these vulnerabilities through several modifications. In CombinedResourceInfo.java, the decompression routine was restricted using a maximum output constraint. The deserialization threshold was capped at 64 KiB to prevent memory exhaustion from zip-bomb payloads:

// Hardening decompression length
private static final int MAX_UNSERIALIZED_LENGTH = 64 * 1024;

Additionally, a validation method isCombinable was added to ensure only stylesheet and script files can be processed during reconstruction:

private static boolean isCombinable(Set<ResourceIdentifier> resourceIdentifiers) {
    for (ResourceIdentifier resourceIdentifier : resourceIdentifiers) {
        String name = resourceIdentifier.getName();
        if (name == null) {
            return false;
        }
        String lowerCaseName = name.toLowerCase();
        if (!lowerCaseName.endsWith(CombinedResourceHandler.EXTENSION_CSS) && !lowerCaseName.endsWith(CombinedResourceHandler.EXTENSION_JS)) {
            return false;
        }
    }
    return true;
}

The WebSocket handshake validation was updated in SocketEndpoint.Configurator to retrieve the HTTP Session and assert that the session registered the requested WebSocket channel identifier prior to allowing connection upgrade.

Exploitation of the combined resource handler requires an attacker to construct a Base64-encoded, deflated resource string containing a path-traversal indicator. A script can generate this payload and make an HTTP request to the resource endpoint. This forces the application server to decompress the path, locate the internal configuration file, and return its contents to the client.

To hijack a WebSocket channel, an attacker must acquire the private channel UUID of a victim. Because the application server did not compare the WebSocket handshake session with the session that registered the channel identifier, the attacker could establish a direct WebSocket connection using the stolen identifier. The server would then deliver view-scoped or session-scoped push messages directly to the unauthorized connection.

The collective impact of these vulnerabilities affects confidentiality, availability, and integrity. The arbitrary file disclosure allows attackers to view proprietary source code, application templates, and server configurations, facilitating further analysis and targeted attacks.

Memory exhaustion vectors (via the inflation of combined resource IDs and the unbounded static maps in the source-map cache) enable remote, unauthenticated attackers to systematically deplete the Java Virtual Machine heap memory. This leads to OutOfMemoryError failures, rendering the application unavailable. The WebSocket session hijacking exposes private, session-specific updates directly to unauthorized clients, while the XSS in the hash parameter component allows executing arbitrary JavaScript code within the victim's session.

The primary remediation strategy is upgrading the org.omnifaces:omnifaces dependency to version 2.7.33 or higher. This version implements strict input limits, sanitizes parameters, enforces type restrictions, and secures WebSocket handshake logic.

For defense-in-depth, configure Web Application Firewall (WAF) rules to detect and intercept anomalous queries directed to /javax.faces.resource/ containing combined resource library components (ln=omnifaces.combined). Implement connection limits and request timeouts to minimize the impact of resource exhaustion attempts on your application containers. Ensure WebSocket-capable proxies and load balancers preserve session cookies to allow correct authorization validation during the handshake phase.