Executive Summary

This vulnerability in Packistry, a self-hosted Composer repository, involves the failure to enforce expiration of deploy tokens prior to version 0.13.0. The authorization method verified the presence and abilities of tokens but did not check if the token had expired. As a result, expired deploy tokens with valid abilities could still access repository endpoints such as Composer metadata and download APIs.

The issue was fixed by adding an explicit expiration check in the authorization process, ensuring that expired tokens are rejected. Tests were also updated to verify that expired deploy tokens no longer grant access.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability allows an attacker or unauthorized user to continue accessing repository endpoints using expired deploy tokens that still have valid abilities. This means that even after a token should no longer be valid, it could be used to access Composer metadata and download APIs.

The impact is limited to unauthorized continued access, potentially exposing limited data. The CVSS score rates this as a moderate severity issue with low confidentiality impact, no integrity or availability impact, and low privileges required for exploitation.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves expired deploy tokens being accepted by the Packistry repository endpoints due to missing expiration checks. Detection would involve identifying requests made with deploy tokens that are expired but still granting access.

To detect this on your system or network, you can monitor access logs for requests to repository endpoints (such as Composer metadata or download APIs) that use deploy tokens. Specifically, look for tokens that have an expiration timestamp in the past but are still being accepted.

Since the vulnerability is related to token expiration not being enforced, you can audit tokens stored in your system by checking their expiration timestamps against the current time.

Suggested commands (assuming access to the Packistry database or token storage) might include querying tokens with expired timestamps that have been used recently:

• SQL example: SELECT * FROM tokens WHERE expires_at < NOW() AND last_used_at > expires_at;
• Check web server or application logs for HTTP 200 responses to requests with deploy tokens that should be expired.

Additionally, you can test the system by attempting to use a known expired deploy token to access repository endpoints and observe if access is granted (which indicates vulnerability) or denied (which indicates the fix is applied).

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to upgrade Packistry to version 0.13.0 or later, where the vulnerability is fixed by adding an explicit token expiration check in the authorization process.

Until you can upgrade, consider the following immediate actions:

• Manually revoke or delete any deploy tokens that have expired to prevent their use.
• Audit and rotate deploy tokens regularly to minimize the risk of expired tokens being used.
• Monitor access logs for suspicious activity involving deploy tokens, especially those that should be expired.

Applying these steps will reduce the risk of unauthorized access using expired deploy tokens until the official fix is deployed.

Useful 0 Not Useful 0