Summary

A malicious suborganization admin could have added any team of the main organization to their suborganization and seen the team's name and members, and could have made any credential of the main organization available in their suborganization and used it there, without the corresponding access in the main organization. The attacker could also have switched the packages of the main organization that used one of its credentials to another credential with the same type and domain, including one the attacker created in their suborganization.

Who was affected

Organizations 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:

• The organization uses suborganizations.
• A malicious user is an admin of a suborganization but does not have the right to manage the main organization.
• The attacker knows or is able to guess the internal identifier of a credential or a team.

Only teams and credentials of the main organization that the attacker's suborganization belongs to could be added.

Impact

A malicious suborganization admin could have added any team of the main organization to their suborganization. The attacker could then have seen the team's name and its members in the suborganization, and the team's members would have gotten the selected access to the suborganization. Every team added this way would have been listed on the suborganization's Teams page and recorded in the audit logs of the suborganization and the main organization.

The attacker could also have made any credential of the main organization available in their suborganization and then used it there like any other credential available to the suborganization. The credential's description, type and domain would have been shown on the suborganization's Credentials page, and every package added with it would have been recorded in the suborganization's audit log.

When removing a credential from their suborganization, the attacker could also have chosen any credential of the main organization as its replacement. The replacement would then have become available in every suborganization the removed credential was available in, including the attacker's. If both credentials had the same type and domain, the packages, synchronizations and mirrored third-party repositories of the main organization and all its suborganizations that used the removed credential would have been switched to the replacement, which could have been a credential the attacker created in their suborganization. Updates of these packages could then have failed or used a credential the organization did not choose. Replacing a credential this way would not have been recorded in the audit log.

The attacker could not see or change a credential's secret, could not change teams or their members in the main organization, could not access the main organization's packages or settings apart from switching the credential described above, and could not see teams or use credentials of other organizations.

What we did

Private Packagist now checks that the user is an owner or admin of the main organization before a team of the main organization is added to a suborganization, and that the user has the right to manage credentials in the main organization before a credential of the main organization is made available in a suborganization. Requests without that access are rejected. Replacing a credential is only possible in the main organization; a replacement chosen while removing a credential from a suborganization is rejected.

We reviewed the audit log entries of teams added to suborganizations on Private Packagist Cloud since April 18, 2023, when we started recording them, and found no team of a main organization added by a suborganization admin without the corresponding access in the main 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.
• Private Packagist Cloud: No action is required.
• If you do not fully trust all of your suborganization admins, review the teams and credentials in each of their suborganizations, and the credentials used by the packages, synchronizations and mirrored third-party repositories of your main organization.

All security advisories