GHSA-V8X7-R927-CC93

Vulnerability from github – Published: 2026-06-19 19:36 – Updated: 2026-06-19 19:36
VLAI
Summary
parse-server: Stored XSS via non-standard file extension bypassing file upload extension blocklist
Details

Impact

Parse Server's default fileUpload.fileExtensions blocklist is intended to prevent uploading files that browsers render as active content (such as HTML and SVG), which can be used to perform stored cross-site scripting (XSS) attacks against other users. The blocklist could be bypassed by uploading a file whose extension is not an exact match of a blocked extension (for example a non-standard or compound extension) together with a dangerous content type. On storage adapters that persist and serve the uploaded content type (such as S3 and GCS), the file is then served with the attacker-supplied content type, enabling stored XSS against users who open the file URL.

This affects the default configuration, in which authenticated users are allowed to upload files. The default GridFS/filesystem adapter sets the X-Content-Type-Options: nosniff response header, which mitigates browser rendering on that adapter, but the upload restriction itself is still bypassed. This is an incomplete-fix follow-up of GHSA-vr5f-2r24-w5hc and GHSA-7wqv-xjf3-x35v.

Patches

The file upload extension validation now also evaluates the request content type against the configured blocklist whenever the filename's extension is not a recognized type. As a result, a dangerous content type can no longer be preserved by uploading a file with a non-standard extension, and such uploads are rejected.

Workarounds

Configure fileUpload.fileExtensions as a strict allowlist of only the file extensions your application needs (for example ["^(png|jpe?g|gif|pdf)$"]) instead of relying on the default blocklist. Additionally, serve uploaded files from a separate domain than the application, so that any executed content is isolated from the application's origin.

Severity
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.9.1-alpha.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.6.80"
      },
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.81"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55778"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T19:36:36Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\n\nParse Server\u0027s default `fileUpload.fileExtensions` blocklist is intended to prevent uploading files that browsers render as active content (such as HTML and SVG), which can be used to perform stored cross-site scripting (XSS) attacks against other users. The blocklist could be bypassed by uploading a file whose extension is not an exact match of a blocked extension (for example a non-standard or compound extension) together with a dangerous content type. On storage adapters that persist and serve the uploaded content type (such as S3 and GCS), the file is then served with the attacker-supplied content type, enabling stored XSS against users who open the file URL.\n\nThis affects the default configuration, in which authenticated users are allowed to upload files. The default GridFS/filesystem adapter sets the `X-Content-Type-Options: nosniff` response header, which mitigates browser rendering on that adapter, but the upload restriction itself is still bypassed. This is an incomplete-fix follow-up of GHSA-vr5f-2r24-w5hc and GHSA-7wqv-xjf3-x35v.\n\n### Patches\n\nThe file upload extension validation now also evaluates the request content type against the configured blocklist whenever the filename\u0027s extension is not a recognized type. As a result, a dangerous content type can no longer be preserved by uploading a file with a non-standard extension, and such uploads are rejected.\n\n### Workarounds\n\nConfigure `fileUpload.fileExtensions` as a strict allowlist of only the file extensions your application needs (for example `[\"^(png|jpe?g|gif|pdf)$\"]`) instead of relying on the default blocklist. Additionally, serve uploaded files from a separate domain than the application, so that any executed content is isolated from the application\u0027s origin.",
  "id": "GHSA-v8x7-r927-cc93",
  "modified": "2026-06-19T19:36:36Z",
  "published": "2026-06-19T19:36:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-v8x7-r927-cc93"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10505"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/10506"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "parse-server: Stored XSS via non-standard file extension bypassing file upload extension blocklist"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.