CVE-2024-4978 is a (JAVS) installer embedded malicious code vulnerability in Justice AV Solutions Viewer. CISA added it to the Known Exploited Vulnerabilities catalogue on 29 May 2024, which means attackers have used it in real attacks. Justice AV Solutions (JAVS) Viewer installer contains a malicious version of ffmpeg.exe, named fffmpeg.exe (SHA256: 421a4ad2615941b177b6ec4ab5e239c14e62af2ab07c6df1741e2a62223223c4).
What this vulnerability means
CVE-2024-4978 is not a logic flaw in a live application workflow, it is an installer supply-chain compromise, where the software package itself contains malicious code. That makes the trust boundary break at installation time, before the user has even run the product.
For defenders, that matters because installer-delivered malware can bypass ordinary user caution, tamper with the initial software trust chain, and create a foothold that looks like legitimate software deployment. When a vulnerable package has already been observed in real attacks, the question becomes less about theory and more about whether the affected installer was ever introduced into your environment.
The most reliable public record remains the CVE Program entry and the NIST National Vulnerability Database, which are the right places to confirm the canonical identifier and review authoritative vulnerability metadata.
Why embedded malicious code is dangerous
Embedded malicious code in an installer is dangerous because it collapses the distinction between deployment and compromise. A user or administrator may believe they are installing trusted software, while the package is already carrying an attacker-controlled executable or payload.
That creates a particularly effective path for persistence and privilege abuse. Installers often run with elevated trust, are allowed through application-control exceptions, and may be executed during routine IT workflows, which gives the malicious component a stronger chance of running successfully and blending in with normal software rollout activity.
In this case, the primary security problem is not just the presence of a suspicious binary, but the fact that the installer package itself is the delivery vehicle. That raises the stakes for software provenance, download integrity, and internal software distribution controls.
How organisations check exposure
Exposure assessment starts with knowing whether Justice AV Solutions Viewer was ever downloaded, staged, or installed anywhere in the estate. Asset inventory, endpoint software inventory, software distribution logs, and browser or proxy download records are the fastest ways to establish whether the installer reached your environment.
Because the issue is tied to a specific malicious installer artefact, administrators should also verify whether the exact package or file hash appears in internal repositories, software catalogues, mail attachments, or endpoint telemetry. If the installer was shared outside standard channels, exposure can extend beyond managed endpoints to isolated analyst machines, jump hosts, or support laptops.
If you need version and remediation details, use the vendor advisory and the CISA KEV catalogue rather than relying on reposted summaries. KEV inclusion means the issue has been exploited in the wild, so internet exposure and any unverified download path should be treated as materially higher risk.
Remediation, detection, and recovery
Remediation should begin with removing the malicious installer artefact from approved software locations and preventing any further distribution. If the installer was executed, treat the endpoint as potentially compromised until you have checked for follow-on activity, unexpected child processes, new persistence mechanisms, and other signs that the malicious binary executed beyond installation.
Detection should focus on endpoint execution telemetry, newly created files, unusual network traffic after installation, and any process lineage associated with the malicious installer. Where the installer may have run with elevated rights, review local admin activity, scheduled tasks, services, startup items, and software inventory drift.
If compromise is confirmed or strongly suspected, rotate any credentials, tokens, or service account material that could have been exposed on the affected host, then reimage or clean the system according to your incident-response standard. Because installer-based malware often arrives as trusted software, post-patch compromise review is as important as patching itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | CVE exposure depends on knowing where the installer exists. |
| CIS-10 — Malware Defenses | Embedded malicious code requires endpoint controls that can detect and block execution. | |
| Recommendation — Inventory installed and downloaded software to find and remove the malicious installer. Use malware defenses to detect the malicious binary and its follow-on activity. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | The issue is malicious code embedded in trusted software media. |
| SA-12 — Supply Chain Protection | The vulnerability is a trust-break in software acquisition and distribution. | |
| RA-5 — Vulnerability Monitoring and Scanning | KEV-listed exploitation requires active exposure tracking and validation. | |
| Recommendation — Apply malicious code protection to scan and block suspect installer content. Verify software provenance and supplier channels before approving installers. Continuously scan assets and reconcile them against exploited vulnerability records. | ||
Practitioner Guidance
Why practitioners should care: This class of issue is about software trust, not just vulnerability remediation. An installer that already contains malicious code can turn a routine deployment into an initial access event, so exposure management must include software provenance, not only patch status.
What to watch for: Look for the exact installer artefact, any internal redistribution of it, and any endpoint that executed the package before it was removed from circulation. If the installer was used in a scripted or enterprise deployment path, the blast radius can be broader than a single user download.
Practitioner takeaway: Treat any exploitable installer compromise as both a supply-chain event and a host-compromise investigation, because the security question is not only whether the software is installed, but whether the installer itself was trusted when it should not have been.