CVE-2026-33746: Convoy KVM Panel Auth Bypass Vulnerability

CVE-2026-33746 Overview

CVE-2026-33746 is a critical authentication bypass vulnerability in Convoy, a KVM server management panel designed for hosting businesses. The vulnerability exists in the JWTService::decode() method, which fails to verify the cryptographic signature of JWT tokens. While the method configures a symmetric HMAC-SHA256 signer via the lcobucci/jwt library, it only validates time-based claims (exp, nbf, iat) using the StrictValidAt constraint, omitting the crucial SignedWith constraint from the validation step.

This flaw allows attackers to forge or tamper with JWT token payloads — including modifying the user_uuid claim — and have those tokens accepted as valid, provided the time-based claims are satisfied. This directly impacts the SSO authentication flow through the LoginController::authorizeToken endpoint, enabling attackers to authenticate as any user by crafting a token with an arbitrary user_uuid.

Critical Impact

Complete authentication bypass allowing attackers to impersonate any user in Convoy panel deployments, potentially gaining full administrative access to KVM server infrastructure.

Affected Products

• Convoy KVM Server Management Panel versions 3.9.0-beta through 4.5.0
• Deployments utilizing SSO authentication flow
• All hosting environments running vulnerable Convoy versions

Discovery Timeline

• 2026-04-02 - CVE CVE-2026-33746 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-33746

Vulnerability Analysis

The vulnerability is classified under CWE-287 (Improper Authentication) and represents a fundamental failure in JWT token validation. JWT (JSON Web Tokens) security relies on cryptographic signatures to ensure token integrity and authenticity. The signature verification step is critical — without it, any party can modify token claims without detection.

In Convoy's implementation, the JWTService::decode() method was configured to use HMAC-SHA256 for signing tokens but critically failed to include the SignedWith constraint during token validation. This created a situation where tokens were checked only for temporal validity (not expired, not used before valid time, issued in the past) while completely ignoring whether the signature was genuine.

This vulnerability allows complete impersonation of any user in the system, including administrative accounts, by simply crafting a JWT with the desired user_uuid claim and valid time-based claims.

Root Cause

The root cause is the incomplete implementation of JWT validation in the JWTService::decode() method. The code properly instantiated the HMAC-SHA256 signer via lcobucci/jwt but only added the StrictValidAt constraint to the validation configuration. The SignedWith constraint, which is essential for verifying the token's cryptographic signature, was not included in the validation constraints array.

This represents a failure to implement the full security model of JWT tokens, where both signature verification AND claim validation are required for secure token handling.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Constructing a malicious JWT token with arbitrary claims, specifically setting the user_uuid to match a target user (such as an administrator)
2. Ensuring the time-based claims (exp, nbf, iat) are valid (token not expired, valid issuance time)
3. Sending the forged token to the LoginController::authorizeToken SSO endpoint
4. The server accepts the forged token as valid since signature verification is bypassed
5. The attacker gains authenticated access as the target user

The vulnerability mechanism involves the validation flow in JWTService::decode(). The method uses the lcobucci/jwt library with HMAC-SHA256 configured but critically omits the SignedWith constraint from validation. Only time-based claims are verified via StrictValidAt, allowing forged tokens with valid timestamps to be accepted regardless of their signature. See the GitHub Security Advisory for complete technical details.

Detection Methods for CVE-2026-33746

Indicators of Compromise

• Unusual login patterns from unexpected IP addresses for administrative or privileged accounts
• JWT tokens in authentication logs with invalid or missing signatures that were still accepted
• Multiple authentications as different users originating from the same IP address or session
• Sudden access pattern changes for user accounts, especially those with elevated privileges

Detection Strategies

• Monitor authentication logs for tokens with malformed or suspicious signature sections
• Implement application-level logging that captures JWT validation steps and failures
• Deploy Web Application Firewalls (WAF) with rules to detect JWT manipulation attempts
• Analyze SSO endpoint traffic for unusual patterns or high-frequency authentication attempts

Monitoring Recommendations

• Enable verbose logging on the LoginController::authorizeToken endpoint
• Set up alerts for administrative account authentications from new IP addresses
• Monitor for users accessing resources inconsistent with their normal behavior patterns
• Implement session tracking to correlate authentication events with subsequent actions

How to Mitigate CVE-2026-33746

Immediate Actions Required

• Upgrade Convoy to version 4.5.1 or later immediately
• Audit all user sessions and invalidate any suspicious authentications
• Review access logs for signs of exploitation since deploying version 3.9.0-beta
• Rotate all JWT signing keys after upgrading to prevent reuse of previously issued tokens

Patch Information

The vulnerability has been patched in Convoy version 4.5.1. The fix adds the SignedWith constraint to the JWT validation flow, ensuring that all tokens must have a valid cryptographic signature before being accepted. Organizations should upgrade immediately.

For detailed patch information, see the GitHub Release v4.5.1 and the GitHub Security Advisory GHSA-92pg-3w49-4w5x.

Workarounds

• If immediate upgrade is not possible, disable SSO authentication functionality temporarily
• Implement network-level access controls to restrict access to the SSO endpoints
• Deploy a reverse proxy or WAF to validate JWT signatures before requests reach the application
• Consider placing Convoy behind a VPN to limit exposure to trusted networks only

# Configuration example
# Verify your Convoy version and upgrade if vulnerable
# Check current version
cat /path/to/convoy/composer.json | grep version

# Upgrade to patched version using composer
composer require convoypanel/panel:^4.5.1

# After upgrade, rotate JWT signing keys
# Update your .env file with a new APP_KEY
php artisan key:generate

# Clear application cache
php artisan cache:clear
php artisan config:clear