# CVE-2020-14871: Oracle Solaris and Zettabyte File System (ZFS) Unspecified

> Unauthenticated attackers can achieve full system takeover via a memory corruption flaw in the Pluggable Authentication Module.

- **Severity:** Critical 10.0 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`)
- **Exploited in the wild:** Yes, since 3 Nov 2021 (CISA KEV)
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 21 Oct 2020
- **Updated:** 21 Oct 2025
- **Also known as:** GHSA-7pcp-8fjh-246q

## What is CVE-2020-14871?

CVE-2020-14871 is a critical memory corruption vulnerability in Oracle Solaris, published on 21 Oct 2020. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

Vulnerability in the Oracle Solaris product of Oracle Systems (component: Pluggable authentication module). Supported versions that are affected are 10 and 11. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Solaris. While the vulnerability is in Oracle Solaris, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Solaris. Note: This CVE is not exploitable for Solaris 11.1 and later releases, and ZFSSA 8.7 and later releases, thus the CVSS Base Score is 0.0. CVSS 3.1 Base Score 10.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).

Weakness: CWE-787 (Out-of-bounds Write)

## Which versions are affected by CVE-2020-14871?

It affects 1 product.


Products: Oracle Solaris.

## How do I fix CVE-2020-14871?

No fix has been published for CVE-2020-14871 yet. Limit exposure of the affected software until one is available. US federal agencies must fix it by 3 May 2022.

## Is CVE-2020-14871 being exploited?

Yes. Attackers have exploited CVE-2020-14871 in the wild since at least 3 Nov 2021.

Public exploit code:

- This is a basic ROP based exploit for CVE 2020-14871. CVE 2020-14871 is a vulnerability in Sun Solaris systems libpam library, and exploitable over ssh (github_poc): https://github.com/robidev/CVE-2020-14871-Exploit
- Oracle Solaris SunSSH PAM parse_user_name() Buffer Overflow (metasploit)
- Solaris SunSSH 11.0 x86 - libpam Remote Root (exploitdb)
- Solaris SunSSH 11.0 x86 - libpam Remote Root (2) (exploitdb)
- Solaris SunSSH 11.0 x86 - libpam Remote Root (3) (exploitdb)
- This is a little Python script to detect the "EvilSun" vulnerability (CVE-2020-14871) on Solaris systems. The vulnerability is a buffer overflow in the Pluggable Authentication Module (PAM) `pam_unix_auth` when handling keyboard-interactive authentication in SSH. (github_poc): https://github.com/FromPartsUnknown/EvilSunCheck

## Other vulnerabilities in Oracle Solaris

- [CVE-2019-3010](https://insights.sbomify.com/CVE-2019-3010/): Oracle Solaris Privilege Escalation (high 8.8, exploited in the wild)
- [CVE-2026-46978](https://insights.sbomify.com/CVE-2026-46978/): Missing authorization in Oracle Solaris (critical 10.0)
- [CVE-2017-3623](https://insights.sbomify.com/CVE-2017-3623/): Other in Solaris Operating System (critical 10.0)
- [CVE-2014-0397](https://insights.sbomify.com/CVE-2014-0397/): Memory corruption in n/a (critical 10.0)
- [CVE-2010-3509](https://insights.sbomify.com/CVE-2010-3509/): Other in n/a (critical 10.0)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2020-14871 and fix it if it is affected.

What it is: CVE-2020-14871 is a critical memory corruption vulnerability in Oracle Solaris, published on 21 Oct 2020. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: Yes. Attackers have exploited CVE-2020-14871 in the wild since at least 3 Nov 2021.

Affected product: Oracle Solaris. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2020-14871/ (Markdown: https://insights.sbomify.com/CVE-2020-14871/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2020-14871
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2020-14871
- OSV: https://osv.dev/vulnerability/CVE-2020-14871

---
From sbomify Insights: https://insights.sbomify.com/CVE-2020-14871/
Summaries are generated and may contain mistakes; the official description above is the record.