Summary

A user with a Composer authentication token or login of one organization could have found out whether a package with a given name existed in another organization, because the Composer repository answered requests for existing and missing packages of an organization the user had no access to with different errors. On Private Packagist Cloud, a vendor customer of an organization could similarly have found out whether other packages and versions existed in the organization, and added installs of them to the organization's install statistics.

Who was affected

Organizations and suborganizations on Private Packagist Cloud until the fix on October 14, 2026, and on Private Packagist Self-Hosted installations running a version before 2.0.38, if all of the following are true:

• A malicious user has a Composer authentication token or a login of any organization.
• The attacker knows the URL name of the targeted organization, as used in its Composer repository URL.
• The attacker guesses the names of the packages to check, one name per request.

On Private Packagist Self-Hosted, only users of other organizations on the same installation could check package names.

Organizations on Private Packagist Cloud that give vendor customers access to packages were also affected, if all of the following are true:

• A malicious vendor customer has the Composer authentication token of their customer repository.
• The attacker guesses the names of the packages to check, and for installs also their versions, one name per request or a list of names per install report.

A vendor customer could only check packages of the organization that gave them access. Private Packagist Self-Hosted does not offer vendor customers, so Self-Hosted installations were not affected by this part of the issue.

Impact

A malicious user could have confirmed, one guessed name at a time, whether a package with that name existed in another organization, including packages mirrored from public repositories. Private package names can reveal internal project, product or client names.

The attacker could not list the packages of the other organization, and could not see any package metadata such as versions, descriptions or source URLs, or download any code. The requests did not change any data.

A malicious vendor customer could have confirmed whether a package of the organization existed, and whether a version of it existed, beyond the packages they were given. The customer could also have recorded installs of these package versions, which would then have appeared in the organization's install statistics. The customer could not list the organization's packages, see their metadata or download their code, and could not change any other data.

What we did

When a user or authentication token without access to an organization requests a package from the organization's Composer repository, Private Packagist now returns the same error for every package name, whether or not the package exists in the organization. The error is the same one returned for organizations that do not exist or that the user cannot access. Members of the organization without access to a package still get an error naming the package, so they can fix their permissions.

For vendor customers, Private Packagist now handles packages of the organization that were not given to the customer the same way as missing packages: downloads of them return the same error, and install reports for them are rejected and not counted.

The fix was deployed on Private Packagist Cloud on October 14, 2026, and released in Private Packagist Self-Hosted 2.0.38.

Do customers need to do anything

• Private Packagist Self-Hosted: Upgrade to 2.0.38 or any later version. We recommend upgrading to the latest release.
• Private Packagist Cloud: No action is required.

Credits

Thanks to andikafransisko for reporting this issue.

All security advisories