GHSA-95WR-3F2V-V2WH

Vulnerability from github – Published: 2026-04-14 23:36 – Updated: 2026-04-14 23:36
VLAI?
Summary
Craft CMS has a host header injection leading to SSRF via resource-js endpoint
Details

Summary

The resource-js endpoint in Craft CMS allows unauthenticated requests to proxy remote JavaScript resources. When trustedHosts is not explicitly restricted (default configuration), the application trusts the client-supplied Host header.

This allows an attacker to control the derived baseUrl, which is used in prefix validation inside actionResourceJs(). By supplying a malicious Host header, the attacker can make the server issue arbitrary HTTP requests, leading to Server-Side Request Forgery (SSRF).

Details

The vulnerability exists in AppController::actionResourceJs().

The function validates that the url parameter starts with assetManager->baseUrl. However, baseUrl is derived from the current request host. If trustedHosts is not configured, the Host header is fully attacker-controlled.

Attack chain:

  1. Attacker sends request with controlled Host header.
  2. Application derives baseUrl from the malicious Host.
  3. url parameter is required to start with this baseUrl.
  4. Validation passes.
  5. Guzzle performs a server-side HTTP request to the attacker-controlled host.
  6. SSRF occurs.

This does not rely on string parsing bypass. It relies on Host header trust.

PoC (safe reproduction steps)

Environment: - Craft CMS 5.9.12 - Default configuration (no trustedHosts restriction) - Docker deployment

  1. Start a listener inside the container: python3 -m http.server 9999

  2. Send a request to resource-js with a controlled Host header.

  3. Observe that the internal listener receives a request (OOB confirmation).

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.9.14"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.9.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.17.8"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-RC1"
            },
            {
              "fixed": "4.17.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:36:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `resource-js` endpoint in Craft CMS allows unauthenticated requests to proxy remote JavaScript resources. \nWhen `trustedHosts` is not explicitly restricted (default configuration), the application trusts the client-supplied Host header. \n\nThis allows an attacker to control the derived `baseUrl`, which is used in prefix validation inside `actionResourceJs()`. \nBy supplying a malicious Host header, the attacker can make the server issue arbitrary HTTP requests, leading to Server-Side Request Forgery (SSRF).\n\n### Details\n\nThe vulnerability exists in `AppController::actionResourceJs()`.\n\nThe function validates that the `url` parameter starts with `assetManager-\u003ebaseUrl`. However, `baseUrl` is derived from the current request host. If `trustedHosts` is not configured, the Host header is fully attacker-controlled.\n\nAttack chain:\n\n1. Attacker sends request with controlled `Host` header.\n2. Application derives `baseUrl` from the malicious Host.\n3. `url` parameter is required to start with this `baseUrl`.\n4. Validation passes.\n5. Guzzle performs a server-side HTTP request to the attacker-controlled host.\n6. SSRF occurs.\n\nThis does not rely on string parsing bypass. It relies on Host header trust.\n\n### PoC (safe reproduction steps)\n\nEnvironment:\n- Craft CMS 5.9.12\n- Default configuration (no trustedHosts restriction)\n- Docker deployment\n\n1. Start a listener inside the container:\n   python3 -m http.server 9999\n\n2. Send a request to resource-js with a controlled Host header.\n\n3. Observe that the internal listener receives a request (OOB confirmation).",
  "id": "GHSA-95wr-3f2v-v2wh",
  "modified": "2026-04-14T23:36:10Z",
  "published": "2026-04-14T23:36:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-95wr-3f2v-v2wh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/commit/ebe7e85f1c89700d64332f72492be2e9a594e783"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/craftcms/cms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Craft CMS has a host header injection leading to SSRF via resource-js endpoint"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…