W0Rty

WireMock is a tool for mocking HTTP services. When certain request URLs like "@127.0.0.1:1234" are used in WireMock Studio configuration fields, the request might be forwarded to an arbitrary service reachable from WireMock's instance. There are 3 identified potential attack vectors: via "TestRequester" functionality, webhooks, and the proxy mode. As we can control HTTP Method, HTTP Headers, HTTP Data, it allows sending requests with the default level of credentials for the WireMock instance.

The issue is related to insufficient checking of incoming requests in WireMock, a tool for mocking HTTP services. This can allow a remote attacker to redirect POST requests to arbitrary services. The filtering of target addresses from the proxy mode did not work for Webhooks until WireMock Webhooks Extension 3.0.0-beta-15, making users potentially vulnerable regardless of the `limitProxyTargets` settings. Via the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock’s instance.

The issue is related to the proxy mode of WireMock, which can be protected by network restrictions configuration. However, when these restrictions are configured using domain names, the configuration is vulnerable to DNS rebinding attacks. The root cause of the attack is a defect in the logic that allows for a race condition triggered by a DNS server whose address expires between the initial validation and the outbound network request. Control over a DNS service is required to exploit this attack, resulting in high execution complexity and limited impact.

The issue is related to the lack of proper sanitization of external links, which can be used for a Cross-Site Scripting (XSS) attack. This allows a remote attacker to exploit the vulnerability.

The issue is related to the usage of RSS feeds or an external calendar in planning, which is subject to a Server-Side Request Forgery (SSRF) exploit. If a remote script returns a redirect response, the redirect target URL is not checked against the URL allow list defined by the administrator. This could allow a remote attacker to redirect users to an arbitrary URL.