PEAR Archive_Tar improper link resolution (CVE-2020-36193) — a component nobody remembers installing, running inside products
A PHP component for handling archive files checks symbolic links inadequately, allowing writes to places never intended. The catalog description goes out of its way to note that this component is known to be used inside third-party products such as Drupal Core and Red Hat Linux.
Key facts
- CVE IDCVE-2020-36193
- Affected (vendor / product)PEAR Archive_Tar
- CWECWE-22, CWE-59
- ExploitationListed in CISA KEV (exploitation confirmed)
- Remediation due2022-09-15 (U.S. federal civilian agencies, BOD 22-01)
Key points
- A PHP component for tar archives checks symbolic links inadequately, so writes involving directory traversal become possible.
- The catalog explicitly notes known use of the component inside products built by others, among them Drupal Core and the Red Hat distribution of Linux.
- Two weaknesses are recorded, CWE-22 and CWE-59; only 102 of the 1,694 records this site holds as of 2026-09-04 (6.0%) carry more than one.
- Only 2 of those same 1,694 records name PEAR as vendor, showing that rarity of listing says nothing about reach.
- Added 25 August 2022, due 15 September 2022, an allowance of 21 days, with updates per vendor instructions as the required action.
1A component running under a name you do not know
Archive_Tar is a PHP component for reading and writing tar archives. Most people have never heard of it, and use it anyway. That is presumably why the catalog adds its note about products built by others. Strictly, naming third-party products is not part of describing a vulnerability.
Without it, though, the description never reaches the people who need to act, because they do not know a component by that name is running in their environment.
2Not using it directly does not mean not being affected
Unpacking an archive is a classic case of handling a file that arrived from outside. Where link checking is loose, writes can land somewhere that was never meant to receive them. Hence two classifications: the limitation on pathnames and the following of links both take part.
3What two classifications mean
Only 6.0% of entries carry more than one classification. Some flaws are not a single weakness but a pair that has to line up before anything works. Fix one and leave the other, and a different route can remain open. Note too that a component this widely deployed has appeared in the catalog twice. How rarely something is listed says nothing about how far it reaches.
4Who does the fixing
From the position of someone using it, the party who must fix it is often not you. Component updates arrive as product updates, so waiting is frequently the only option. Even then, knowing what is inside at least allows the question of whether this concerns you to be answered. That the catalog names third-party products reads as help toward exactly that judgment.
Why it matters
A vulnerability in a widely embedded component reaches least well the users who do not know its name. Without knowing what is inside, they cannot even decide whether it concerns them. The catalog naming third-party products is an unusual courtesy, which also means that ordinarily, tracing your own dependencies is the only way the information arrives.
FAQ
What is PEAR?
Why name third-party products in the description?
What follows from two classifications?
Sources (primary)
This article is an independent organization based on the U.S. official data below. Always verify the exact, latest details and applicability with the official and vendor sources.
- CISA KEV Catalog (known exploited list)
- NVD (CVE details / CVSS)
- This product uses data from the NVD API but is not endorsed or certified by the NVD. KEV data is CC0 (public domain).