Is CVE-2024-4978 (Justice AV Solutions (JAVS) Viewer Installer Embedded Malicious Code) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2024-4978 to its Known Exploited Vulnerabilities catalogue on 29 May 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Justice AV Solutions (JAVS) Viewer installer contains a malicious version of ffmpeg.exe, named fffmpeg.exe (SHA256: 421a4ad2615941b177b6ec4ab5e239c14e62af2ab07c6df1741e2a62223223c4). Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for CVE-2024-4978

For this CVE, “exploited in the wild” is not a theoretical label. It means the vulnerability has crossed from disclosure into real attacker activity, so exposure is no longer a planning concern only. For teams that still run the installer, the practical question is whether the product is present, whether the malicious file was executed, and whether any supporting evidence suggests compromise already occurred.

That matters because installer-based malicious code can be delivered during normal deployment or update workflows, which reduces the need for attackers to rely on separate delivery infrastructure. When the affected software is used on multiple endpoints, the blast radius can expand quickly through ordinary administrative activity.

For background on how CISA distinguishes actively exploited issues from ordinary CVEs, see CISA Known Exploited Vulnerabilities Catalog and the official CVE Program.

How to confirm exposure without wasting time

Start by confirming whether Justice AV Solutions Viewer is installed anywhere in the environment, including endpoints that may have been imaged, provisioned, or used temporarily by support staff. Then verify whether the malicious fffmpeg.exe file is present, whether the installer came from a trusted source, and whether any endpoint logs, EDR telemetry, or software inventory records show execution tied to the vulnerable installer.

If you can only answer one question first, answer this: does any system still trust or retain the installer package, or any extracted copy of the embedded binary, in a location where users or deployment tools can execute it? A positive answer means exposure is operational, not just historical.

For a structured triage path that pairs asset scoping with exploitability prioritisation, use Zero-Day and Exploited Vulnerabilities Guide alongside the vendor advisory and CISA KEV entry.

What to do when patching or removal cannot happen immediately

If remediation must wait, reduce the chance that the installer can be run again and narrow the systems that can still reach it. That usually means removing the installer from shared locations, blocking execution from untrusted paths, tightening software distribution controls, and preventing end users from sideloading or reusing old packages.

Because the malicious code sits inside an installer, simply warning users is rarely enough. Treat the package like a compromised artifact: preserve a copy for analysis if needed, but stop it from being used for further installs, upgrades, or reinstallation.

For execution-control and containment patterns that help when you need to suppress a known-bad binary before full eradication is complete, see Code Signing Security Guide and the NIST SP 800-53 Rev 5 Security and Privacy Controls.

Risk and Threat Considerations

The main risk is that a malicious installer can create compromise during routine software deployment, which makes initial access harder to spot than a normal exploit chain. Once a poisoned installer is trusted by operations staff or endpoint management tooling, it can seed malware across multiple hosts before defenders recognise the source.

Failure mechanism: The attacker leverages a distributed software installation path to place or execute malicious code under the cover of a legitimate product workflow, which weakens user suspicion and can bypass informal trust checks.

Impact: The likely result is endpoint compromise, possible follow-on persistence, and the need to assume that any system that installed or executed the package may require investigation, not just the one where the file was first found.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-10 — Malware Defenses	Malicious installer code is a malware exposure that needs containment and blocking.
Recommendation — Block and quarantine the known-bad installer across endpoints and distribution paths.
NIST SP 800-53 Rev 5	SI-3 — Malicious Code Protection	The issue is embedded malicious code, which maps directly to malware detection and blocking.
	RA-5 — Vulnerability Monitoring and Scanning	Actively exploited CVEs require exposure checks, inventorying, and hunt-driven validation.
Recommendation — Scan for and block the malicious installer and related binaries. Continuously identify affected assets and verify whether the vulnerable installer is present.
NIST CSF 2.0	DE.CM-09 — Malicious Code is Detected	Active exploitation calls for monitoring that detects malicious code execution or presence.
	RS.MI-01 — Incidents are Contained	If the installer was used, containment is needed to stop spread and further execution.
Recommendation — Alert on execution or presence of the known malicious installer binary. Isolate affected hosts and remove the malicious installer from reachable locations.

Practitioner Guidance

What to prioritise: Triage installation footprint first, then look for execution evidence. If the product is present on any business-critical endpoint, treat that host set as a compromise candidate until you have checked logs, file integrity, and process telemetry.

What to verify: Confirm whether the installer hash or embedded file hash matches the malicious object identified by CISA and whether any internal software distribution cache, ticket attachment, or admin download repository still contains it. That evidence tells you whether the risk is confined to one endpoint or is already circulating internally.

Practitioner takeaway: For an actively exploited installer flaw, the safest operating assumption is that exposure equals potential compromise until you can prove the bad package was never used or has already been fully removed and hunted.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org