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.

6224 vulnerabilities reference this CWE, most recent first.

GHSA-V82V-RQ72-PHQ9

Vulnerability from github – Published: 2022-01-26 22:13 – Updated: 2022-01-31 22:00
VLAI
Summary
Server side request forgery in @isomorphic-git/cors-proxy
Details

The package @isomorphic-git/cors-proxy before 2.7.1 is vulnerable to Server-side Request Forgery (SSRF) due to missing sanitization and validation of the redirection action in middleware.js.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@isomorphic-git/cors-proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-01-24T22:53:26Z",
    "nvd_published_at": "2022-01-21T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "The package @isomorphic-git/cors-proxy before 2.7.1 is vulnerable to Server-side Request Forgery (SSRF) due to missing sanitization and validation of the redirection action in middleware.js.",
  "id": "GHSA-v82v-rq72-phq9",
  "modified": "2022-01-31T22:00:02Z",
  "published": "2022-01-26T22:13:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23664"
    },
    {
      "type": "WEB",
      "url": "https://github.com/isomorphic-git/cors-proxy/commit/1b1c91e71d946544d97ccc7cf0ac62b859e03311"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/isomorphic-git/cors-proxy"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-ISOMORPHICGITCORSPROXY-1734788"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server side request forgery in @isomorphic-git/cors-proxy"
}

GHSA-V8F7-CG9P-W5JX

Vulnerability from github – Published: 2026-04-10 21:31 – Updated: 2026-06-08 12:50
Withdrawn 2026-06-08 VLAI
Summary
Duplicate Advisory: GeoNode contains a server-side request forgery vulnerability in the service registration endpoint
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-hw9r-6m78-w6h3. This link is maintained to preserve external references.

Original Description

GeoNode versions 4.0 before 4.4.5 and 5.0 before 5.0.2 contain a server-side request forgery vulnerability in the service registration endpoint that allows authenticated attackers to trigger outbound network requests to arbitrary URLs by submitting a crafted service URL during form validation. Attackers can probe internal network targets including loopback addresses, RFC1918 private IP ranges, link-local addresses, and cloud metadata services by exploiting insufficient URL validation in the WMS service handler without private IP filtering or allowlist enforcement.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "geonode"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "geonode"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T12:50:43Z",
    "nvd_published_at": "2026-04-10T20:16:22Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-hw9r-6m78-w6h3. This link is maintained to preserve external references.\n\n### Original Description\nGeoNode versions 4.0 before 4.4.5 and 5.0 before 5.0.2 contain a server-side request forgery vulnerability in the service registration endpoint that allows authenticated attackers to trigger outbound network requests to arbitrary URLs by submitting a crafted service URL during form validation. Attackers can probe internal network targets including loopback addresses, RFC1918 private IP ranges, link-local addresses, and cloud metadata services by exploiting insufficient URL validation in the WMS service handler without private IP filtering or allowlist enforcement.",
  "id": "GHSA-v8f7-cg9p-w5jx",
  "modified": "2026-06-08T12:50:43Z",
  "published": "2026-04-10T21:31:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/GeoNode/geonode/security/advisories/GHSA-hw9r-6m78-w6h3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39922"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GeoNode/geonode/releases/tag/4.4.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GeoNode/geonode/releases/tag/5.0.2"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/geonode-ssrf-via-service-registration"
    }
  ],
  "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: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"
    }
  ],
  "summary": "Duplicate Advisory: GeoNode contains a server-side request forgery vulnerability in the service registration endpoint",
  "withdrawn": "2026-06-08T12:50:43Z"
}

GHSA-V8RQ-G678-PM22

Vulnerability from github – Published: 2026-09-14 12:31 – Updated: 2026-09-14 12:31
VLAI
Details

A vulnerability was determined in taisan tarzan-cms 1.0.0. This issue affects the function openConnection of the file com/tarzan/cms/modules/admin/service/biz/ThemeService.java of the component Theme Download Function. Executing a manipulation of the argument httpUrl can lead to server-side request forgery. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-90710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-14T12:17:51Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in taisan tarzan-cms 1.0.0. This issue affects the function openConnection of the file com/tarzan/cms/modules/admin/service/biz/ThemeService.java of the component Theme Download Function. Executing a manipulation of the argument httpUrl can lead to server-side request forgery. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-v8rq-g678-pm22",
  "modified": "2026-09-14T12:31:41Z",
  "published": "2026-09-14T12:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90710"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/taisan/tarzan-cms"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/taisan/tarzan-cms/issues/IK768M"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-90710"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/918522"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/403265"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/403265/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-V8V6-2CHV-GCGP

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:38
VLAI
Details

