ARTEMIS-X Bump mockserver.version from 7.2.0 to 7.5.0

[dependabot]

Bumps mockserver.version from 7.2.0 to 7.5.0.
Updates org.mock-server:mockserver-netty from 7.2.0 to 7.5.0

Updates org.mock-server:mockserver-core from 7.2.0 to 7.5.0

Release notes

Sourced from org.mock-server:mockserver-core's releases.

MockServer 7.5.0

[7.5.0] - 2026-07-29

Security

• BREAKING: response templates can no longer reach arbitrary Java classes by default, closing the template remote-code-execution path reported as GHSA-7pwj-xvc2-hfpc. A caller who can reach the management API can register an expectation, and a response template was able to load java.lang.Runtime and execute OS commands in the MockServer process. Both engines that could do this are now sandboxed out of the box:
  • velocityDisallowClassLoading now defaults to true (was false), installing Velocity's SecureUberspector so a template cannot reach classes through $request.class.classLoader.loadClass(...). This is the more exposed half of the issue, and the half the report did not cover: Velocity ships in the DEFAULT distribution, whereas the JavaScript engine does not.
  • JavaScript templates now resolve no Java classes unless an operator grants them. Previously an empty javascriptAllowedClasses and empty javascriptDisallowedClasses meant unrestricted Java.type(...) access; that combination — the out-of-the-box state — now denies every class.
  • The GraalJS guest context no longer grants access to the members of java.lang.Class or java.lang.ClassLoader. Denying classes at Java.type(...) alone was not sufficient: real host objects are bound into the context (faker and the other built-in helpers), and under the previous HostAccess.ALL a template could walk from one of them to a classloader — faker.getClass().getClassLoader().loadClass('java.lang.Runtime') — reaching Runtime without the class filter ever being consulted. That walk is now closed, so host-class lookup is the single complete gate; a regression test drives four such walks (including through request) and fails if any resolves. Velocity's SecureUberspector already blocked the equivalent walk through its own bound helpers, which is now covered by a test too. Both flips are fully reversible with one property and remove no functionality: set mockserver.velocityDisallowClassLoading=false, or list the classes your templates need in mockserver.javascriptAllowedClasses (the single entry * lets any class resolve again). Templates that do not touch Java classes are unaffected, which is the overwhelming majority — JavaScript templates have the full ES2023 standard library available regardless of this setting. A refused class is logged once at WARN naming the class and the property to set, because GraalJS otherwise surfaces a refusal only as the class being undefined ("... is not a function"); the log is bounded and de-duplicated so a hostile template cannot flood it. mockserver.javascriptAllowedClasses is now also settable through the Spring test listener's @MockServerTest properties, which it was not before — it was a nice-to-have while the default was unrestricted, and is the only way to grant a class now that it is not. The insecure-mode WARN now fires when an operator has explicitly opened the sandbox rather than when it is closed. Proven end-to-end by a Netty integration test that registers the reported payload through the real management API and asserts the OS command creates no marker file, with a negative control on a deliberately unsandboxed server that DOES create it — so a regression cannot pass as an inert payload. This lands DEF-2 and DEF-3 of docs/plans/later/security-defaults.md ahead of the other default flips listed there; JavaScript went further than that plan proposed (deny everything, not a built-in "safe types" allow-list) because deny-by-default is the only form that stays safe as the JDK grows new reachable classes.

Fixed

