Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

5475 vulnerabilities reference this CWE, most recent first.

GHSA-XJWM-593F-HR6X

Vulnerability from github – Published: 2024-11-08 18:30 – Updated: 2024-11-08 21:33
VLAI
Details

Northern.tech Hosted Mender before 2024.07.11 allows SSRF.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-47190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-08T16:15:24Z",
    "severity": "LOW"
  },
  "details": "Northern.tech Hosted Mender before 2024.07.11 allows SSRF.",
  "id": "GHSA-xjwm-593f-hr6x",
  "modified": "2024-11-08T21:33:57Z",
  "published": "2024-11-08T18:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47190"
    },
    {
      "type": "WEB",
      "url": "https://mender.io/blog/cve-2024-46947-cve-2024-47190-ssrf-issues-in-mender-enterprise-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XM2P-HXQ8-XJ3Q

Vulnerability from github – Published: 2024-03-05 18:31 – Updated: 2025-03-20 06:31
VLAI
Details

A Server-Side Request Forgery (SSRF) in pictureproxy.php of ChatGPT commit f9f4bbc allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the urlparameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-27564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-05T17:15:06Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Request Forgery (SSRF) in pictureproxy.php of ChatGPT commit f9f4bbc allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the urlparameter.",
  "id": "GHSA-xm2p-hxq8-xj3q",
  "modified": "2025-03-20T06:31:08Z",
  "published": "2024-03-05T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27564"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dirk1983/chatgpt/issues/114"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/save/https://github.com/dirk1983/chatgpt/blob/f9f4bbc99eed7210b291ec116bd57b3d8276bee5/README.md"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/save/https://github.com/dirk1983/chatgpt/issues/114"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20250320031248/https://mm1.ltd"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20250320032559/https://github.com/dirk1983/chatgpt/blob/f9f4bbc99eed7210b291ec116bd57b3d8276bee5/pictureproxy.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XM3X-9CFW-JHX4

Vulnerability from github – Published: 2026-06-19 14:17 – Updated: 2026-06-19 14:17
VLAI
Summary
NL Portal Backend Libraries: Unauthenticated form resolver forwards the privileged Objecten-API token to a caller-supplied URL (SSRF)
Details

Summary

The public GraphQL resolvers getFormDefinitionByObjectenApiUrl(url) and the deprecated getFormDefinitionById(id) fetch a caller-supplied URL using the privileged Objecten-API token. Because the /graphql endpoint is permitAll() and these resolvers do not declare a CommonGroundAuthentication parameter, an unauthenticated caller can make the backend issue an outbound request carrying Authorization: Token <objecten-api-token> to a caller-influenced URL on the configured Objecten-API host. This is a constrained (same-host) server-side request forgery combined with missing authorization.

Reported responsibly and confirmed in a local lab build against the project's own WebFlux security stack. No production system was accessed.

Affected

  • nl.nl-portal:form (the public resolver / entry point) together with nl.nl-portal:objectenapi (where the host guard lives).
  • First shipped in 1.1.0.RELEASE (2023-10-31); the vulnerable code was introduced on 2023-08-12 (commit b2f87ca) and is present in every release since (1.1.x, 1.2.5, 1.3.0, the 3.0.x line, and 3.1.0 / next-minor, HEAD 45abcd2). Fixed in 3.0.4.RELEASE (see Fix below).

Data flow (confirmed in source)

  1. form/.../graphql/FormDefinitionQuery.kt — @QueryMapping getFormDefinitionByObjectenApiUrl(@Argument url), no CommonGroundAuthentication parameter (same for getFormDefinitionById).
  2. → form/.../service/ObjectsApiFormDefinitionService.kt — passes the URL through unvalidated.
  3. → zgw/objectenapi/.../service/ObjectenApiService.kt getObjectByUrl(url) — the only guard is host equality (URI.create(url).host == objectsApiClientConfig.url.host); no scheme/port/path check.
  4. → zgw/objectenapi/.../client/ObjectsApiClient.kt getObjectByUrl(url) via webClientWithoutBaseUrl(), which attaches the default header Authorization: Token <token> to the fully caller-supplied URL.

Reachability: /graphql is permitAll() (core/.../security/OauthSecurityAutoConfiguration.kt). Authentication is only enforced on resolvers that declare a CommonGroundAuthentication parameter; these do not, and there is no @PreAuthorize/instrumentation safety net. The project's own GraphQLEndpointAuthorizationIT lists getFormDefinitionByObjectenApiUrl as an intentionally public operation — so the unauthenticated reachability is by design; the defect is that an intentionally-public resolver forwards a privileged token to a caller-influenced URL.

Secondary (defense-in-depth): zgw/zaken-api/.../service/ZakenApiService.kt getZaakDetails calls objectsApiClient.getObjectByUrl directly, bypassing the service-level host guard. It is currently only reachable via the authenticated ZaakQuery.zaakdetails field resolver with server-derived URLs, so it is not an unauthenticated vector today — but it shows why the guard belongs in the client.

Proof of concept (lab, against the real WebFlux stack)

  • An unauthenticated POST /graphql calling getFormDefinitionByObjectenApiUrl(url: ...) executes without authentication.
  • With the configured Objecten-API host pointed at a mock server, an outbound request to a caller-chosen port/path on that host carried Authorization: Token <configured-token> — confirming the token is attached to caller-influenced URLs.

Impact and severity — important limitations

Assessed as Medium because two code-level facts constrain practical impact:

  1. No cross-host SSRF / token exfiltration in standard deployments. The token only travels to the configured Objecten-API host. Exfiltration requires an attacker-controlled listener at that host (a different port/path routing elsewhere) — generally not the case in managed deployments. A range of URL-parser bypass payloads was tested (userinfo @, %2f/%00/%09, backslash, #/?, double-host, trailing-dot, IDN/Unicode full-stop, fraction-slash, IPv6); no parser differential was found between the java.net.URI-based guard and the Spring/Netty URI builder used by WebClient — every payload either kept the request on the configured host or was rejected (fail-closed). The lab token-leak PoC works only because the configured host there is localhost; this does not generalize to production.

  2. Arbitrary PII object read is blocked by typed deserialization. The response is deserialized into ObjectsApiObject<ObjectsApiFormIoFormDefinition>, whose envelope fields and data.formDefinition are all non-nullable Kotlin properties (Jackson KotlinModule registered). An object without a top-level data.formDefinition (e.g. taken/berichten/zaakdetails) fails to deserialize (DecodingException) and returns no data. The resolver can therefore only return objects shaped like a form definition — and form definitions are intentionally public (loaded pre-login).

Escalation conditions that would raise severity toward High: - the Objecten-API host shares infrastructure with an attacker-controllable endpoint (other port/path), enabling capture of the privileged token; or - a URL-parser differential is later found that escapes the host guard.

Remediation

  • Move the host validation out of ObjectenApiService.getObjectByUrl and into ObjectsApiClient.getObjectByUrl so the direct caller ZakenApiService.getZaakDetails is covered too, and tighten it from host-only to scheme + host + port + path-prefix. Preferably, do not accept a full URL at all: validate/extract the object UUID and rebuild the URL from the fixed configured base (reuse the existing ObjectsApiClient.getObjectById pattern, /api/v2/objects/{uuid}).
  • Separately decide whether getFormDefinitionByObjectenApiUrl / getFormDefinitionById should remain unauthenticated. They are currently intentionally public (forms load before login); for a stricter posture, add a CommonGroundAuthentication parameter as in the other resolvers — noting this breaks pre-login form loading.

Credit

Reported responsibly by Ray Sabee (https://whitehatsecurity.nl), independent security researcher — GitHub @raysabee.

Fix

Fixed in 3.0.4.RELEASE (commit 39ad80f, PR #700, "rework form module"): - The unauthenticated resolvers getFormDefinitionByObjectenApiUrl and the deprecated getFormDefinitionById were removed from both FormDefinitionQuery and the GraphQL schema. - getFormDefinitionByName now requires a CommonGroundAuthentication parameter (no longer public). - The URL-based service method findObjectsApiFormDefinitionByUrl(url) was removed and replaced by getObjectsApiFormDefinitionById(objectId: UUID), which fetches by UUID via the fixed /api/v2/objects/{uuid} path (no caller-supplied URL, so no SSRF) and validates the object type against the configured form-definition object type. - Form definitions are now retrieved through the new authenticated query getFormDefinitionByTaskId(taskId) in nl.nl-portal:taak, which authorizes the caller against the task (CommonGroundAuthentication, BSN/KVK match, else 401) and derives the form-definition UUID from the task's own server-side data, not from caller input. - No resolver feeds caller-controlled input into ObjectenApiService.getObjectByUrl anymore. The objectenapi module itself was not changed; the fix lives entirely in nl.nl-portal:form and the new nl.nl-portal:taak query.

Upgrade instructions

  • Backend: upgrade nl.nl-portal:* to 3.0.4 (or later).
  • Frontend: upgrade nl-portal-frontend-libraries to v3.0.3 (or later). This is required: the removed GraphQL queries (getFormDefinitionByObjectenApiUrl, getFormDefinitionById) and the now-authenticated getFormDefinitionByName are a breaking change. Frontend v3.0.3 uses the new authenticated getFormDefinitionByTaskId / getFormDefinitionByName queries.
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "nl.nl-portal:form"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "3.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55414"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T14:17:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe public GraphQL resolvers `getFormDefinitionByObjectenApiUrl(url)` and the deprecated `getFormDefinitionById(id)` fetch a caller-supplied URL using the **privileged Objecten-API token**. Because the `/graphql` endpoint is `permitAll()` and these resolvers do not declare a `CommonGroundAuthentication` parameter, an **unauthenticated** caller can make the backend issue an outbound request carrying `Authorization: Token \u003cobjecten-api-token\u003e` to a **caller-influenced URL on the configured Objecten-API host**. This is a constrained (same-host) server-side request forgery combined with missing authorization.\n\nReported responsibly and confirmed in a local lab build against the project\u0027s own WebFlux security stack. No production system was accessed.\n\n## Affected\n\n- `nl.nl-portal:form` (the public resolver / entry point) together with `nl.nl-portal:objectenapi` (where the host guard lives).\n- First shipped in **1.1.0.RELEASE** (2023-10-31); the vulnerable code was introduced on 2023-08-12 (commit `b2f87ca`) and is present in every release since (1.1.x, 1.2.5, 1.3.0, the 3.0.x line, and 3.1.0 / `next-minor`, HEAD `45abcd2`). Fixed in 3.0.4.RELEASE (see Fix below).\n\n## Data flow (confirmed in source)\n\n1. `form/.../graphql/FormDefinitionQuery.kt` \u2014 `@QueryMapping getFormDefinitionByObjectenApiUrl(@Argument url)`, **no** `CommonGroundAuthentication` parameter (same for `getFormDefinitionById`).\n2. \u2192 `form/.../service/ObjectsApiFormDefinitionService.kt` \u2014 passes the URL through unvalidated.\n3. \u2192 `zgw/objectenapi/.../service/ObjectenApiService.kt` `getObjectByUrl(url)` \u2014 the only guard is host equality (`URI.create(url).host == objectsApiClientConfig.url.host`); **no scheme/port/path check**.\n4. \u2192 `zgw/objectenapi/.../client/ObjectsApiClient.kt` `getObjectByUrl(url)` via `webClientWithoutBaseUrl()`, which attaches the default header `Authorization: Token \u003ctoken\u003e` to the fully caller-supplied URL.\n\n**Reachability:** `/graphql` is `permitAll()` (`core/.../security/OauthSecurityAutoConfiguration.kt`). Authentication is only enforced on resolvers that declare a `CommonGroundAuthentication` parameter; these do not, and there is no `@PreAuthorize`/instrumentation safety net. The project\u0027s own `GraphQLEndpointAuthorizationIT` lists `getFormDefinitionByObjectenApiUrl` as an intentionally public operation \u2014 so the unauthenticated reachability is by design; the defect is that an intentionally-public resolver forwards a privileged token to a caller-influenced URL.\n\n**Secondary (defense-in-depth):** `zgw/zaken-api/.../service/ZakenApiService.kt` `getZaakDetails` calls `objectsApiClient.getObjectByUrl` **directly**, bypassing the service-level host guard. It is currently only reachable via the authenticated `ZaakQuery.zaakdetails` field resolver with server-derived URLs, so it is not an unauthenticated vector today \u2014 but it shows why the guard belongs in the client.\n\n## Proof of concept (lab, against the real WebFlux stack)\n\n- An unauthenticated `POST /graphql` calling `getFormDefinitionByObjectenApiUrl(url: ...)` executes without authentication.\n- With the configured Objecten-API host pointed at a mock server, an outbound request to a **caller-chosen port/path on that host** carried `Authorization: Token \u003cconfigured-token\u003e` \u2014 confirming the token is attached to caller-influenced URLs.\n\n## Impact and severity \u2014 important limitations\n\nAssessed as **Medium** because two code-level facts constrain practical impact:\n\n1. **No cross-host SSRF / token exfiltration in standard deployments.** The token only travels to the *configured* Objecten-API host. Exfiltration requires an attacker-controlled listener at that host (a different port/path routing elsewhere) \u2014 generally not the case in managed deployments. A range of URL-parser bypass payloads was tested (userinfo `@`, `%2f`/`%00`/`%09`, backslash, `#`/`?`, double-host, trailing-dot, IDN/Unicode full-stop, fraction-slash, IPv6); **no parser differential** was found between the `java.net.URI`-based guard and the Spring/Netty URI builder used by WebClient \u2014 every payload either kept the request on the configured host or was rejected (fail-closed). The lab token-leak PoC works only because the configured host there is `localhost`; this does not generalize to production.\n\n2. **Arbitrary PII object read is blocked by typed deserialization.** The response is deserialized into `ObjectsApiObject\u003cObjectsApiFormIoFormDefinition\u003e`, whose envelope fields and `data.formDefinition` are all non-nullable Kotlin properties (Jackson `KotlinModule` registered). An object without a top-level `data.formDefinition` (e.g. taken/berichten/zaakdetails) fails to deserialize (`DecodingException`) and returns no data. The resolver can therefore only return objects shaped like a form definition \u2014 and form definitions are intentionally public (loaded pre-login).\n\n**Escalation conditions** that would raise severity toward High:\n- the Objecten-API host shares infrastructure with an attacker-controllable endpoint (other port/path), enabling capture of the privileged token; or\n- a URL-parser differential is later found that escapes the host guard.\n\n## Remediation\n\n- Move the host validation out of `ObjectenApiService.getObjectByUrl` and into `ObjectsApiClient.getObjectByUrl` so the direct caller `ZakenApiService.getZaakDetails` is covered too, and tighten it from host-only to **scheme + host + port + path-prefix**. Preferably, do not accept a full URL at all: validate/extract the object UUID and rebuild the URL from the fixed configured base (reuse the existing `ObjectsApiClient.getObjectById` pattern, `/api/v2/objects/{uuid}`).\n- Separately decide whether `getFormDefinitionByObjectenApiUrl` / `getFormDefinitionById` should remain unauthenticated. They are currently intentionally public (forms load before login); for a stricter posture, add a `CommonGroundAuthentication` parameter as in the other resolvers \u2014 noting this breaks pre-login form loading.\n\n## Credit\n\nReported responsibly by **Ray Sabee** (https://whitehatsecurity.nl), independent security researcher \u2014 GitHub [@raysabee](https://github.com/raysabee).\n\n\n## Fix\n\nFixed in **3.0.4.RELEASE** (commit `39ad80f`, PR #700, \"rework form module\"):\n- The unauthenticated resolvers `getFormDefinitionByObjectenApiUrl` and the deprecated `getFormDefinitionById` were **removed** from both `FormDefinitionQuery` and the GraphQL schema.\n- `getFormDefinitionByName` now requires a `CommonGroundAuthentication` parameter (no longer public).\n- The URL-based service method `findObjectsApiFormDefinitionByUrl(url)` was removed and replaced by `getObjectsApiFormDefinitionById(objectId: UUID)`, which fetches by UUID via the fixed `/api/v2/objects/{uuid}` path (no caller-supplied URL, so no SSRF) and validates the object type against the configured form-definition object type.\n- Form definitions are now retrieved through the new authenticated query `getFormDefinitionByTaskId(taskId)` in `nl.nl-portal:taak`, which authorizes the caller against the task (`CommonGroundAuthentication`, BSN/KVK match, else `401`) and derives the form-definition UUID from the task\u0027s own server-side data, not from caller input.\n- No resolver feeds caller-controlled input into `ObjectenApiService.getObjectByUrl` anymore. The `objectenapi` module itself was not changed; the fix lives entirely in `nl.nl-portal:form` and the new `nl.nl-portal:taak` query.\n\n## Upgrade instructions\n\n- **Backend:** upgrade `nl.nl-portal:*` to **3.0.4** (or later).\n- **Frontend:** upgrade `nl-portal-frontend-libraries` to **v3.0.3** (or later). This is required: the removed GraphQL queries (`getFormDefinitionByObjectenApiUrl`, `getFormDefinitionById`) and the now-authenticated `getFormDefinitionByName` are a breaking change. Frontend v3.0.3 uses the new authenticated `getFormDefinitionByTaskId` / `getFormDefinitionByName` queries.",
  "id": "GHSA-xm3x-9cfw-jhx4",
  "modified": "2026-06-19T14:17:18Z",
  "published": "2026-06-19T14:17:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/security/advisories/GHSA-xm3x-9cfw-jhx4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries/pull/700"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nl-portal/nl-portal-backend-libraries"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NL Portal Backend Libraries: Unauthenticated form resolver forwards the privileged Objecten-API token to a caller-supplied URL (SSRF)"
}

GHSA-XM79-W8W3-C5R7

Vulnerability from github – Published: 2026-05-02 09:31 – Updated: 2026-08-18 00:30
VLAI
Details

The Royal Elementor Addons plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 1.7.1057. This is due to insufficient validation of user-supplied URLs in the render_csv_data() function, which can be bypassed by including 'docs.google.com/spreadsheets' in a query parameter, and the subsequent use of these URLs in fopen() calls without blocking internal or private network addresses. This makes it possible for authenticated attackers, with Contributor-level access and above, to make requests to arbitrary URLs and retrieve sensitive information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-02T08:16:27Z",
    "severity": "HIGH"
  },
  "details": "The Royal Elementor Addons plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 1.7.1057. This is due to insufficient validation of user-supplied URLs in the render_csv_data() function, which can be bypassed by including \u0027docs.google.com/spreadsheets\u0027 in a query parameter, and the subsequent use of these URLs in fopen() calls without blocking internal or private network addresses. This makes it possible for authenticated attackers, with Contributor-level access and above, to make requests to arbitrary URLs and retrieve sensitive information from internal services.",
  "id": "GHSA-xm79-w8w3-c5r7",
  "modified": "2026-08-18T00:30:24Z",
  "published": "2026-05-02T09:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6229"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L1832"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L1873"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L1918"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/tags/1.7.1049/modules/data-table/widgets/wpr-data-table.php#L2075"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L1832"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L1873"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L1918"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/royal-elementor-addons/trunk/modules/data-table/widgets/wpr-data-table.php#L2075"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3514363%40royal-elementor-addons\u0026new=3514363%40royal-elementor-addons\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://research.cleantalk.org/cve-2026-6229"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9744055a-b199-4945-afcc-4f5b85f5f1e8?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-XM7X-F3W2-4HJM

Vulnerability from github – Published: 2023-10-03 21:54 – Updated: 2023-10-03 21:54
VLAI
Summary
Presto JDBC Server-Side Request Forgery by redirect
Details

Summary

Presto JDBC is vulnerable to Server-Side Request Forgery (SSRF) when connecting a remote Presto server. An attacker can construct a redirect response that Presto JDBC client will follow and view sensitive information from highly sensitive internal servers or perform a local port scan.

Details

Presto JDBC client uses OkHttp to send POST /v1/statement and GET /v1/info requests to the remote Presto server. And OkHttp will follow 301 and 302 redirect by default. In addition, JDBC will manually follow 307 and 308 redirect. Therefore, if a malicious server returns a 30x redirect, JDBC client will follow the redirect and cause SSRF.

For unexpected responses, JDBC will put the response body into the error. So the response of the internal server will be leaked if the server also returns the error directly to the user.

The relevant code is in file path /presto-client/src/main/java/com/facebook/presto/client/StatementClientV1.java and function StatementClientV1 .

The flowchart is as follows:

trino_jdbc_ssrf_1.png

PoC

Running an HTTP service to route POST /v1/statement redirect to the intranet. For example, using these Python code:

from flask import Flask, redirect

app = Flask(__name__)

@app.route('/v1/statement', methods=['POST'])
def redirect_to_interal_server():
    return redirect('http://127.0.0.1:8888', code=302)

if __name__ == '__main__':
    app.run(host="0.0.0.0",port=8000)

Connecting to the malicious server using JDBC:

String url = "jdbc:presto://<ip>:<port>";
Properties properties = new Properties();
properties.setProperty("user", "root");
try {
    Connection connection = DriverManager.getConnection(url, properties);
    Statement stmt = connection.createStatement();
    ResultSet res = stmt.executeQuery("show catalogs");
    while(res.next()) {
        System.out.println(res.getString(1));
    }
} catch (Exception e) {
    e.printStackTrace();
}

Pwned!

Impact

When the target remote Presto server to be connected is controllable, an attacker can view sensitive information from highly sensitive internal servers or perform a local port scan.

Others

Regarding the fix suggestions, the redirect issue we can consider directly disable the following redirect. If not, we can add a jdbc parameter such as allowRedirect. Like MySQL JDBC caused arbitrary file reading before, its solution is adding the allowLoadLocalInfile parameters. Disable redirect by default, and there is a need to open. The nextUri issue is similar. If we can only take the path of nextUri instead of the complete URL, join the host and path. If not, add a jdbc parameter too.

I think these two vulnerabilities are worth fixing. There is no effective way to avoid this vulnerability at the server side, and the only way to fix them is modifying the jdbc source code. I think many other vendors also have this issue.

I hope to apply for CVEs and give security thanks in the vulnerability bulletin to prove my work, thank you.

Vulnerability Discovery Credit: Jianyu Li @ WuHeng Lab of ByteDance

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.facebook.presto:presto-jdbc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.283"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-03T21:54:02Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPresto JDBC is vulnerable to Server-Side Request Forgery (SSRF) when connecting a remote Presto server. An attacker can construct a redirect response that Presto JDBC client will follow and view sensitive information from highly sensitive internal servers or perform a local port scan. \n\n### Details\n\nPresto JDBC client uses OkHttp to send `POST /v1/statement` and `GET /v1/info` requests to the remote Presto server. And OkHttp will follow 301 and 302 redirect by default. In addition, JDBC will manually follow 307 and 308 redirect. Therefore, if a malicious server returns a 30x redirect,  JDBC client will follow the redirect and cause SSRF.\n\nFor unexpected responses, JDBC will put the response body into the error. So the response of the internal server will be leaked if the server also returns the error directly to the user.\n\nThe relevant code is in file path `/presto-client/src/main/java/com/facebook/presto/client/StatementClientV1.java` and function `StatementClientV1` .\n\nThe flowchart is as follows:\n\n\u003cimg src=\"https://s2.loli.net/2023/09/18/AhiHNL5neuYIK4X.png\" alt=\"trino_jdbc_ssrf_1.png\" style=\"zoom:50%;\" /\u003e\n\n### PoC\n\nRunning an HTTP service to route POST /v1/statement redirect to the intranet. For example, using these Python code:\n\n```python\nfrom flask import Flask, redirect\n\napp = Flask(__name__)\n\n@app.route(\u0027/v1/statement\u0027, methods=[\u0027POST\u0027])\ndef redirect_to_interal_server():\n    return redirect(\u0027http://127.0.0.1:8888\u0027, code=302)\n\nif __name__ == \u0027__main__\u0027:\n    app.run(host=\"0.0.0.0\",port=8000)\n```\n\nConnecting to the malicious server using JDBC:\n\n```java\nString url = \"jdbc:presto://\u003cip\u003e:\u003cport\u003e\";\nProperties properties = new Properties();\nproperties.setProperty(\"user\", \"root\");\ntry {\n    Connection connection = DriverManager.getConnection(url, properties);\n    Statement stmt = connection.createStatement();\n    ResultSet res = stmt.executeQuery(\"show catalogs\");\n    while(res.next()) {\n        System.out.println(res.getString(1));\n    }\n} catch (Exception e) {\n    e.printStackTrace();\n}\n```\n\nPwned!\n\n### Impact\n\nWhen the target remote Presto server to be connected is controllable,  an attacker can view sensitive information from highly sensitive internal servers or perform a local port scan. \n\n### Others\n\nRegarding the fix suggestions, the redirect issue we can consider directly disable the following redirect. If not, we can add a jdbc parameter such as allowRedirect. Like MySQL JDBC caused arbitrary file reading before, its solution is adding the allowLoadLocalInfile parameters. Disable redirect by default, and there is a need to open. The nextUri issue is similar. If we can only take the path of nextUri instead of the complete URL, join the host and path. If not, add a jdbc parameter too.\n\nI think these two vulnerabilities are worth fixing. There is no effective way to avoid this vulnerability at the server side, and the only way to fix them is modifying the jdbc source code. I think many other vendors also have this issue.\n\nI hope to apply for CVEs and give security thanks in the vulnerability bulletin to prove my work, thank you.\n\nVulnerability Discovery Credit: Jianyu Li @ WuHeng Lab of ByteDance",
  "id": "GHSA-xm7x-f3w2-4hjm",
  "modified": "2023-10-03T21:54:02Z",
  "published": "2023-10-03T21:54:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/prestodb/presto/security/advisories/GHSA-xm7x-f3w2-4hjm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/prestodb/presto"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Presto JDBC Server-Side Request Forgery by redirect"
}

GHSA-XMG6-QG4M-GW97

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

JizhiCMS v2.5.4 was discovered to contain a Server-Side Request Forgery (SSRF) via the component \c\PluginsController.php. This vulnerability allows attackers to perform an intranet scan via a crafted request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-25785"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T15:15:26Z",
    "severity": "CRITICAL"
  },
  "details": "JizhiCMS v2.5.4 was discovered to contain a Server-Side Request Forgery (SSRF) via the component \\c\\PluginsController.php. This vulnerability allows attackers to perform an intranet scan via a crafted request.",
  "id": "GHSA-xmg6-qg4m-gw97",
  "modified": "2025-03-05T15:30:50Z",
  "published": "2025-03-05T15:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25785"
    },
    {
      "type": "WEB",
      "url": "https://www.jizhicms.cn"
    },
    {
      "type": "WEB",
      "url": "http://jizhicms.com"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XMHC-7QJ6-CR9Q

Vulnerability from github – Published: 2026-07-27 15:32 – Updated: 2026-07-27 15:32
VLAI
Details

Unauthenticated Server Side Request Forgery (SSRF) in 3D Flipbook PDF Viewer & Embedder <= 1.4.2 versions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-59552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T15:17:05Z",
    "severity": "HIGH"
  },
  "details": "Unauthenticated Server Side Request Forgery (SSRF) in 3D Flipbook PDF Viewer \u0026amp; Embedder \u003c= 1.4.2 versions.",
  "id": "GHSA-xmhc-7qj6-cr9q",
  "modified": "2026-07-27T15:32:32Z",
  "published": "2026-07-27T15:32:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59552"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/pdf-embed-viewer/vulnerability/wordpress-3d-flipbook-pdf-viewer-embedder-plugin-1-4-2-server-side-request-forgery-ssrf-vulnerability?_s_id=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-XMJ7-XJ85-HFC3

