Is CVE-2018-14667 (Red Hat JBoss RichFaces Framework Expression Language Injection) being exploited in the wild?

Yes. CISA added CVE-2018-14667 to its Known Exploited Vulnerabilities catalogue on 28 September 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Red Hat JBoss RichFaces Framework contains an expression language injection vulnerability via the UserResource resource. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for CVE-2018-14667

For this CVE, the practical question is not whether the flaw exists, but whether attackers have already started using it against real systems. CISA’s KEV inclusion is the strongest public signal that exploitation is not theoretical. That changes priority immediately: treat this as an active exposure, not a routine backlog item.

Because the issue is an expression language injection path in Red Hat JBoss RichFaces Framework, the first concern is whether any internet-facing or internally reachable application still exposes the vulnerable component. If the product is present, assume attackers may probe for it with minimal noise and move quickly from discovery to execution.

When a vulnerability is already in the wild, remediation work should be framed around exposure reduction, not just patch compliance. The relevant operational question becomes: where is the vulnerable component deployed, how reachable is it, and how fast can you remove the attack path or move traffic away from it while fixing the underlying issue?

How to confirm exposure and reduce blast radius

Start by identifying every application, environment, and inherited platform that includes Red Hat JBoss RichFaces Framework. Validate whether the vulnerable UserResource path is actually deployed, because partial application inventories often miss embedded framework usage inside older enterprise applications, test systems, and forgotten instances.

Then narrow the blast radius. If the component cannot be patched immediately, reduce access to the smallest practical audience, remove public exposure, and place compensating controls around the affected endpoint or application tier. A temporary mitigation is only useful if it materially changes reachability, not if it leaves the same request path exposed.

For active exploitation cases, Zero-Day and Exploited Vulnerabilities Guide is useful because it frames KEV-driven triage, emergency mitigation, and post-patch hunting as one response loop rather than separate tasks. The goal is to reduce attacker opportunity first, then verify that the environment is clean enough to trust.

What to do if patching must wait

If you cannot remediate immediately, treat the delay as a risk-management decision with explicit ownership. Record why the system cannot be updated, what temporary control is in place, how long the exception is valid, and what condition will force escalation. For exploitable application flaws, “we are planning a patch” is not a compensating control.

While the fix is pending, increase monitoring for unusual requests, application errors, and signs that the vulnerable path is being exercised. Pair that with a focused hunt for adjacent compromise indicators, because successful exploitation often leaves little obvious evidence at the application layer.

Use the CISA KEV catalogue and the vendor advisory for the authoritative remediation path, version details, and any product-specific guidance. If the application is business critical, the decision is usually not whether to disrupt service, but how to do it in a controlled way before an attacker does it for you.

Risk and Threat Considerations

Active exploitation means the risk is no longer limited to known weakness, it includes opportunistic scanning, rapid weaponisation, and potential follow-on compromise of the application host or the data behind it. Expression language injection is especially concerning because it can turn a single request into code execution or deeper application abuse depending on the deployment and privileges.

Failure mechanism: An attacker finds the vulnerable RichFaces endpoint, sends a crafted request to the UserResource path, and uses the injection flaw to gain execution or reach sensitive application state before defenders notice.

Impact: The likely consequences are unauthorized access, application compromise, potential data exposure, and a faster path to persistence or lateral movement if the affected system is trusted inside a larger environment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Vulnerability Identification and Analysis	Active exploitation makes exposure analysis central to prioritization.
	PR.PS-01 — Baseline Configuration	The question concerns removing an exploitable component from the running environment.
	DE.CM-01 — Networks and Systems Monitored	Exploited-in-the-wild vulnerabilities require monitoring for active probing and compromise signals.
Recommendation — Prioritise remediation for the exposed RichFaces deployment and verify whether attackers can still reach it. Remove or harden the vulnerable component and confirm the application no longer exposes the attack path. Monitor the application and adjacent systems for exploit attempts and post-compromise indicators.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The CVE is an active vulnerability that must be tracked and verified across deployments.
	CM-7 — Least Functionality	Reducing exposed functionality is a key mitigation when patching must wait.
	SI-2 — Flaw Remediation	The CVE requires prompt remediation because active exploitation is already confirmed.
Recommendation — Scan for every RichFaces instance and validate whether the vulnerable path is still present. Disable or isolate the vulnerable application functionality until the fix is fully applied. Apply the vendor fix or approved mitigation as an urgent remediation action.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Confirmed exploitation drives immediate discovery, prioritisation and remediation of the flaw.
	CIS-13 — Network Monitoring and Defense	Exploit activity should be detected through monitoring and defense telemetry.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Temporary exposure reduction depends on secure configuration and removal of unnecessary reachability.
Recommendation — Track all affected assets, prioritise this CVE urgently, and verify remediation completion. Watch for exploit attempts and suspicious application activity around the RichFaces endpoint. Reduce exposure by tightening configuration and removing unnecessary access paths to the vulnerable service.

Practitioner Guidance

What to prioritise: Focus first on live, reachable instances that still expose the affected framework, then on systems that support sensitive data or have broad network trust. A dormant lab system is lower priority than a production service that can be reached from the internet or from a shared internal network segment.

What to verify: Confirm not just that a patch exists, but that the vulnerable component is no longer callable, the application restarted cleanly, and there is no evidence of post-exploitation activity. If you only validate version numbers, you can miss a system that was patched inconsistently or already compromised before remediation.

Practitioner takeaway: Once CISA has placed a CVE in KEV, the right mental model is emergency exposure management, not routine vulnerability tracking, because the operational goal shifts from “eventually fix” to “remove attacker access before the next probe lands.”