Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

6020 vulnerabilities reference this CWE, most recent first.

GHSA-94H9-Q657-456H

Vulnerability from github – Published: 2026-08-05 18:31 – Updated: 2026-08-05 18:31
VLAI
Details

IBM Langflow OSS 1.0.0 through 1.10.3 Langflow could allow server-side request forgery (SSRF) due to incomplete and ineffective SSRF protection enforcement.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-7657"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T18:17:15Z",
    "severity": "MODERATE"
  },
  "details": "IBM Langflow OSS 1.0.0 through 1.10.3 Langflow could allow server-side request forgery (SSRF) due to incomplete and ineffective SSRF protection enforcement.",
  "id": "GHSA-94h9-q657-456h",
  "modified": "2026-08-05T18:31:43Z",
  "published": "2026-08-05T18:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7657"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7282650"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-94HW-32GV-86PF

Vulnerability from github – Published: 2024-11-04 15:31 – Updated: 2024-11-04 15:31
VLAI
Details

AppSmith Community 1.8.3 before 1.46 allows SSRF via New DataSource for application/json requests to 169.254.169.254 to retrieve AWS metadata credentials.

Severity
8.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-51408"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-04T14:15:16Z",
    "severity": "HIGH"
  },
  "details": "AppSmith Community 1.8.3 before 1.46 allows SSRF via New DataSource for application/json requests to 169.254.169.254 to retrieve AWS metadata credentials.",
  "id": "GHSA-94hw-32gv-86pf",
  "modified": "2024-11-04T15:31:58Z",
  "published": "2024-11-04T15:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51408"
    },
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/pull/29286"
    },
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/releases/tag/v1.46"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jahithoque/Vulnerability-Research/tree/main/CVE-2024-51408"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-953P-CW63-FHM7

Vulnerability from github – Published: 2022-12-22 00:30 – Updated: 2022-12-28 21:30
VLAI
Details

Dataprobe iBoot-PDU FW versions prior to 1.42.06162022 contain a vulnerability where a specially crafted PHP script could use parameters from a HTTP request to create a URL capable of changing the host parameter. The changed host parameter in the HTTP could point to another host that will send a request to the host or IP specified in the changed host parameter.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-3189"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-21T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dataprobe iBoot-PDU FW versions prior to 1.42.06162022 contain a vulnerability where a specially crafted PHP script could use parameters from a HTTP request to create a URL capable of changing the host parameter. The changed host parameter in the HTTP could point to another host that will send a request to the host or IP specified in the changed host parameter.",
  "id": "GHSA-953p-cw63-fhm7",
  "modified": "2022-12-28T21:30:23Z",
  "published": "2022-12-22T00:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3189"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-263-03"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-954P-556P-R752

Vulnerability from github – Published: 2026-07-28 21:42 – Updated: 2026-07-28 21:42
VLAI
Summary
datamodel-code-generator vulnerable to SSRF via JSON-Schema `$ref` to HTTP URL (silent by default)
Details

Summary

JSON-Schema $ref values pointing at HTTP or HTTPS URLs are silently dereferenced by datamodel-code-generator with no IP/host validation, no scheme allow-list, and redirects followed unconditionally. The --allow-remote-refs gate added in 0.56.0 defaults to None, which only emits a deprecation warning and then fetches the URL anyway; only explicit --allow-remote-refs=false blocks the request. The fetched body is parsed as a sub-schema and reflected verbatim into the generated .py source. As a result, any JSON-Schema document the developer feeds to datamodel-codegen — including documents authored by an attacker — can pivot to arbitrary internal addresses and leak the response into the generated code, with no developer cooperation beyond running the tool.

Details

Sink: src/datamodel_code_generator/parser/jsonschema.py, _get_ref_body (lines 4776–4793, at tag 0.60.1 / commit a321547e):

def _get_ref_body(self, resolved_ref: str) -> dict[str, YamlValue]:
    if is_url(resolved_ref):
        if not resolved_ref.startswith("file://") and self.http_local_ref_path is None:
            if self.allow_remote_refs is False:
                raise Error(f"Fetching remote $ref is disabled: {resolved_ref}...")
            if self.allow_remote_refs is None:
                warn_deprecated(                            # (A) warn only
                    "behavior.remote-ref-default",
                    details=f"Reference: {resolved_ref}",
                    stacklevel=2,
                )
        return self._get_ref_body_from_url(resolved_ref)    # (B) fetch fires
    return self._get_ref_body_from_remote(resolved_ref)
  • (A) emits a deprecation warning when allow_remote_refs is its default (None); execution falls through to (B).
  • (B) routes the URL through _get_text_from_url → get_body, the same fetcher described in other report — no IP validation, redirects followed.