Vulnerability from github – Published: 2026-07-21 20:37 – Updated: 2026-07-21 20:37
VLAI
Summary
Gitea: SSRF in restore-repo via unsanitized pull_request.yml Head.CloneURL
Details

Summary

Gitea's restore-repo CLI command restores a repository from a dump directory/archive. When parsing pull_request.yml from that dump, the Head.CloneURL field is used to add a git remote and fetch from it with no validation, because the safety check that's supposed to guard it (CheckAndEnsureSafePR) is called with an empty commonCloneBaseURL, which silently disables it. This lets a malicious dump make the Gitea server execute git fetch against an attacker-chosen URL (SSRF), or disclose a local git repository via file://. This is a different root cause from the recently fixed path-traversal issue in the same command (#38215), which patched DownloadURL/PatchURL but not Head.CloneURL.

Details

services/migrations/restore.go's GetPullRequests() unmarshals pull_request.yml directly into base.PullRequest structs with no validation of Head.CloneURL:

err = yaml.Unmarshal(bs, &pulls)
...
for _, pr := range pulls {
    if pr.PatchURL != "" {
        pr.PatchURL = "file://" + util.FilePathJoinAbs(r.baseDir, pr.PatchURL)
    }
    CheckAndEnsureSafePR(pr, "", r)   // <-- empty baseURL
}

