CISA's required action for CVE-2024-4978 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Justice AV Solutions Viewer in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.
What CVE-2024-4978 Means for Exposure and Urgency
CVE-2024-4978 is an embedded malicious-code issue in Justice AV Solutions (JAVS) Viewer Installer, so the first decision is not whether the flaw is theoretical but whether the installer still exists anywhere in your environment. Treat this as an active exposure problem: if the software is present, the response is to reduce blast radius immediately and move toward removal or vendor-directed mitigation.
Search for every installation, copy, and package instance, including golden images, software repositories, remote endpoints, and any place the installer may have been cached for repeat deployment. If the product is still needed, prefer a vendor security update or documented workaround; if that path is unavailable, take the product out of service rather than leaving it reachable from the internet.
CISA Known Exploited Vulnerabilities Catalog should be part of the triage loop for this case because the response expectation is driven by active exploitation risk, not by ordinary vulnerability backlog handling. Pair that with the CVE Program record and the vendor advisory so you are working from the authoritative source of truth for the fix path.
How to Reduce Risk While You Apply the Fix
If you cannot remediate immediately, the practical goal is to make the vulnerable installer unavailable to untrusted users and untrusted networks. That usually means removing public access, blocking download or execution paths, and preventing redeployment from shared file stores or unmanaged endpoints. The safer posture is to treat the installer as potentially unsafe even before you confirm whether it has been executed.
Where the software remains operational, limit access to the smallest set of hosts and administrators that actually need it, and keep a strict record of where the package was removed, disabled, or replaced. If the product is business-critical and cannot be retired immediately, isolate it behind internal controls and document the exception so the residual risk is explicit rather than accidental.
Zero-Day and Exploited Vulnerabilities Guide is the right internal playbook for the emergency mindset here, because CVE-2024-4978 should be handled as a fast-moving exploited-vulnerability event rather than a routine patch cycle. The same applies to Vulnerability Management Guide, which is useful for asset scoping, prioritisation, and verification after remediation.
What to Check After Remediation or Removal
Once the installer is patched, mitigated, or removed, verify that no user can still retrieve or launch the old package from alternate locations. Check download portals, endpoint software catalogs, shared drives, backup restore points, and unattended deployment tooling. If any copy survives, the exposure has not really been closed.
Also look for signs that the vulnerable code may already have been used on hosts that received the installer before remediation. Review execution history, recent process launches, file integrity, and any related alerts around the affected time window. If the installer was ever exposed externally or widely distributed internally, assume you may need to validate the environment for earlier compromise rather than only confirming that the package version changed.
Risk and Threat Considerations
This kind of installer compromise is dangerous because the malicious content lives inside software users may trust, so the attack surface is expanded through normal distribution and installation workflows. The main risk is not just that the file is vulnerable, but that it can be propagated, executed, or reintroduced before teams realise the package itself is the problem.
Failure mechanism: The defender patches the obvious host but leaves the installer, mirror, cache, or deployment source available, allowing the same malicious payload to be reintroduced or reused.
Impact: Users can keep installing the compromised package, which preserves the chance of infection, foothold creation, or further compromise even after an attempted fix.
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, OWASP ASVS 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 requires malware-oriented containment and detection. |
| Recommendation — Block, detect, and remove malicious software before it executes or spreads. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Embedded malicious code requires protection against execution and reinfection. |
| SI-7 — Software, Firmware, and Information Integrity | Integrity checks help confirm the installer and distribution path are trustworthy. | |
| Recommendation — Deploy malicious code protection to detect and prevent execution of compromised installers. Verify software integrity before deployment and after remediation. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Supply-path trust and integrity failures map to software assurance controls. |
| Recommendation — Enforce build and distribution integrity for released software artifacts. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity of Information | The issue centers on preserving integrity of the delivered installer. |
| Recommendation — Protect software artifacts so tampering is detected and prevented. | ||
Practitioner Guidance
What to verify: Confirm not only that the affected product is removed or updated, but that no trusted source still hosts the old installer. In practice, the weak point is often the distribution path, not the endpoint itself.
Decision rule: If the vendor mitigation is clear and deployable, use it and validate the clean package path immediately after. If the vendor path is unavailable or unreliable, discontinuing the product is the safer operational choice than leaving a compromised installer in circulation.
What to measure: Track every environment where the product existed, every location from which it could be downloaded, and every host where the installer was executed. That gives you a defensible closure test instead of a superficial patch count.
Practitioner takeaway: For embedded malicious code, remediation is only complete when the vulnerable software is no longer obtainable, executable, or silently reintroduced from any approved distribution point.
Related resources from NHI Mgmt Group
- Is CVE-2024-4978 (Justice AV Solutions (JAVS) Viewer Installer Embedded Malicious Code) being exploited in the wild?
- CVE-2024-4978 (Justice AV Solutions (JAVS) Viewer Installer Embedded Malicious Code)
- How do you patch or mitigate CVE-2025-54313 (Prettier eslint-config-prettier Embedded Malicious Code)?
- How do you patch or mitigate CVE-2025-59374 (ASUS Live Update Embedded Malicious Code)?
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.
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