[9.1.0] - 2026-10-21

Security

• Control-plane mTLS could be bypassed by sending the CA certificate after an untrusted client certificate. With controlPlaneTLSMutualAuthenticationRequired on, MockServer 5.13.0 to 9.0.0 accepted a control-plane request if any certificate the client sent could be validated against controlPlaneTLSMutualAuthenticationCAChain. A CA certificate is public, so anyone who could reach the control plane could send their own certificate followed by your CA certificate and create, read or delete expectations, change the configuration or reset the server, without the CA's private key. Also requiring data-plane mTLS (tlsMutualAuthenticationRequired) did not prevent this in the default set-up: the data-plane check also trusts MockServer's own CA, which by default is the CA bundled with MockServer, and its private key is published in the jar, so an attacker could sign their certificate with it. Data-plane mTLS prevented it only if MockServer had its own CA (certificateAuthorityCertificate and certificateAuthorityPrivateKey, or dynamicallyCreateCertificateAuthorityCertificate) and every CA in tlsMutualAuthenticationCertificateChain was private. MockServer now checks only the client's own certificate (the one whose private key it used for the connection): it must be signed by a CA in the chain, directly or through intermediate CA certificates the client sends after it, be in date, allow digital signatures if it lists key usages, allow client authentication if it lists extended key usages, and not be a CA certificate, a self-signed certificate or one of the certificates in the chain. A self-signed client certificate listed in controlPlaneTLSMutualAuthenticationCAChain is no longer accepted; sign client certificates with a CA instead. A controlPlaneTLSMutualAuthenticationCAChain that contains the bundled CA (or any certificate for its key) is now refused: MockServer does not start, PUT /mockserver/configuration answers 400, and any other change makes every control-plane request fail, where before only a warning was logged. If MockServerClient and MockServer share that property in one JVM (for example ClientAndServer or the JUnit rule) and you added the bundled CA so the client trusts MockServer's certificate, give MockServer its own CA with certificateAuthorityCertificate and certificateAuthorityPrivateKey and put that CA in the chain instead. The control-plane audit log now records the validated client certificate's subject as a verified principal (verified-mtls) unless OIDC supplied one; with mTLS and JWT both on, the audit principal is now the certificate subject instead of the unverified JWT sub. If a MockServer reachable by others had control-plane mTLS on, with or without data-plane mTLS, treat its expectations, recorded traffic and settings as possibly read or changed by someone else
• mTLS (tlsMutualAuthenticationRequired) no longer accepts client certificates anyone can create (BREAKING for mTLS set-ups that use MockServer's default CA; see upgrading to 9). Up to 9.0.0, MockServer trusted client certificates signed by MockServer's own CA whenever mTLS was on, even with tlsMutualAuthenticationCertificateChain set. By default that CA is the one bundled with MockServer, and its private key is published in the MockServer jar, so anyone could create a client certificate, with any name, that MockServer accepted. That client also matched any client certificate condition in your expectations and, when control-plane authentication was off, could create, read or delete expectations. MockServer now never trusts the bundled CA for mTLS. If mTLS is on and nothing but the bundled CA would be trusted, or tlsMutualAuthenticationCertificateChain contains the bundled CA, MockServer does not start, PUT /mockserver/configuration answers 400, and the message names the fix: give MockServer

[9.0.0] - 2026-10-15

This release delivers a sustained performance and memory programme alongside data-integrity fixes under load, plus a large set of LLM-provider correctness fixes, dashboard improvements, and client-library parity work. Headline numbers from the single-load-generator benchmark on the same six-core rig (builds 420 and 464): the healthy ceiling rises from 39,033 to 57,149 req/s and the peak from 43,671 to 59,905 req/s, with p95 at 32,000 req/s falling from 56.6 ms to 0.44 ms on the new ZGC default in the Docker images; event-log retained heap at 20,000 entries falls from 429 MB to 61 MB; Docker image download shrinks ~23%; and instance shutdown drops from ~107 ms to near zero. 22 BREAKING changes affect HTTP/3, DNS mocking, binary (non-HTTP) proxying and binary expectation matching while proxying, template-failure response codes, maxLoggedMatchFailures's default, initialisation-file id conflicts, the Node client's TypeScript typings and exports map, LOG_ENTRIES log output, control-plane error handling and mTLS, the Rust client's enums, verification-failure wording, response statusCode validation, AsyncAPI and response/OpenAPI verification, GenAI trace span names, the Node client's recorded-request typings, and the Go client/Testcontainers module's /v9 module paths — see Upgrading from 8.0.0 and the BREAKING entries under Changed. For a per-change migration list, see the upgrade guide at https://www.mock-server.com/mock_server/upgrading_to_9.html.

"Before" is perf build 420 (commit d568695a2, 2026-09-24, JDK 17.0.20, G1 collector), measured nine days after the 8.0.0 tag and already carrying some of this release's own work, since 8.0.0 itself was never measured on this rig. "After" is perf build 464 (commit efdc5227b2, 2026-09-27, JDK 25, ZGC), the performance page's single-load-generator figures; the page's headline is now a different, multi-generator measurement (see Changed). Both are comparable with each other but not with any benchmark published after this release.

Upgrading from 8.0.0

• Go client and Go Testcontainers module users: both modules move to /v9 module paths (the Go module proxy refused their 8.0.0 tags) — run go get github.com/mock-server/mockserver-monorepo/mockserver-client-go/v9 (and the Testcontainers module's /v9 path if you use it) and change your imports from the /v7/unsuffixed paths to the /v9 ones; see Changed.
• HTTP/3 users (http3Port set): the QUIC native library now ships separately — use the -jar-with-dependencies-http3 jar or the mockserver/mockserver:<version>-http3 Docker image (latest-http3, snapshot-http3; Helm: image.variant=http3), and a server that cannot serve HTTP/3 (missing native, or the port unusable) now refuses to start instead of silently falling back.
• DNS mocking users (dnsEnabled=true): MockServer now refuses to start if its dnsPort cannot be bound, instead of logging a warning and running without DNS. Leave dnsPort at its default of 0 to let the OS pick a free port, or set dnsEnabled=false.
• TypeScript users of mockserver-client/llm: the deep-import typings no longer declare a default export; import from mockserver-client itself, use import llm = require(...)/import * as llm from ..., or turn on esModuleInterop (see Changed).
• Binary (non-HTTP) proxy users: a client connection now always keeps one upstream connection for its whole life — forwarding one message per upstream connection is removed, along with its `forwardBinaryRequestsWithoutWaitingForRespo

[8.0.0] - 2026-09-15

Added

• Test port allocation can opt into a fixed port band instead of the OS ephemeral range. org.mockserver.socket.PortFactory normally finds a free port with bind(0), which draws from the same ephemeral range (on macOS net.inet.ip.portrange.hifirst..hilast, typically 49152-65535) that every other bind(0) on the machine uses — including unrelated applications, IDE helpers, and other JVMs. On a busy developer machine that causes two kinds of test flake: a foreign process can occupy a number a test is about to choose, and a test can momentarily connect to that foreign listener instead of the server under test. Setting both mockserver.testPortRangeStart and mockserver.testPortRangeEnd (for example -Dmockserver.testPortRangeStart=20000 -Dmockserver.testPortRangeEnd=40000) makes PortFactory choose ports by explicitly binding inside that band — which the OS does not itself hand out to bind(0) — retrying past any number already in use. Both properties are unset by default, so continuous integration and any machine that does not set them keep the exact bind(0) behaviour as before. This affects only test port selection; it does not change how MockServer binds its own ports at runtime (starting on port 0 and reading back the assigned port remains the fully race-free option and is unchanged). In a surefire/failsafe fork the two properties must reach the fork, e.g. via -Dmockserver.testArgLine="-Dmockserver.testPortRangeStart=20000 -Dmockserver.testPortRangeEnd=40000".

Changed

• HTTP/2 now gives every request stream its own channel. MockServer's HTTP/2 server — both h2 (over TLS) and cleartext h2c — now uses Netty's stream-multiplexing model for every connection, replacing the previous shared-connection HTTP/2 pipeline. Each HTTP/2 stream is processed on its own isolated child channel. This removes a class of cross-stream interference on busy connections: concurrent streaming responses (Server-Sent Events, NDJSON, AWS Bedrock event-stream, and therefore all streaming LLM responses) can no longer have a later chunk of one stream mis-routed onto another, and each stream's end-of-stream is delivered independently, so a slow or streaming response on one stream cannot stall another. This model was previously used only when grpcBidiStreamingEnabled was set; it is now the standard HTTP/2 pipeline and needs no configuration — so the HTTP/2 correctness fixes listed below apply to all HTTP/2 traffic, not only when that flag is enabled. There is no change to the REST/Java API, to how expectations are written, or to HTTP/1.1 and HTTP/3 traffic, and HTTP/2 clients receive the same responses. Users driving very large numbers of concurrent streams over a single connection may notice different memory and throughput characteristics, since each stream now has its own lightweight channel. (GitHub issue #2669).
• Behaviour change — over HTTP/2, closeSocket now ends the stream, not the connection. A per-expectation ConnectionOptions.closeSocket / closeChannel (and the slowCloseDelay connection-lifecycle chaos) applied to an HTTP/2 request now closes only that request's stream; other requests in flight on the same connection continue and complete normally. Previously it tore down the whole TCP connection, killing every concurrent stream on it — so one expectation could destroy unrelated clients' in-flight requests. Ending a single stream is the correct HTTP/2 semantic and is what the same expectation already did over HTTP/1.1, where a connection carries one request at a time. If you rely on closeSocket to tear down an HTTP/2 connection — for example to test how your client recovers from a dropped connection — use the resetMidResponse connection-lifecycle chaos fault instead, which still aborts the whole TCP connection (that is its purpose, and it now does so properly rather than degrading into a single-st

[7.6.0] - 2026-08-17

Changed

• The three Kubernetes container-integration cases that need Java-built images — helm_sidecar_injection (admission-webhook sidecar injection), helm_clustered_convergence, and helm_jgroups_dns_ping (both the -clustered Infinispan image) — now run blocking in CI instead of recording a skip. Previously the CI helm step ran with no JDK and never built those images, so all three recorded an honest but permanent SKIP — coverage that looked green while proving nothing. A new :maven: build container-test images (jars) step in the mockserver-container-tests pipeline builds the mockserver-netty, mockserver-k8s-webhook, and mockserver-state-infinispan jars from the tree (once, via the Maven-in-Docker reactor) and hands them to the helm step as Buildkite artifacts; the helm step downloads them and does cheap docker builds (a COPY into distroless) to produce the -clustered and mockserver-webhook images, then runs the suite. The jars travel as artifacts (~200 MB total) rather than docker saved images (~1.3 GB), mirroring the node-launcher / WAR hand-off. Both layers fail closed: the helm step exits non-zero if any jar artifact is absent, and the harness runs with REQUIRE_CLUSTERED_IMAGE=true/REQUIRE_WEBHOOK_IMAGE=true so an image that is expected-but-absent is recorded as a FAILURE, never a skip — a skip in CI is now impossible. Local container_integration_tests/integration_tests.sh is unchanged for a developer without the images: it still records a comprehensible SKIP (no fail-closed flag set), and the harness now also builds the mockserver-webhook image locally (build_webhook_docker) so the sidecar case runs blocking in local dev too — it was never built by the harness before, so that case had always skipped.

Added

• Two new rules in the always-on check-false-green-guards.sh CI gate. Rule 4 fails the build if a CI step runs the container-integration harness with the helm/k3d cases active but does not export both REQUIRE_CLUSTERED_IMAGE=true and REQUIRE_WEBHOOK_IMAGE=true — the exact way the three image-dependent Kubernetes cases could silently revert to a green SKIP. It is keyed on the step's behaviour (invokes integration_tests.sh without SKIP_HELM_TESTS=true), not on a filename, so a rename or a second helm-running step is covered automatically. Rule 5 fails the build if a mockserver-core test that performs a JVM-global logging side effect (reaching LogManager.readConfiguration's handler reset() via the static ConfigurationProperties logging setters or a forced fresh <clinit>) is not in the sequential-tests include list — the shape behind a release-blocking flake that ParallelStaticStateGuardTest structurally cannot catch. Both rules fail closed on an empty corpus and carry a rotating allow-list. See docs/operations/false-green-guards.md.
• A jarPath launcher option and matching MOCKSERVER_JAR_PATH environment variable for mockserver-node, pointing start_mockserver at a pre-provisioned mockserver-netty jar-with-dependencies instead of downloading one from Maven Central. When set, that exact jar is launched and no download is attempted; a configured-but-missing path is a hard error (... refusing to fall back to downloading a release) rather than a silent fall-back to a released jar, so a missing artifact fails loudly. Mirrors the existing MOCKSERVER_BINARY_BASE_URL bring-your-own-artifact path for the standalone binary, and serves air-gapped/corporate installs as well as testing a locally-built jar (jarPath takes precedence over mockServerVersion/artifactory*; the option beats the env var). The Node launcher integration tests now use it in CI: a new :maven: build node launcher jar step builds the jar from the tree and the launcher-test step downloads it as an artifact and launche