See how kestra compares to other vendors in security performance
Kestra is an open-source, event-driven orchestration platform. Prior to 2.0.0-rc6, Kestra's cli/src/main/resources/application.yml serves Micronaut management endpoints on port 8081 without authentication even when Basic Auth protects /api/v1/ on port 8080, allowing unauthenticated GET /env requests to disclose resolved configuration and POST /loggers/{name} requests to change runtime log levels. This issue is fixed in 2.0.0-rc6.
Kestra is an open-source, event-driven orchestration platform. Prior to 2.0.0, Kestra's core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java passes the user-controlled http() uri argument to URI.create() and the server-side HTTP client without restricting private, loopback, or link-local destinations, allowing an unauthenticated attacker to import and execute a flow that accesses internal services or cloud metadata.
Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.45 and 1.3.21, AuthenticationFilter in Kestra OSS uses request.getPath().endsWith("/configs") to whitelist the public configuration endpoint from Basic Auth. Because the check is a suffix match rather than an exact path match, any API path whose last segment is configs bypasses authentication entirely. An unauthenticated remote attacker can exploit this to create and execute arbitrary workflows without credentials. Because Kestra ships with script execution plugins (plugin-script-shell, plugin-script-python, etc.) enabled by default, this directly results in unauthenticated Remote Code Execution as root inside the Kestra worker container. This vulnerability is fixed in 1.0.45 and 1.3.21.
Summary
Kestra’s Markdown renderer supports a custom [[link ...]] syntax that is converted into a custom HTML element. The custom Markdown parser allows attacker-controlled attributes to be rendered into the generated element without proper allowlisting or sanitization.
As a result, a user who can create or edit Markdown-rendered content, such as a Flow description, can inject JavaScript event-handler attributes. When another user views or interacts with the affected Markdown-rendered UI element, the JavaScript executes in that user’s browser.
This is not a normal raw-HTML Markdown payload such as <img onerror=...>. The payload uses Kestra’s custom [[link]] Markdown syntax, and the dangerous HTML attributes are introduced by Kestra’s own Markdown plugin.
Affected version
Tested on Kestra 1.3.22.
Affected components
Source review identified the issue in the custom Markdown link renderer:
ui/src/utils/markdownplugins/link.ts ui/src/utils/markdown.ts ui/src/components/layout/Markdown.vue
The vulnerable code path renders parsed attributes directly into an HTML string:
ts const attrs = token.attrs ? token.attrs.map(([name, value]) => ${name}="${value}").join("") : "";
return <router-md ${attrs}>;
The implementation does not safely restrict attribute names or values before inserting the generated HTML into the DOM.
Proof of concept
Create or edit a Flow with the following YAML:
yaml id: markdownxssflowdesc namespace: company.team description: | [[link x="y" style="position:fixed;inset:0;z-index:9999;background:rgba(255,0,0,0.05)" onmouseover="alert(document.domain)"]]
tasks: - id: hello type: io.kestra.plugin.core.log.Log message: hello
Save the Flow.
Then navigate to the Flow list:
text http://localhost:8080/ui/main/flows
Click the description/info icon next to the malicious Flow.
Actual result
The browser executes JavaScript from the Flow description. In the PoC, an alert is triggered showing the current domain.
Expected result
Markdown-rendered Flow descriptions should not be able to inject arbitrary JavaScript event handlers or attacker-controlled HTML attributes into the page.
The custom [[link]] syntax should only generate safe attributes required for the intended router-link behavior.
Security impact
An attacker with permission to create or update a Flow in a namespace can store a malicious Markdown payload in the Flow description. When another Kestra user views the Flow list and opens the Flow description/info panel, attacker-controlled JavaScript executes in the victim’s browser.
Depending on the victim’s privileges, this may allow the attacker to perform actions as the victim within the Kestra UI, access data visible to the victim, or pivot into more privileged namespace or administrative functionality.
This crosses a security boundary in multi-user Kestra deployments where Flow authors are less privileged than administrators or other operators who review workflows.
Suggested remediation
The custom Markdown link plugin should not render arbitrary attributes into raw HTML.
Recommended fixes:
1. Allowlist only the exact attributes required by the custom router link component. 2. Reject all attributes beginning with on, such as onclick, onmouseover, and onfocus. 3. Reject or sanitize dangerous attributes such as style. 4. HTML-escape all attribute values before rendering. 5. Ensure attributes are joined safely with spaces. 6. Sanitize the final rendered Markdown output before passing it to v-html. 7. Add regression tests for custom [[link]] payloads containing event-handler attributes.
Minimal payload
md [[link x="y" style="position:fixed;inset:0;z-index:9999;background:rgba(255,0,0,0.05)" onmouseover="alert(document.domain)"]]
Evidence collected
The payload was stored in a Flow description. The Flow list displayed the malicious Flow. Opening the Flow description/info panel triggered JavaScript execution in the browser. The payload did not require execution of the Flow. The payload used Kestra’s custom [[link]] syntax rather than raw HTML.
Kestra is an open-source, event-driven orchestration platform. Prior to version 1.3.7, Kestra (default docker-compose deployment) contains a SQL Injection vulnerability that leads to Remote Code Execution (RCE) in the following endpoint "GET /api/v1/main/flows/search". Once a user is authenticated, simply visiting a crafted link is enough to trigger the vulnerability. The injected payload is executed by PostgreSQL using COPY ... TO PROGRAM ..., which in turn runs arbitrary OS commands on the host. This issue has been patched in version 1.3.7.
Kestra v1.3.3 and before is vulnerable to SQL Injection. The vulnerability occurs because user-controlled input from a GET parameter is directly concatenated into an SQL query without proper sanitization or parameterization. As a result, attackers can inject arbitrary SQL expressions into the database query.
Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.43 and 1.3.19, several Kestra API endpoints accept a kestra:// URI from the client and pass it through StorageInterface.parentTraversalGuard before reading the underlying file from the local storage backend. The guard only inspects the literal URI.toString(), so a URL-encoded .. written as %2E%2E slips through. The downstream code then calls URI.getPath(), which decodes %2E%2E back to .., and the resulting path is handed to Paths.get(...) without normalization. The OS resolves the .. segments at open(2) time, so an authenticated user with a single execution can read any file the Kestra process has access to on the host filesystem (/etc/passwd, mounted secrets, other tenants' execution outputs, etc.). This vulnerability is fixed in 1.0.43 and 1.3.19.
Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.45 and 1.3.23, the local internal-storage backend validates user-supplied paths for .. traversal before it converts Windows-style backslashes to forward slashes. An attacker can therefore smuggle a traversal sequence past the guard using backslashes (..\..\..\); the guard sees a harmless string, and the path is only rewritten to ../../../ after validation, immediately before the file is opened. Any authenticated user who can view an execution (the lowest-privilege role) can call GET /api/v1/{tenant}/executions/{executionId}/file?path=… and read any file on the server filesystem readable by the Kestra process, outside the storage sandbox and across every tenant and namespace. This includes the embedded H2 database (all flows, all users, all stored secrets), internal storage of every other tenant/namespace, mounted secret files, and the process environment (/proc/self/environ) which contains configured database and secret-backend credentials. It is a complete breach of Kestra's storage isolation and multi-tenancy boundary. This vulnerability is fixed in 1.0.45 and 1.3.23.
Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.45 and 1.3.21, the authentication filter for the REST API (@Filter("/api/v1/")) treats any request whose path ends in /configs as the public instance-config endpoint and forwards it without a credential check. kestra addresses its resources by URL path segments that the caller chooses (/api/v1/{tenant}/flows/{namespace}, /api/v1/{tenant}/executions/{namespace}/{id}, /api/v1/{tenant}/namespaces/{namespace}/kv/{key}). An anonymous caller picks the literal configs as the final segment, and the request bypasses Basic-Auth entirely. Because the bypass reaches the flow-create and execution-trigger routes, an unauthenticated caller creates a flow containing a Shell or Process task and runs it. The task executes as root inside the kestra container. The official docker-compose.yml mounts /var/run/docker.sock, so root in the container reaches the host Docker daemon. This vulnerability is fixed in 1.0.45 and 1.3.21.
Kestra is an open-source, event-driven orchestration platform. Prior to 1.0.45 and 1.3.21, the previewFileFromExecution endpoint (GET /api/v1/{tenant}/executions/{executionId}/file/preview) contains an access control bypass that allows any authenticated user to read output files from any other execution within the same tenant, bypassing execution-level and namespace-level isolation. This vulnerability is fixed in 1.0.45 and 1.3.21.
Kestra is an open-source, event-driven orchestration platform. Prior to 1.3.24, this vulnerability exists in the BasicAuth authentication component of the Kestra OSS workflow orchestration platform. An attacker who gains read access to the PostgreSQL database can exploit SHA-512's high computation speed to recover the administrator password offline. In Kubernetes deployments, a successful crack further enables reading of the cluster ServiceAccount Token and all K8s Secrets, achieving vertical privilege escalation. This vulnerability is fixed in 1.3.24.
Kestra is an open-source, event-driven orchestration platform. Prior to versions 1.3.19, 1.2.19, 1.1.19, and 1.0.43, Kestra task inputFiles writes rendered file names directly under the task working directory. When a flow forwards untrusted execution or webhook data into an inputFiles file name, a caller can use ../ path segments to create or overwrite files outside that task working directory on the worker filesystem. Versions 1.3.19, 1.2.19, 1.1.19, and 1.0.43 patch the issue.
Kestra is an open-source, event-driven orchestration platform Versions up to and including 1.3.3 render user-supplied flow YAML metadata fields — description, inputs[].displayName, inputs[].description — through the Markdown.vue component instantiated with html: true. The resulting HTML is injected into the DOM via Vue's v-html without any sanitization. This allows a flow author to embed arbitrary JavaScript that executes in the browser of any user who views or interacts with the flow. This is distinct from GHSA-r36c-83hm-pc8j / CVE-2026-29082, which covers only FilePreview.vue rendering .md files from execution outputs. The present finding affects different components, different data sources, and requires significantly less user interaction (zero-click for input.displayName). As of time of publication, it is unclear if a patch is available.
Kestra is an event-driven orchestration platform. In versions from 1.1.10 and prior, Kestra’s execution-file preview renders user-supplied Markdown (.md) with markdown-it instantiated as html:true and injects the resulting HTML with Vue’s v-html without sanitisation. At time of publication, there are no publicly available patches.
Kestra is an event-driven orchestration platform. The error message in execution "Overview" tab is vulnerable to stored XSS due to improper handling of HTTP response received. This vulnerability is fixed in 0.22.0.