How do you patch or mitigate CVE-2020-14871 (Oracle Solaris and Zettabyte File System (ZFS) Unspecified)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

CISA's required action for CVE-2020-14871 is to apply updates per vendor instructions. In practice, find every instance of Oracle Solaris and Zettabyte File System (ZFS) 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 patching CVE-2020-14871 should look like in practice

For this CVE, the safe default is to treat Oracle Solaris and ZFS as a vulnerability management problem first, then a containment problem if patching is delayed. Use the vendor update path specified in Oracle’s advisory, validate that every affected host is inventoried, and confirm that the fix or mitigation is actually present rather than assuming the package manager completed the job.

When the product is externally reachable, patching should be paired with exposure reduction, because an unpatched but internet-facing system remains a live target. If you cannot apply the required update immediately, the next-best action is to remove public exposure, restrict access to trusted management paths, and document the exception until the host can be remediated or retired.

Why post-patch checking matters for an exploited-in-the-wild flaw

This vulnerability was used in the wild, so the remediation task is not finished when the update is installed. Teams should assume that exploitation may have occurred before patching, especially on systems with long patch windows, exposed services, or weak monitoring, and they should verify the state of the host after remediation.

That verification usually means reviewing authentication, system, and application logs for unusual access, unexpected privilege changes, suspicious file activity, and other signs that the flaw was used as an initial access or execution path. If the host handled sensitive data or privileged operations, it is also prudent to validate whether adjacent credentials, sessions, or service accounts could have been reached during the exposure window.

How to reduce the chance of a repeat exposure

The most durable control is to make this kind of patching event routine rather than emergency-driven. Keep an accurate asset list for Solaris and ZFS, track which systems are internet-facing or reachable from untrusted networks, and maintain a clear owner for applying vendor security updates and approved mitigations.

Where patching depends on operational windows, the important decision is whether the exception is temporary and bounded or whether the system is effectively an unmaintained exposure point. Systems that cannot be patched quickly should either be isolated with compensating controls or removed from service before they become the easiest path in your environment.

Risk and Threat Considerations

The main risk is not just the software flaw itself, but the combination of active exploitation, delayed remediation, and systems that remain reachable while waiting for maintenance. That creates a straightforward attack window where an external actor can target the vulnerable host before defenders have applied the vendor fix.

Failure mechanism: A public or weakly restricted Solaris or ZFS system remains exploitable until the update or mitigation is in place, and the same exposure window can be long enough for attackers to gain access and leave persistence or other artefacts behind.

Impact: The consequence can extend beyond the original host, including unauthorized access, service disruption, and the need for incident response on systems that were thought to be only “pending patch.”

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while 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-7 — Continuous Vulnerability Management	CVE patching and exposure reduction are core vulnerability management tasks.
Recommendation — Prioritise remediation of exposed Solaris and ZFS assets, then verify completion with rescans.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE response centers on applying vendor updates or documented mitigations.
	AU-6 — Audit Review, Analysis, and Reporting	Post-patch log review is needed to look for earlier exploitation.
Recommendation — Track the Oracle fix, apply it promptly, and document any approved exception. Review logs for indicators of compromise before closing the remediation ticket.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification and Assessment	You must identify every Solaris and ZFS instance before patching can be complete.
	PR.PS-03 — Configuration Change Management	Applying vendor updates is a controlled configuration change on production systems.
Recommendation — Inventory all affected hosts and confirm which ones remain externally exposed. Use controlled change management to deploy the Oracle update and validate the resulting state.
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Compromised systems may retain access paths that should be revoked after exploitation.
	NHI-07 — Long-Lived Secrets	Exploitation review may require rotating secrets that could have been accessed.
Recommendation — Revoke or replace any access paths that were exposed during the vulnerable period. Rotate exposed secrets or service credentials after confirming the host was not compromised.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The response explicitly addresses internet exposure and exploitation in the wild.
Recommendation — Hunt for evidence of exploitation on any publicly reachable Solaris or ZFS system.

Practitioner Guidance

What to prioritise: Patch internet-facing or high-value Solaris and ZFS assets first, then move to internal systems that support sensitive workloads or privileged administration. If a fix is not yet available on a given host, treat exposure removal as the immediate objective.

What to verify: Confirm the exact Oracle update or mitigation has been applied, confirm the host is still supported, and confirm the vulnerability is no longer reachable from the internet or from broad internal segments. Then check for signs of prior compromise before declaring the system clean.

Practitioner takeaway: For an exploited vulnerability, remediation is a sequence, not a single action, patch first, contain if you must delay, and then prove the host was not already used as an access point.

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