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.
4711 vulnerabilities reference this CWE, most recent first.
GHSA-PH82-G2MR-P678
Vulnerability from github – Published: 2022-10-29 12:00 – Updated: 2022-11-03 19:00The Web Stories plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including 1.24.0 due to insufficient validation of URLs supplied via the 'url' parameter found via the /v1/hotlink/proxy REST API Endpoint. This made it possible for authenticated users to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2022-3708"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-28T19:15:00Z",
"severity": "HIGH"
},
"details": "The Web Stories plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including 1.24.0 due to insufficient validation of URLs supplied via the \u0027url\u0027 parameter found via the /v1/hotlink/proxy REST API Endpoint. This made it possible for authenticated users to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-ph82-g2mr-p678",
"modified": "2022-11-03T19:00:27Z",
"published": "2022-10-29T12:00:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3708"
},
{
"type": "WEB",
"url": "https://github.com/GoogleForCreators/web-stories-wp/commit/3ad2099f95155d658624ffac2e34ce0da739e34b"
},
{
"type": "WEB",
"url": "https://github.com/GoogleForCreators/web-stories-wp/compare/v1.24.0...v1.25.0"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/web-stories"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/7817a840-325a-4709-8374-84bb32d98d0e?source=cve"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/vulnerability-advisories-continued/#CVE-2022-3708"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-PHH2-62X4-4JFJ
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34JetBrains YouTrack before 2020.3.5333 was vulnerable to SSRF.
{
"affected": [],
"aliases": [
"CVE-2020-27626"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-16T15:15:00Z",
"severity": "MODERATE"
},
"details": "JetBrains YouTrack before 2020.3.5333 was vulnerable to SSRF.",
"id": "GHSA-phh2-62x4-4jfj",
"modified": "2022-05-24T17:34:18Z",
"published": "2022-05-24T17:34:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27626"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com/2020/11/16/jetbrains-security-bulletin-q3-2020"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PHHP-CVW3-V4HR
Vulnerability from github – Published: 2024-04-29 12:30 – Updated: 2026-04-28 21:35Server-Side Request Forgery (SSRF) vulnerability in codeSavory Knowledge Base documentation & wiki plugin – BasePress.This issue affects Knowledge Base documentation & wiki plugin – BasePress: from n/a through 2.16.1.
{
"affected": [],
"aliases": [
"CVE-2024-33590"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-29T11:15:46Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in codeSavory Knowledge Base documentation \u0026 wiki plugin \u2013 BasePress.This issue affects Knowledge Base documentation \u0026 wiki plugin \u2013 BasePress: from n/a through 2.16.1.",
"id": "GHSA-phhp-cvw3-v4hr",
"modified": "2026-04-28T21:35:01Z",
"published": "2024-04-29T12:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33590"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/basepress/wordpress-basepress-plugin-2-16-1-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PHX5-R46P-24FC
Vulnerability from github – Published: 2022-05-17 00:24 – Updated: 2022-05-17 00:24Mahara 1.8 before 1.8.7 and 1.9 before 1.9.5 and 1.10 before 1.10.3 and 15.04 before 15.04.0 are vulnerable to server-side request forgery attacks as not all processes of curl redirects are checked against a white or black list. Employing SafeCurl will prevent issues.
{
"affected": [],
"aliases": [
"CVE-2017-1000139"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-03T18:29:00Z",
"severity": "HIGH"
},
"details": "Mahara 1.8 before 1.8.7 and 1.9 before 1.9.5 and 1.10 before 1.10.3 and 15.04 before 15.04.0 are vulnerable to server-side request forgery attacks as not all processes of curl redirects are checked against a white or black list. Employing SafeCurl will prevent issues.",
"id": "GHSA-phx5-r46p-24fc",
"modified": "2022-05-17T00:24:06Z",
"published": "2022-05-17T00:24:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000139"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/mahara/+bug/1397736"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PHXC-H9CH-Q3GG
Vulnerability from github – Published: 2026-06-30 21:31 – Updated: 2026-06-30 21:31IBM Langflow OSS 1.0.0 through 1.9.3 contains a Server-Side Request Forgery (SSRF) vulnerability in the URL component ( src/lfx/src/lfx/components/data_source/url.py ) due to a Time-of-Check/Time-of-Use (TOCTOU) race condition that can be exploited via DNS rebinding.
{
"affected": [],
"aliases": [
"CVE-2026-10546"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T20:17:27Z",
"severity": "HIGH"
},
"details": "IBM Langflow OSS 1.0.0 through 1.9.3 contains a Server-Side Request Forgery (SSRF) vulnerability in the URL component ( src/lfx/src/lfx/components/data_source/url.py ) due to a Time-of-Check/Time-of-Use (TOCTOU) race condition that can be exploited via DNS rebinding.",
"id": "GHSA-phxc-h9ch-q3gg",
"modified": "2026-06-30T21:31:44Z",
"published": "2026-06-30T21:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10546"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7277560"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PJ2V-GGQH-CMQ2
Vulnerability from github – Published: 2026-06-03 21:09 – Updated: 2026-07-20 21:33Impact
In versions >= 2.82.0, < 2.91.0, if the HTML backend was explicitly configured for rendering (rendering option by default deactivated), then the Playwright-based rendering feature could allow JavaScript execution and unrestricted network access when processing untrusted HTML documents. An attacker could craft malicious HTML that executes arbitrary JavaScript in the rendering context or makes unauthorized network requests to internal services, potentially leading to SSRF attacks, data exfiltration, or remote code execution in the rendering environment.
Patches
Fixed in version 2.91.0. The rendering context now explicitly disables JavaScript execution (java_script_enabled=False) and implements network isolation controls. When enable_remote_fetch is disabled, the browser operates in offline mode, preventing all network requests.
Workarounds
Refrain from using render_page=True when processing untrusted HTML documents.
References
- Fix release: v2.91.0
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "docling"
},
"ranges": [
{
"events": [
{
"introduced": "2.82.0"
},
{
"fixed": "2.91.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44016"
],
"database_specific": {
"cwe_ids": [
"CWE-918",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-03T21:09:37Z",
"nvd_published_at": "2026-06-24T18:17:16Z",
"severity": "HIGH"
},
"details": "### Impact\nIn versions `\u003e= 2.82.0, \u003c 2.91.0`, if the HTML backend was explicitly configured for rendering (rendering option by default deactivated), then the Playwright-based rendering feature could allow JavaScript execution and unrestricted network access when processing untrusted HTML documents. An attacker could craft malicious HTML that executes arbitrary JavaScript in the rendering context or makes unauthorized network requests to internal services, potentially leading to SSRF attacks, data exfiltration, or remote code execution in the rendering environment.\n\n### Patches\nFixed in version 2.91.0. The rendering context now explicitly disables JavaScript execution (`java_script_enabled=False`) and implements network isolation controls. When `enable_remote_fetch` is disabled, the browser operates in offline mode, preventing all network requests.\n\n### Workarounds\nRefrain from using `render_page=True` when processing untrusted HTML documents.\n\n### References\n- Fix release: [v2.91.0](https://github.com/docling-project/docling/releases/tag/v2.91.0)",
"id": "GHSA-pj2v-ggqh-cmq2",
"modified": "2026-07-20T21:33:26Z",
"published": "2026-06-03T21:09:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/security/advisories/GHSA-pj2v-ggqh-cmq2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44016"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-44016"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492339"
},
{
"type": "PACKAGE",
"url": "https://github.com/docling-project/docling"
},
{
"type": "WEB",
"url": "https://github.com/docling-project/docling/releases/tag/v2.91.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/docling/PYSEC-2026-2142.yaml"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44016.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Docling: Unsafe Playwright-based HTML Rendering"
}
GHSA-PJ7V-XFVX-WMJQ
Vulnerability from github – Published: 2026-06-26 21:54 – Updated: 2026-06-26 21:54Summary
hackney_url:normalize/2 URL-decodes the host component of a parsed URL, but the caller's SSRF allowlist runs before normalization using OTP's uri_string:parse/1 and inet:parse_address/1, neither of which decodes percent-escapes in hostnames. A URL like http://%31%32%37%2E%30%2E%30%2E%31/ presents an encoded, non-IP-looking host to the validator, which passes the allowlist check; hackney's normalizer then decodes it to 127.0.0.1 and connects to loopback. Because hackney:request/5 always calls normalize/2 with no opt-out, every request path that accepts a binary or list URL is affected. This is a parser-differential SSRF in the same class as CVE-2025-1211, but in a different function.
Details
In src/hackney_url.erl (lines 161–186), normalize/2 checks whether the parsed host is already a dotted-quad or IPv6 literal via inet_parse:address/1. Percent-encoded forms like %31%32%37%2E%30%2E%30%2E%31 fail that check and fall into the catch-all branch, where urldecode/1 decodes the host before passing it to IDNA conversion:
Host1 = binary_to_list(
urldecode(unicode:characters_to_binary(Host0))
),
The decoded host ("127.0.0.1") replaces the original in the returned #hackney_url{} record. hackney:request/5 at src/hackney.erl:463 always calls normalize/2, so the decoded host is what do_dispatch/1 and add_host_header/2 ultimately use. The on-wire Host: header and the TCP connect target both reflect the decoded value.
The same payload pattern reaches the AWS/GCP/Azure IMDS (169.254.169.254), RFC1918 ranges, and any localhost admin endpoint. The 1.21.0 patch for CVE-2025-1211 fixed a separate differential in parse_url/1 and did not touch normalize/2.
PoC
- Validate the URL with the canonical Erlang SSRF allowlist:
uri_string:parse/1returns host<<"%31%32%37%2E%30%2E%30%2E%31">>,inet:parse_address/1returns{error, einval}, so the allowlist accepts it. - Pass the same URL to
hackney:get/1. - hackney's
normalize/2decodes the host to"127.0.0.1"and connects to127.0.0.1:80. The internal service receives the request withHost: 127.0.0.1.
Impact
Unauthenticated SSRF bypassing the canonical Erlang allowlist pattern. Affects hackney 0.13.0 through 4.0.0 for any application that accepts attacker-supplied URLs. Targets include cloud IMDS endpoints, localhost admin interfaces, and RFC1918 backends. CVSS v4.0: 6.9 (MEDIUM).
Resources
- Introduction commit: https://github.com/benoitc/hackney/commit/4d725507588942fd00efca15b86da3273656510a
- Patch commit: https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "hackney"
},
"ranges": [
{
"events": [
{
"introduced": "0.13.0"
},
{
"fixed": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47076"
],
"database_specific": {
"cwe_ids": [
"CWE-436",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T21:54:55Z",
"nvd_published_at": "2026-05-25T15:16:22Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`hackney_url:normalize/2` URL-decodes the host component of a parsed URL, but the caller\u0027s SSRF allowlist runs before normalization using OTP\u0027s `uri_string:parse/1` and `inet:parse_address/1`, neither of which decodes percent-escapes in hostnames. A URL like `http://%31%32%37%2E%30%2E%30%2E%31/` presents an encoded, non-IP-looking host to the validator, which passes the allowlist check; hackney\u0027s normalizer then decodes it to `127.0.0.1` and connects to loopback. Because `hackney:request/5` always calls `normalize/2` with no opt-out, every request path that accepts a binary or list URL is affected. This is a parser-differential SSRF in the same class as CVE-2025-1211, but in a different function.\n\n### Details\n\nIn `src/hackney_url.erl` (lines 161\u2013186), `normalize/2` checks whether the parsed host is already a dotted-quad or IPv6 literal via `inet_parse:address/1`. Percent-encoded forms like `%31%32%37%2E%30%2E%30%2E%31` fail that check and fall into the catch-all branch, where `urldecode/1` decodes the host before passing it to IDNA conversion:\n\n```erlang\nHost1 = binary_to_list(\n urldecode(unicode:characters_to_binary(Host0))\n ),\n```\n\nThe decoded host (`\"127.0.0.1\"`) replaces the original in the returned `#hackney_url{}` record. `hackney:request/5` at `src/hackney.erl:463` always calls `normalize/2`, so the decoded host is what `do_dispatch/1` and `add_host_header/2` ultimately use. The on-wire `Host:` header and the TCP connect target both reflect the decoded value.\n\nThe same payload pattern reaches the AWS/GCP/Azure IMDS (`169.254.169.254`), RFC1918 ranges, and any `localhost` admin endpoint. The 1.21.0 patch for CVE-2025-1211 fixed a separate differential in `parse_url/1` and did not touch `normalize/2`.\n\n### PoC\n\n1. Validate the URL with the canonical Erlang SSRF allowlist: `uri_string:parse/1` returns host `\u003c\u003c\"%31%32%37%2E%30%2E%30%2E%31\"\u003e\u003e`, `inet:parse_address/1` returns `{error, einval}`, so the allowlist accepts it.\n2. Pass the same URL to `hackney:get/1`.\n3. hackney\u0027s `normalize/2` decodes the host to `\"127.0.0.1\"` and connects to `127.0.0.1:80`. The internal service receives the request with `Host: 127.0.0.1`.\n\n### Impact\n\nUnauthenticated SSRF bypassing the canonical Erlang allowlist pattern. Affects hackney 0.13.0 through 4.0.0 for any application that accepts attacker-supplied URLs. Targets include cloud IMDS endpoints, `localhost` admin interfaces, and RFC1918 backends. CVSS v4.0: **6.9 (MEDIUM)**.\n\n## Resources\n\n* Introduction commit: https://github.com/benoitc/hackney/commit/4d725507588942fd00efca15b86da3273656510a\n* Patch commit: https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f",
"id": "GHSA-pj7v-xfvx-wmjq",
"modified": "2026-06-26T21:54:55Z",
"published": "2026-06-26T21:54:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/benoitc/hackney/security/advisories/GHSA-pj7v-xfvx-wmjq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47076"
},
{
"type": "WEB",
"url": "https://github.com/benoitc/hackney/commit/452620a92ec1da2e6b4862a049a2a4f04b42068f"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-47076.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/benoitc/hackney"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-47076"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Hackney has SSRF allowlist bypass in hackney_url:normalize/2 via percent-encoded host"
}
GHSA-PJ8J-P4G4-4VW8
Vulnerability from github – Published: 2026-07-10 16:04 – Updated: 2026-07-10 16:04Summary
Kimai 2.56.0 contains a server-side request forgery vulnerability in its invoice PDF preview and generation workflow. If an attacker can control Markdown content that is later rendered into an invoice PDF, such as Customer.invoiceText, the server-side PDF renderer will fetch remote image URLs embedded in Markdown image syntax.
This allows the application server to issue outbound requests to attacker-controlled or internal targets during PDF rendering. The behavior can be used for internal network probing, server-side reachability checks, and potentially follow-on exploitation depending on deployment environment and accessible internal services.
Details
The vulnerable behavior occurs in the invoice rendering chain when user-controlled Markdown is transformed into HTML and then rendered by mPDF.
- First, customer invoice text is copied into the invoice model. . Second, the default PDF invoice template renders that field through the Markdown-to-HTML filter.
- Third,
md2htmlenables full Markdown rendering. - Although safe mode is enabled, the tested Markdown image syntax still survives into the rendered HTML chain in a form that causes the PDF renderer to fetch the image resource.
- Finally, the HTML is handed to mPDF.
The live test confirms that mPDF attempts to retrieve the remote image URL from the server side during PDF preview. This means the issue is not a template-injection problem but an SSRF condition caused by the rendering pipeline:
- attacker-controlled Markdown
- Markdown converted to HTML
- HTML rendered by mPDF
- mPDF fetches remote image resources from the server side
A PoC was provided, but removed for security reasons.
Impact
This vulnerability allows an attacker who can influence invoice-rendered Markdown fields to cause the Kimai server to make outbound requests to arbitrary destinations. In real deployments, this can be used to probe internal services, test access to internal administrative or metadata endpoints, and confirm server-side reachability to attacker-controlled infrastructure.
Depending on the environment, SSRF can also become a stepping stone toward more serious outcomes, such as triggering side effects on internal HTTP services or extracting sensitive information from services reachable only by the server. Because invoice generation is commonly performed by administrative or finance-related users, the feature is realistically reachable in business workflows.
Solution
- Kimai does not allow to use markdown images any longer and converts them to HTML links instead
- Kimai uses a specialized HttpClient for mPDF (called
NoPrivateNetworkHttpClient), which prevents access to a variety of URLs, the full list can be fetched from the documentation - This change can be a BC break, if someone used
- the Kimai domain for hosting invoice or export template images
- an internal IP for hosting invoice or export template images
See https://www.kimai.org/en/security/ghsa-pj8j-p4g4-4vw8
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.57.0"
},
"package": {
"ecosystem": "Packagist",
"name": "kimai/kimai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.58.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49865"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-10T16:04:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nKimai 2.56.0 contains a server-side request forgery vulnerability in its invoice PDF preview and generation workflow. If an attacker can control Markdown content that is later rendered into an invoice PDF, such as `Customer.invoiceText`, the server-side PDF renderer will fetch remote image URLs embedded in Markdown image syntax.\n\nThis allows the application server to issue outbound requests to attacker-controlled or internal targets during PDF rendering. The behavior can be used for internal network probing, server-side reachability checks, and potentially follow-on exploitation depending on deployment environment and accessible internal services.\n\n### Details\n\nThe vulnerable behavior occurs in the invoice rendering chain when user-controlled Markdown is transformed into HTML and then rendered by mPDF.\n\n- First, customer invoice text is copied into the invoice model.\n. Second, the default PDF invoice template renders that field through the Markdown-to-HTML filter. \n- Third, `md2html` enables full Markdown rendering. \n- Although safe mode is enabled, the tested Markdown image syntax still survives into the rendered HTML chain in a form that causes the PDF renderer to fetch the image resource.\n- Finally, the HTML is handed to mPDF. \n\nThe live test confirms that mPDF attempts to retrieve the remote image URL from the server side during PDF preview. This means the issue is not a template-injection problem but an SSRF condition caused by the rendering pipeline:\n\n- attacker-controlled Markdown\n- Markdown converted to HTML\n- HTML rendered by mPDF\n- mPDF fetches remote image resources from the server side\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nThis vulnerability allows an attacker who can influence invoice-rendered Markdown fields to cause the Kimai server to make outbound requests to arbitrary destinations. In real deployments, this can be used to probe internal services, test access to internal administrative or metadata endpoints, and confirm server-side reachability to attacker-controlled infrastructure.\n\nDepending on the environment, SSRF can also become a stepping stone toward more serious outcomes, such as triggering side effects on internal HTTP services or extracting sensitive information from services reachable only by the server. Because invoice generation is commonly performed by administrative or finance-related users, the feature is realistically reachable in business workflows.\n\n# Solution\n\n- Kimai does not allow to use markdown images any longer and converts them to HTML links instead\n- Kimai uses a specialized HttpClient for mPDF (called `NoPrivateNetworkHttpClient`), which prevents access to a variety of URLs, the full list can be fetched [from the documentation](https://www.kimai.org/documentation/pdf-templates.html#embedding-images)\n- This change can be a BC break, if someone used \n - the Kimai domain for hosting invoice or export template images \n - an internal IP for hosting invoice or export template images \n\nSee https://www.kimai.org/en/security/ghsa-pj8j-p4g4-4vw8",
"id": "GHSA-pj8j-p4g4-4vw8",
"modified": "2026-07-10T16:04:40Z",
"published": "2026-07-10T16:04:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kimai/kimai/security/advisories/GHSA-pj8j-p4g4-4vw8"
},
{
"type": "PACKAGE",
"url": "https://github.com/kimai/kimai"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kimai has Server-Side Request Forgery in Invoice PDF Rendering via Markdown Image URLs"
}
GHSA-PJPG-43J3-PGJ7
Vulnerability from github – Published: 2025-05-14 09:30 – Updated: 2025-05-14 09:30The Ninja Forms Webhooks plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.0.7 via the form webhook functionality. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2024-13940"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-14T09:15:18Z",
"severity": "MODERATE"
},
"details": "The Ninja Forms Webhooks plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 3.0.7 via the form webhook functionality. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-pjpg-43j3-pgj7",
"modified": "2025-05-14T09:30:25Z",
"published": "2025-05-14T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13940"
},
{
"type": "WEB",
"url": "https://ninjaforms.com/extensions/webhooks"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4cf2af62-2b5a-4c0a-9e82-f80dde204a9d?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PJWM-PJ3P-43MV
Vulnerability from github – Published: 2026-05-29 15:59 – Updated: 2026-07-20 12:33Summary
shouldBypassProxy, introduced in v1.15.0 to fix CVE-2025-62718, does not normalise IPv4-mapped IPv6 addresses. When NO_PROXY lists an IPv4 address such as 127.0.0.1 or 169.254.169.254, a request URL using the IPv4-mapped IPv6 form (::ffff:7f00:1, ::ffff:a9fe:a9fe) still routes through the configured proxy. Node.js resolves these addresses to the underlying IPv4 host, so the request reaches the internal service via the proxy rather than being blocked.
Details
lib/helpers/shouldBypassProxy.js (v1.15.0):
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
// normalizeNoProxyHost strips brackets and trailing dots, but not ::ffff: prefix
return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));
The WHATWG URL parser canonicalises http://[::ffff:127.0.0.1]/ to hostname [::ffff:7f00:1]. After bracket-stripping: ::ffff:7f00:1. This string does not match 127.0.0.1 in NO_PROXY and is not in LOOPBACK_ADDRESSES, so shouldBypassProxy returns false and the proxy is used. proxy-from-env (called before shouldBypassProxy) has the same gap - it does not equate ::ffff:7f00:1 with 127.0.0.1 - so neither layer catches the bypass.
PoC
// NO_PROXY=127.0.0.1,localhost,::1 HTTP_PROXY=http://attacker:8080
import shouldBypassProxy from 'axios/lib/helpers/shouldBypassProxy.js';
// All three should return true (bypass proxy). Only the first two do.
console.log(shouldBypassProxy('http://127.0.0.1/')); // true [OK]
console.log(shouldBypassProxy('http://[::1]/')); // true [OK]
console.log(shouldBypassProxy('http://[::ffff:127.0.0.1]/')); // false <- bypass
console.log(shouldBypassProxy('http://[::ffff:7f00:1]/')); // false <- bypass
Node.js routes ::ffff:7f00:1 to 127.0.0.1:
// net.connect({ host: '::ffff:7f00:1', port: 80 }) reaches a service
// bound to 127.0.0.1:80 — confirmed on Node.js v24, Linux and macOS.
Cloud metadata SSRF: ::ffff:a9fe:a9fe = ::ffff:169.254.169.254. If NO_PROXY=169.254.169.254 is set to block IMDS access, a request to http://[::ffff:a9fe:a9fe]/latest/meta-data/ bypasses it.
Fix
Canonicalise IPv4-mapped IPv6 in normalizeNoProxyHost before any comparison:
```javascript
const ipv4MappedDotted = /^::ffff:(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})$/i;
const ipv4MappedHex = /^::ffff:([0-9a-f]{1,4}):([0-9a-f]{1,4})$/i;
function hexToIPv4(a, b) {
const hi = parseInt(a, 16), lo = parseInt(b, 16);
return ${hi >> 8}.${hi & 0xff}.${lo >> 8}.${lo & 0xff};
}
const normalizeNoProxyHost = (hostname) => {
if (!hostname) return hostname;
if (hostname[0] === '[' && hostname.at(-1) === ']')
hostname = hostname.slice(1, -1);
hostname = hostname.replace(/.+$/, '').toLowerCase();
let m;
if ((m = hostname.match(ipv4MappedDotted))) return m[1];
if ((m = hostname.match(ipv4MappedHex))) return hexToIPv4(m[1], m[2]);
return hostname;
};
```
Impact
Any application that sets NO_PROXY to exclude internal or metadata endpoints and uses an HTTP/HTTPS proxy can have those exclusions bypassed by a URL using IPv4-mapped IPv6 notation. The attacker must control the request URL. In cloud environments with instance metadata services, this can lead to credential exfiltration.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.15.0"
},
{
"fixed": "1.16.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.31.1"
},
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.32.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44492"
],
"database_specific": {
"cwe_ids": [
"CWE-289",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T15:59:30Z",
"nvd_published_at": "2026-06-11T17:16:33Z",
"severity": "HIGH"
},
"details": "### Summary\nshouldBypassProxy, introduced in v1.15.0 to fix CVE-2025-62718, does not normalise IPv4-mapped IPv6 addresses. When NO_PROXY lists an IPv4 address such as `127.0.0.1` or `169.254.169.254`, a request URL using the IPv4-mapped IPv6 form (`::ffff:7f00:1`, `::ffff:a9fe:a9fe`) still routes through the configured proxy. Node.js resolves these addresses to the underlying IPv4 host, so the request reaches the internal service via the proxy rather than being blocked.\n\n### Details\nlib/helpers/shouldBypassProxy.js (v1.15.0): \n\n```javascript \n const LOOPBACK_ADDRESSES = new Set([\u0027localhost\u0027, \u0027127.0.0.1\u0027, \u0027::1\u0027]); \n const isLoopback = (host) =\u003e LOOPBACK_ADDRESSES.has(host); \n \n // normalizeNoProxyHost strips brackets and trailing dots, but not ::ffff: prefix \n return hostname === entryHost || (isLoopback(hostname) \u0026\u0026 isLoopback(entryHost)); \n```\n \nThe WHATWG URL parser canonicalises `http://[::ffff:127.0.0.1]/` to hostname `[::ffff:7f00:1]`. After bracket-stripping: `::ffff:7f00:1`. This string does not match 127.0.0.1 in NO_PROXY and is not in LOOPBACK_ADDRESSES, so shouldBypassProxy returns false and the proxy is used. proxy-from-env (called before shouldBypassProxy) has the same gap - it does not equate ::ffff:7f00:1 with 127.0.0.1 - so neither layer catches the bypass.\n\n### PoC\n```javascript\n\n// NO_PROXY=127.0.0.1,localhost,::1 HTTP_PROXY=http://attacker:8080\nimport shouldBypassProxy from \u0027axios/lib/helpers/shouldBypassProxy.js\u0027; \n \n// All three should return true (bypass proxy). Only the first two do. \nconsole.log(shouldBypassProxy(\u0027http://127.0.0.1/\u0027)); // true [OK] \nconsole.log(shouldBypassProxy(\u0027http://[::1]/\u0027)); // true [OK] \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:127.0.0.1]/\u0027)); // false \u003c- bypass \nconsole.log(shouldBypassProxy(\u0027http://[::ffff:7f00:1]/\u0027)); // false \u003c- bypass\n\n``` \n \nNode.js routes ::ffff:7f00:1 to 127.0.0.1: \n\n``` \n// net.connect({ host: \u0027::ffff:7f00:1\u0027, port: 80 }) reaches a service \n// bound to 127.0.0.1:80 \u2014 confirmed on Node.js v24, Linux and macOS. \n``` \nCloud metadata SSRF: ::ffff:a9fe:a9fe = ::ffff:169.254.169.254. If NO_PROXY=169.254.169.254 is set to block IMDS access, a request to http://[::ffff:a9fe:a9fe]/latest/meta-data/ bypasses it. \n \n#### Fix \n \nCanonicalise IPv4-mapped IPv6 in normalizeNoProxyHost before any comparison: \n \n ```javascript \nconst ipv4MappedDotted = /^::ffff:(\\d{1,3}\\.\\d{1,3}\\.\\d{1,3}\\.\\d{1,3})$/i; \nconst ipv4MappedHex = /^::ffff:([0-9a-f]{1,4}):([0-9a-f]{1,4})$/i; \n \nfunction hexToIPv4(a, b) { \n const hi = parseInt(a, 16), lo = parseInt(b, 16); \n return `${hi \u003e\u003e 8}.${hi \u0026 0xff}.${lo \u003e\u003e 8}.${lo \u0026 0xff}`; \n} \n \nconst normalizeNoProxyHost = (hostname) =\u003e { \n if (!hostname) return hostname; \n if (hostname[0] === \u0027[\u0027 \u0026\u0026 hostname.at(-1) === \u0027]\u0027)\n hostname = hostname.slice(1, -1); \n hostname = hostname.replace(/\\.+$/, \u0027\u0027).toLowerCase();\n \n let m; \n if ((m = hostname.match(ipv4MappedDotted))) return m[1]; \n if ((m = hostname.match(ipv4MappedHex))) return hexToIPv4(m[1], m[2]); \n return hostname; \n};\n\n```\n\n### Impact\nAny application that sets NO_PROXY to exclude internal or metadata endpoints and uses an HTTP/HTTPS proxy can have those exclusions bypassed by a URL using IPv4-mapped IPv6 notation. The attacker must control the request URL. In cloud environments with instance metadata services, this can lead to credential exfiltration.",
"id": "GHSA-pjwm-pj3p-43mv",
"modified": "2026-07-20T12:33:05Z",
"published": "2026-05-29T15:59:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-pjwm-pj3p-43mv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44492"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62718"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36611"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36754"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36820"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36882"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36883"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40119"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40138"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40262"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41031"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41055"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41064"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41066"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-44492"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2487938"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44492.json"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20889"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20938"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26234"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27044"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:27063"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28964"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29082"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29197"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30650"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30651"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33005"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33155"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33160"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33163"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33173"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33183"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33574"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34766"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36108"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "axios\u0027s shouldBypassProxy does not recognize IPv4-mapped IPv6 addresses, allowing NO_PROXY bypass (incomplete fix for CVE-2025-62718)"
}
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.