There are 2 open security issues in trixie.
1 important issue:
- CVE-2026-84308:
phpseclib is a PHP secure communications library. Prior to 3.0.57 and 4.0.1, pure-PHP X25519 scalar multiplication in phpseclib/Math/PrimeField/Integer.php performs data-dependent conditional modular reductions in add() and subtract(). During the Montgomery ladder in phpseclib/Crypt/EC/BaseCurves/Montgomery.php, the reduction behavior of each step depends on the secret scalar prefix, creating per-step timing and libgmp call-count observations that can reveal a reused 251-bit clamped private scalar. The phpseclib/Crypt/EC/Formats/Keys/MontgomeryPrivate.php derivation path invokes the pure-PHP multiplication without a native-engine check, while phpseclib/Crypt/EC/Formats/Keys/PKCS8.php reaches it when ext-sodium is unavailable. Exploitation requires a reused or long-lived X25519 private key, knowledge of the corresponding public key, execution of the pure-PHP path, and a local observer capable of resolving individual ladder steps or libgmp entry-point calls. Ephemeral X25519 keys, including phpseclib's normal SSH exchange path, are not affected. Recovery of the scalar permanently compromises operations that reuse that key. This issue is fixed in versions 3.0.57 and 4.0.1.
1 issue left for the package maintainer to handle:
- CVE-2026-55599:
(needs triaging)
phpseclib is a PHP secure communications library. From 0.1.1 until 1.0.30, 2.0.55, and 3.0.54, when an application validates an untrusted X.509 certificate with phpseclib, X509::validateSignature() reads a URL out of that certificate's Authority Information Access (AIA) extension and connects to it. Attacker who supplies certificate fully controls host, port, and path of that connection. URL fetching is enabled by default, and no destination is blocked. An unauthenticated attacker can therefore make a validating server open connections to internal hosts and ports it should never reach, for example loopback 127.0.0.1, cloud metadata address 169.254.169.254, and internal-only services. This is a server-side request forgery (SSRF) caused by an insecure default. This vulnerability is fixed in 1.0.30, 2.0.55, and 3.0.54.
You can find information about how to handle this issue in the security team's documentation.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/p/php-phpseclib3.png){kind=link}