CWE-918

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-78682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T16:41:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nCurrent NLTK source reopens SSRF in proxied environments. `pathsec.urlopen()` validates the requested hostname locally, but once proxy inheritance is enabled the real fetch is performed by the proxy rather than by the validated direct-connect socket path.\n\n### Details\n\n- **Vulnerability type:** Server-side request forgery\n- **Affected component:** `nltk.pathsec.urlopen`, `nltk.data.load`, `nltk.downloader.Downloader.index`, `nltk.downloader.Downloader.download`\n- **Affected versions:** Current source `v3.10.0-rc2`; published `3.9.4` was a negative control and did not reproduce.\n- **Patched versions:** Not yet patched\n- **Root cause:** Proxy-handler inheritance disables `_SafeHTTPHandler` and `_SafeHTTPSHandler`, so the validated hostname no longer matches the actual egress destination.\n\nThe hardened direct path pins the validated numeric destination IP before opening the socket. The proxied branch instead copies `ProxyHandler` instances from the global opener, marks the request as proxied, and skips the pinned handlers. I confirmed that a validated public URL can be fetched from a loopback-only internal service through the proxy path via `pathsec.urlopen()`, `nltk.data.load()`, `Downloader.index()`, and `Downloader.download()`.\n\n### PoC\n\n**Preconditions**\n- The runtime has an HTTP proxy configured and the caller relies on `pathsec` to keep network fetches SSRF-safe.\n\n**Steps**\n1. Start a loopback-only HTTP server that serves secret text, a valid downloader index, and a ZIP payload.\n2. Configure a proxy that forwards a validated public URL to that internal loopback service.\n3. Call `pathsec.urlopen()` or `nltk.data.load()` on the public URL and observe the internal response is returned.\n4. Instantiate `Downloader(server_index_url=...)`, call `index()` and `download()`, and observe internal-only content is parsed and installed.\n\n**Minimal reproducible excerpt**\n\n```text\n{\u0027urlopen\u0027: \u0027PROXY_TEXT_SECRET\u0027, \u0027data_load\u0027: \u0027PROXY_TEXT_SECRET\u0027, \u0027downloaded_file\u0027: \u0027INTERNAL_ZIP_SECRET\u0027}\n```\n\n### Impact\n\nConsumers that trust `pathsec` as an SSRF barrier in proxied environments can be made to read internal-only HTTP resources, load forged downloader indexes, and install attacker-chosen package content fetched from the proxy\u0027s network view.\n\n### Remediation\n\nPreserve destination validation for the actual proxy egress target or fail closed when the request would otherwise downgrade into an unpinned proxied path. Add regression tests across `pathsec.urlopen`, `nltk.data.load`, and downloader fetches with a configured proxy.\n\n### References\n\n- https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/pathsec.py#L468-L518\n- https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/data.py#L1247-L1283\n- https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/downloader.py#L875-L889\n- https://github.com/nltk/nltk/blob/v3.10.0-rc2/nltk/downloader.py#L1220-L1226\n- https://github.com/nltk/nltk/blob/3.9.4/nltk/pathsec.py#L245-L250\n\n---\n\n## Fix + attack demonstration (verified)\n\n\nNLTK cannot pin the egress through a proxy, so it stops pretending to: under `ENFORCE` a proxied fetch is **refused** rather than performed unvalidated. Operators who trust their proxy opt back in with `NLTK_ALLOW_PROXIED_URLOPEN=1` or `nltk.pathsec.ALLOW_PROXIED_FETCH=True`; under `ENFORCE=False` the refusal degrades to a warning. This closes the **whole class** (environment proxies and explicit `ProxyHandler` alike), because NLTK declines any fetch whose egress it cannot validate.\n\n## Attack demonstration (reproduced; captured output)\nA loopback HTTP server stands in for the internal target; `http_proxy` points at it; NLTK is asked for a **public** IP URL.\n\n**Before the fix** \u2014 the internal secret is exfiltrated through the proxy:\n```\nvalidate_network_url(public): PASSED\n*** BYPASS: pathsec.urlopen returned INTERNAL content via proxy: \u0027INTERNAL_ONLY_SECRET\u0027\n```\n\n**After the fix** \u2014 five scenarios, isolated subprocesses:\n| Scenario | Result |\n|---|---|\n| proxied (env) + ENFORCE | `PermissionError` \u2014 **blocked** |\n| proxied + opt-in | returns secret \u2014 escape hatch works |\n| explicit `ProxyHandler` (not env) + ENFORCE | `PermissionError` \u2014 **blocked** (whole class) |\n| no proxy (direct) | internal IP still refused \u2014 pinning intact |\n| proxied + `ENFORCE=False` | returns secret **+ warns** |\n\n## Tests\n`nltk/test/unit/test_pathsec.py`: 64 passed. Added an end-to-end regression (`test_proxied_fetch_does_not_reach_internal_target`) plus `test_env_proxy_fails_closed_under_enforce`; the prior `test_env_proxy_skips_pinning_handlers` (which encoded the vulnerable path) is re-expressed as the opt-in case. Existing direct-path DNS-rebinding and IP-policy tests unchanged and passing. pre-commit (isort/black/ruff) clean.\n\n## Note\nThe upfront `validate_network_url()` and the direct-path IP pinning (from the earlier DNS-rebinding fixes, CVE-2026-54296 / GHSA-qvv7) are unchanged \u2014 this only closes the proxied downgrade they didn\u0027t cover.",
  "id": "GHSA-6ww7-3frv-cqxh",
  "modified": "2026-09-08T16:41:40Z",
  "published": "2026-09-08T16:41:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-6ww7-3frv-cqxh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78682"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/commit/767333a005a1cd3d82d2029215f2dbe66a5844d9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nltk/nltk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/releases/tag/v3.10.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3733.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-before-ssrf-protection-bypass-via-proxy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NLTK: pathsec SSRF protection can be bypassed when a proxy is configured"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nezhahq/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.20.0"
            },
            {
              "fixed": "2.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/naiba/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47268"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T22:10:12Z",
    "nvd_published_at": "2026-06-12T22:16:51Z",
    "severity": "MODERATE"
  },
  "details": "#### Summary\n\nAn authenticated Nezha dashboard user can create or update a DDNS profile with provider `webhook` and configure an arbitrary `webhook_url`, HTTP method, request body, and headers. When DDNS is triggered for a server that uses that profile, the dashboard process sends the configured request with `utils.HttpClient` without the SSRF protections used by notification webhooks.\n\nThis allows a low-privileged authenticated user who controls an owned server/DDNS profile to make the dashboard host issue HTTP requests to loopback or internal network services. The response body is not returned to the attacker in the confirmed path, so this is a blind SSRF / internal state-changing request primitive.\n\n#### Details\n\nThe DDNS API is available to authenticated users, not only administrators:\n\n- `cmd/dashboard/controller/controller.go:137` registers `GET /api/v1/ddns`.\n- `cmd/dashboard/controller/controller.go:139` registers `POST /api/v1/ddns`.\n- `cmd/dashboard/controller/controller.go:140` registers `PATCH /api/v1/ddns/:id`.\n\nThe create and update handlers copy attacker-controlled webhook fields directly from JSON request bodies into `model.DDNSProfile`:\n\n- `cmd/dashboard/controller/ddns.go:47-74` accepts `model.DDNSForm` and stores `WebhookURL`, `WebhookMethod`, `WebhookRequestType`, `WebhookRequestBody`, and `WebhookHeaders`.\n- `cmd/dashboard/controller/ddns.go:112-145` updates the same fields after profile ownership is checked.\n- `model/ddns_api.go:11-15` exposes these fields as JSON input.\n- `model/ddns.go:28-33` stores these fields on the persisted profile.\n\nUsers can attach owned DDNS profiles to owned servers, and DDNS updates are triggered in common server update and agent IP-reporting paths:\n\n- `cmd/dashboard/controller/server.go:63-83` checks DDNS profile ownership, then stores `EnableDDNS`, `DDNSProfiles`, and `OverrideDDNSDomains` on an owned server.\n- `service/singleton/server.go:44-58` calls `UpdateDDNS` when a server with DDNS enabled is updated.\n- `service/rpc/nezha.go:247-279` calls `UpdateDDNS` when an authenticated agent reports a changed IP.\n\nThe DDNS provider dispatcher instantiates the webhook provider when `Provider == \"webhook\"`:\n\n- `service/singleton/ddns.go:58-95`, especially `service/singleton/ddns.go:79-81`.\n\nThe sink is the DDNS webhook provider:\n\n- `pkg/ddns/webhook/webhook.go:49-65` prepares and sends the HTTP request with `utils.HttpClient.Do(req)`.\n- `pkg/ddns/webhook/webhook.go:85-100` formats and applies attacker-controlled headers.\n- `pkg/ddns/webhook/webhook.go:91-92` creates the request with the configured method and URL.\n- `pkg/ddns/webhook/webhook.go:117-134` parses the configured URL and only formats query parameters; it does not restrict scheme, host, IP range, or redirects.\n- `pkg/ddns/webhook/webhook.go:137-158` builds attacker-controlled request bodies for POST/PATCH/PUT.\n\nThe project already contains SSRF defenses for notification webhooks, showing the expected mitigation pattern is absent from the DDNS webhook path:\n\n- `model/notification.go:34-58` defines blocked private/reserved CIDRs.\n- `model/notification.go:193-221` creates a notification HTTP client that resolves and pins a validated IP and disables redirects.\n- `model/notification.go:229-263` only allows `http`/`https`, requires a hostname, resolves all addresses, and rejects disallowed IPs.\n- `model/notification.go:265-276` rejects blocked ranges and non-global-unicast targets.\n\nEquivalent validation was not found in `pkg/ddns/webhook/webhook.go`.\n\n#### Safe local PoC\n\nEnvironment:\n\n- Repository: `https://github.com/nezhahq/nezha.git`\n- Commit tested: `05e5da2535197fc223b79601d50eeea362dcf853`\n- Tag at commit: `v2.0.9`\n- Module: `github.com/nezhahq/nezha`\n- Go version: `go1.26.3 linux/amd64`\n- Testing scope: local-only; loopback HTTP listener and fake local UDP DNS SOA server only.\n\nA temporary same-package test was created and removed automatically after execution. It used a local `httptest` listener as the internal service and a local UDP DNS server that returned an SOA for `example.com.`. The test then executed the normal DDNS update pipeline with a webhook DDNS profile pointing at the loopback HTTP listener.\n\nCommand run:\n\n```bash\ntmp=\"pkg/ddns/ddns_ssrf_local_poc_test.go\"; trap \u0027rm -f \"$tmp\"\u0027 EXIT; cat \u003e \"$tmp\" \u003c\u003c\u0027EOF\u0027\npackage ddns\n\nimport (\n    \"context\"\n    \"io\"\n    \"net\"\n    \"net/http\"\n    \"net/http/httptest\"\n    \"testing\"\n\n    \"github.com/miekg/dns\"\n    \"github.com/nezhahq/nezha/model\"\n    \"github.com/nezhahq/nezha/pkg/ddns/webhook\"\n)\n\nfunc TestLocalPoCDDNSUpdatePipelineReachesLoopback(t *testing.T) {\n    hit := make(chan string, 1)\n    httpSrv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n        body, _ := io.ReadAll(r.Body)\n        hit \u003c- r.Method + \" \" + r.URL.Path + \" \" + r.Header.Get(\"X-Proof\") + \" \" + string(body)\n        w.WriteHeader(http.StatusNoContent)\n    }))\n    defer httpSrv.Close()\n\n    dnsPacketConn, err := net.ListenPacket(\"udp\", \"127.0.0.1:0\")\n    if err != nil {\n        t.Fatal(err)\n    }\n    dnsSrv := \u0026dns.Server{PacketConn: dnsPacketConn, Handler: dns.HandlerFunc(func(w dns.ResponseWriter, r *dns.Msg) {\n        msg := new(dns.Msg)\n        msg.SetReply(r)\n        if len(r.Question) \u003e 0 \u0026\u0026 r.Question[0].Qtype == dns.TypeSOA {\n            msg.Answer = append(msg.Answer, \u0026dns.SOA{\n                Hdr:     dns.RR_Header{Name: \"example.com.\", Rrtype: dns.TypeSOA, Class: dns.ClassINET, Ttl: 60},\n                Ns:      \"ns.example.com.\",\n                Mbox:    \"hostmaster.example.com.\",\n                Serial:  1,\n                Refresh: 60,\n                Retry:   60,\n                Expire:  60,\n                Minttl:  60,\n            })\n        }\n        _ = w.WriteMsg(msg)\n    })}\n    go func() { _ = dnsSrv.ActivateAndServe() }()\n    defer dnsSrv.Shutdown()\n\n    enableIPv4 := true\n    enableIPv6 := false\n    profile := \u0026model.DDNSProfile{\n        EnableIPv4:         \u0026enableIPv4,\n        EnableIPv6:         \u0026enableIPv6,\n        MaxRetries:         1,\n        Domains:            []string{\"host.example.com\"},\n        Provider:           model.ProviderWebHook,\n        WebhookURL:         httpSrv.URL + \"/internal\",\n        WebhookMethod:      2,\n        WebhookRequestType: 1,\n        WebhookRequestBody: `{\"ip\":\"#ip#\",\"domain\":\"#domain#\",\"type\":\"#type#\"}`,\n        WebhookHeaders:     `{\"X-Proof\":\"nezha-ddns-pipeline-ssrf\"}`,\n    }\n    provider := \u0026Provider{\n        DDNSProfile: profile,\n        IPAddrs:     \u0026model.IP{IPv4Addr: \"203.0.113.10\"},\n        Setter:      \u0026webhook.Provider{DDNSProfile: profile},\n    }\n\n    ctx := context.WithValue(context.Background(), DNSServerKey{}, []string{dnsPacketConn.LocalAddr().String()})\n    if err := provider.updateDomain(ctx, \"host.example.com\"); err != nil {\n        t.Fatalf(\"updateDomain returned error: %v\", err)\n    }\n\n    select {\n    case got := \u003c-hit:\n        t.Logf(\"observed loopback request through DDNS update pipeline: %s\", got)\n    default:\n        t.Fatalf(\"expected loopback listener to receive DDNS webhook request\")\n    }\n}\nEOF\ngo test ./pkg/ddns -run TestLocalPoCDDNSUpdatePipelineReachesLoopback -v\n```\n\nObserved output:\n\n```text\n=== RUN   TestLocalPoCDDNSUpdatePipelineReachesLoopback\n    ddns_ssrf_local_poc_test.go:76: observed loopback request through DDNS update pipeline: POST /internal nezha-ddns-pipeline-ssrf {\"ip\":\"203.0.113.10\",\"domain\":\"host.example.com\",\"type\":\"ipv4\"}\n--- PASS: TestLocalPoCDDNSUpdatePipelineReachesLoopback (0.00s)\nPASS\nok  \tgithub.com/nezhahq/nezha/pkg/ddns\t0.009s\n```\n\nA lower-level provider-only confirmation was also run with `go test ./pkg/ddns/webhook -run TestLocalPoCDDNSWebhookReachesLoopback -v` and observed:\n\n```text\nobserved loopback request: POST /internal nezha-ddns-ssrf {\"ip\":\"203.0.113.10\",\"domain\":\"host.example.com\",\"type\":\"ipv4\"}\n```\n\nCleanup:\n\n- Both temporary PoC test files were removed by shell `trap`.\n- `find . -path \u0027./.git\u0027 -prune -o \\( -name \u0027ssrf_local_poc_test.go\u0027 -o -name \u0027ddns_ssrf_local_poc_test.go\u0027 \\) -print` returned no files.\n\n#### Impact\n\nAn authenticated dashboard user can cause the Nezha dashboard process to send arbitrary HTTP requests to services reachable from the dashboard host, including loopback and private network targets. The confirmed path allows attacker-controlled method, URL path/query, headers, and request body.\n\nPotential impacts depend on deployment and reachable internal services, but include:\n\n- Blind probing of internal HTTP services from the dashboard network location.\n- Triggering state-changing internal endpoints that trust localhost or private network origins.\n- Reaching services not exposed to the attacker directly.\n- Interaction with cloud metadata or control-plane endpoints if reachable and not otherwise protected.\n\nThe response body is not returned to the attacker in the confirmed code path, so this should not be described as direct arbitrary internal file/secret read without an additional response-disclosure primitive.",
  "id": "GHSA-6x26-5727-rrm9",
  "modified": "2026-06-26T21:28:39Z",
  "published": "2026-05-29T22:10:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-6x26-5727-rrm9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47268"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nezhahq/nezha"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nezha\u0027s authenticated DDNS webhook configuration allows blind SSRF from the dashboard host"
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-3553"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-24T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability in the EPPUpdateService of Bitdefender Endpoint Security Tools allows an attacker to use the Endpoint Protection relay as a proxy for any remote host. This issue affects: Bitdefender Endpoint Security Tools versions prior to 6.6.27.390; versions prior to 7.1.2.33. Bitdefender Unified Endpoint for Linux versions prior to 6.2.21.160. Bitdefender GravityZone versions prior to 6.24.1-1.",
  "id": "GHSA-6x2g-jp65-m547",
  "modified": "2022-05-24T19:21:17Z",
  "published": "2022-05-24T19:21:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3553"
    },
    {
      "type": "WEB",
      "url": "https://www.bitdefender.com/support/security-advisories/server-side-request-forgery-eppupdateservice-remote-config-file-va-9825"
    },
    {
      "type": "WEB",
      "url": "https://www.bitdefender.com/support/security-advisories/server-side-request-forgery-in-eppupdateservice-remote-config-file-va-9825"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-31390"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-09T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Jizhicms v2.2.5 was discovered to contain a Server-Side Request Forgery (SSRF) vulnerability via the Update function in app/admin/c/TemplateController.php.",
  "id": "GHSA-6x33-6gc7-rp43",
  "modified": "2022-06-16T00:00:22Z",
  "published": "2022-06-10T00:00:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31390"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cherry-toto/jizhicms/issues/75"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-73058"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-16T14:16:55Z",
    "severity": "MODERATE"
  },
  "details": "stoatchat versions before 0.15.0 fail to block the IPv6 unspecified address (::) in the SSRF blocklist, allowing unauthenticated attackers to bypass protections via the /proxy and /embed endpoints. Attackers can craft requests using IPv6 literal syntax to access services on the loopback interface and retrieve sensitive internal content.",
  "id": "GHSA-6x44-jq26-vpv6",
  "modified": "2026-08-16T15:30:24Z",
  "published": "2026-08-16T15:30:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/stoatchat/stoatchat/security/advisories/GHSA-4rmr-77qv-hq47"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73058"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/stoatchat-before-ssrf-via-ipv6-unspecified-address-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/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": [],
  "aliases": [
    "CVE-2026-69904"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T18:20:00Z",
    "severity": "LOW"
  },
  "details": "Server-side request forgery (ssrf) in Microsoft Office SharePoint allows an authorized attacker to disclose information over a network.",
  "id": "GHSA-6x4f-7fpp-hmmw",
  "modified": "2026-09-08T18:33:04Z",
  "published": "2026-09-08T18:33:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-69904"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-69904"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-107362"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-08T18:17:21Z",
    "severity": "HIGH"
  },
  "details": "Malcolm file-upload component ships the upstream FilePond PHP server (pqina/filepond-server-php) largely unmodified: Dockerfile copies all upstream *.php files and Malcolm only overwrites config.php and submit.php. Upstream index.php exposes a fetch API route that instructs the server to download an arbitrary URL with curl (including FOLLOWLOCATION) and, for HEAD requests, stores the fetched response body in the upload container\u0027s transfer directory and returns the transfer ID to the caller, enabling full readback of the fetched content.",
  "id": "GHSA-6x93-f29r-jwj6",
  "modified": "2026-10-08T18:32:30Z",
  "published": "2026-10-08T18:32:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/Malcolm/security/advisories/GHSA-cvx2-hj33-vc4q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107362"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-280-01.json"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "MindsDB"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "25.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-2531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T17:47:09Z",
    "nvd_published_at": "2026-02-16T04:15:51Z",
    "severity": "LOW"
  },
  "details": "A security vulnerability has been detected in MindsDB up to 25.14.1. This vulnerability affects the function clear_filename of the file mindsdb/utilities/security.py of the component File Upload. Such manipulation leads to server-side request forgery. The attack may be performed from remote. The exploit has been disclosed publicly and may be used.",
  "id": "GHSA-6xw9-2p64-7622",
  "modified": "2026-06-06T00:37:43Z",
  "published": "2026-02-16T06:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2531"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mindsdb/mindsdb/issues/12163"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mindsdb/mindsdb/pull/12213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/themavik/mindsdb/commit/74d6f0fd4b630218519a700fbee1c05c7fd4b1ed"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mindsdb/mindsdb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mindsdb/PYSEC-2026-91.yaml"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.346119"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.346119"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.748219"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MindsDB affected by a SSRF vulnerability"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.49.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66844"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-17T19:40:24Z",
    "nvd_published_at": "2025-12-15T16:15:53Z",
    "severity": "CRITICAL"
  },
  "details": "In grav \u003c1.7.49.5, a SSRF (Server-Side Request Forgery) vector may be triggered via Twig templates when page content is processed by Twig and the configuration allows undefined PHP functions to be registered.",
  "id": "GHSA-729w-j79f-2c34",
  "modified": "2025-12-17T19:47:12Z",
  "published": "2025-12-15T18:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66844"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yohane-Mashiro/grav_cve/issues/2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Grav may be vulnerable to SSRF attack via Twig Templates"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.19.2"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "fluentd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.19.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T16:36:11Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The `out_http` output plugin allows the use of placeholders (such as `${tag}`) in the `endpoint` configuration parameter.\nIt was discovered that if the placeholder value is derived from untrusted user input, an attacker can maliciously control the destination hostname of the outbound HTTP requests made by Fluentd.\n\n### Impact\nThis vulnerability allows for a **Server-Side Request Forgery (SSRF)** attack.\nAn unauthenticated attacker can force the Fluentd node to send HTTP requests to arbitrary internal services. This can lead to unauthorized access to internal APIs, data exfiltration, or the compromise of cloud metadata endpoints (e.g., AWS IMDS `169.254.169.254`).\n\n### Patches\nv1.19.3\n\n### Workarounds\nIf an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:\n\n1. Avoid Dynamic Hostnames\n   * Do not use the placeholder in the endpoint parameter as hostname.\n\n2. Restrict Network Access \n   * Use firewall rules (e.g., iptables, AWS Security Groups) to block the Fluentd node from accessing sensitive internal IP addresses, specifically the cloud provider\u0027s metadata service and other internal microservices that Fluentd does not explicitly need to access.\n\n3. Restrict allowed hosts\n   * Inject filter to accept allowed hosts in placeholders explicitly if possible.",
  "id": "GHSA-72f5-rr8c-r6gr",
  "modified": "2026-06-26T16:36:11Z",
  "published": "2026-06-26T16:36:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fluent/fluentd/security/advisories/GHSA-72f5-rr8c-r6gr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fluent/fluentd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fluent/fluentd/releases/tag/v1.19.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fluentd is Vulnerable to Server-Side Request Forgery (SSRF) via Placeholder Expansion in `out_http`"
}