GHSA-hpj9-grjp-7vc7: Medium severity maven/io.kestra:kestra vulnerability
Summary Kestra's Micronaut management endpoints are served on port 8081 with no authentication, even when the main API (port 8080) has basic-auth enabled. Anyone who can reach :8081 can read GET /env (full resolved environment/configuration) and mutate runtime state via POST /loggers/{name} (change log levels), among the other management endpoints. Enabling basic-auth creates a false sense of protection because the auth filter only covers /api/v1/ on 8080 and never applies to the 8081 management port. The shipped repository contains no statement that 8081 is management-only / must-not-be-exposed, and the vendor's reference docker-compose.yml publishes it with no warning. Affected - Product: Kestra (kestra-io/kestra), an open-source orchestration/data-pipeline platform (Java / Micronaut). - Version: v1.3.29 (confirmed); the management-port exposure is an insecure default of the shipped configuration. - No fix at time of report. Technical detail Kestra runs the Micronaut management/actuator endpoints on a separate HTTP port 8081. The authentication filter (basic-auth, when configured) is scoped to the main API on port 8080 (/api/v1/) and does not apply to 8081. As a result: - GET http://<host>:8081/env returns the full resolved environment/configuration (property sources), unauthenticated. - POST http://<host>:8081/loggers/{name} changes a logger's level at runtime, unauthenticated (a state-changing operation). - The other Micronaut management endpoints on 8081 are similarly reachable. The shipped application.yml comments, SECURITY.md, and the vendor's reference docker-compose.yml do not warn that 8081 must be kept internal, and the reference compose publishes 8081, so a deployment that enables basic-auth on the API still exposes the management port with no auth. Impact An unauthenticated network client that can reach port 8081 can read the full application configuration/environment (/env) and change runtime logging (/loggers), and reach the other management endpoints — an authentication-bypass on the management surface. (Sensitive credential values in /env are masked, so this is scored without a full-secret-read confidentiality impact.) Proof of concept Reproduced live on Kestra v1.3.29 with basic-auth enabled on the main API. Unauthenticated GET http://<host>:8081/env returned 200 with the resolved configuration/property sources, and POST http://<host>:8081/loggers/{name} returned 200 and changed the logger level — both with no credentials. The equivalent main-API request on 8080 returned 401 (control), confirming the auth filter covers only the API port and not the 8081 management port. (Credential values in /env were masked.) Full request/response captures available on request. Remediation Apply authentication to the management port (bind the Micronaut management endpoints behind the same auth as the API, or require a separate management credential), and by default bind port 8081 to loopback only. At minimum, document prominently (SECURITY.md, application.yml, the reference docker-compose) that port 8081 must never be exposed to untrusted networks, and do not publish 8081 in the reference compose. Credit Reported by Santosh Kumar Puppala (GitHub: https://github.com/Santoshkumarpuppala).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/io.kestra:kestrato a version that resolves this vulnerability.Fixed in 2.0.0 - Configuration
Bind Kestra Micronaut management endpoints (port 8081) to loopback only so port 8081 is not reachable from untrusted networks.
Kestra (Micronaut management port) management port bind address = loopback-only - Configuration
Apply authentication to the Micronaut management endpoints served on port 8081—bind them behind the same auth as the API on 8080, or require a separate management credential—because the basic-auth filter on 8080 (/api/v1/**) does not apply to 8081.
Kestra (Micronaut management endpoints on 8081) authentication enforcement = enable authentication on 8081 - Configuration
Do not expose/publish port 8081 in the reference docker-compose (ensure 8081 is not mapped to the host/public network).
Kestra deployment (reference docker-compose) port publishing for 8081 = do not publish 8081 - Configuration
Document prominently (SECURITY.md, application.yml, and the reference docker-compose) that port 8081 must never be exposed to untrusted networks and must remain internal.
Kestra documentation (SECURITY.md / deployment docs) documentation warning for 8081 = prominently document must-not-be-exposed
Event History
Frequently Asked Questions
Does configuring basic authentication on the main API protect the management interface?
No. The basic-auth filter applies only to /api/v1/** on port 8080 and does not cover the management endpoints on port 8081.
Who can exploit this exposure?
Any unauthenticated party that can reach port 8081 can access management endpoints. No credentials or user interaction are required.
What can an unauthenticated user do through the exposed interface?
They can retrieve the fully resolved environment and configuration through GET /env. They can also change runtime log levels through POST /loggers/{name}.
What should be done if a fix is not available?
Restrict access to port 8081 so that untrusted users cannot reach it. The shipped configuration exposes this management port by default, and the vendor reference docker-compose.yml publishes it without a warning.
How can I check whether an instance is affected?
Check whether port 8081 is reachable without authentication and whether GET /env responds. Version v1.3.29 is confirmed affected; no fix was available at the time of the report.