The fetched body is then parsed as a sub-schema and merged into the model graph, so description, title, properties, etc. from the remote document end up in the generated .py source.

Only affects users who installed the [http] extra (pip install 'datamodel-code-generator[http]').

PoC

A self-contained one-file PoC is available here: https://gist.github.com/thegr1ffyn/562a6972d7dc3f2869458ae93fc608c0

Impact

Who is impacted. Anyone running datamodel-codegen on a JSON-Schema or OpenAPI document of uncertain provenance, with the [http] extra installed. Real-world scenarios:

  1. Trojaned OpenAPI document. A public REST API publishes openapi.yaml. One $ref points at http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>; running datamodel-codegen against the spec from an EC2 instance leaks the IAM credentials into the generated client.
  2. Customer-supplied JSON Schema. A B2B SaaS auto-generates client code from customer-uploaded schemas. The customer adds an HTTP $ref to http://internal-admin:8080/users.json; the response (e.g. JSON user list) ends up in the generated Python the SaaS hands back to the customer.
  3. CI on a private network. A PR adds schemas/inbound.json with an HTTP $ref pointed at a service reachable only from the CI cluster's VPC; the CI runner fetches it and the generated .py leaks the response in PR artifacts.

Higher real-world risk than the sibling CLI-flag SSRF (other SSRF in this report bundle) because the schema author chooses the destination — the developer doesn't have to type any URL.

Suggested fix.

  1. Flip the default in parser/base.py: allow_remote_refs: bool = False, and remove the silent-fetch-with-warning fallback at parser/jsonschema.py:4786-4791.
  2. When fetching is allowed, apply the same IP/host validation proposed for other submitted SSRF report to both the initial $ref URL and every redirect target.
  3. Document HTTP $ref in a third-party schema as equivalent to running curl on the developer's host.

Maintainer resolution

This $ref report is fixed by the same shared HTTP fetcher hardening that resolved GHSA-rfr2-mq9m-x2qx. The code landed through the GHSA-rfr2 private security PR koxudaxi/datamodel-code-generator-ghsa-rfr2-mq9m-x2qx#1 and was merged into the public repository as 5fdba4a09f2d7a9996a504975b7ef7d63e3715bb. Follow-up generated-file and coverage fixes were merged in koxudaxi/datamodel-code-generator#3279 and docs were synced in #3280. The patched release is 0.61.0.

No separate net code diff remains in the GHSA-954 private PR because the shared HTTP fetcher patch is already present on main. This advisory remains separate because the affected entry point is remote JSON Schema/OpenAPI $ref resolution rather than direct CLI --url input.

The fix does not flip the --allow-remote-refs compatibility default in this patch. Instead, it mitigates the SSRF issue by blocking localhost, loopback, private, link-local, reserved, and other non-public network targets by default, validating every redirect target before it is fetched, and requiring --allow-private-network / allow_private_network=True for trusted internal schema endpoints. Remote $ref fetching remains controlled by --allow-remote-refs; non-public/internal targets additionally require --allow-private-network.

