CVE-2026-27968: Packistry Authentication Bypass Vulnerability

CVE-2026-27968 Overview

CVE-2026-27968 is an authentication bypass vulnerability in Packistry, a self-hosted Composer repository designed to handle PHP package distribution. Prior to version 0.13.0, the RepositoryAwareController::authorize() method verified token presence and ability but did not enforce token expiration. This authentication flaw allows expired deploy tokens with the correct ability to continue accessing repository endpoints, including Composer metadata and download APIs.

Critical Impact

Expired deploy tokens can bypass authentication controls and maintain unauthorized access to private Composer repository endpoints, potentially exposing proprietary PHP packages and sensitive dependency information.

Affected Products

• Packistry versions prior to 0.13.0
• Self-hosted Composer repository installations using deploy token authentication
• Environments relying on token expiration for access control

Discovery Timeline

• February 26, 2026 - CVE CVE-2026-27968 published to NVD
• February 26, 2026 - Last updated in NVD database

Technical Details for CVE-2026-27968

Vulnerability Analysis

This vulnerability is classified under CWE-287 (Improper Authentication). The core issue lies in the incomplete authentication validation logic within the RepositoryAwareController::authorize() method. While the implementation correctly validates that a token exists and possesses the required ability (permission), it fails to check whether the token has exceeded its designated expiration time.

This authentication bypass enables persistent unauthorized access even after administrators have intentionally set tokens to expire. The vulnerability affects network-accessible repository endpoints with low attack complexity, requiring only valid (albeit expired) credentials. The impact is primarily confidentiality-related, as attackers with expired tokens can continue reading protected Composer metadata and downloading private packages.

Root Cause

The root cause is missing expiration validation in the authorization logic. The original implementation in RepositoryAwareController.php only verified token presence and capability without calling isExpired() to check the expires_at timestamp against the current time.

Attack Vector

An attacker who previously possessed a valid deploy token can continue using that token to access protected repository endpoints after the token's intended expiration date. This is particularly concerning in scenarios where:

1. A contractor or temporary employee was issued a time-limited deploy token
2. A compromised token was rotated with a new expiration date
3. Security policies require periodic token rotation

The network-based attack vector allows remote exploitation without user interaction, though the attacker requires low-privilege access (possession of a previously valid token).

Vulnerable Code:

            return;
        }

-        if (is_null($token) || ! $token->tokenCan($ability->value)) {
+        if (is_null($token) || ! $token->tokenCan($ability->value) || $token->currentAccessToken()->isExpired()) {
            abort(401);
        }

Source: GitHub Commit Reference

Token Expiration Check Implementation:

        return parent::findToken($token);
    }

    public function isExpired(): bool
    {
        return $this->expires_at?->isPast() ?? false;
    }
}

Source: GitHub Commit Reference

Detection Methods for CVE-2026-27968

Indicators of Compromise

• Successful API requests to repository endpoints using tokens that have passed their expires_at timestamp
• Authentication logs showing access from tokens that should have been invalidated
• Unusual access patterns from deploy tokens that were intended to be temporary

Detection Strategies

• Audit authentication logs for requests made with tokens past their expiration dates
• Implement monitoring for API access using credentials issued to former contractors or revoked accounts
• Review the tokens database table to identify expired tokens that may have been used recently

Monitoring Recommendations

• Enable detailed logging of all deploy token authentications including token expiration status
• Set up alerts for repository access from tokens approaching or past expiration
• Periodically audit active deploy tokens against authorized user lists

How to Mitigate CVE-2026-27968

Immediate Actions Required

• Upgrade Packistry to version 0.13.0 or later immediately
• Audit all existing deploy tokens and revoke any that should have expired
• Review repository access logs for potential unauthorized access using expired tokens
• Regenerate deploy tokens for all active integrations as a precautionary measure

Patch Information

The vulnerability is fixed in Packistry version 0.13.0. The patch adds an explicit expiration check by calling $token->currentAccessToken()->isExpired() during the authorization process. The fix also includes tests to verify that expired deploy tokens are properly rejected.

For detailed patch information, see the GitHub Pull Request and GitHub Security Advisory.

Workarounds

• Manually invalidate all deploy tokens by deleting them from the database and reissuing new tokens
• Implement a proxy layer that validates token expiration before forwarding requests to Packistry
• Restrict network access to Packistry endpoints to trusted IP ranges until patching is complete

# Configuration example
# Upgrade Packistry to the patched version
composer update packistry/packistry --with-all-dependencies

# Verify the installed version is 0.13.0 or later
composer show packistry/packistry | grep version