An SSRF issue was discovered in Enghouse Web Chat 6.1.300.31. In any POST request, one can replace the port number at WebServiceLocation=http://localhost:8085/UCWebServices/ with a range of ports to determine what is visible on the internal network (as opposed to what general web traffic would see on the product's host). The response from open ports is different than from closed ports. The product does not allow one to change the protocol: anything except http(s) will throw an error; however, it is the type of error that allows one to determine if a port is open or not.

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-2019-16948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-13T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An SSRF issue was discovered in Enghouse Web Chat 6.1.300.31. In any POST request, one can replace the port number at WebServiceLocation=http://localhost:8085/UCWebServices/ with a range of ports to determine what is visible on the internal network (as opposed to what general web traffic would see on the product\u0027s host). The response from open ports is different than from closed ports. The product does not allow one to change the protocol: anything except http(s) will throw an error; however, it is the type of error that allows one to determine if a port is open or not.",
  "id": "GHSA-v8v6-2chv-gcgp",
  "modified": "2024-04-04T02:38:49Z",
  "published": "2022-05-24T17:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16948"
    },
    {
      "type": "WEB",
      "url": "https://mjlanders.com/2019/11/07/multiple-vulnerabilities-found-in-enghouse-zeacom-web-chat"
    }
  ],
  "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-V8WJ-F5C7-PVXF

Vulnerability from github – Published: 2025-05-27 17:59 – Updated: 2025-05-29 21:03
VLAI
Summary
Strapi allows Server-Side Request Forgery in Webhook function
Details

Description

In Strapi latest version, at function Settings -> Webhooks, the application allows us to input a URL in order to create a Webook connection. However, we can input into this field the local domains such as localhost, 127.0.0.1, 0.0.0.0,.... in order to make the Application fetching into the internal itself, which causes the vulnerability Server - Side Request Forgery (SSRF).

Payloads

  • http://127.0.0.1:80 -> The Port is not open
  • http://127.0.0.1:1337 -> The Port which Strapi is running on

Steps to Reproduce

  • First of all, let's input the URL http://127.0.0.1:80 into the URL field, and click "Save".

CleanShot 2024-06-04 at 22 45 17@2x

  • Next, use the "Trigger" function and use Burp Suite to capture the request / response

CleanShot 2024-06-04 at 22 47 50@2x

  • The server return request to http://127.0.0.1/ failed, reason: connect ECONNREFUSED 127.0.0.1:80, BECAUSE the Port 80 is not open, since we are running Strapi on Port 1337, let's change the URL we input above into http://127.0.0.1:1337

CleanShot 2024-06-04 at 22 50 13@2x

  • Continue to click the "Trigger" function, use Burp to capture the request / response

CleanShot 2024-06-04 at 22 53 25@2x

  • The server returns Method Not Allowed, which means that there actually is a Port 1337 running the machine.

PoC

Here is the Poc Video, please check:

https://drive.google.com/file/d/1EvVp9lMpYnGLmUyr16gQ_2RetI-GqYjV/view?usp=sharing