Submitted by: Hamza Haroon (thegr1ffyn)

Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.60.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "datamodel-code-generator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.1"
            },
            {
              "fixed": "0.61.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T21:42:22Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nJSON-Schema `$ref` values pointing at HTTP or HTTPS URLs are silently dereferenced by `datamodel-code-generator` with no IP/host validation, no scheme allow-list, and redirects followed unconditionally. The `--allow-remote-refs` gate added in 0.56.0 defaults to `None`, which only emits a deprecation warning and then fetches the URL anyway; only explicit `--allow-remote-refs=false` blocks the request. The fetched body is parsed as a sub-schema and reflected verbatim into the generated `.py` source. As a result, any JSON-Schema document the developer feeds to `datamodel-codegen` \u2014 including documents authored by an attacker \u2014 can pivot to arbitrary internal addresses and leak the response into the generated code, with no developer cooperation beyond running the tool.\n\n### Details\n\nSink: `src/datamodel_code_generator/parser/jsonschema.py`, `_get_ref_body` (lines 4776\u20134793, at tag `0.60.1` / commit `a321547e`):\n\n```python\ndef _get_ref_body(self, resolved_ref: str) -\u003e dict[str, YamlValue]:\n    if is_url(resolved_ref):\n        if not resolved_ref.startswith(\"file://\") and self.http_local_ref_path is None:\n            if self.allow_remote_refs is False:\n                raise Error(f\"Fetching remote $ref is disabled: {resolved_ref}...\")\n            if self.allow_remote_refs is None:\n                warn_deprecated(                            # (A) warn only\n                    \"behavior.remote-ref-default\",\n                    details=f\"Reference: {resolved_ref}\",\n                    stacklevel=2,\n                )\n        return self._get_ref_body_from_url(resolved_ref)    # (B) fetch fires\n    return self._get_ref_body_from_remote(resolved_ref)\n```\n\n- (A) emits a deprecation warning when `allow_remote_refs` is its default (`None`); execution falls through to (B).\n- (B) routes the URL through `_get_text_from_url` \u2192 `get_body`, the same fetcher described in other report \u2014 no IP validation, redirects followed.\n\nThe fetched body is then parsed as a sub-schema and merged into the model graph, so `description`, `title`, `properties`, etc. from the remote document end up in the generated `.py` source.\n\nOnly affects users who installed the `[http]` extra (`pip install \u0027datamodel-code-generator[http]\u0027`).\n\n### PoC\n\nA self-contained one-file PoC is available here: https://gist.github.com/thegr1ffyn/562a6972d7dc3f2869458ae93fc608c0\n\n### Impact\n\n**Who is impacted.** Anyone running `datamodel-codegen` on a JSON-Schema or OpenAPI document of uncertain provenance, with the `[http]` extra installed. Real-world scenarios:\n\n1. **Trojaned OpenAPI document.** A public REST API publishes `openapi.yaml`. One `$ref` points at `http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole\u003e`; running `datamodel-codegen` against the spec from an EC2 instance leaks the IAM credentials into the generated client.\n2. **Customer-supplied JSON Schema.** A B2B SaaS auto-generates client code from customer-uploaded schemas. The customer adds an HTTP `$ref` to `http://internal-admin:8080/users.json`; the response (e.g. JSON user list) ends up in the generated Python the SaaS hands back to the customer.\n3. **CI on a private network.** A PR adds `schemas/inbound.json` with an HTTP `$ref` pointed at a service reachable only from the CI cluster\u0027s VPC; the CI runner fetches it and the generated `.py` leaks the response in PR artifacts.\n\nHigher real-world risk than the sibling CLI-flag SSRF (other SSRF in this report bundle) because the *schema author* chooses the destination \u2014 the developer doesn\u0027t have to type any URL.\n\n**Suggested fix.**\n\n1. Flip the default in `parser/base.py`: `allow_remote_refs: bool = False`, and remove the silent-fetch-with-warning fallback at `parser/jsonschema.py:4786-4791`.\n2. When fetching is allowed, apply the same IP/host validation proposed for other submitted SSRF report to both the initial `$ref` URL and every redirect target.\n3. Document HTTP `$ref` in a third-party schema as equivalent to running `curl` on the developer\u0027s host.\n\n### Maintainer resolution\n\nThis `$ref` report is fixed by the same shared HTTP fetcher hardening that resolved GHSA-rfr2-mq9m-x2qx. The code landed through the GHSA-rfr2 private security PR koxudaxi/datamodel-code-generator-ghsa-rfr2-mq9m-x2qx#1 and was merged into the public repository as 5fdba4a09f2d7a9996a504975b7ef7d63e3715bb. Follow-up generated-file and coverage fixes were merged in koxudaxi/datamodel-code-generator#3279 and docs were synced in #3280. The patched release is 0.61.0.\n\nNo separate net code diff remains in the GHSA-954 private PR because the shared HTTP fetcher patch is already present on `main`. This advisory remains separate because the affected entry point is remote JSON Schema/OpenAPI `$ref` resolution rather than direct CLI `--url` input.\n\nThe fix does not flip the `--allow-remote-refs` compatibility default in this patch. Instead, it mitigates the SSRF issue by blocking localhost, loopback, private, link-local, reserved, and other non-public network targets by default, validating every redirect target before it is fetched, and requiring `--allow-private-network` / `allow_private_network=True` for trusted internal schema endpoints. Remote `$ref` fetching remains controlled by `--allow-remote-refs`; non-public/internal targets additionally require `--allow-private-network`.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
  "id": "GHSA-954p-556p-r752",
  "modified": "2026-07-28T21:42:22Z",
  "published": "2026-07-28T21:42:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/security/advisories/GHSA-954p-556p-r752"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/commit/5fdba4a09f2d7a9996a504975b7ef7d63e3715bb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koxudaxi/datamodel-code-generator"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/releases/tag/0.61.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "datamodel-code-generator vulnerable to SSRF via JSON-Schema `$ref` to HTTP URL (silent by default)"
}

