CVE-2026-55599

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.

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.

Summary

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. It is reproducible on current released LTS 3.0.53 and on 4.0 development line.

Details

When no already-trusted certificate authority is the issuer of certificate under validation, validateSignatureCountable() continues to AIA fetching. Default for validateSignature() is caonly = true:

// phpseclib/File/X509.php:1316-1327 (4.0 development line, commit 74ada1a6)
if (!isset($signingCert)) {
    if ($caonly) {
        return $this->testForIntermediate(true, $count) && $this->validateSignature(true);
    } else {
        try {
            $this->testForSelfSigned();
            $signingCert = $this;
        } catch (BadMethodCallException) {
            return $this->testForIntermediate(true, $count) && $this->validateSignature(true);
        }
    }
}

testForIntermediate() takes URL straight out of certificate's AIA caIssuers field and fetches it. Value comes directly from certificate content and is never restricted:

// phpseclib/File/X509.php:1357-1391 (4.0 development line)
$opts = $this->getExtension('id-pe-authorityInfoAccess');
...
foreach ($opts['extnValue'] as $opt) {
    if ($opt['accessMethod'] == 'id-ad-caIssuers') {
        if (isset($opt['accessLocation']['uniformResourceIdentifier'])) {
            $url = (string) $opt['accessLocation']['uniformResourceIdentifier']; // attacker controlled
            break;
        }
    }
}
...
$cert = static::fetchURL($url); // server-side request forgery

fetchURL() connects to attacker host and port. There is no destination validation: no block on loopback, link-local, private, or metadata ranges, and no port restriction:

// phpseclib/File/X509.php:1456-1476 (4.0 development line)
private static function fetchURL(string $url): ?string
{
    if (self::$disable_url_fetch) {  // default false, so fetching happens
        return null;
    }
    $parts = parse_url($url);
    switch ($parts['scheme']) {
        case 'http':
            $fsock = @fsockopen($parts['host'], $parts['port'] ?? 80); // attacker host and port
            ...
            fputs($fsock, "GET $path HTTP/1.0\r\n");
            fputs($fsock, "Host: $parts[host]\r\n\r\n");

Fetching is on by default:

// phpseclib/File/X509.php:110 (4.0 development line)
private static bool $disable_url_fetch = false;

Same default-enabled logic exists in released 3.0.x. In 3.0.53 it sits at $disable_url_fetch = false on line 255 and fsockopen($parts['host'], ...) on line 1136 of phpseclib/File/X509.php.

Why this is a vulnerability and not merely a feature. AIA chasing is a legitimate capability described by RFC 4325, and this report does not claim fetching is wrong in itself. Vulnerability is the combination of three properties that together match definition of SSRF:

1. URL comes from untrusted input. It is read out of certificate that an application is trying to validate, which is exactly the data an attacker controls.
2. Fetching is enabled by default. An integrator who simply calls validateSignature() gets outbound requests with no opt-in. Only control, X509::disableURLFetch(), is off by default, so secure behaviour requires knowing about and calling a method that most callers never see.
3. No destination is restricted. Loopback, private ranges, link-local…

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.

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.

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.

Summary

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. It is reproducible on current released LTS 3.0.53 and on 4.0 development line.

Details

When no already-trusted certificate authority is the issuer of certificate under validation, validateSignatureCountable() continues to AIA fetching. Default for validateSignature() is caonly = true:

// phpseclib/File/X509.php:1316-1327 (4.0 development line, commit 74ada1a6)
if (!isset($signingCert)) {
    if ($caonly) {
        return $this->testForIntermediate(true, $count) && $this->validateSignature(true);
    } else {
        try {
            $this->testForSelfSigned();
            $signingCert = $this;
        } catch (BadMethodCallException) {
            return $this->testForIntermediate(true, $count) && $this->validateSignature(true);
        }
    }
}

testForIntermediate() takes URL straight out of certificate's AIA caIssuers field and fetches it. Value comes directly from certificate content and is never restricted:

// phpseclib/File/X509.php:1357-1391 (4.0 development line)
$opts = $this->getExtension('id-pe-authorityInfoAccess');
...
foreach ($opts['extnValue'] as $opt) {
    if ($opt['accessMethod'] == 'id-ad-caIssuers') {
        if (isset($opt['accessLocation']['uniformResourceIdentifier'])) {
            $url = (string) $opt['accessLocation']['uniformResourceIdentifier']; // attacker controlled
            break;
        }
    }
}
...
$cert = static::fetchURL($url); // server-side request forgery

fetchURL() connects to attacker host and port. There is no destination validation: no block on loopback, link-local, private, or metadata ranges, and no port restriction:

// phpseclib/File/X509.php:1456-1476 (4.0 development line)
private static function fetchURL(string $url): ?string
{
    if (self::$disable_url_fetch) {  // default false, so fetching happens
        return null;
    }
    $parts = parse_url($url);
    switch ($parts['scheme']) {
        case 'http':
            $fsock = @fsockopen($parts['host'], $parts['port'] ?? 80); // attacker host and port
            ...
            fputs($fsock, "GET $path HTTP/1.0\r\n");
            fputs($fsock, "Host: $parts[host]\r\n\r\n");

Fetching is on by default:

// phpseclib/File/X509.php:110 (4.0 development line)
private static bool $disable_url_fetch = false;

Same default-enabled logic exists in released 3.0.x. In 3.0.53 it sits at $disable_url_fetch = false on line 255 and fsockopen($parts['host'], ...) on line 1136 of phpseclib/File/X509.php.

Why this is a vulnerability and not merely a feature. AIA chasing is a legitimate capability described by RFC 4325, and this report does not claim fetching is wrong in itself. Vulnerability is the combination of three properties that together match definition of SSRF:

1. URL comes from untrusted input. It is read out of certificate that an application is trying to validate, which is exactly the data an attacker controls.
2. Fetching is enabled by default. An integrator who simply calls validateSignature() gets outbound requests with no opt-in. Only control, X509::disableURLFetch(), is off by default, so secure behaviour requires knowing about and calling a method that most callers never see.
3. No destination is restricted. Loopback, private ranges, link-local…

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.