Summary

Adding a package to a team did not check that the package belongs to the team's organization. A user with edit access to a package in one organization and to a team in another could have added the package to that team. The team's members and notification channels would then have received the package's security notifications, also after the user lost access to the package's organization.

Who was affected

Organizations on Private Packagist Cloud until the fix on October 19, 2026, and on Private Packagist Self-Hosted installations running a version before 2.0.38.

To exploit this, an attacker needed edit access to a package in the targeted organization and edit access to a team in a second organization. On Self-Hosted, both organizations had to be on the same installation.

Packages managed by a synchronization of members and packages could not be added this way.

Impact

A malicious user could have made the members of a team in their own organization, and the notification channels set up for that team, receive the security notifications of a package they had edit access to in another organization. These notifications contain the package name, the affected versions and dependencies, and details of the security advisories found for them. The team would have kept receiving them after the user lost access to the other organization.

The members of the team could not view the package, download its code or see it in their organization's Composer repository, and the attacker could not change the package or any data of the other organization.

What we did

Teams now only accept packages of their own organization. Security notifications are now only sent to teams of the package's organization, which also stops notifications through packages that were added to a team before. The fix was deployed on Private Packagist Cloud on October 19, 2026, and released in Private Packagist Self-Hosted 2.0.38. We found this vulnerability during an internal security review.

We reviewed the package access of all teams on Private Packagist Cloud, and the audit log entries of packages added to teams since August 20, 2025, when we started recording them, and found no team that was given a package of another organization. To the best of our knowledge, this vulnerability was not exploited on Private Packagist Cloud.

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. Afterwards, run this command to check your installation for teams that have access to a package of another organization, and for audit log entries that gave a team such access. It prints one line for each match, and otherwise "No teams with packages of other organizations found" and "No audit log entries granting teams access to packages of other organizations found". Access given to a package that was deleted since cannot be checked. If it reports any match, contact us at contact@packagist.com.

  kubectl exec $(kubectl get pods --field-selector=status.phase=Running --no-headers -o custom-columns=":metadata.name"|grep worker-) -- /bin/sh -c "/srv/manager/bin/console packagist:audit --vulnerability PPSA-202610-14"
  

• Private Packagist Cloud: No action is required.

All security advisories