GHSA-9592-7844-9GM7

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

IBM Jazz Foundation and IBM Engineering products are vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-ForceID: 194597.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-20348"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-02T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Jazz Foundation and IBM Engineering products are vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-ForceID: 194597.",
  "id": "GHSA-9592-7844-9gm7",
  "modified": "2022-05-24T19:03:49Z",
  "published": "2022-05-24T19:03:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20348"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/194597"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6457739"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-95C3-6VVW-4MRQ

Vulnerability from github – Published: 2026-05-08 17:06 – Updated: 2026-05-15 23:47
VLAI
Summary
MCP Registry's GitHub OIDC tokens are replayable across registry deployments due to shared audience
Details

[SECURITY] registry_001 Vulnerability Report

While analyzing the code logic, an area that may lead to unintended behavior under specific conditions was discovered.

Overview

  • Verified Version: c5c4b9e8890dd5754bee889b2f1417f4fe3b5ce5
  • Vulnerability Type: Authentication bypass via cross-registry OIDC token replay
  • Affected Location: cmd/publisher/commands/login.go:67-105,130-135,199-224; cmd/publisher/auth/github-oidc.go:24-38,58-75,108-165; internal/api/handlers/v0/auth/github_oidc.go:75-135,229-277,280-296
  • Trigger Scenario: a workflow invokes mcp-publisher login github-oidc --registry <other-registry> (or equivalent publish flow) and the publisher still requests a GitHub Actions ID token with the shared audience mcp-registry; any other registry deployment running this code can replay that token to its own /v0/auth/github-oidc endpoint and mint a publish-capable registry JWT for the same GitHub owner namespace.

Root Cause

The client-side and server-side GitHub OIDC flow is bound only to a global audience string, not to the specific registry instance being targeted. On the client side, the publisher always appends audience=mcp-registry when requesting the GitHub Actions ID token, regardless of the selected --registry URL. On the server side, the exchange endpoint validates only that same fixed audience and then derives publish permissions directly from repository_owner. As a result, a token legitimately obtained while interacting with one registry deployment remains acceptable to any other deployment that shares the same code and audience string.

