NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
MEDIUM severity

CVE-2023-41327 — wiremock-webhooks-extensi…

MEDIUM

CVE-2023-41327 is a medium-severity (CVSS 4.6) Server-Side Request Forgery (SSRF) vulnerability in org.wiremock:wiremock-webhooks-extension. A fix is available for org.wiremock:wiremock-webhooks-extension — see the affected versions and patch details below.

Controlled SSRF through URL in the WireMock

Also known asBIT-wiremock-2023-41327GHSA-hq8w-9w8w-pmx7
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Nov 7, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2023-41327.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs43th percentile — riskier than 43% of all scored CVEsHighest risk
0.00%0.33%0.67%1.00%0.2%0.5%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected
☕org.wiremock:wiremock-webhooks-extension☕org.wiremock:wiremock-webhooks-extension

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Impact

WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. Documentation.

Until WireMock Webhooks Extension 3.0.0-beta-15, the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were 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. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passing a token, discovered using another exploit, via authentication headers.

Affected components

  • WireMock Webhooks Extension 2.x versions until 2.35.1 (security patch)
  • WireMock 3.x version until 3.0.3 (security patch)
  • All versions of WireMock Studio (discontinued). This distribution bundles the WireMock Webhooks Extension and activates it by default

Patches and Mitigation

NOTE: It was confirmed that WireMock Cloud does not expose sensitive internal APIs and hence not vulnerable to the issue. No action is needed if you use this SaaS distribution.

Workarounds

  • Use external firewall rules to define the list of permitted destinations

References

Credits

  • @W0rty for reporting CVE-2023-39967 in WireMock Studio
  • WireMock Inc. team for discovering similar exploits in Webhooks and the risk in the Proxy mode defaults for WireMock

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenorg.wiremock:wiremock-webhooks-extension≥ 3.0.0&&< 3.0.33.0.3org.wiremock:wiremock-webhooks-extension:3.0.3
☕Mavenorg.wiremock:wiremock-webhooks-extension≥ 2.0.0&&< 2.35.12.35.1org.wiremock:wiremock-webhooks-extension:2.35.1

Affected Products

2 products · 3 configurations
Application
studiowiremock
≤ 2.32.0-17
range
Application
wiremockwiremock
≥ 3.0.0 && < 3.0.3
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.wiremock:wiremock-webhooks-extension, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update org.wiremock:wiremock-webhooks-extension to 3.0.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2023-41327 is resolved across your whole dependency graph.

  3. Workarounds

    Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Frequently Asked Questions

### Impact WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. [Documentation](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). Until WireMock Webhooks Extension [3.0.0-beta-15](https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-15), the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially v
O3 Security · Impact-Aware SCA

Is CVE-2023-41327 in your dependencies?

Find it across Maven, including transitive dependencies.

CVE-2023-41327: wiremock-webhooks — Fixed in 3.0.3