| ID | PPSA-202610-2 |
|---|---|
| Published | 2026-10-02 |
| Private Packagist Cloud | Affected. Fixed on 2026-10-02. |
| Private Packagist Self-Hosted (KOTS) | Affected <= 2.0.36. Fixed in 2.0.37. |
| Private Packagist Self-Hosted (Helm) | Affected <= 2.0.36. Fixed in 2.0.37. |
Summary
A malicious suborganization admin could have set up a notification channel in their suborganization that received the security notifications for private packages of the main organization, including package and repository details they had no access to.
Who was affected
Organizations on Private Packagist Cloud until the fix on October 2, 2026, and on Private Packagist Self-Hosted installations running a version before 2.0.37, if all of the following are true:
- The organization uses suborganizations.
- Security monitoring is enabled for the main organization (Settings > Security).
- A user is an admin of a suborganization but does not have access to the main organization's private packages.
- That user created a notification channel in the suborganization and selected a team of the main organization for security notifications.
Impact
A malicious suborganization admin who created a notification channel in their suborganization and selected a team of the main organization for security notifications could have received, for each private package of that team with a security issue:
- the package name and the affected branches or versions
- the advisory details
- the affected dependency and its installed version
- the issue state, the policy, and the username of the user who last changed the state
- malware report details, if the issue is a malware report
- the repository URL
- the custom package JSON, if configured
- the IDs of the credentials, the mirrored repository and the uploaded artifacts the package uses
- the package's update webhook URL
With the update webhook URL, the attacker could have triggered updates of these packages from their configured source, but not changed the packages or their source.
The form to add a notification channel in the suborganization also showed the attacker:
- the names of the main organization's teams, including teams the suborganization has no access to, and the number of private packages in each
- all email addresses used as recipients in the main organization's notification channels, and whether each one is confirmed
The attacker could not read package code or credential secrets, could not change anything in the main organization, and could not see data of other organizations.
What we did
The form to add a notification channel in a suborganization now only offers the suborganization's teams and email addresses, and Private Packagist rejects teams of the main organization. Notification channels that were already bound to a team of another organization no longer receive security notifications for that team.
Do customers need to do anything
- Private Packagist Self-Hosted: Upgrade to 2.0.37 or any later version. We recommend upgrading to the latest release.
- Private Packagist Cloud: No action is required to prevent unauthorized access from now on.
- To check for past unauthorized access, open Settings > Notification channels in each suborganization, edit each channel, and check whether the team selected for security notifications belongs to the suborganization. The audit log shows who created each channel. For webhook channels, Deliveries shows what was sent for each triggered webhook.
Credits
Thanks to TruongLV1 from FPT NightWolf for reporting this issue.
Start Free Trial
Login to create an organization and start your free trial!