Impact

  • If there is a real server running Strapi with many ports open, by using this SSRF vulnerability, the attacker can brute-force through all 65535 ports to know what ports are open.
Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@strapi/admin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.25.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-52588"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-27T17:59:52Z",
    "nvd_published_at": "2025-05-29T09:15:25Z",
    "severity": "MODERATE"
  },
  "details": "## Description\nIn Strapi latest version, at function Settings -\u003e Webhooks, the application allows us to input a URL in order to create a Webook connection. However, we can input into this field the local domains such as `localhost`, `127.0.0.1`, `0.0.0.0`,.... in order to make the Application fetching into the internal itself, which causes the vulnerability `Server - Side Request Forgery (SSRF)`.\n\n\n## Payloads\n- `http://127.0.0.1:80` -\u003e `The Port is not open`\n- `http://127.0.0.1:1337` -\u003e `The Port which Strapi is running on`\n\n\n## Steps to Reproduce\n- First of all, let\u0027s input the URL `http://127.0.0.1:80` into the `URL` field, and click \"Save\".\n\n\n![CleanShot 2024-06-04 at 22 45 17@2x](https://github.com/strapi/strapi/assets/71650574/7336b817-cb61-41e6-9b3f-87151d8667e9)\n\n\n- Next, use the \"Trigger\" function and use Burp Suite to capture the request / response\n\n\n![CleanShot 2024-06-04 at 22 47 50@2x](https://github.com/strapi/strapi/assets/71650574/659f1bbe-6b03-456c-a9c2-5187fca20dd6)\n\n\n- The server return `request to http://127.0.0.1/ failed, reason: connect ECONNREFUSED 127.0.0.1:80`, BECAUSE the `Port 80` is not open, since we are running Strapi on `Port 1337`, let\u0027s change the URL we input above into `http://127.0.0.1:1337`\n\n\n![CleanShot 2024-06-04 at 22 50 13@2x](https://github.com/strapi/strapi/assets/71650574/a7916c86-1923-49ed-bd43-a70fa00d41e9)\n\n\n- Continue to click the \"Trigger\" function, use Burp to capture the request / response\n\n\n![CleanShot 2024-06-04 at 22 53 25@2x](https://github.com/strapi/strapi/assets/71650574/6fc51bb7-5a66-4b2b-b24f-2eba45ba1db9)\n\n\n- The server returns `Method Not Allowed`, which means that there actually is a `Port 1337` running the machine.\n\n\n## PoC\nHere is the Poc Video, please check: \n\nhttps://drive.google.com/file/d/1EvVp9lMpYnGLmUyr16gQ_2RetI-GqYjV/view?usp=sharing\n\n## Impact\n\n- If there is a real server running Strapi with many ports open, by using this SSRF vulnerability, the attacker can brute-force through all 65535 ports to know what ports are open.",
  "id": "GHSA-v8wj-f5c7-pvxf",
  "modified": "2025-05-29T21:03:02Z",
  "published": "2025-05-27T17:59:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/strapi/strapi/security/advisories/GHSA-v8wj-f5c7-pvxf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52588"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/strapi/strapi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Strapi allows Server-Side Request Forgery in Webhook function"
}

GHSA-V93X-3HQQ-X949

Vulnerability from github – Published: 2025-09-15 06:30 – Updated: 2025-09-15 06:30
VLAI
Details

O'View MapServer developed by PilotGaea Technologies has a Server-Side Request Forgery vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to probe internal network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-10453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-15T06:15:36Z",
    "severity": "MODERATE"
  },
  "details": "O\u0027View MapServer developed by PilotGaea Technologies has a Server-Side Request Forgery vulnerability, allowing unauthenticated remote attackers to exploit this vulnerability to probe internal network.",
  "id": "GHSA-v93x-3hqq-x949",
  "modified": "2025-09-15T06:30:27Z",
  "published": "2025-09-15T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10453"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/en/cp-139-10382-781cc-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-10381-4d482-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/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:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-V9M3-WFH8-5646

Vulnerability from github – Published: 2026-09-22 20:36 – Updated: 2026-09-22 20:36
VLAI
Summary
MCP Atlassian: Incomplete fix for GHSA-7r34-79r5-rcc9: redirect-based SSRF via unhooked requests session in Jira user-permission lookup
Details

Summary

The fix for the SSRF vulnerability tracked as GHSA-7r34-79r5-rcc9 / CVE-2026-27826 is incomplete. That fix added two defenses: validate_url_for_ssrf() on the per-request X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers (blocking a directly-internal base URL), and a redirect-validation hook (_make_ssrf_safe_hook) attached to the fetcher's HTTP session so that an attacker-controlled public host cannot redirect outbound requests to an internal address.

However, one outbound request path does not go through the hooked session. JiraUserMixin._lookup_user_by_permissions issues its request with the module-level requests.get instead of self.jira._session.get, so the redirect-validation hook never runs for it. An unauthenticated attacker (in the HTTP / multi-tenant transport mode that binds 0.0.0.0 with no credentials) can therefore set a public base URL that passes validate_url_for_ssrf(), then have their own server return an HTTP redirect to an internal address. The bare requests.get follows that redirect with no validation, resulting in a blind server-side request to an arbitrary internal host and port.

Affected component

src/mcp_atlassian/jira/users.py, method _lookup_user_by_permissions (the requests.get(...) call):

url = f"{self.config.url}/rest/api/2/user/permission/search"
params = {"query": username, "permissions": "BROWSE"}
...
response = requests.get(           # module-level requests, NOT self.jira._session
    url,
    params=params,
    auth=auth,
    headers=headers,
    verify=self.config.ssl_verify,
)

