CVE-2026-40194: Observable Timing Discrepancy in phpseclib SSH2 HMAC Verification

CVE-2026-40194 identifies a timing side-channel vulnerability in phpseclib, a widely utilized PHP library for secure communications. The vulnerability resides in the SSH2 protocol implementation, specifically within the phpseclib\Net\SSH2::get_binary_packet() method. This function is responsible for receiving and validating incoming SSH packets against a negotiated MAC algorithm.

The flaw manifests as CWE-208: Observable Timing Discrepancy during the HMAC validation phase of the packet lifecycle. The application compares the computed local HMAC with the provided remote HMAC using a standard inequality operator. This operation executes in variable time depending on the length of the matching byte prefix between the two hashes.

An attacker observing the execution time of the validation sequence can theoretically infer the correct bytes of the HMAC. This timing signal leaks state information about the expected cryptographic signature. The vulnerability highlights the importance of constant-time comparison functions when handling cryptographic material.

Despite the cryptographic weakness, the practical risk is heavily constrained by external factors. The vulnerability requires precise nanosecond-level timing measurements over a network connection. Protocol-level design features in SSH further obstruct the extraction of a complete HMAC.

The root cause of CVE-2026-40194 lies in the use of PHP's standard inequality operator (!=) for comparing binary string data. In the get_binary_packet() function, the library reconstructs the incoming packet and generates a local hash using the session's active MAC algorithm. It then compares this locally generated hash against the MAC appended to the received packet.

When the PHP engine evaluates the != operator on two strings of equal length, it delegates the comparison to the underlying C library function memcmp(). Standard implementations of memcmp() are optimized for performance rather than security. The function compares memory buffers byte-by-byte and terminates immediately upon encountering the first mismatching byte.

This short-circuiting behavior creates a direct correlation between the execution time and the number of matching leading bytes. A comparison where the first byte mismatches will return faster than a comparison where the first 15 bytes match. Researchers measured this timing discrepancy to be approximately 2 to 14 nanoseconds per byte in typical PHP environments.

The execution time variation provides an observable signal that corresponds to the internal state of the cryptographic comparison. While the signal is deterministic, it is exceedingly small. The timing delta exists strictly within the CPU cycles consumed by the memcmp() routine before returning control to the PHP execution context.

The vulnerable code path in phpseclib/Net/SSH2.php performed a direct comparison between the extracted HMAC and the computed hash. The implementation used the != operator, which inherently lacks constant-time guarantees.

// Vulnerable implementation
if ($hmac != $this->hmac_check->hash($reconstructed)) {
    $this->disconnect_helper(DisconnectReason::MAC_ERROR);
    throw new ConnectionClosedException('Invalid UMAC');
}

The patch resolves this by replacing the standard inequality operator with hash_equals(). The hash_equals() function is explicitly designed to compare two strings in constant time, regardless of whether or where a mismatch occurs. This change eliminates the timing side-channel by ensuring the comparison always processes the entire string length.

// Patched implementation
- if ($hmac != $this->hmac_check->hash($reconstructed)) {
+ if (!hash_equals($hmac, $this->hmac_check->hash($reconstructed))) {

To support legacy PHP environments where hash_equals() is unavailable, the patch introduces an internal fallback method named _equals(). This method implements an XOR-sum loop that bitwise-XORs each byte of the two strings and accumulates the result using a bitwise-OR operation. The loop iterates over the entire length of the string unconditionally, ensuring the execution time remains constant.

Exploitation of CWE-208 typically involves statistical timing analysis to iteratively guess a secret value. An attacker sends multiple crafted inputs, measures the response time for each, and isolates the input that yields the longest processing time. The longest time indicates the highest number of matching prefix bytes.

In the context of CVE-2026-40194, applying this methodology is virtually impossible due to severe signal-to-noise ratio issues. The observable timing difference of 2 to 14 nanoseconds is completely masked by network latency and jitter. Typical local area network jitter is measured in hundreds of microseconds, which is orders of magnitude larger than the timing signal.

Furthermore, the SSH protocol specification strictly prevents the iterative testing required for a timing attack. If the get_binary_packet() method detects a MAC mismatch, it immediately terminates the connection. An attacker cannot submit multiple guesses against the same session state because the channel is destroyed upon the first failure.

Re-establishing a connection to continue the attack is also ineffective. Each new SSH connection initiates a fresh Key Exchange (KEX) phase, resulting in the negotiation of a completely new MAC key. Additionally, the HMAC computation includes a monotonically increasing sequence number, ensuring the expected hash changes with every single packet.

The direct impact of CVE-2026-40194 is limited to a theoretical information leak of HMAC prefix bits. An attacker capable of measuring execution time with nanosecond precision could deduce partial knowledge of the expected packet signature. This exposure does not extend to the underlying cryptographic keys or plaintext data.

The vulnerability is assigned a CVSS v3.1 score of 3.7, reflecting a Low severity rating. The attack vector is Network, but the attack complexity is classified as High. The stringent constraints imposed by the SSH protocol and network realities reduce the probability of successful remote exploitation to near zero.

Confidentiality is scored as Low because the leaked information is restricted to the MAC value itself. Integrity and Availability are not impacted, as the vulnerability provides no mechanism to modify data or disrupt service operations. The scope of the vulnerability remains unchanged, confined entirely to the SSH daemon process.

Despite the low exploitability, patching is highly recommended to enforce cryptographic best practices. Side-channel vulnerabilities, while often theoretical in isolation, can sometimes be combined with other flaws or executed in specific constrained environments where timing measurements are more reliable.

The primary remediation for CVE-2026-40194 is upgrading the phpseclib dependency to a patched version. The maintainers have backported the fix across all supported major version lines. Organizations should update their package configurations to require version 1.0.28, 2.0.53, or 3.0.51 as appropriate for their environment.

For projects utilizing Composer for dependency management, the update can be applied by modifying the composer.json file or executing the composer update phpseclib/phpseclib command. Verification of the installed version should be performed using composer show phpseclib/phpseclib.

No configuration changes are required to activate the fix. The patched library automatically utilizes hash_equals() or the safe XOR-sum fallback for all HMAC verifications. This ensures constant-time execution without any action required from the integrating application developer.

In environments where immediate patching is strictly impossible, no direct workarounds exist within the library's configuration. The vulnerability is embedded in the core packet parsing logic. However, given the lack of a viable remote exploitation path, the immediate operational risk is minimal.