CheckAndEnsureSafePR (services/migrations/common.go) is supposed to reject Head.CloneURL/PatchURL values that don't share a common base URL:

func hasBaseURL(toCheck, baseURL string) bool {
    if len(baseURL) > 0 && baseURL[len(baseURL)-1] != '/' {
        baseURL += "/"
    }
    return strings.HasPrefix(toCheck, baseURL)
}

func CheckAndEnsureSafePR(pr *base.PullRequest, commonCloneBaseURL string, g base.Downloader) bool {
    valid := true
    if pr.PatchURL != "" && !hasBaseURL(pr.PatchURL, commonCloneBaseURL) {
        pr.PatchURL = ""
        valid = false
    }
    if pr.Head.CloneURL != "" && !hasBaseURL(pr.Head.CloneURL, commonCloneBaseURL) {
        pr.Head.CloneURL = ""
        valid = false
    }
    return valid
}

strings.HasPrefix(anything, "") is always true in Go. Because restore.go is the only caller that passes "" as commonCloneBaseURL, this check is a complete no-op on the restore-repo path — Head.CloneURL survives unchanged regardless of its value. Every other downloader (github.go, gitlab.go, gitea_downloader.go, codebase.go, codecommit.go, onedev.go) passes a real base URL, so they are not affected.

