The PHP project is ending its endorsement of PEAR, and I think that is right. An end with a date is better than an end by neglect. But the static archive that is to replace pear.php.net will serve go-pear.phar until the end of 2027, at the same address where a version containing malware was served in 2019. Whether a downloaded copy is the one that was put there still cannot be checked today. A frozen archive is only safe once its integrity can be verified and its last users notice in time that it is going away.
In February 2019, we at thePHP.cc began an article by admitting that we had not expected to ever write about PEAR again. This time I was not surprised. The only open question was when the topic would come back. “Blast from the Past” ended with a sentence that now has an answer:
If the PEAR project lacks the human resources to ensure the safe and secure operation of pear.php.net as well as related infrastructure and software then maybe they should acknowledge that fact and as a consequence come up with a plan to retire PEAR.
On 27 August 2026, Nick Sdot opened the discussion of the RFC “End PEAR Project Endorsement”. The vote closed yesterday, 19 October 2026, at 13:15 UTC. It needed a two-thirds majority. The RFC received 40 votes in favour, none against, and no abstentions.
A word on transparency: I serve on the board of The PHP Foundation and am a member of its Ecosystem Security Team. The RFC is not a project of The PHP Foundation. I voted in favour of it on 5 October 2026.
Where PEAR came from and how it got here is told by Eric L. Barnes in “The History of PEAR, PHP's First Package Manager”, published on 13 October. I will not retell that story here.
The diagnosis of 2019 held
One statement from 2019 did not survive the year. We wrote that PHP installs a PEAR environment unless you configure --without-pear when you build it. On the day our article appeared, Nikita Popov suggested on internals that the installation of PEAR be disabled by default in PHP 7.4. I replied with “+1”. Ten days later, the change was committed. Since PHP 7.4, released on 28 November 2019, PEAR including PECL is only installed with --with-pear, and that option is deprecated.
Nikita explicitly did not base his suggestion on the break-in:
It's not really the recent security breach itself, but rather the underlying issue that PEAR simply isn't actively maintained anymore.
In March 2022, Thomas Chauchefoin of SonarSource showed that the problem of 2019 had not been a single artefact. He found two vulnerabilities in pearweb, the software behind pear.php.net, that had been exploitable for more than 15 years. A token for resetting a password could be guessed in fewer than 50 attempts, which allowed the takeover of any maintainer's account. pearweb unpacked uploaded packages with a version of Archive_Tar that had a known vulnerability. Together, this allowed arbitrary code to be executed on the server. SonarSource reported both on 30 July 2021, and they were fixed with pearweb 1.32 on 13 March 2022. SonarSource's summary raises questions about “the lack of security contributions from companies relying on them”.
What the RFC says about the state of things in 2026 reads like a sequel. The website has broken links, a search that does not work, and visible spam such as links to online casinos. The pearweb repository has been archived. The PHP project has no access to PEAR's infrastructure and website, even though both run under php.net. According to PEAR's metadata as of 22 June 2026, 534 of its 603 packages are marked as unmaintained, and 63 of the remaining 69 have not been updated for a long time.
None of these numbers describes the failure of a single person. They describe a project that had too few people to operate public infrastructure securely. That was our diagnosis in 2019, and it has been confirmed.
The RFC ends only what PHP is responsible for
The RFC proposes four actions. A static archive with package pages, downloads, manuals, and bug reports replaces pear.php.net. It remains available, including the endpoints for the PEAR Installer, until 31 December 2027, and is offered as a download after that. From PHP 8.7 onwards, the PEAR Installer is no longer bundled. The official websites name Composer instead of PEAR as the community package manager, without that making Composer a PHP project. PEAR's mailing lists move to the “Inactive Lists”.
The most important paragraph of the RFC is in its introduction:
PHP internals cannot vote to stop independent maintainers from maintaining PEAR elsewhere. PHP internals can, however, decide what PHP bundles, what PHP domains serve, and what official websites endorse.
This is the plan we asked for in 2019. The PHP project does not end PEAR; it ends its own responsibility for PEAR. Whoever wants to continue PEAR as an active project remains free to do so, according to the RFC, under a domain of their own.
Earlier RFCs by Davey Shafik (2016) and James Titcumb (2025) never went to a vote. Titcumb withdrew his on the day he had published it, because it had become unclear whether PHP had any say over PEAR at all, and called the topic “a can of worms”. Nick Sdot sidesteps that question by separating bundling, hosting, and endorsement, and by putting to the vote only what is in the hands of the PHP project anyway.
Support came from the other side as well. Chuck Burgess, long-time PEAR maintainer and member of the PEAR Group, contacted the author of the RFC during the discussion and expressed his support. He also voted in favour himself. After several attempts at contact and many months without a result, Rowan Tommins asked: “If that's not long enough, how long is?”
How little still depends on PEAR was worked out by Nick Sdot in the same discussion. Of the six packages that are still published through PEAR, three belong to PEAR's own infrastructure, and two were recently marked as unmaintained. That leaves a single independent package, Net_SMTP, and it is also available on Packagist.
The last reason for bundling is gone
In 2019, we wrote that the only reason PHP installs PEAR by default is that pecl needs it. That reason no longer exists. In September 2025, James Titcumb's RFC “Recommend PIE and deprecate PECL” was accepted with 36 votes in favour, none against, and five abstentions. Since then, the PHP project recommends PIE, the PHP Installer for Extensions. Version 1.0.0 was released on 17 June 2025. Like Composer, PIE is distributed as a PHAR, and it finds extensions through Packagist.
In November 2020, Derick Rethans, as release manager of PHP 7.4, had still asked the maintainers of the php image that Docker distributes on Docker Hub to keep building with --with-pear, because pecl was the only official way to install extensions. Since June 2026, the images for PHP 8.6 are built without --with-pear. The images for PHP 8.2 to 8.5 still contain pecl. Homebrew still builds PHP with --with-pear.
In php-src, pull request #20124 by Jakub Zelenka has been open since 10 October 2025, one day after Titcumb withdrew his RFC on PEAR. The draft removes PEAR and PECL together: the --with-pear option, the pear/ directory, and the download of install-pear-nozlib.phar when the source tarballs are created. According to its checklist, the Windows build, the constants PEAR_INSTALL_DIR and PEAR_EXTENSION_DIR, and documentation that points to PIE are still open. The RFC makes the direction of this pull request binding for PHP 8.7.
Frozen is not the same as safe
What the archive gets right follows from what it no longer has. A static archive has no logins, no password resets, and no uploads that are unpacked on the server. Both vulnerabilities from 2022 were in code that ran on the server, and that code does not exist in the archive. The attack surface of 2022 disappears completely. In an earlier article, I wrote that the safest door is the one that was never built. The archive removes several such doors again.
What remains is the problem of 2019. The proof of concept for the archive still serves go-pear.phar and install-pear-nozlib.phar. Both files are byte-for-byte identical to the ones on pear.php.net today. There are no checksums or signatures, neither in the proof of concept nor in the RFC nor in the discussion on internals. Nick Sdot confirmed on internals that the archive is to keep providing these files under pear.php.net and that the domain will not change. In 2019, we wrote that the maintainers of PEAR should have provided signatures to make it possible to verify go-pear.phar. That argument still holds.
One thing does change, though. Until now, the PHP project could point out that it has no access to pear.php.net. Once the archive replaces the current website, the PHP project serves these files itself. The responsibility for their integrity then lies with the PHP project.
A pull request by Daniel Scherzer shows that this question is not only about old installations. The script scripts/dev/makedist, which release managers use to create PHP's source tarballs, downloads install-pear-nozlib.phar from pear.php.net for every release. This is the case on every branch from PHP 8.2 to 8.6. Scherzer points out that this happens “without any validation”, and proposes adding the file to the php-src repository instead. His attempt to rebuild it from PEAR's sources produced a file with a different SHA-256 checksum that could not be installed. So whoever wants to check the downloaded file against its sources currently cannot. The pull request is still open. PHP 8.5 receives security updates until the end of 2029, PHP 8.6 for even longer. Unless something changes, their release managers will download this file for years after 31 December 2027, from an address that is then no longer meant to exist in its current form.
Andrew Nesbitt, whom Rowan Tommins quoted in the discussion, uses CocoaPods to describe what freezing a registry means: “A frozen registry is the one place a package can never be patched again.” The fix for a vulnerability in a PEAR package will at best be available on Packagist. For everybody who uses the PEAR Installer, the vulnerable version remains the latest one.
Then there are the zombies of 2019. On 21 April 2014, I announced that PHPUnit would no longer be distributed as a PEAR package. PHPUnit 3.7.35 and 4.0.17, the last working PEAR packages, printed a notice about this every time the test runner was invoked. On 1 December 2014, 3.7.36 and 4.0.18 followed as PEAR packages that no longer installed a working PHPUnit, only a script that printed an error message. On 31 December 2014, I shut down pear.phpunit.de. More than four years later, dozens of requests from PEAR Installer clients were still arriving at pear.phpunit.de every hour.
The announcement, the warning, and the tombstone did not reach these clients. A warning only reaches whoever reads the output. A cron job or a forgotten step in a build reads no output. The archive keeps such clients quietly alive until the end of 2027. On 1 January 2028 they will break, without any warning ever having reached them.
Derick Rethans suggested on internals that the archive be operated for a limited time only and that a tarball then be moved to museum.php.net, “for archeologists”. The RFC turned this into the deadline at the end of 2027 and the download after it. For that tarball, too, the question is how anybody can check that it is unaltered.
According to the RFC, the infrastructure team decides the technical details. Today, on internals, I made four suggestions for them:
- A signed manifest with the SHA-256 checksums of every file in the archive, published together with the archive and later with the tarball. For
install-pear-nozlib.phar, the checksum also belongs inmakedist, or the file itself in the php-src repository, as Scherzer proposes. -
go-pear.pharas a tombstone: a file that no longer installs a PEAR environment and only explains how to move on to Composer and PIE. This is what I did with PHPUnit 3.7.36 and 4.0.18 in 2014. This is not possible forinstall-pear-nozlib.pharas long as PHP's source tarballs contain that file. - Brown-outs before the deadline, following the example of JCenter. In 2024, JFrog redirected requests to JCenter to Maven Central for a few hours at a time, then for a full day, before the redirect became permanent. According to Nesbitt, this gave every remaining build a failure it could react to before the final one came.
- Aggregated access numbers: which files and endpoints are still requested, how often, and by which versions of the PEAR Installer. Without these numbers, nobody knows whether the last users can be reached at all.
Each of these suggestions costs the infrastructure team time, and a lack of time is what brought PEAR to where it is today. Brown-outs break builds on purpose. A tombstone breaks installations that still work today. I still think both are right, because an announced failure is cheaper than the unannounced one on 1 January 2028. I consider the manifest with checksums the minimum. Without it, the archive repeats the gap of 2019, this time under the responsibility of the PHP project.
PEAR lives on in the PHAR
PHPUnit was released on pear.php.net from 2001 until July 2006, and after that through my own channel, pear.phpunit.de, until the end of 2014, together with PHP_CodeCoverage, PHPUnit_MockObject, phpcpd, and phploc. On pear.php.net, I also maintained Image_GraphViz and XML_Transformer. The PEAR Installer installed packages globally into a directory on the include_path, so every project on a machine had to use the same version of PHPUnit. Composer installs dependencies per project, and every project can have its own version of a PHAR. Since PHPUnit 3.7, released in the autumn of 2012, the PEAR Installer was no longer the only way to install PHPUnit. From PHPUnit 4.0 onwards, the PEAR package was only a wrapper around the PHAR.
The idea for the PHAR came out of the PEAR project. PHP_Archive, a PEAR package originally conceived by Davey Shafik, was first released in May 2005 and made it possible to ship an entire PHP application as a single file. Greg Beaver and Marcus Börger, who maintained PHP_Archive together with Davey Shafik, built the phar extension on top of it, which has been part of PHP since PHP 5.3. PHPUnit is distributed as a PHAR today, and so are Composer and PIE. There are GPG signatures for PHPUnit, SHA-256 checksums for Composer, and attestations for PIE that can be checked with gh attestation verify. go-pear.phar is a PHAR, too, but there is none of this for it.
Other parts of PEAR live on without anybody calling them PEAR anymore: the naming convention that became PSR-0, the packages under pear/ on Packagist, and tools such as PHP_CodeSniffer and phpDocumentor, which started as PEAR packages just like PHPUnit. Barnes traces these lines in detail.
My thanks go to everybody who kept PEAR going when most of us had long moved on. In September, Chuck Burgess recovered the bug pages that had been lost so that the archive is complete. In 2019, we wrote that PEAR was a significant driver for the professionalisation of PHP. That still stands.
Your builds may still depend on PEAR
Everything keeps working until 31 December 2027. That is exactly why nothing stands out. There are three things you should check before then:
- Search Dockerfiles, CI configurations, and provisioning scripts for
go-pear,install-pear,pear install,pear channel-discover, andpecl install. A Dockerfile that builds onphp:8.6and callspecl installfails, because these images no longer containpecl. - Get the PEAR packages you still need with Composer from the
pear/vendor on Packagist, and replacepeclwith PIE. For Docker builds, PIE provides an image that can be mounted during the build without remaining in the final image. - Find the systems nobody knows about anymore. In 2019, we wrote that many companies do not know exactly which applications are still running on their infrastructure. If such a system uses PEAR, nobody will notice until 1 January 2028.
Ending things is part of the process
In 2019, we quoted Bruce Schneier: “Security is a process, not a product.” Ending things is part of that process. In 2019, we asked for a plan to retire PEAR. Now there is one, and the only open question is how well it will be carried out. In January 2019, nobody could check whether a downloaded go-pear.phar was the genuine one. Whether that will be different in December 2027 depends on a single file of checksums.
The most important sources for this article are the RFC “End PEAR Project Endorsement” by Nick Sdot (version 1.0.0), the discussion on internals, “The History of PEAR, PHP's First Package Manager” by Eric L. Barnes (13 October 2026), and “Sunsetting a Package Manager” by Andrew Nesbitt (23 June 2026). All other sources are linked where they are used in the text.
