Summary
Kestra: Unauthenticated management/actuator endpoints exposed on port 8081 (/env, /loggers) bypass API basic-auth
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/envreturns 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 shippedapplication.ymlcomments,SECURITY.md, and the vendor's referencedocker-compose.ymldo 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.
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.
Credit
Reported by Santosh Kumar Puppala (GitHub: https://github.com/Santoshkumarpuppala).
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.)
A critical operation is accessible without requiring any authentication. Typical impact: any user can invoke the privileged function.
CVE-2026-73245 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.0.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-73245? CVE-2026-73245 is a medium-severity missing authentication for critical function vulnerability in io.kestra:kestra (maven), affecting versions < 2.0.0. It is fixed in 2.0.0. A critical operation is accessible without requiring any authentication.
- How severe is CVE-2026-73245? CVE-2026-73245 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of io.kestra:kestra are affected by CVE-2026-73245? io.kestra:kestra (maven) versions < 2.0.0 is affected.
- Is there a fix for CVE-2026-73245? Yes. CVE-2026-73245 is fixed in 2.0.0. Upgrade to this version or later.
- Is CVE-2026-73245 exploitable, and should I be worried? Whether CVE-2026-73245 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-73245 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-73245? Upgrade
io.kestra:kestrato 2.0.0 or later.