• A property file that cannot be read is now reported instead of ignored in silence (#2358). When a mockserver.propertyFile an operator had explicitly configured could not be read, MockServer applied none of its properties and said nothing about it — at any log level. The only symptom was that every

... (truncated)

Changelog

Sourced from org.mock-server:mockserver-core's changelog.

[7.5.0] - 2026-07-29

Security

• BREAKING: response templates can no longer reach arbitrary Java classes by default, closing the template remote-code-execution path reported as GHSA-7pwj-xvc2-hfpc. A caller who can reach the management API can register an expectation, and a response template was able to load java.lang.Runtime and execute OS commands in the MockServer process. Both engines that could do this are now sandboxed out of the box:
  • velocityDisallowClassLoading now defaults to true (was false), installing Velocity's SecureUberspector so a template cannot reach classes through $request.class.classLoader.loadClass(...). This is the more exposed half of the issue, and the half the report did not cover: Velocity ships in the DEFAULT distribution, whereas the JavaScript engine does not.
  • JavaScript templates now resolve no Java classes unless an operator grants them. Previously an empty javascriptAllowedClasses and empty javascriptDisallowedClasses meant unrestricted Java.type(...) access; that combination — the out-of-the-box state — now denies every class.
  • The GraalJS guest context no longer grants access to the members of java.lang.Class or java.lang.ClassLoader. Denying classes at Java.type(...) alone was not sufficient: real host objects are bound into the context (faker and the other built-in helpers), and under the previous HostAccess.ALL a template could walk from one of them to a classloader — faker.getClass().getClassLoader().loadClass('java.lang.Runtime') — reaching Runtime without the class filter ever being consulted. That walk is now closed, so host-class lookup is the single complete gate; a regression test drives four such walks (including through request) and fails if any resolves. Velocity's SecureUberspector already blocked the equivalent walk through its own bound helpers, which is now covered by a test too. Both flips are fully reversible with one property and remove no functionality: set mockserver.velocityDisallowClassLoading=false, or list the classes your templates need in mockserver.javascriptAllowedClasses (the single entry * lets any class resolve again). Templates that do not touch Java classes are unaffected, which is the overwhelming majority — JavaScript templates have the full ES2023 standard library available regardless of this setting. A refused class is logged once at WARN naming the class and the property to set, because GraalJS otherwise surfaces a refusal only as the class being undefined ("... is not a function"); the log is bounded and de-duplicated so a hostile template cannot flood it. mockserver.javascriptAllowedClasses is now also settable through the Spring test listener's @MockServerTest properties, which it was not before — it was a nice-to-have while the default was unrestricted, and is the only way to grant a class now that it is not. The insecure-mode WARN now fires when an operator has explicitly opened the sandbox rather than when it is closed. Proven end-to-end by a Netty integration test that registers the reported payload through the real management API and asserts the OS command creates no marker file, with a negative control on a deliberately unsandboxed server that DOES create it — so a regression cannot pass as an inert payload. This lands DEF-2 and DEF-3 of docs/plans/later/security-defaults.md ahead of the other default flips listed there; JavaScript went further than that plan proposed (deny everything, not a built-in "safe types" allow-list) because deny-by-default is the only form that stays safe as the JDK grows new reachable classes.

Fixed

• A property file that cannot be read is now reported instead of ignored in silence (#2358). When a mockserver.propertyFile an operator had explicitly configured could not be read, MockServer applied none of its properties and said nothing about it — at any log level. The only symptom was that every property in the file appeared to be at its default, which surfaces far downstream as unexplained

... (truncated)

Commits

• 4c29b29 release: set version 7.5.0
• 545ed6d fix(oidc): revoke every spelling of a token, not just the string presented
• 726e02a docs(security): stop naming a release the template sandbox may not ship in
• a84fd8c fix(test-node): give TLS readiness a budget that survives a loaded agent
• 35246c2 fix(config): report a property file that cannot be read instead of ignoring it
• 083ebe1 build(deps): bump the maven-minor-and-patch group
• 2024884 build(deps): bump the npm-minor-and-patch group across 2 directories with 3 u...
• 6d2977f build(deps): bump distroless/java17 in /docker/graaljs
• 9cc2676 build(deps): bump distroless/java17 in /docker/clustered
• f335ec0 build(deps): bump actions/stale from 10.4.0 to 11.0.0
• Additional commits viewable in compare view

Updates org.mock-server:mockserver-client-java from 7.2.0 to 7.5.0

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)