A researcher hijacked over a dozen Packagist packages—with some having been installed hundreds of millions of times over the course of their lifetime.
The researcher reached out to BleepingComputer stating that by hijacking these packages he hopes to get a job. And, he seems pretty confident that this would work.
At least 14 Packagist packages hijacked
Yesterday, a researcher with the pseudonym ‘neskafe3v1’ reached out to BleepingComputer stating he had taken over fourteen Packagist packages, with one of them having over 500 million installs.
Packagist is the primary registry of PHP packages that are installable via Composer, a dependency management tool. Rather than hosting these packages though, Packagist serves more as a metadata directory that aggregates open source packages published to GitHub. These packages can then be installed by developers on their machines by running the composer install command.
The names of the hijacked packages include:
|Package name||Total number of Installs|
|tga/simhash-php (aka tgalopin/simhashphp)||30,555|
The researcher provided proof to BleepingComputer demonstrating that on Monday, May 1, the Packagist pages for these packages were modified to point to the researcher’s (fake) repo, as opposed to the legitimate GitHub repository for each package.
As an example, here’s how the Packagist page for package appeared on Monday—with its GitHub link changed to researcher’s repo instead of the authentic github.com/acmephp/acmephp.
These changes have now been reverted by the Packagist team as checked by BleepingComputer.
Publishing process on Packagist is a bit different from that on open source repos like npm or PyPI. A developer, as opposed to uploading binaries or software releases directly to Packagist.org, simply creates a Packagist.org account, and “submits” a link to their GitHub repo for a particular package. Packagist’s crawler then visits the provided repo and aggregates all the data to display on the Packagist page for that package.
When a developer runs Composer with ‘install’ or ‘update’ commands, their Composer instance may first look for the presence of the packages locally, failing which, it defaults to and retrieving the GitHub URL listed for that package. The contents of the package are then downloaded from this GitHub repo listed on the package’s Packagist page.
This is in stark contrast to how npm or PyPI works—that is, these registries host and distribute software releases directly from their servers.
By modifying the Packagist page for each of these packages, the researcher effectively hijacked the installation workflow used within Composer environments. Developers would now get the contents of a package from neskafe3v1‘s GitHub repo, rather than the project’s repository.
To keep the demonstration to a minimum, the researcher simply changed the composer.json file—something akin to an application manifest, within these packages to read:
“Pwned by neskafe3v1…. Ищу работу на позиции Application Security, Penetration Tester, Cyber Security Specialist.”
He did so by forking the original project repository, modifying the “description” field within composer.json, and committing the change to his forked repository. At no point did he merge the changes back into the original repository (doing so would have required additional access and possibly invited scrutiny of maintainers).
Instead, the researcher apparently gained access to the maintainers’ Packagist accounts and changed the GitHub URLs to the listed packags to that of his forked repos. But, he did not reveal the exact method used for hijacking to BleepingComputer.
When pressed by BleepingComputer to reveal the exact technique that the researcher had used to hijack these packages, we were told this was not a zero-day but a known technique. But we were not told whether the hijack was achieved through, for example, credentials compromise, takeover of , or yet another technique:
“As you can see, I’m looking for a job (that message ‘Ищу работу на позиции…’ means ‘I’m looking for a job…’), so I will disclose a report after I will be hired by some company,” the researcher told BleepingComputer, likening the entire hijacking campaign to “an advertisement of myself as an employee.”
“Until there is success, there is nothing to talk about.”
Hijacked via credentials compromise
In a statement to BleepingComputer, the Packagist team said that no malicious impact had been observed thus far on the platform as a result of this action while confirming the takeover indeed resulted from credentials compromise of maintainer accounts.
“To our knowledge this has not been used for any malicious purposes and was limited to a few old accounts with insecure passwords and missing 2 factor authentication,” Nils Aderman of Packagist.org, who is also one of the original Composer developers, told BleepingComputer.
“All four accounts appear to have been using shared passwords leaked in previous incidents on other platforms. Please, do not reuse passwords,” warn Packagist admins.
“On May 2nd, at 7:21 am UTC we were notified by Juha Suni about the change of URL to multiple Doctrine packages,” further explain the admins in a released today.
Working alongside Marco Pivetta aka Ocramius, Packagist admins promptly identified all accessed accounts, disabled access to them and restored the GitHub URLs to their former values. The restoration effort was completed by Tuesday morning.
The researcher additionally told BleepingComputer that he had not abused the technique to distribute malware, but at the same time, said he had not notified either Packagist or the package owners of the little experiment—which raises eyebrows with regards to the ‘ethical’ nature of this research.
“The only thing I did – I altered ‘description’ field in composer.json files,” said the researcher pointing us to proofs such as Git commits.
“I’ve just changed the link from (original) to …my fork. There is no malware, you can diff the original files to mine. I didn’t notify anybody of the attack, neither Packagist admins, nor package owners.”
In their blog post, Packagist admins request that researchers report bugs and vulnerabilties in a responsible manner.
“If you are a security researcher and know of a Packagist.org vulnerability or would like to do research on Packagist.org, we ask you to please coordinate testing with us to avoid negative user impact, and to disclose these vulnerabilities .”
“You can reach us at firstname.lastname@example.org and we reply promptly to all requests or reports. We of course provide credit and publish details of reported vulnerabilities…”