Controlled SSRF through URL in the WireMock

Root

Cause

WireMock allows administrators to restrict which target addresses the proxy mode can forward requests to through a list of allowed and denied rules [1]. However, in the WireMock Webhooks Extension prior to version 3.0.0-beta-15, this filtering did not apply to webhook-triggered requests [2]. This means that even if an administrator had configured limitProxyTargets to restrict proxying, a webhook configuration could still forward POST requests to any address reachable by the WireMock instance [2].

Attack

Vector

A threat actor could exploit this vulnerability by crafting a webhook that targets an arbitrary internal or external service [2]. The attack requires the ability to configure a webhook on the WireMock instance—this could be achieved through administrative access or by leveraging another vulnerability that allows modification of stubs or settings [2]. For example, if WireMock is running within a private cluster (e.g., a Docker container in a Kubernetes environment), an attacker could use a webhook to trigger POST requests against unsecured internal APIs or even secured endpoints by supplying an authentication token obtained from another exploit [2].

Impact

Successful exploitation enables the attacker to perform unauthorized HTTP POST requests to any service that the WireMock instance can reach [2]. This can lead to lateral movement, data exfiltration, or disruption of internal services, depending on the network topology and the sensitivity of the targeted endpoints [2]. The vulnerability is particularly critical in environments where WireMock is deployed with network access to internal, non-public services.

Mitigation

The issue has been patched in WireMock versions 2.35.1 and 3.0.3 [2]. Users who are unable to upgrade should implement external firewall rules to restrict outbound traffic from the WireMock instance to only permitted destinations [2]. Note that WireMock Studio, a discontinued product, will not receive a fix [2].