CISA's required action for CVE-2022-29303 is to apply updates per vendor instructions or discontinue use of the product if updates are unavailable. In practice, find every instance of SolarView Compact 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. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What a secure fix for CVE-2022-29303 actually looks like
The right first move is to confirm every SolarView Compact instance in scope, then apply the vendor update or documented mitigation exactly as instructed. If the vendor cannot provide a fix for a given deployment, the safer decision is to remove that instance from internet reach or retire it from service rather than leave a command-injection exposure in place.
That is not just a patching task, it is an exposure-management task. Command injection means the vulnerable interface can turn attacker input into operating-system commands, so the practical question is whether any reachable instance can still accept untrusted requests before the update is applied.
Zero-Day and Exploited Vulnerabilities Guide is the best internal playbook for treating an actively exploited flaw as an emergency remediation problem, including triage, mitigation and post-patch hunting.
CISA Known Exploited Vulnerabilities Catalog is the authoritative place to verify that this CVE is handled as a known exploited vulnerability and to align your remediation timing with CISA guidance.
How to reduce exposure when you cannot patch immediately
If patching has to wait, the goal is to break the attack path, not to compensate with monitoring alone. Restrict network access to the management interface, remove exposure to the public internet, and limit who can reach the device from trusted administrative networks. If the system is business critical, place it behind stronger network controls while you prepare the update window.
For command injection, compensating controls matter only if they actually remove attacker reachability. A weak perimeter rule or temporary “watch and wait” approach still leaves the vulnerable parser exposed, which is why the mitigation should focus on reachability, not just alerting.
Vulnerability Management Guide provides the broader prioritisation approach for KEV-listed issues, including asset scoping, exceptions and verification after remediation.
NIST National Vulnerability Database is useful for checking the canonical CVE record and the product metadata while you confirm your inventory and remediation tracking.
What to check after remediation or removal
After the fix is in place, review logs and adjacent telemetry for signs that the vulnerability was already used. Look for unusual command execution, unexpected outbound connections, new administrative changes, or suspicious activity around the period when the vulnerable system was exposed. If you find evidence of compromise, treat the device as an incident, not a routine patch outcome.
Because the flaw was exploited in the wild, the post-fix step is a compromise assessment as much as a verification step. The main question is whether the device only needed repair, or whether the exposure already gave an attacker a foothold that must be investigated and contained.
Web Application Attacks Guide helps map command injection to the attack patterns and defensive checks that matter when a web-facing interface can be driven into operating-system command execution.
CVE Program is the reference point for the vulnerability identifier itself and for cross-checking the canonical record when you document remediation and incident findings.
Risk and Threat Considerations
A command-injection flaw on an exposed product creates two practical risks: immediate remote abuse of the vulnerable interface and delayed discovery if the system was already touched before patching. The more internet-facing and operationally critical the device is, the more likely attackers are to scan for it quickly and use it as an initial access point.
Failure mechanism: The vulnerable application accepts attacker-controlled input that reaches an operating-system command context, allowing arbitrary command execution before or instead of the intended function.
Impact: Attackers may obtain execution on the device, alter configuration, steal data, pivot into nearby systems, or leave persistence that survives a simple patch.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | CVE-2022-29303 requires rapid identification and remediation of exploited vulnerable assets. |
| Recommendation — Prioritise, patch and verify exposed SolarView Compact instances under continuous vulnerability management. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The question is about finding and remediating a known exploited vulnerability across the estate. |
| SI-2 — Flaw Remediation | This CVE is remediated through vendor updates or documented mitigation. | |
| AC-4 — Information Flow Enforcement | If patching waits, the mitigation is to stop untrusted access to the vulnerable interface. | |
| Recommendation — Scan for SolarView Compact, confirm exposure and verify remediation of the vulnerable instance. Apply the vendor fix or approved mitigation and remove unpatchable instances from service. Restrict network reachability to the management interface until remediation is complete. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Command injection is an input-to-command execution failure rooted in insecure application design. |
| Recommendation — Review the command-execution path and eliminate unsafe input handling in the affected interface. | ||
Practitioner Guidance
What to prioritise: Patch or isolate the most exposed SolarView Compact instances first, especially any instance reachable from the internet or from broad internal segments. If you cannot do both quickly, remove exposure before you defer the update.
What to verify: Confirm the vendor fix or documented mitigation was applied to the exact deployed version, then validate that the management surface is no longer reachable from untrusted networks. Do not rely on change tickets alone as evidence of safety.
Decision rule: If the product cannot be updated in a reasonable time, treat retirement or disconnection as the safer control, because a live exploitable command-injection path is a worse residual risk than temporary loss of the service.
Practitioner takeaway: For KEV-listed command injection, the right sequence is inventory, patch or isolate, then hunt for compromise, because exposure that was exploited before remediation can remain a security problem after the fix is installed.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-30525 (Zyxel Multiple Firewalls OS Command Injection)?
- CVE-2022-29303 (SolarView Compact Command Injection)
- How do you patch or mitigate CVE-2025-59689 (Libraesva Email Security Gateway Command Injection)?
- How do you patch or mitigate CVE-2024-9474 (Palo Alto Networks PAN-OS Management Interface OS Command Injection)?
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