CVE-2026-27968
Token Expiration Bypass in Packistry Repository Authorization
Publication date: 2026-02-26
Last updated on: 2026-03-02
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| packistryphp | packistry | to 0.13.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-613 | According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization." |
| CWE-287 | When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
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.
How can this vulnerability impact me? :
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.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
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).
What immediate steps should I take to mitigate this vulnerability?
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.