For comparison, the equivalent non-standard-endpoint call in src/mcp_atlassian/jira/development.py correctly uses the hooked session (self.jira._session.get(...)), and the SSRF redirect hook is attached only to that session in src/mcp_atlassian/servers/dependencies.py (get_session=lambda f: f.jira._session). The bare requests.get in users.py is the one outbound path the hook does not cover.

Details — why the existing defenses do not apply here

  1. self.config.url is attacker-controlled in the header-PAT branch of _get_fetcher (dependencies.py): header_config = spec.config_class(url=url_header_val, auth_type="pat", personal_token=token_header_val, ...).
  2. The middleware validates that header URL with validate_url_for_ssrf() before storing it, so it must resolve to a public address. The attacker simply points it at a public server they control — this passes validation.
  3. Credential validation (_create_and_validate → spec.validate_fn) runs against that same attacker-controlled server, so it returns success and no real Atlassian credentials are required.
  4. The redirect-validation hook is attached to f.jira._session. _lookup_user_by_permissions does not use that session — it uses bare requests.get, which follows redirects (allow_redirects=True by default) with no SSRF check.

Proof of Concept

Preconditions: the server is running in HTTP transport (streamable-http or sse) multi-tenant mode, as described in the GHSA-7r34-79r5-rcc9 advisory (binds 0.0.0.0, per-request header auth, no server-side credentials).

  1. Attacker stands up a public HTTP server http://attacker.example that:
  2. responds to GET /rest/api/2/user/search (and the atlassian client's user-find call) with 200 [] — an empty user list, forcing the direct-lookup fallthrough;
  3. responds to GET /rest/api/2/user/permission/search with 302 Location: http://169.254.169.254/latest/meta-data/ (or any internal host:port).
  4. Attacker sends a tool call to the MCP HTTP endpoint with headers:
  5. X-Atlassian-Jira-Url: http://attacker.example
  6. X-Atlassian-Jira-Personal-Token: anything and invokes a tool that resolves an assignee — e.g. jira_create_issue / jira_update_issue with assignee set to a value that the direct lookup cannot match.
  7. Flow: _get_account_id → _lookup_user_directly returns None (attacker returned []) → _lookup_user_by_permissions → requests.get("http://attacker.example/rest/api/2/user/permission/search?...") → attacker server returns 302 → bare requests follows the redirect to http://169.254.169.254/....

The server makes an outbound GET to the internal target, confirming SSRF.

Impact

Blind, unauthenticated server-side request forgery from the mcp-atlassian host. An attacker who can reach the HTTP transport endpoint can cause the server to issue GET requests to arbitrary internal hosts and ports (internal service reachability and port discovery, triggering of internal GET-actuated endpoints, reachability of cloud metadata endpoints). The response body is not reflected to the attacker except in the narrow case where an internal service returns a JSON object shaped like {"users": [...]}, so this is primarily a blind SSRF: weaker than the original CVE-2026-27826 (no general internal data exfiltration), but the redirect-based internal-reachability that GHSA-7r34-79r5-rcc9 intended to close remains exploitable through this code path in the latest release (v0.21.1).

Suggested Remediation

Route the request through the hooked session instead of the module-level requests, mirroring development.py:

response = self.jira._session.get(
    url,
    params=params,
    verify=self.config.ssl_verify,
)

(The session already carries the appropriate authentication, so the manual auth / Authorization handling can be dropped.) More generally, auditing for any remaining bare requests. / httpx. calls that use self.config.url and routing them through the SSRF-hooked session would prevent recurrence.

Coordinated Disclosure

This appears to be an incomplete fix for GHSA-7r34-79r5-rcc9 (CVE-2026-27826). If you agree, I would kindly ask you to consider requesting a CVE ID for this residual instance through this repository's Security Advisory "Request CVE ID" workflow once confirmed, so that downstream users and distributions can track the additional fix. The severity here is lower than the parent advisory — it is a blind, redirect-only SSRF gated on the HTTP multi-tenant deployment mode — so a Medium rating seems appropriate, and I defer to your judgment on the final score. Thank you very much for your time and for your work on this project.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:36:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Summary\n\nThe fix for the SSRF vulnerability tracked as GHSA-7r34-79r5-rcc9 / CVE-2026-27826 is incomplete. That fix added two defenses: validate_url_for_ssrf() on the per-request X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers (blocking a directly-internal base URL), and a redirect-validation hook (_make_ssrf_safe_hook) attached to the fetcher\u0027s HTTP session so that an attacker-controlled public host cannot redirect outbound requests to an internal address.\n\nHowever, one outbound request path does not go through the hooked session. JiraUserMixin._lookup_user_by_permissions issues its request with the module-level requests.get instead of self.jira._session.get, so the redirect-validation hook never runs for it. An unauthenticated attacker (in the HTTP / multi-tenant transport mode that binds 0.0.0.0 with no credentials) can therefore set a public base URL that passes validate_url_for_ssrf(), then have their own server return an HTTP redirect to an internal address. The bare requests.get follows that redirect with no validation, resulting in a blind server-side request to an arbitrary internal host and port.\n\nAffected component\n\nsrc/mcp_atlassian/jira/users.py, method _lookup_user_by_permissions (the requests.get(...) call):\n\n    url = f\"{self.config.url}/rest/api/2/user/permission/search\"\n    params = {\"query\": username, \"permissions\": \"BROWSE\"}\n    ...\n    response = requests.get(           # module-level requests, NOT self.jira._session\n        url,\n        params=params,\n        auth=auth,\n        headers=headers,\n        verify=self.config.ssl_verify,\n    )\n\nFor comparison, the equivalent non-standard-endpoint call in src/mcp_atlassian/jira/development.py correctly uses the hooked session (self.jira._session.get(...)), and the SSRF redirect hook is attached only to that session in src/mcp_atlassian/servers/dependencies.py (get_session=lambda f: f.jira._session). The bare requests.get in users.py is the one outbound path the hook does not cover.\n\nDetails \u2014 why the existing defenses do not apply here\n\n1. self.config.url is attacker-controlled in the header-PAT branch of _get_fetcher (dependencies.py): header_config = spec.config_class(url=url_header_val, auth_type=\"pat\", personal_token=token_header_val, ...).\n2. The middleware validates that header URL with validate_url_for_ssrf() before storing it, so it must resolve to a public address. The attacker simply points it at a public server they control \u2014 this passes validation.\n3. Credential validation (_create_and_validate \u2192 spec.validate_fn) runs against that same attacker-controlled server, so it returns success and no real Atlassian credentials are required.\n4. The redirect-validation hook is attached to f.jira._session. _lookup_user_by_permissions does not use that session \u2014 it uses bare requests.get, which follows redirects (allow_redirects=True by default) with no SSRF check.\n\nProof of Concept\n\nPreconditions: the server is running in HTTP transport (streamable-http or sse) multi-tenant mode, as described in the GHSA-7r34-79r5-rcc9 advisory (binds 0.0.0.0, per-request header auth, no server-side credentials).\n\n1. Attacker stands up a public HTTP server http://attacker.example that:\n   - responds to GET /rest/api/2/user/search (and the atlassian client\u0027s user-find call) with 200 [] \u2014 an empty user list, forcing the direct-lookup fallthrough;\n   - responds to GET /rest/api/2/user/permission/search with 302 Location: http://169.254.169.254/latest/meta-data/ (or any internal host:port).\n2. Attacker sends a tool call to the MCP HTTP endpoint with headers:\n   - X-Atlassian-Jira-Url: http://attacker.example\n   - X-Atlassian-Jira-Personal-Token: anything\n     and invokes a tool that resolves an assignee \u2014 e.g. jira_create_issue / jira_update_issue with assignee set to a value that the direct lookup cannot match.\n3. Flow: _get_account_id \u2192 _lookup_user_directly returns None (attacker returned []) \u2192 _lookup_user_by_permissions \u2192 requests.get(\"http://attacker.example/rest/api/2/user/permission/search?...\") \u2192 attacker server returns 302 \u2192 bare requests follows the redirect to http://169.254.169.254/....\n\nThe server makes an outbound GET to the internal target, confirming SSRF.\n\nImpact\n\nBlind, unauthenticated server-side request forgery from the mcp-atlassian host. An attacker who can reach the HTTP transport endpoint can cause the server to issue GET requests to arbitrary internal hosts and ports (internal service reachability and port discovery, triggering of internal GET-actuated endpoints, reachability of cloud metadata endpoints). The response body is not reflected to the attacker except in the narrow case where an internal service returns a JSON object shaped like {\"users\": [...]}, so this is primarily a blind SSRF: weaker than the original CVE-2026-27826 (no general internal data exfiltration), but the redirect-based internal-reachability that GHSA-7r34-79r5-rcc9 intended to close remains exploitable through this code path in the latest release (v0.21.1).\n\nSuggested Remediation\n\nRoute the request through the hooked session instead of the module-level requests, mirroring development.py:\n\n    response = self.jira._session.get(\n        url,\n        params=params,\n        verify=self.config.ssl_verify,\n    )\n\n(The session already carries the appropriate authentication, so the manual auth / Authorization handling can be dropped.) More generally, auditing for any remaining bare requests.* / httpx.* calls that use self.config.url and routing them through the SSRF-hooked session would prevent recurrence.\n\nCoordinated Disclosure\n\nThis appears to be an incomplete fix for GHSA-7r34-79r5-rcc9 (CVE-2026-27826). If you agree, I would kindly ask you to consider requesting a CVE ID for this residual instance through this repository\u0027s Security Advisory \"Request CVE ID\" workflow once confirmed, so that downstream users and distributions can track the additional fix. The severity here is lower than the parent advisory \u2014 it is a blind, redirect-only SSRF gated on the HTTP multi-tenant deployment mode \u2014 so a Medium rating seems appropriate, and I defer to your judgment on the final score. Thank you very much for your time and for your work on this project.",
  "id": "GHSA-v9m3-wfh8-5646",
  "modified": "2026-09-22T20:36:31Z",
  "published": "2026-09-22T20:36:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-v9m3-wfh8-5646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Atlassian:  Incomplete fix for GHSA-7r34-79r5-rcc9: redirect-based SSRF via unhooked requests session in Jira user-permission lookup"
}

