EnvironmentEndpoint passes the user-supplied pattern directly to
Pattern.compile(...) when building the predicate used to filter property
names.
As a result, an invalid regex such as GET /actuator/env?pattern=[ appears to
raise a PatternSyntaxException before the request can be translated into the
actuator's usual bad-request path.
The actuator MVC and WebFlux handler mappings currently translate
InvalidEndpointRequestException into 400 Bad Request, but that path does
not seem to be used here.
Other actuator endpoints already use InvalidEndpointRequestException for
invalid user input. For example, MetricsEndpoint#parseTag does this for
malformed tag parameters.
A similar issue was addressed in gh-9730, where the approach was a try-catch
fallback because the value came from a path variable and the user's intent was
ambiguous. Now that pattern is an explicit query parameter, wrapping the
error in an InvalidEndpointRequestException might be more appropriate.
Steps to reproduce:
- Start any Spring Boot application with the
env actuator endpoint exposed
- Send
GET /actuator/env?pattern=[
- Observe that the invalid pattern does not appear to be handled as a bad
request
Relevant locations:
module/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/env/EnvironmentEndpoint.javamodule/spring-boot-webmvc/src/main/java/org/springframework/boot/webmvc/actuate/endpoint/web/AbstractWebMvcEndpointHandlerMapping.javamodule/spring-boot-webflux/src/main/java/org/springframework/boot/webflux/actuate/endpoint/web/AbstractWebFluxEndpointHandlerMapping.javamodule/spring-boot-micrometer-metrics/src/main/java/org/springframework/boot/micrometer/metrics/actuate/endpoint/MetricsEndpoint.java
Spring Boot version: current main branch
I believe this also affects 3.5.x as the same code path is shared there.
If this looks like a bug, I can put together a small PR.
EnvironmentEndpointpasses the user-suppliedpatterndirectly toPattern.compile(...)when building the predicate used to filter propertynames.
As a result, an invalid regex such as
GET /actuator/env?pattern=[appears toraise a
PatternSyntaxExceptionbefore the request can be translated into theactuator's usual bad-request path.
The actuator MVC and WebFlux handler mappings currently translate
InvalidEndpointRequestExceptioninto400 Bad Request, but that path doesnot seem to be used here.
Other actuator endpoints already use
InvalidEndpointRequestExceptionforinvalid user input. For example,
MetricsEndpoint#parseTagdoes this formalformed
tagparameters.A similar issue was addressed in gh-9730, where the approach was a try-catch
fallback because the value came from a path variable and the user's intent was
ambiguous. Now that
patternis an explicit query parameter, wrapping theerror in an
InvalidEndpointRequestExceptionmight be more appropriate.Steps to reproduce:
envactuator endpoint exposedGET /actuator/env?pattern=[request
Relevant locations:
module/spring-boot-actuator/src/main/java/org/springframework/boot/actuate/env/EnvironmentEndpoint.javamodule/spring-boot-webmvc/src/main/java/org/springframework/boot/webmvc/actuate/endpoint/web/AbstractWebMvcEndpointHandlerMapping.javamodule/spring-boot-webflux/src/main/java/org/springframework/boot/webflux/actuate/endpoint/web/AbstractWebFluxEndpointHandlerMapping.javamodule/spring-boot-micrometer-metrics/src/main/java/org/springframework/boot/micrometer/metrics/actuate/endpoint/MetricsEndpoint.javaSpring Boot version: current
mainbranchI believe this also affects
3.5.xas the same code path is shared there.If this looks like a bug, I can put together a small PR.