CVE-2020-28949: PEAR Archive_Tar Deserialization of Untrusted Data Vulnerability

CVE-2020-28949 is a deserialization of untrusted data flaw in PEAR Archive_Tar, a PHP component used to handle tar archives. The issue allows an unserialization attack because the lowercase phar: stream wrapper is blocked while the uppercase PHAR: variant is not. PEAR (PHP Extension and Application Repository) is a widely reused open-source framework for PHP components and appears in third-party products such as Drupal Core and Red Hat Linux distributions. Teams that process untrusted archives or run PHP applications embedding Archive_Tar should treat this as a priority until they confirm their versions and configurations against the vendor advisory.

How it works

The weakness is classified as CWE-74 (improper neutralization of special elements). Archive_Tar performs checks intended to block dangerous stream wrappers such as phar:, which can lead to object injection when PHP unserializes data. Because the check is case-sensitive, an attacker who can supply a crafted archive or path that uses the PHAR: prefix can bypass the filter. Once the wrapper is accepted, PHP may deserialize attacker-controlled data, potentially resulting in arbitrary code execution or other unintended behavior inside the PHP process. Exact exploit mechanics and preconditions vary by how the library is called; defenders should rely on the vendor advisory rather than assuming a single attack path.

Am I affected? How to find it in your systems

PEAR Archive_Tar commonly appears wherever PHP applications extract or inspect tar archives—content-management systems, package managers, backup tools, and custom PHP services. It is known to be pulled in by products such as Drupal Core and packages shipped with Red Hat Linux, but any PHP codebase that depends on the Archive_Tar package is in scope.

• Inventory PHP applications and their Composer/PEAR dependencies; search for the package name Archive_Tar or the class Archive_Tar.
• On Linux hosts, check installed PEAR packages and system PHP libraries that may bundle the component (for example, packages provided by the distribution).
• Review configuration and code paths that accept user-supplied archive files or paths and pass them to Archive_Tar methods.
• Confirm the exact installed version against the vendor advisory; public detail on fixed versions is limited here, so treat any unpatched installation as potentially vulnerable.
• Telemetry signs of exploitation are not standardized; look for unexpected PHP process behavior, archive extraction from untrusted sources, or errors referencing phar/PHAR stream wrappers. Correlate with web or application logs that show uploads or path parameters containing PHAR:.

How to remediate

Apply updates per vendor instructions, as required by CISA. Obtain the patched Archive_Tar release (or the updated product package that embeds it) from the official PEAR or downstream vendor channel and deploy it through your normal change process. After patching, re-inventory to verify the vulnerable component is no longer present.

• Rebuild or redeploy any container images and application artifacts that vendorship the library.
• For downstream products (for example Drupal or distribution packages), apply the vendor’s security update rather than attempting a manual library swap unless the vendor documents that approach.
• Harden archive-handling code: accept only expected archive formats, enforce strict allow-lists on file paths, and avoid passing raw user input to extraction routines.
• Run PHP with least privilege and disable unused stream wrappers where the runtime permits.

If you can't patch immediately

Reduce exposure until the update can be installed.

• Segment systems that process untrusted archives so they cannot reach sensitive networks or credentials.
• Disable or restrict archive-upload and extraction features that rely on Archive_Tar if the business can tolerate the outage.
• Apply virtual patching or WAF rules that block request parameters and filenames containing PHAR: (case-insensitive) and other suspicious stream-wrapper prefixes; tune to avoid breaking legitimate traffic.
• Increase monitoring on PHP error logs, file-upload endpoints, and process execution to detect anomalous deserialization or wrapper usage.
• Ensure the PHP process runs with minimal filesystem and network permissions so a successful exploit has limited blast radius.

If your data may have been exposed

Actively exploited vulnerabilities can lead to compromise of the hosting application and any data it can reach. Ransomware use of this CVE is not documented, but that does not rule out other post-exploitation activity. If you suspect exploitation, isolate affected hosts, preserve logs, and begin incident response. As a quick additional check, you can run a free exposure scan of your email addresses against known breach data to see whether credentials or personal information have appeared in prior incidents.