Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe vulnerability (CVE-2026-84308) in phpseclib stems from a non-constant-time implementation of X25519 scalar multiplication. The core issue lies in the phpseclib3\Math\PrimeField\Integer::add and phpseclib3\Math\PrimeField\Integer::subtract methods. These methods, as described in the vulnerability details, performed data-dependent conditional modular reductions. Specifically, add() would conditionally subtract the modulo if the sum was greater than or equal to the modulo, and subtract() would conditionally add the modulo if the result was negative. These conditional branches introduce timing discrepancies that can be observed by an attacker, allowing for full private-key recovery through a side-channel attack. The phpseclib3\Crypt\EC\BaseCurves\Montgomery::multiplyPoint function is the higher-level operation that performs the scalar multiplication, and it internally relies on these arithmetic primitives. In the vulnerable versions, MontgomeryPrivate::load and PKCS8::loadECDH directly or indirectly invoked multiplyPoint without ensuring a constant-time execution path, especially when native cryptographic extensions like ext-sodium or OpenSSL were not available or explicitly forced. The patch addresses this by modifying Integer::add and Integer::subtract to use a newly introduced constant-time conditionalAddModulo function, which avoids data-dependent branches. Additionally, a new static method deriveMontgomeryPublicKey is introduced in Common.php and used by MontgomeryPrivate::load and PKCS8::loadECDH to properly gate calls to multiplyPoint, prioritizing native constant-time implementations (like libsodium or OpenSSL) over the pure-PHP implementation. Therefore, the add and subtract methods in Integer.php are directly vulnerable due to their non-constant-time implementation, and multiplyPoint in Montgomery.php is vulnerable as it orchestrates the non-constant-time operations when the pure-PHP path is taken.
phpseclib3\Math\PrimeField\Integer::addphpseclib/Math/PrimeField/Integer.php
phpseclib3\Math\PrimeField\Integer::subtractphpseclib/Math/PrimeField/Integer.php
phpseclib3\Crypt\EC\BaseCurves\Montgomery::multiplyPointphpseclib/Crypt/EC/BaseCurves/Montgomery.php
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| phpseclib/phpseclib | composer | < 3.0.57 | 3.0.57 |
| phpseclib/phpseclib | composer | >= 4.0.0, < 4.0.1 | 4.0.1 |
Operation counts in the ladder are already constant — 10 field multiplications, 4 additions and 4 subtractions per step, 2560 multiplications per 256-step ladder. Operand values are not. Each PrimeField\Integer::add() / subtract() takes a data-dependent branch costing ~0.85–1.0 µs on the GMP engine, against a ~32 µs step period, so per-step cost is α + β·c where c is that step's conditional-reduction count. Measured across 20 keys: R² = 0.91–0.98, β = 838–920 ns.
c depends on the whole scalar prefix, not on the current bit, so per-step thresholding is useless — it saturates at ~93% per bit for u = p−1 and at chance for u = 9, and recovers 0/20 keys either way, because the bit string is a prefix-XOR in which one flipped step inverts the entire tail. Conditioning on the prefix removes the ambiguity: a beam search replays both branches from each candidate ladder state, reads off the exact c for each, and scores against the observation. The victim's public key adjudicates the small residual search.
Two facts bound the problem and are worth stating precisely, because they determine whether a fix is needed at all:
T(k) has exact entropy H(T) = 4.0357 bits over clamped scalars, so a noiseless transition-count oracle still leaves ~2^247 candidates. The summed reduction count Σc is richer (~6.6–6.9 bits) and still leaves ~2^244. Any measurement that collapses the call to one number is safe. Per-step measurement is not.__gmpz_add = 4 + csub, __gmpz_sub = 4 + cadd, __gmpz_mul = __gmpz_mod = 10. Verified by differencing gdb breakpoint counts against phpseclib's own doubleAndAddPoint — 27/27 steps exact, extended independently to 64/64 and 38/38 by our two reviewers. An observer that only counts these calls needs no timing, no calibration and no repetition.Results, 20 keys × 3 sampling seeds, 800 traces per path collected from 800 distinct PHP processes (so the observations are cross-process, as real requests would be):
| observer | path | observations needed | exact 251-bit recovery |
|---|---|---|---|
| timing | key load, u = 9 | 32 | 20/20 keys, 95% CI [83.9%, 100%] |
| timing | ECDH, u = p−1 | 32 | 18/20 keys, 95% CI [69.9%, 96.8%] |
| timing | either | 8 | 18–23% of trials |
| libgmp call counts | either | 1 | 20/20 keys; tolerates 20–30% of per-step counts being wrong |
The model underlying the decoder is validated against the pinned implementation: 254/254 (key, peer) outputs match the real DH::computeSecret, and all four RFC 7748 §6.1 vectors match both phpseclib and the published constants.
Negative controls are clean — wrong public key, shuffled trace, wrong peer value, foreign key: 0/20 in every case. Nothing derived from the private key reaches the decoder; its inputs are the observation vector, the peer value, the victim's public key, and the public clamping constants.
In the instrumented, local model, recovery of the clamped scalar gives a permanent compromise of the X25519 private key. Clamping is applied on every call, so the recovered value is what every past and future operation with that key uses.
Required for exploitation:
EC::loadFormat('MontgomeryPrivate', $raw32) runs the ladder in every
configuration — but the format declares IS_INVISIBLE (MontgomeryPrivate.php:40),
so PublicKeyLoader::load skips it and nothing inside phpseclib calls it. An
application must name the format explicitly.PKCS8 / PublicKeyLoader::load / EC::createKey run the ladder only when ext-sodium is absent — PKCS8.php:194 gates on sodium_crypto_box_publickey_from_secretkey. OpenSSL does not help here.DH::computeSecret runs the ladder only under EC::forceEngine('PHP'), or when both openssl_pkey_derive (DH.php:325) and sodium_crypto_scalarmult (EC/PrivateKey.php:75) are unavailable. ext-sodium is bundled and enabled by default in PHP 7.2+, so the reachable configurations are a minority — though disable_functions hardening and --disable-sodium builds do occur, particularly in shared hosting.libgmp.so mapping — __gmpz_add / __gmpz_sub are the correct targets; __gmpn_* are not, being size-dispatched internals).Not demonstrated — stated so it is not found rather than disclosed:
hrtime() hook inside Montgomery::multiplyPoint (one file differs from the pinned tree; Math/PrimeField/Integer.php, which carries the leak, is byte-identical). This models an observer with intra-call resolution; it is not itself an attacker capability. We note that the requisite primitives are present on ordinary hardware — on our test host clflush and rdtscp work, with 187–312 cycle cached/flushed separation — but building and validating a spy is separate work we have not done.Accordingly we report this as a hardening issue and demonstrated side channel, not as a completed remote exploit.
Integer.php:189 and :207 remain operand-dependent.MontgomeryPrivate.php:66 the way PKCS8.php:194–200 already is. That is a one-block change and it closes the only entry point that is un-gated in every configuration. Keep the $curve instanceof Curve25519 guard — MontgomeryPrivate also accepts Curve448 keys.PKCS8::loadECDH, or fail closed, so stacks without ext-sodium do not fall through to the ladder.u = 9.George Stergiopoulos Assistant Professor of cybersecurity Athens University of Economics and Business, Greece E: geostergiop@aueb.gr | s: https://www.aueb.gr/en/faculty_page/stergiopoulos-georgios