services/migrations/gitea_uploader.go then uses the unvalidated value directly:

err := g.gitRepo.AddRemote(remote, pr.Head.CloneURL, true)
// ... later: fetch from that remote

resulting in the server executing git fetch against an attacker-controlled URL sourced from the dump file.

RCE via git's ext:: transport helper was tested and ruled out — a normal git install rejects it by default (fatal: transport 'ext' not allowed), independent of Gitea's own configuration. This report is scoped to SSRF and local git-repository disclosure.

Confirmed present, byte-for-byte identical, in v1.26.4 (latest stable tag), release/v1.27, and main, by direct checkout and diff.

PoC

  1. Create a dump directory following the normal restore-repo layout (repo.yml, etc.), and add a pull_request.yml containing at least one entry with:
   - number: 1
     head:
       cloneURL: "http://<attacker-controlled-or-internal-host>:<port>/ssrf-proof"
       ref: "main"
  1. Run gitea restore-repo against that dump directory for any repo owner.
  2. Observe on the target host/listener: an actual git HTTP discovery request arrives, e.g. GET /ssrf-proof/info/refs?service=git-upload-pack, driven entirely by the value from the dump file.

Verified the core mechanism (steps 2–3, i.e. the unvalidated Head.CloneURL surviving CheckAndEnsureSafePR("") and then being used in a real git remote add + git fetch) with a minimal, standalone Go program built from the verbatim, unmodified hasBaseURL / CheckAndEnsureSafePR function bodies (attached: gitea_ssrf_poc.go), run end-to-end against a local HTTP listener. The listener's access log confirms the request actually arrives.