GHSA-V9MP-J8G7-2Q6M

Vulnerability from github – Published: 2023-01-30 06:30 – Updated: 2024-05-20 21:44
VLAI
Summary
Paranoidhttp Server-Side Request Forgery vulnerability
Details

Paranoidhttp before 0.3.0 allows SSRF because [::] is equivalent to the 127.0.0.1 address, but does not match the filter for private addresses.

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": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hakobe/paranoidhttp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-24623"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-08T21:51:47Z",
    "nvd_published_at": "2023-01-30T05:15:00Z",
    "severity": "HIGH"
  },
  "details": "Paranoidhttp before 0.3.0 allows SSRF because [::] is equivalent to the 127.0.0.1 address, but does not match the filter for private addresses.",
  "id": "GHSA-v9mp-j8g7-2q6m",
  "modified": "2024-05-20T21:44:34Z",
  "published": "2023-01-30T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24623"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hakobe/paranoidhttp/commit/07f671da14ce63a80f4e52432b32e8d178d75fd3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hakobe/paranoidhttp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hakobe/paranoidhttp/blob/master/CHANGELOG.md#v030-2023-01-19"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hakobe/paranoidhttp/compare/v0.2.0...v0.3.0"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2023-1526"
    }
  ],
  "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"
    }
  ],
  "summary": "Paranoidhttp Server-Side Request Forgery vulnerability"
}

