CVE-2026-102695 in OmniFaces
Summary
by MITRE • 10/15/2026
OmniFaces is a utility library for Faces. In OmniFaces versions before 1.14.3, 2.7.33, 3.14.23, 4.7.12, and 5.4.2, CombinedResourceHandler accepts a structurally valid deflated and base64 encoded combined resource ID without verifying that the server issued it. A forged ID can cause unbounded decoded output, add unique reconstructed IDs to a process-lifetime cache, or combine resources other than stylesheets and scripts. Because jakarta.faces.RESOURCE_EXCLUDES is not applied by this custom resolution path, a forged ID can disclose Facelets source from the webapp resource tree or META-INF/resources. In a deployment configured with the wildcard CDN mapping, a forged ID that selects omnifaces.graphic can also cause a blind, deployment-dependent server-side fetch whose destination derives partly from the request Host header. The flaw does not provide arbitrary file read or establish arbitrary-scheme or arbitrary-destination SSRF. The shared authenticity failure permits memory exhaustion and limited resource disclosure. This issue is fixed in versions 1.14.3, 2.7.33, 3.14.23, 4.7.12, and 5.4.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in OmniFaces represents a critical failure in input validation and authenticity verification within the CombinedResourceHandler component of JavaServer Faces utility libraries. This flaw affects multiple versions including those prior to 1.14.3, 2.7.33, 3.14.23, 4.7.12, and 5.4.2. The core technical issue stems from the handler accepting combined resource identifiers that are structurally valid but cryptographically unverified. Specifically, an attacker can craft a deflated and base64 encoded string representing a combined resource ID without possessing the server-generated signature or token required to prove its legitimacy. By bypassing this authenticity check, the application processes arbitrary input as if it were authorized by the server itself, leading to several distinct operational impacts ranging from denial of service to information disclosure.
From an architectural perspective, this vulnerability is classified under CWE-347 Improper Verification of Cryptographic Signature and CWE-20 Improper Input Validation. The absence of integrity checks allows malicious actors to manipulate how resources are aggregated on the client side. When a forged ID is processed, it triggers unbounded decoding operations because there are no limits placed on the size or complexity of the decompressed output. This mechanism can be exploited to cause memory exhaustion by forcing the server to allocate excessive amounts of heap space during the decomposition and processing phases. Furthermore, these reconstructed IDs are added to a process-lifetime cache, meaning that repeated exploitation attempts not only consume resources but also pollute application memory with malicious entries, potentially degrading performance for all users until the service is restarted or caches are cleared.
Beyond resource exhaustion, the vulnerability facilitates limited information disclosure due to the bypass of standard security exclusions. In normal JSF operations, the RESOURCE_EXCLUDES configuration parameter prevents access to sensitive files such as Facelets source code located in the webapp resource tree or META-INF/resources directories. However, because OmniFaces utilizes a custom resolution path for combined resources, this exclusion list is not enforced when processing forged IDs. Consequently, an attacker can construct specific payloads that reference these protected paths, resulting in the exposure of internal application logic and potentially sensitive configuration details to unauthorized parties. This behavior aligns with CWE-200 Exposure of Sensitive Information to an Unauthorized Actor, as it reveals implementation-specific data through a non-standard access vector.
In deployments configured with wildcard CDN mapping features, the risk profile expands further due to potential server-side request forgery characteristics. If the forged ID selects specific internal components like omnifaces.graphic, the application may initiate blind HTTP requests where parts of the destination URL are derived from the Host header provided by the attacker. While this does not constitute a full arbitrary scheme or arbitrary destination SSRF as defined in CWE-918, it introduces a deployment-dependent server-side fetch mechanism that can be leveraged for network reconnaissance or amplification attacks within controlled environments. This aspect highlights the danger of trusting user-supplied data to influence internal routing logic without strict validation against an allowlist of permitted domains and protocols.
Mitigation strategies must prioritize immediate upgrading to patched versions where these checks have been implemented. For organizations unable to upgrade immediately, implementing a Web Application Firewall rule set that detects anomalous patterns in combined resource requests can provide temporary relief. This includes monitoring for unusually large base64 encoded strings or repeated cache population attempts indicative of memory exhaustion attacks. Additionally, ensuring that the RESOURCE_EXCLUDES configuration is strictly enforced across all resolution paths, including custom handlers, reduces the attack surface for information disclosure. Security teams should also audit CDN configurations to prevent wildcard mappings from being exploited in server-side fetch scenarios, thereby closing the gap between client-side manipulation and unintended server behavior.