Impact

An attacker who can get an administrator to run gitea restore-repo against a malicious dump (the same threat model already accepted for the just-fixed path-traversal issue in this command, #38215) can make the Gitea server issue a git fetch against an arbitrary attacker-chosen URL. This allows: - SSRF against internal-only services or cloud metadata endpoints reachable from the Gitea host. - Disclosure of local git repositories reachable via file:// paths readable by the Gitea process.

No public disclosure planned. Happy to provide further detail on request.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-58441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:37:29Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nGitea\u0027s `restore-repo` CLI command restores a repository from a dump\ndirectory/archive. When parsing `pull_request.yml` from that dump, the\n`Head.CloneURL` field is used to add a git remote and fetch from it with\nno validation, because the safety check that\u0027s supposed to guard it\n(`CheckAndEnsureSafePR`) is called with an empty `commonCloneBaseURL`,\nwhich silently disables it. This lets a malicious dump make the Gitea\nserver execute `git fetch` against an attacker-chosen URL (SSRF), or\ndisclose a local git repository via `file://`. This is a different root\ncause from the recently fixed path-traversal issue in the same command\n(#38215), which patched `DownloadURL`/`PatchURL` but not `Head.CloneURL`.\n\n### Details\n`services/migrations/restore.go`\u0027s `GetPullRequests()` unmarshals\n`pull_request.yml` directly into `base.PullRequest` structs with no\nvalidation of `Head.CloneURL`:\n\n```go\nerr = yaml.Unmarshal(bs, \u0026pulls)\n...\nfor _, pr := range pulls {\n    if pr.PatchURL != \"\" {\n        pr.PatchURL = \"file://\" + util.FilePathJoinAbs(r.baseDir, pr.PatchURL)\n    }\n    CheckAndEnsureSafePR(pr, \"\", r)   // \u003c-- empty baseURL\n}\n```\n\n`CheckAndEnsureSafePR` (`services/migrations/common.go`) is supposed to\nreject `Head.CloneURL`/`PatchURL` values that don\u0027t share a common base\nURL:\n\n```go\nfunc hasBaseURL(toCheck, baseURL string) bool {\n    if len(baseURL) \u003e 0 \u0026\u0026 baseURL[len(baseURL)-1] != \u0027/\u0027 {\n        baseURL += \"/\"\n    }\n    return strings.HasPrefix(toCheck, baseURL)\n}\n\nfunc CheckAndEnsureSafePR(pr *base.PullRequest, commonCloneBaseURL string, g base.Downloader) bool {\n    valid := true\n    if pr.PatchURL != \"\" \u0026\u0026 !hasBaseURL(pr.PatchURL, commonCloneBaseURL) {\n        pr.PatchURL = \"\"\n        valid = false\n    }\n    if pr.Head.CloneURL != \"\" \u0026\u0026 !hasBaseURL(pr.Head.CloneURL, commonCloneBaseURL) {\n        pr.Head.CloneURL = \"\"\n        valid = false\n    }\n    return valid\n}\n```\n\n`strings.HasPrefix(anything, \"\")` is always `true` in Go. Because\n`restore.go` is the only caller that passes `\"\"` as\n`commonCloneBaseURL`, this check is a complete no-op on the restore-repo\npath \u2014 `Head.CloneURL` survives unchanged regardless of its value. Every\nother downloader (`github.go`, `gitlab.go`, `gitea_downloader.go`,\n`codebase.go`, `codecommit.go`, `onedev.go`) passes a real base URL, so\nthey are not affected.\n\n`services/migrations/gitea_uploader.go` then uses the unvalidated value\ndirectly:\n\n```go\nerr := g.gitRepo.AddRemote(remote, pr.Head.CloneURL, true)\n// ... later: fetch from that remote\n```\n\nresulting in the server executing `git fetch` against an\nattacker-controlled URL sourced from the dump file.\n\n**RCE via git\u0027s `ext::` transport helper was tested and ruled out** \u2014 a\nnormal `git` install rejects it by default (`fatal: transport \u0027ext\u0027 not\nallowed`), independent of Gitea\u0027s own configuration. This report is\nscoped to SSRF and local git-repository disclosure.\n\nConfirmed present, byte-for-byte identical, in `v1.26.4` (latest stable\ntag), `release/v1.27`, and `main`, by direct checkout and diff.\n\n### PoC\n1. Create a dump directory following the normal `restore-repo` layout\n   (`repo.yml`, etc.), and add a `pull_request.yml` containing at least\n   one entry with:\n```yaml\n   - number: 1\n     head:\n       cloneURL: \"http://\u003cattacker-controlled-or-internal-host\u003e:\u003cport\u003e/ssrf-proof\"\n       ref: \"main\"\n```\n2. Run `gitea restore-repo` against that dump directory for any repo\n   owner.\n3. Observe on the target host/listener: an actual `git` HTTP\n   discovery request arrives, e.g.\n   `GET /ssrf-proof/info/refs?service=git-upload-pack`, driven entirely\n   by the value from the dump file.\n\nVerified the core mechanism (steps 2\u20133, i.e. the unvalidated\n`Head.CloneURL` surviving `CheckAndEnsureSafePR(\"\")` and then being used\nin a real `git remote add` + `git fetch`) with a minimal, standalone Go\nprogram built from the **verbatim, unmodified** `hasBaseURL` /\n`CheckAndEnsureSafePR` function bodies (attached: `gitea_ssrf_poc.go`),\nrun end-to-end against a local HTTP listener. The listener\u0027s access log\nconfirms the request actually arrives. \n\n### Impact\nAn attacker who can get an administrator to run `gitea restore-repo`\nagainst a malicious dump (the same threat model already accepted for the\njust-fixed path-traversal issue in this command, #38215) can make the\nGitea server issue a `git fetch` against an arbitrary attacker-chosen\nURL. This allows:\n- SSRF against internal-only services or cloud metadata endpoints\n  reachable from the Gitea host.\n- Disclosure of local git repositories reachable via `file://` paths\n  readable by the Gitea process.\n\nNo public disclosure planned. Happy to provide further detail on\nrequest.",
  "id": "GHSA-xmj7-xj85-hfc3",
  "modified": "2026-07-21T20:37:29Z",
  "published": "2026-07-21T20:37:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-xmj7-xj85-hfc3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gitea: SSRF in restore-repo via unsanitized pull_request.yml Head.CloneURL"
}

GHSA-XMM3-9X39-98R5

Vulnerability from github – Published: 2026-03-27 15:30 – Updated: 2026-03-28 00:31
VLAI
Details

A weakness has been identified in mingSoft MCMS 迄 5.5.0. This issue affects the function catchImage of the file net/mingsoft/cms/action/BaseAction.java of the component Editor Endpoint. Executing a manipulation of the argument catchimage can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-4953"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-27T15:17:02Z",
    "severity": "MODERATE"
  },
  "details": "A weakness has been identified in mingSoft MCMS \u8fc4 5.5.0. This issue affects the function catchImage of the file net/mingsoft/cms/action/BaseAction.java of the component Editor Endpoint. Executing a manipulation of the argument catchimage can lead to server-side request forgery. It is possible to launch the attack remotely. The exploit has been made available to the public and could be used for attacks.",
  "id": "GHSA-xmm3-9x39-98r5",
  "modified": "2026-03-28T00:31:13Z",
  "published": "2026-03-27T15:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4953"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wing3e/public_exp/issues/3"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.353831"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.353831"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.777516"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-XMMP-7836-3M8W

Vulnerability from github – Published: 2023-09-28 00:30 – Updated: 2024-04-04 07:56
VLAI
Details

An issue in phpkobo AjaxNewsTicker v.1.0.5 allows a remote attacker to execute arbitrary code via a crafted payload to the reque parameter.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-41449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-27T23:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "An issue in phpkobo AjaxNewsTicker v.1.0.5 allows a remote attacker to execute arbitrary code via a crafted payload to the reque parameter.",
  "id": "GHSA-xmmp-7836-3m8w",
  "modified": "2024-04-04T07:56:20Z",
  "published": "2023-09-28T00:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41449"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/RNPG/c1ae240f2acec138132aa64ce3faa2e0"
    },
    {
      "type": "WEB",
      "url": "http://ajaxnewsticker.com"
    },
    {
      "type": "WEB",
      "url": "http://phpkobo.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list