GHSA-V9QG-8JQW-Q8XG

Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2022-05-13 01:15
VLAI
Details

Server Side Request Forgery vulnerability in Vebto Pixie Image Editor 1.4 and 1.7 allows remote attackers to disclose information or execute arbitrary code via the url parameter to Launderer.php.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-12905"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-25T17:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Server Side Request Forgery vulnerability in Vebto Pixie Image Editor 1.4 and 1.7 allows remote attackers to disclose information or execute arbitrary code via the url parameter to Launderer.php.",
  "id": "GHSA-v9qg-8jqw-q8xg",
  "modified": "2022-05-13T01:15:01Z",
  "published": "2022-05-13T01:15:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12905"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2017/Sep/47"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9R3-MCXC-M58R

Vulnerability from github – Published: 2025-09-13 00:30 – Updated: 2025-09-13 00:30
VLAI
Details

A vulnerability was detected in cdevroe unmark up to 1.9.3. This affects an unknown part of the file /application/controllers/Marks.php. The manipulation of the argument url results in server-side request forgery. The attack may be launched remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-10329"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-12T22:15:33Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was detected in cdevroe unmark up to 1.9.3. This affects an unknown part of the file /application/controllers/Marks.php. The manipulation of the argument url results in server-side request forgery. The attack may be launched remotely. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-v9r3-mcxc-m58r",
  "modified": "2025-09-13T00:30:34Z",
  "published": "2025-09-13T00:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10329"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YZS17/CVE/blob/main/unmark/ssrf1.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YZS17/CVE/blob/main/unmark/ssrf1.md#poc"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.323755"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.323755"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.643531"
    }
  ],
  "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"
    }
  ]
}

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