Source-to-Sink Chain

  1. Source cmd/publisher/commands/login.go:67-105,130-135,199-224 parses the user-controlled --registry flag into flags.RegistryURL, creates a GitHubOIDCProvider, and calls authProvider.GetToken(ctx) for the chosen authentication method.
  2. Propagation cmd/publisher/auth/github-oidc.go:24-38 obtains an OIDC token and immediately exchanges it against the selected registry URL. cmd/publisher/auth/github-oidc.go:58-75 builds exchangeURL := o.registryURL + "/v0/auth/github-oidc" and posts the GitHub token to whichever registry instance was selected. cmd/publisher/auth/github-oidc.go:108-165 constructs fullURL := requestURL + "&audience=mcp-registry" and therefore requests the same audience for every registry deployment.
  3. Sink internal/api/handlers/v0/auth/github_oidc.go:75-135 validates only the shared audience value passed into ValidateToken. internal/api/handlers/v0/auth/github_oidc.go:254-277 calls h.validator.ValidateToken(ctx, oidcToken, "mcp-registry") and, on success, signs a new registry JWT. internal/api/handlers/v0/auth/github_oidc.go:280-296 converts claims.RepositoryOwner into the publish permission pattern io.github.<owner>/*, which is then embedded into the new registry JWT.

Exploitation Preconditions

  1. The victim uses the GitHub Actions OIDC publishing path.
  2. The victim workflow targets another registry deployment first, such as staging, self-hosted infrastructure, or an attacker-controlled registry URL.
  3. The receiving registry deployment can observe the posted OIDC token and replay it before expiry to another registry deployment running the same shared audience configuration.

Risk

This breaks deployment isolation between registry instances. A token issued for one registry interaction can be replayed across trust boundaries, allowing one deployment to impersonate the same GitHub owner identity on another deployment.

Impact

An attacker-controlled or compromised registry deployment can mint a valid registry JWT on another deployment and inherit publish permissions for the victim GitHub owner namespace. In practical terms, this enables unauthorized publication or update actions for names such as io.github.<owner>/* on the victim registry instance.

Remediation

  1. Replace the shared audience string with a registry-specific audience, such as a deployment-specific client ID or origin-derived identifier.
  2. Ensure the publisher requests the audience that matches the exact registry instance it is targeting, and ensure the server validates that same instance-specific value.
  3. Consider binding the exchange to additional deployment-specific claims so that a token captured by one registry cannot be replayed on another.
  4. Add regression tests that cover cross-deployment replay attempts between different registry URLs.
Severity
4.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/modelcontextprotocol/registry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44428"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T17:06:22Z",
    "nvd_published_at": "2026-05-14T22:16:44Z",
    "severity": "LOW"
  },
  "details": "# [SECURITY] registry_001 Vulnerability Report\n\nWhile analyzing the code logic, an area that may lead to unintended behavior under specific conditions was discovered. \n\n## Overview\n- Verified Version: `c5c4b9e8890dd5754bee889b2f1417f4fe3b5ce5`\n- Vulnerability Type: Authentication bypass via cross-registry OIDC token replay\n- Affected Location: `cmd/publisher/commands/login.go:67-105,130-135,199-224`; `cmd/publisher/auth/github-oidc.go:24-38,58-75,108-165`; `internal/api/handlers/v0/auth/github_oidc.go:75-135,229-277,280-296`\n- Trigger Scenario: a workflow invokes `mcp-publisher login github-oidc --registry \u003cother-registry\u003e` (or equivalent publish flow) and the publisher still requests a GitHub Actions ID token with the shared audience `mcp-registry`; any other registry deployment running this code can replay that token to its own `/v0/auth/github-oidc` endpoint and mint a publish-capable registry JWT for the same GitHub owner namespace.\n\n## Root Cause\nThe client-side and server-side GitHub OIDC flow is bound only to a global audience string, not to the specific registry instance being targeted. On the client side, the publisher always appends `audience=mcp-registry` when requesting the GitHub Actions ID token, regardless of the selected `--registry` URL. On the server side, the exchange endpoint validates only that same fixed audience and then derives publish permissions directly from `repository_owner`. As a result, a token legitimately obtained while interacting with one registry deployment remains acceptable to any other deployment that shares the same code and audience string.\n\n## Source-to-Sink Chain\n1. Source\n   `cmd/publisher/commands/login.go:67-105,130-135,199-224` parses the user-controlled `--registry` flag into `flags.RegistryURL`, creates a `GitHubOIDCProvider`, and calls `authProvider.GetToken(ctx)` for the chosen authentication method.\n2. Propagation\n   `cmd/publisher/auth/github-oidc.go:24-38` obtains an OIDC token and immediately exchanges it against the selected registry URL.\n   `cmd/publisher/auth/github-oidc.go:58-75` builds `exchangeURL := o.registryURL + \"/v0/auth/github-oidc\"` and posts the GitHub token to whichever registry instance was selected.\n   `cmd/publisher/auth/github-oidc.go:108-165` constructs `fullURL := requestURL + \"\u0026audience=mcp-registry\"` and therefore requests the same audience for every registry deployment.\n3. Sink\n   `internal/api/handlers/v0/auth/github_oidc.go:75-135` validates only the shared audience value passed into `ValidateToken`.\n   `internal/api/handlers/v0/auth/github_oidc.go:254-277` calls `h.validator.ValidateToken(ctx, oidcToken, \"mcp-registry\")` and, on success, signs a new registry JWT.\n   `internal/api/handlers/v0/auth/github_oidc.go:280-296` converts `claims.RepositoryOwner` into the publish permission pattern `io.github.\u003cowner\u003e/*`, which is then embedded into the new registry JWT.\n\n## Exploitation Preconditions\n1. The victim uses the GitHub Actions OIDC publishing path.\n2. The victim workflow targets another registry deployment first, such as staging, self-hosted infrastructure, or an attacker-controlled registry URL.\n3. The receiving registry deployment can observe the posted OIDC token and replay it before expiry to another registry deployment running the same shared audience configuration.\n\n## Risk\nThis breaks deployment isolation between registry instances. A token issued for one registry interaction can be replayed across trust boundaries, allowing one deployment to impersonate the same GitHub owner identity on another deployment.\n\n## Impact\nAn attacker-controlled or compromised registry deployment can mint a valid registry JWT on another deployment and inherit publish permissions for the victim GitHub owner namespace. In practical terms, this enables unauthorized publication or update actions for names such as `io.github.\u003cowner\u003e/*` on the victim registry instance.\n\n## Remediation\n1. Replace the shared audience string with a registry-specific audience, such as a deployment-specific client ID or origin-derived identifier.\n2. Ensure the publisher requests the audience that matches the exact registry instance it is targeting, and ensure the server validates that same instance-specific value.\n3. Consider binding the exchange to additional deployment-specific claims so that a token captured by one registry cannot be replayed on another.\n4. Add regression tests that cover cross-deployment replay attempts between different registry URLs.",
  "id": "GHSA-95c3-6vvw-4mrq",
  "modified": "2026-05-15T23:47:13Z",
  "published": "2026-05-08T17:06:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/security/advisories/GHSA-95c3-6vvw-4mrq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44428"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/pull/1229"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/commit/3f89fc2b1fb34fd49f3c0e1b39e964a5c67b613f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/registry"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCP Registry\u0027s GitHub OIDC tokens are replayable across registry deployments due to shared audience"
}

GHSA-95CP-92VM-RCPC

Vulnerability from github – Published: 2026-07-14 06:31 – Updated: 2026-07-14 06:31
VLAI
Details

A vulnerability has been found in louisho5 picobot up to 0.2.0. This vulnerability affects the function WebTool.Execute of the file internal/agent/tools/web.go of the component web Tool. The manipulation of the argument url leads to server-side request forgery. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-15668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T05:16:18Z",
    "severity": "LOW"
  },
  "details": "A vulnerability has been found in louisho5 picobot up to 0.2.0. This vulnerability affects the function WebTool.Execute of the file internal/agent/tools/web.go of the component web Tool. The manipulation of the argument url leads to server-side request forgery. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-95cp-92vm-rcpc",
  "modified": "2026-07-14T06:31:22Z",
  "published": "2026-07-14T06:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15668"
    },
    {
      "type": "WEB",
      "url": "https://github.com/louisho5/picobot/issues/41"
    },
    {
      "type": "WEB",
      "url": "https://github.com/louisho5/picobot"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-15668"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/855866"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/378162"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/378162/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-95PX-34X5-P37H

Vulnerability from github – Published: 2026-08-18 18:01 – Updated: 2026-08-18 18:01
VLAI
Summary
MobSF has SSRF port restriction bypass in assetlinks_check
Details

Summary

MobSF's Android App Link assetlinks checker validates only the manifest android:host value with valid_host(), but then appends the separate android:port value into the URL used for the server-side request. This bypasses the current port restriction in valid_host() and lets a crafted APK cause MobSF to fetch http://host:<attacker-port>/.well-known/assetlinks.json or https://host:<attacker-port>/.well-known/assetlinks.json.

Impact

An authenticated user who can upload or trigger analysis of a crafted APK can cause the MobSF server to make an outbound request to an attacker-selected port during Android manifest analysis. When the host is controlled by the attacker and uses DNS rebinding, the validation lookup can resolve to a public IP while the later HTTP client lookup resolves to an internal address, allowing SSRF to internal services on non-80/443 ports.

This is not arbitrary URL SSRF. The path remains fixed to /.well-known/assetlinks.json, and redirects are disabled. The bypass is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.

Root cause

valid_host() rejects ports other than 80 and 443 when a port is included in the string being validated:

port = parsed.port
...
if port and port not in (80, 443):
    return False

In get_browsable_activities(), only the host attribute is passed to valid_host():

host = data.getAttribute(f'{ns}:host')
port = data.getAttribute(f'{ns}:port')
...
if not valid_host(host):
    logger.warning('Invalid Host: %s', host)
    continue
shost = f'{scheme}://{host}'
if port and is_number(port):
    c_url = f'{shost}:{port}{WELL_KNOWN_PATH}'
else:
    c_url = f'{shost}{WELL_KNOWN_PATH}'
well_known[c_url] = shost

_check_url() then fetches the assembled URL after checking only path, query, and params:

purl = urlparse(url)
if (purl.path != WELL_KNOWN_PATH
    or len(purl.query) > 0
        or len(purl.params) > 0):
    logger.warning('Invalid Assetlinks URL: %s', url)
    continue
r = requests.get(url,
                 timeout=5,
                 allow_redirects=False,
                 proxies=proxies,
                 verify=verify)

Reproduction

Use an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:

<activity android:name=".DeepLink" android:exported="true">
  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.BROWSABLE" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:scheme="http" android:host="rebind.example" android:port="22" />
  </intent-filter>
</activity>

A safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only rebind.example, then fetches a URL that preserves the unchecked port:

well_known map: {'http://rebind.example:22/.well-known/assetlinks.json': 'http://rebind.example'}
requests.get calls: [('http://rebind.example:22/.well-known/assetlinks.json', {'timeout': 5, 'allow_redirects': False, 'proxies': None, 'verify': True})]
findings: [{'url': 'http://rebind.example:22/.well-known/assetlinks.json', 'host': 'http://rebind.example', 'status_code': 200, 'status': True}]
VULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json

The same code pattern is present in latest release v4.4.6 and current main.

Remediation

Validate the final URL after all manifest components have been applied. In particular:

  1. Build c_url, then run validation on the full URL, including scheme, hostname, port, path, query, and params.
  2. Reject android:port values other than 80 and 443 before appending them to the URL.
  3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.
  4. Keep allow_redirects=False for the existing redirect mitigation.
Severity
3.0 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mobsf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-68927"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T18:01:03Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\nMobSF\u0027s Android App Link assetlinks checker validates only the manifest `android:host` value with `valid_host()`, but then appends the separate `android:port` value into the URL used for the server-side request. This bypasses the current port restriction in `valid_host()` and lets a crafted APK cause MobSF to fetch `http://host:\u003cattacker-port\u003e/.well-known/assetlinks.json` or `https://host:\u003cattacker-port\u003e/.well-known/assetlinks.json`.\n\n## Impact\n\nAn authenticated user who can upload or trigger analysis of a crafted APK can cause the MobSF server to make an outbound request to an attacker-selected port during Android manifest analysis. When the host is controlled by the attacker and uses DNS rebinding, the validation lookup can resolve to a public IP while the later HTTP client lookup resolves to an internal address, allowing SSRF to internal services on non-80/443 ports.\n\nThis is not arbitrary URL SSRF. The path remains fixed to `/.well-known/assetlinks.json`, and redirects are disabled. The bypass is that the final fetched URL is assembled after the host-only validation, so the current port guard is not applied to the actual URL.\n\n## Root cause\n\n`valid_host()` rejects ports other than 80 and 443 when a port is included in the string being validated:\n\n```python\nport = parsed.port\n...\nif port and port not in (80, 443):\n    return False\n```\n\nIn `get_browsable_activities()`, only the host attribute is passed to `valid_host()`:\n\n```python\nhost = data.getAttribute(f\u0027{ns}:host\u0027)\nport = data.getAttribute(f\u0027{ns}:port\u0027)\n...\nif not valid_host(host):\n    logger.warning(\u0027Invalid Host: %s\u0027, host)\n    continue\nshost = f\u0027{scheme}://{host}\u0027\nif port and is_number(port):\n    c_url = f\u0027{shost}:{port}{WELL_KNOWN_PATH}\u0027\nelse:\n    c_url = f\u0027{shost}{WELL_KNOWN_PATH}\u0027\nwell_known[c_url] = shost\n```\n\n`_check_url()` then fetches the assembled URL after checking only path, query, and params:\n\n```python\npurl = urlparse(url)\nif (purl.path != WELL_KNOWN_PATH\n    or len(purl.query) \u003e 0\n        or len(purl.params) \u003e 0):\n    logger.warning(\u0027Invalid Assetlinks URL: %s\u0027, url)\n    continue\nr = requests.get(url,\n                 timeout=5,\n                 allow_redirects=False,\n                 proxies=proxies,\n                 verify=verify)\n```\n\n## Reproduction\n\nUse an Android manifest with a browsable App Link data tag that has a benign-looking host and a restricted port:\n\n```xml\n\u003cactivity android:name=\".DeepLink\" android:exported=\"true\"\u003e\n  \u003cintent-filter\u003e\n    \u003caction android:name=\"android.intent.action.VIEW\" /\u003e\n    \u003ccategory android:name=\"android.intent.category.BROWSABLE\" /\u003e\n    \u003ccategory android:name=\"android.intent.category.DEFAULT\" /\u003e\n    \u003cdata android:scheme=\"http\" android:host=\"rebind.example\" android:port=\"22\" /\u003e\n  \u003c/intent-filter\u003e\n\u003c/activity\u003e\n```\n\nA safe local proof with DNS and HTTP monkeypatching shows that MobSF validates only `rebind.example`, then fetches a URL that preserves the unchecked port:\n\n```text\nwell_known map: {\u0027http://rebind.example:22/.well-known/assetlinks.json\u0027: \u0027http://rebind.example\u0027}\nrequests.get calls: [(\u0027http://rebind.example:22/.well-known/assetlinks.json\u0027, {\u0027timeout\u0027: 5, \u0027allow_redirects\u0027: False, \u0027proxies\u0027: None, \u0027verify\u0027: True})]\nfindings: [{\u0027url\u0027: \u0027http://rebind.example:22/.well-known/assetlinks.json\u0027, \u0027host\u0027: \u0027http://rebind.example\u0027, \u0027status_code\u0027: 200, \u0027status\u0027: True}]\nVULNERABLE: valid_host validated only rebind.example, but assetlinks_check fetched unchecked port 22 via http://rebind.example:22/.well-known/assetlinks.json\n```\n\nThe same code pattern is present in latest release `v4.4.6` and current main.\n\n## Remediation\n\nValidate the final URL after all manifest components have been applied. In particular:\n\n1. Build `c_url`, then run validation on the full URL, including scheme, hostname, port, path, query, and params.\n2. Reject `android:port` values other than 80 and 443 before appending them to the URL.\n3. Prevent DNS rebinding by pinning the validated DNS result to the outbound connection or otherwise ensuring the actual HTTP request cannot resolve to a different address than the validation step.\n4. Keep `allow_redirects=False` for the existing redirect mitigation.",
  "id": "GHSA-95px-34x5-p37h",
  "modified": "2026-08-18T18:01:03Z",
  "published": "2026-08-18T18:01:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/security/advisories/GHSA-95px-34x5-p37h"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/2627"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/62563ca429a75b3e5d47a13b958e1d2e7d5e2bbf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/releases/tag/v4.5.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MobSF has SSRF port restriction bypass in assetlinks_check"
}

GHSA-95R8-F778-2VMC

Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2024-04-04 01:44
VLAI
Details

A Server-Side Request Forgery (SSRF) vulnerability in the backup & restore functionality in earlier versions than ProSyst mBS SDK 8.2.6 and Bosch IoT Gateway Software 9.3.0 allows a remote attacker to forge GET requests to arbitrary URLs. In addition, this could potentially allow an attacker to read sensitive zip files from the local server.

Severity
8.6 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-11897"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-21T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability in the backup \u0026 restore functionality in earlier versions than ProSyst mBS SDK 8.2.6 and Bosch IoT Gateway Software 9.3.0 allows a remote attacker to forge GET requests to arbitrary URLs. In addition, this could potentially allow an attacker to read sensitive zip files from the local server.",
  "id": "GHSA-95r8-f778-2vmc",
  "modified": "2024-04-04T01:44:34Z",
  "published": "2022-05-24T16:54:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11897"
    },
    {
      "type": "WEB",
      "url": "https://psirt.bosch.com/Advisory/BOSCH-SA-562575.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-95WR-3F2V-V2WH

Vulnerability from github – Published: 2026-04-14 23:36 – Updated: 2026-04-24 20:42
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).

Severity
5.5 (Medium)
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
Show details on source website
To clipboard 

{
  "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": [
    "CVE-2026-41130"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:36:09Z",
    "nvd_published_at": "2026-04-22T00:16:28Z",
    "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-24T20:42:23Z",
  "published": "2026-04-14T23:36:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-95wr-3f2v-v2wh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41130"
    },
    {
      "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"
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list