CWE-918
AllowedServer-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.
6164 vulnerabilities reference this CWE, most recent first.
GHSA-GFGJ-8F63-3RWQ
Vulnerability from github – Published: 2026-08-18 15:31 – Updated: 2026-08-18 15:31Subscriber Server Side Request Forgery (SSRF) in [Aotuman] Grab WeChat Articles <= 2.0.1 versions.
{
"affected": [],
"aliases": [
"CVE-2026-32467"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T14:17:04Z",
"severity": "MODERATE"
},
"details": "Subscriber Server Side Request Forgery (SSRF) in [Aotuman] Grab WeChat Articles \u003c= 2.0.1 versions.",
"id": "GHSA-gfgj-8f63-3rwq",
"modified": "2026-08-18T15:31:46Z",
"published": "2026-08-18T15:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32467"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/apoyl-grabweixin/vulnerability/wordpress-aotuman-grab-wechat-articles-plugin-2-0-1-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GFHV-5RQH-7QX3
Vulnerability from github – Published: 2025-03-29 00:31 – Updated: 2025-04-01 14:20ShopXO v6.4.0 is vulnerable to Server-Side Request Forgery (SSRF) in Email Settings.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "shopxo/shopxo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "6.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-28093"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-01T14:20:17Z",
"nvd_published_at": "2025-03-28T22:15:18Z",
"severity": "MODERATE"
},
"details": "ShopXO v6.4.0 is vulnerable to Server-Side Request Forgery (SSRF) in Email Settings.",
"id": "GHSA-gfhv-5rqh-7qx3",
"modified": "2025-04-01T14:20:17Z",
"published": "2025-03-29T00:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28093"
},
{
"type": "PACKAGE",
"url": "https://github.com/gongfuxiang/shopxo"
},
{
"type": "WEB",
"url": "https://www.yuque.com/morysummer/vx41bz/he2hb8ic8an8h07f"
}
],
"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"
}
],
"summary": "ShopXO Vulnerable to Server-Side Request Forgery (SSRF) via Email Settings"
}
GHSA-GFJH-WVFW-6J4F
Vulnerability from github – Published: 2024-03-28 06:30 – Updated: 2026-04-01 18:31Server-Side Request Forgery (SSRF) vulnerability in Kadence WP Gutenberg Blocks by Kadence Blocks.This issue affects Gutenberg Blocks by Kadence Blocks: from n/a through 3.2.19.
{
"affected": [],
"aliases": [
"CVE-2024-23500"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-28T06:15:10Z",
"severity": "HIGH"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Kadence WP Gutenberg Blocks by Kadence Blocks.This issue affects Gutenberg Blocks by Kadence Blocks: from n/a through 3.2.19.",
"id": "GHSA-gfjh-wvfw-6j4f",
"modified": "2026-04-01T18:31:43Z",
"published": "2024-03-28T06:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23500"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/kadence-blocks/vulnerability/wordpress-kadence-blocks-plugin-3-2-19-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/kadence-blocks/wordpress-kadence-blocks-plugin-3-2-19-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GFPR-2VCF-JMXJ
Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-09 18:31Server-Side Request Forgery (SSRF) vulnerability in Brecht Visual Link Preview visual-link-preview allows Server Side Request Forgery.This issue affects Visual Link Preview: from n/a through <= 2.3.0.
{
"affected": [],
"aliases": [
"CVE-2026-39670"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T09:16:38Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Brecht Visual Link Preview visual-link-preview allows Server Side Request Forgery.This issue affects Visual Link Preview: from n/a through \u003c= 2.3.0.",
"id": "GHSA-gfpr-2vcf-jmxj",
"modified": "2026-04-09T18:31:25Z",
"published": "2026-04-08T09:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39670"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/visual-link-preview/vulnerability/wordpress-visual-link-preview-plugin-2-3-0-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GFQ7-5X4G-3XHF
Vulnerability from github – Published: 2026-06-22 23:39 – Updated: 2026-08-12 18:57Summary
Authenticated users with automation permissions can bypass Budibase's SSRF blacklist through DNS rebinding.
The outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection.
This results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints.
Details
The issue comes from the outbound fetch validation flow resolving DNS twice:
During blacklist validation Again during the real socket connection
The first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP.
This creates a classic TOCTOU DNS rebinding issue.
Affected flow in:
packages/backend-core/src/utils/outboundFetch.ts
async function throwIfUnsafe(url: string): Promise<void> {
const parsed = parseUrl(url)
if (await isBlacklisted(parsed.hostname)) {
throw new Error("URL is blocked or could not be resolved safely.")
}
}
for (let redirects = 0; redirects <= MAX_REDIRECTS; redirects++) {
await throwIfUnsafe(nextUrl)
const response = await fetchFn(nextUrl, nextRequest)
// ...
}
fetchFn uses plain node-fetch with no custom http.Agent / https.Agent, so the underlying socket performs its own independent dns.lookup after validation completes.
The same pattern also exists in:
packages/server/src/automations/steps/utils.ts
await throwIfBlacklisted(nextUrl)
const response = await fetch(nextUrl, nextRequest)
The blacklist implementation resolves hostnames but only returns a boolean:
packages/backend-core/src/blacklist/blacklist.ts
async function lookup(address: string): Promise<string[]> {
address = parseAddress(address)
const addresses = await performLookup(address, { all: true })
return addresses.map(addr => addr.address)
}
export async function isBlacklisted(address: string): Promise<boolean> {
// ...
if (!net.isIP(address)) {
try {
ips = await lookup(address)
} catch (e) {
/* ... */
}
} else {
ips = [address]
}
return ips.some(ip => blackList!.check(ip, getIpVersion(ip)))
}
The resolved IPs are discarded, so callers cannot pin the later socket connection to the validated addresses.
An attacker controlling authoritative DNS for a hostname can therefore return:
a public IP during validation a private/internal IP during the actual connection
Anything routing through these helpers inherits the issue, including:
outgoing webhook Slack Discord Make Zapier n8n AI extract object-store fetches
Several of these steps return upstream response content directly into automation output, which makes the SSRF non-blind.
PoC
Tested locally against a self-hosted build from master. No Budibase-operated infrastructure was touched.
Run Budibase locally.
Start a harmless local HTTP listener:
python3 -m http.server 8080 --bind 127.0.0.1
Use a rebinding hostname such as:
7f000001.cb007264.rbndr.us
which rotates between:
127.0.0.1 203.0.113.100
Steps to reproduce:
Log into Budibase with automation permissions. Create an automation using the Outgoing Webhook step. Set the URL to: http://:8080/ Trigger the automation.
Observed result:
The blacklist validation resolves the hostname to the public IP and allows the request. node-fetch performs a second DNS lookup during socket creation. The second lookup resolves to 127.0.0.1. The TCP connection lands on the local service. The local server response body appears directly in the automation output. Impact
This produces a non-blind read-SSRF primitive against anything reachable from the Budibase host process, including:
loopback services (127.0.0.1) RFC1918 ranges internal Kubernetes/VPC services cloud metadata endpoints (169.254.169.254)
On cloud deployments without IMDSv2 enforcement, this may expose temporary IAM credentials via:
/latest/meta-data/iam/security-credentials/
On multi-tenant hosted deployments, this may also create potential cross-tenant access paths through shared internal infrastructure.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@budibase/backend-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.39.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54353"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T23:39:24Z",
"nvd_published_at": "2026-06-26T21:16:35Z",
"severity": "HIGH"
},
"details": "Summary\n\nAuthenticated users with automation permissions can bypass Budibase\u0027s SSRF blacklist through DNS rebinding.\n\nThe outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection.\n\nThis results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints.\n\nDetails\n\nThe issue comes from the outbound fetch validation flow resolving DNS twice:\n\nDuring blacklist validation\nAgain during the real socket connection\n\nThe first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP.\n\nThis creates a classic TOCTOU DNS rebinding issue.\n\nAffected flow in:\n\npackages/backend-core/src/utils/outboundFetch.ts\n```\nasync function throwIfUnsafe(url: string): Promise\u003cvoid\u003e {\n const parsed = parseUrl(url)\n\n if (await isBlacklisted(parsed.hostname)) {\n throw new Error(\"URL is blocked or could not be resolved safely.\")\n }\n}\n\nfor (let redirects = 0; redirects \u003c= MAX_REDIRECTS; redirects++) {\n await throwIfUnsafe(nextUrl)\n\n const response = await fetchFn(nextUrl, nextRequest)\n\n // ...\n}\n```\nfetchFn uses plain node-fetch with no custom http.Agent / https.Agent, so the underlying socket performs its own independent dns.lookup after validation completes.\n\nThe same pattern also exists in:\n\npackages/server/src/automations/steps/utils.ts\n```\nawait throwIfBlacklisted(nextUrl)\n\nconst response = await fetch(nextUrl, nextRequest)\n```\nThe blacklist implementation resolves hostnames but only returns a boolean:\n\npackages/backend-core/src/blacklist/blacklist.ts\n```\nasync function lookup(address: string): Promise\u003cstring[]\u003e {\n address = parseAddress(address)\n\n const addresses = await performLookup(address, { all: true })\n\n return addresses.map(addr =\u003e addr.address)\n}\n\nexport async function isBlacklisted(address: string): Promise\u003cboolean\u003e {\n // ...\n\n if (!net.isIP(address)) {\n try {\n ips = await lookup(address)\n } catch (e) {\n /* ... */\n }\n } else {\n ips = [address]\n }\n\n return ips.some(ip =\u003e blackList!.check(ip, getIpVersion(ip)))\n}\n```\nThe resolved IPs are discarded, so callers cannot pin the later socket connection to the validated addresses.\n\nAn attacker controlling authoritative DNS for a hostname can therefore return:\n\na public IP during validation\na private/internal IP during the actual connection\n\nAnything routing through these helpers inherits the issue, including:\n\noutgoing webhook\nSlack\nDiscord\nMake\nZapier\nn8n\nAI extract\nobject-store fetches\n\nSeveral of these steps return upstream response content directly into automation output, which makes the SSRF non-blind.\n\nPoC\n\nTested locally against a self-hosted build from master.\nNo Budibase-operated infrastructure was touched.\n\nRun Budibase locally.\n\nStart a harmless local HTTP listener:\n\npython3 -m http.server 8080 --bind 127.0.0.1\n\nUse a rebinding hostname such as:\n\n7f000001.cb007264.rbndr.us\n\nwhich rotates between:\n\n127.0.0.1\n203.0.113.100\n\nSteps to reproduce:\n\nLog into Budibase with automation permissions.\nCreate an automation using the Outgoing Webhook step.\nSet the URL to:\nhttp://\u003crebinding-host\u003e:8080/\nTrigger the automation.\n\nObserved result:\n\nThe blacklist validation resolves the hostname to the public IP and allows the request.\nnode-fetch performs a second DNS lookup during socket creation.\nThe second lookup resolves to 127.0.0.1.\nThe TCP connection lands on the local service.\nThe local server response body appears directly in the automation output.\nImpact\n\nThis produces a non-blind read-SSRF primitive against anything reachable from the Budibase host process, including:\n\nloopback services (127.0.0.1)\nRFC1918 ranges\ninternal Kubernetes/VPC services\ncloud metadata endpoints (169.254.169.254)\n\nOn cloud deployments without IMDSv2 enforcement, this may expose temporary IAM credentials via:\n\n/latest/meta-data/iam/security-credentials/\u003crole\u003e\n\nOn multi-tenant hosted deployments, this may also create potential cross-tenant access paths through shared internal infrastructure.",
"id": "GHSA-gfq7-5x4g-3xhf",
"modified": "2026-08-12T18:57:24Z",
"published": "2026-06-22T23:39:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/security/advisories/GHSA-gfq7-5x4g-3xhf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54353"
},
{
"type": "PACKAGE",
"url": "https://github.com/Budibase/budibase"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "@budibase/backend-core has potential SSRF DNS rebinding bypass in outbound fetch validation"
}
GHSA-GFRJ-PXWG-9R69
Vulnerability from github – Published: 2026-08-11 12:30 – Updated: 2026-08-11 12:30A server-side request forgery vulnerability in Apioo Fusio 8.8.3 allows authenticated consumer-role users to make the server issue HTTP requests to internal network addresses by registering a webhook URL pointing to an internal host. The webhook registration endpoint validates URL syntax via FILTER_VALIDATE_URL but applies no IP or host denylist. When the registered event fires, the server issues an HTTP POST to the attacker-supplied internal URL.
{
"affected": [],
"aliases": [
"CVE-2026-72598"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T12:17:42Z",
"severity": "MODERATE"
},
"details": "A server-side request forgery vulnerability in Apioo Fusio 8.8.3 allows authenticated consumer-role users to make the server issue HTTP requests to internal network addresses by registering a webhook URL pointing to an internal host. The webhook registration endpoint validates URL syntax via FILTER_VALIDATE_URL but applies no IP or host denylist. When the registered event fires, the server issues an HTTP POST to the attacker-supplied internal URL.",
"id": "GHSA-gfrj-pxwg-9r69",
"modified": "2026-08-11T12:30:27Z",
"published": "2026-08-11T12:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72598"
},
{
"type": "WEB",
"url": "https://github.com/apioo/fusio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GFW7-F889-5P73
Vulnerability from github – Published: 2024-06-06 18:30 – Updated: 2024-06-06 18:30A Server-Side Request Forgery (SSRF) vulnerability exists in the 'add_webpage' endpoint of the parisneo/lollms-webui application, affecting the latest version. The vulnerability arises because the application does not adequately validate URLs entered by users, allowing them to input arbitrary URLs, including those that target internal resources such as 'localhost' or '127.0.0.1'. This flaw enables attackers to make unauthorized requests to internal or external systems, potentially leading to access to sensitive data, service disruption, network integrity compromise, business logic manipulation, and abuse of third-party resources. The issue is critical and requires immediate attention to maintain the application's security and integrity.
{
"affected": [],
"aliases": [
"CVE-2024-5482"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-06T18:15:21Z",
"severity": "HIGH"
},
"details": "A Server-Side Request Forgery (SSRF) vulnerability exists in the \u0027add_webpage\u0027 endpoint of the parisneo/lollms-webui application, affecting the latest version. The vulnerability arises because the application does not adequately validate URLs entered by users, allowing them to input arbitrary URLs, including those that target internal resources such as \u0027localhost\u0027 or \u0027127.0.0.1\u0027. This flaw enables attackers to make unauthorized requests to internal or external systems, potentially leading to access to sensitive data, service disruption, network integrity compromise, business logic manipulation, and abuse of third-party resources. The issue is critical and requires immediate attention to maintain the application\u0027s security and integrity.",
"id": "GHSA-gfw7-f889-5p73",
"modified": "2024-06-06T18:30:58Z",
"published": "2024-06-06T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5482"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/d97e23e7-172f-4862-a732-86bfc0b7860e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GG29-529G-R9M2
Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2025-09-09 18:31SSRF in Ivanti Connect Secure before 22.7R2.9 or 22.8R2, Ivanti Policy Secure before 22.7R1.6, Ivanti ZTA Gateway before 2.8R2.3-723 and Ivanti Neurons for Secure Access before 22.8R1.4 (Fix deployed on 02-Aug-2025) allows a remote authenticated attacker with admin privileges to enumerate internal services.
{
"affected": [],
"aliases": [
"CVE-2025-55139"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T16:15:33Z",
"severity": "MODERATE"
},
"details": "SSRF in Ivanti Connect Secure before 22.7R2.9 or 22.8R2, Ivanti Policy Secure before 22.7R1.6, Ivanti ZTA Gateway before 2.8R2.3-723 and Ivanti Neurons for Secure Access before 22.8R1.4 (Fix deployed on 02-Aug-2025) allows a remote authenticated attacker with admin privileges to enumerate internal services.",
"id": "GHSA-gg29-529g-r9m2",
"modified": "2025-09-09T18:31:18Z",
"published": "2025-09-09T18:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55139"
},
{
"type": "WEB",
"url": "https://forums.ivanti.com/s/article/September-Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-and-Neurons-for-Secure-Access-Multiple-CVEs?language=en_US"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GG34-F95Q-RFGP
Vulnerability from github – Published: 2026-10-02 12:31 – Updated: 2026-10-02 12:31YesWiki before 4.6.7 contains a server-side request forgery vulnerability in validateKeyIdUrl() that allows unauthenticated attackers to bypass the SSRF guard using 6to4, NAT64, or IPv4-compatible IPv6 addresses. Attackers can send a crafted Signature keyId to the public actor inbox route to reach cloud metadata, loopback services, or internal hosts.
{
"affected": [],
"aliases": [
"CVE-2026-104458"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-02T12:17:17Z",
"severity": "HIGH"
},
"details": "YesWiki before 4.6.7 contains a server-side request forgery vulnerability in validateKeyIdUrl() that allows unauthenticated attackers to bypass the SSRF guard using 6to4, NAT64, or IPv4-compatible IPv6 addresses. Attackers can send a crafted Signature keyId to the public actor inbox route to reach cloud metadata, loopback services, or internal hosts.",
"id": "GHSA-gg34-f95q-rfgp",
"modified": "2026-10-02T12:31:16Z",
"published": "2026-10-02T12:31:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-85f2-5r47-2pwm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104458"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/yeswiki-before-4.6.7-ssrf-guard-bypass-via-ipv6-transition-addresses"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/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:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-GG5C-V856-2RJP
Vulnerability from github – Published: 2026-06-01 09:31 – Updated: 2026-06-01 09:31A vulnerability was determined in JeecgBoot up to 3.9.2. The affected element is the function WordUtil.addImage of the file /airag/word/edit. Executing a manipulation can lead to server-side request forgery. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. A fix is planned for the upcoming release.
{
"affected": [],
"aliases": [
"CVE-2026-10239"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-01T09:16:15Z",
"severity": "LOW"
},
"details": "A vulnerability was determined in JeecgBoot up to 3.9.2. The affected element is the function WordUtil.addImage of the file /airag/word/edit. Executing a manipulation can lead to server-side request forgery. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. A fix is planned for the upcoming release.",
"id": "GHSA-gg5c-v856-2rjp",
"modified": "2026-06-01T09:31:12Z",
"published": "2026-06-01T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10239"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot/issues/9610"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-10239"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/823266"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367517"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367517/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"
}
]
}
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.