Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Kestra

  • Four deadlines expire Saturday, which is why the day’s four fresh 9.8s are not the lead

    Four deadlines expire Saturday, which is why the day’s four fresh 9.8s are not the lead

    Four items published today carry a federal remediation deadline of Saturday, September 5. That is two days out, and it is the day’s lead. It outranks the four fresh 9.8s that landed alongside it, because a 9.8 with no confirmed exploitation and no clock attached is a patch you schedule, and a Saturday deadline is a patch somebody has to be at a keyboard for. Two of those 9.8s do not have a release number to install anyway.

    The thread is real, and it is CISA’s. Six of today’s ten stories trace back to one batch of Known Exploited Vulnerabilities additions made on September 2 — four due September 5, two due September 16. Running underneath it is the same problem in three of the four Saturday items: the authoritative record does not cleanly say what to install.

    Deal with SonicWall’s SMA1000 pair first. It is an internet-facing access appliance, it is the third zero-day pair on that product, and the CVE records SonicWall assigned itself list affected builds without naming a fixed one — two days before the deadline. Then JFrog Artifactory, where CISA’s listing is the first government confirmation that the unauthenticated administrative bypass is being exploited, and where the medium-severity Artifactory CVE listed six days earlier is now due five days later than the critical one. Then Sangoma’s Switchvox, where the release notes mark the fix for both cloud and on-premises but the only CPE on the record covers on-premises, so an agency running the cloud edition cannot tell from the record whether it is in scope. Then Kestra, the one of the four whose difficulty is a label rather than a version: CISA files it as OS command injection, and what an attacker actually reaches is a filter asking whether a request path ends with the word configs.

    The two September 16 items are lower on the clock and higher on reach. Starlette’s BadHost is a 6.5 by three independent scorers, which is the number most likely to send a KEV entry to the bottom of a patch queue — and Starlette is what FastAPI is built on, so the inventory question is not “do we run Starlette” but “what did we build on FastAPI.” LiteLLM is the narrower one, and the sharper bug: the MCP endpoint answered a failed key check by substituting an empty authorization object and letting the request through.

    After the clocked items, the 9.8s. Cisco’s Nexus 9000 Silicon One root RCE names ten switch SKUs and points its Fixed Software section at an interactive tool instead of a release number; the record has no CPE data at all. Cisco’s IOS XR hardening release, published the same afternoon, packages an internal audit into seven CVEs across every release, two of them 9.8, with one CVE ID standing for thirteen distinct weakness types. That is Cisco twice in one day, both times with a remediation story that is harder to read than the vulnerability. Delinea’s Secret Server takes a 9.8 at the FIDO2 registration step in a privileged access manager, and NVD deferred the record the following day, leaving it with no machine-matchable version data. And thirteen Craft CMS CVEs arrived from two CNAs, neither of them Craft, onto advisories that say “No known CVE” — with one advisory drawing two IDs and one record carrying a description for a different bug.

    What is still open. SonicWall has not named a fixed build for either SMA1000 CVE with the deadline on Saturday. JFrog has published no in-the-wild statement of its own; the government confirmed exploitation before the vendor did. Sangoma has not resolved the cloud-versus-on-premises scope on the record itself. Cisco’s first IOS XR fix that is not a software maintenance update has not shipped, and it revised the fixed-release list within six hours of publishing it. The Delinea record is deferred, so scanners matching on CPE will not flag an affected install.

  • Kestra is on a three-day federal clock for a command injection CVE whose actual flaw is a filter calling endsWith

    Kestra is on a three-day federal clock for a command injection CVE whose actual flaw is a filter calling endsWith

    CISA catalogs CVE-2026-49869 as an OS command injection flaw, but what an attacker actually exploits is a filter that checks whether a request path ends with the word configs.

    What happened

    CISA added CVE-2026-49869 in the Kestra orchestration platform to the Known Exploited Vulnerabilities catalog on September 2, 2026. NVD’s record carries CISA’s fields verbatim: cisaExploitAdd of 2026-09-02 and cisaActionDue of 2026-09-05. Federal agencies have three days.

    The catalog entry is titled “Kestra OSS OS Command Injection Vulnerability.” That is where the flaw ends up. It is not where it starts. NVD’s description states the mechanism plainly: “Prior to 1.0.45 and 1.3.21, AuthenticationFilter 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.”

    The whole vulnerability is endsWith where equals was intended. Kestra wanted one endpoint — the public configuration endpoint — to be reachable without credentials, and expressed that intent as a shape rather than an identity. Every other route in the API inherits the exemption for free, provided the attacker appends the right five characters.

    Kestra’s own advisory, GHSA-5vc5-wxxq-3fjx, published June 3, 2026, is titled “Unauthenticated Remote Code Execution via Authentication Bypass in AuthenticationFilter” and scores it 10.0 on CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. It explains what the bypass reaches. An unauthenticated caller can create and execute workflows, and Kestra ships its script plugins — Shell, Python, Node — enabled by default. Workflow creation is therefore code execution, running as root inside worker containers. The advisory also notes that the Pebble template engine’s http() function is unfiltered, which turns the same access into server-side request forgery against internal services and cloud metadata endpoints.

    Affected versions are 1.3.20 and below. Patched releases are 1.0.45 and 1.3.21.

    Trade coverage of the September 2 catalog additions reports that unknown actors have used the flaw to establish reverse shells and deploy cryptocurrency miners. CISA does not publish exploitation detail in the catalog itself, and we have not confirmed the payloads against a primary source; they are consistent with the shape of the bug but should be read as reported rather than established.

    One record detail is worth noting. NVD lists the CVE’s vulnStatus as “Analyzed,” but the only CVSS metric on the record comes from [email protected] as a Secondary source. There is no [email protected] Primary score. The 10.0 that will appear in every dashboard is the project’s own self-assessment, republished. It looks correct here. It is still not an independent one.

    Why it matters

    The gap between the catalog name and the mechanism is not pedantry, because of how remediation actually gets triaged. An organization that receives the September 2 KEV batch and sorts it by vulnerability class is looking for command injection in its orchestration tooling. What it needs to look for is an authentication filter that uses suffix matching. Those are different searches, and only one of them finds anything.

    The CVE record’s own classification shows the strain. It carries four CWEs: CWE-78 for the command injection, CWE-287 for the improper authentication, CWE-918 for the request forgery, and CWE-184 — incomplete list of disallowed inputs — for the filter logic itself. CWE-184 is the honest one. Every other entry describes an outcome. Only that one describes the decision that made the outcome possible: a security control that enumerated what it would allow by pattern instead of by name.

    CISA had to pick one title, and picking the endpoint of the chain is defensible. But the effect is that the catalog, which is increasingly the input to automated compliance work rather than something a human reads, files this under a class that will not match the thing an engineer greps for.

    The second point is about what Kestra is. Orchestration platforms are credential concentrators by design. Kestra exists to run jobs against databases, object stores, message queues, cloud APIs, and internal services, which means it holds — or can mint — access to most of them. Unauthenticated root execution inside its workers is not a compromise of one application. It is a compromise of the credential set for everything that application was built to reach. The unfiltered http() function makes that concrete: cloud instance metadata is one templated request away, and instance metadata is how container root becomes cloud role.

    Third, the timing. The fix shipped June 3, 2026. The KEV listing came September 2 — 91 days later. This is not a vendor failure; Kestra disclosed and patched cleanly, with a named advisory and a clear description. The exposure that CISA is now putting on a three-day clock is entirely operator-side patch lag on a self-hosted, open-source component.

    The branch split is part of why that lag persists. The advisory names two fixed releases, 1.0.45 and 1.3.21, and lists everything at or below 1.3.20 as affected. An operator running 1.1.x or 1.2.x will not find a fixed release on their own line. There isn’t one. They have to move to 1.3.21, which is a minor-version jump on a platform whose configuration surface changes between minors, and that is a materially harder change to schedule than a point release. Three days is not much time to discover that the fix is a migration.

    Finally, the payloads. Reverse shells and coin miners are commodity outcomes, and commodity outcomes come from indiscriminate scanning rather than from targeting. A 10.0 unauthenticated path in an internet-reachable open-source platform gets found by everyone, not by someone. Any Kestra instance that has been reachable from the internet on a vulnerable build since June should be treated as having been tried.

    What to do

    Check the running version, not the chart or manifest version. Anything at or below 1.3.20 is affected. Move to 1.3.21, or to 1.0.45 if you are genuinely on the 1.0 line. If you are on 1.1.x or 1.2.x, plan the jump to 1.3.21 now rather than looking for a backport that does not exist.

    If you cannot upgrade inside the window, the immediate mitigation is network placement. Kestra’s API should not be reachable from the internet, and a reverse proxy in front of it can reject any request path whose last segment is configs other than the single legitimate configuration endpoint. That is a stopgap that mirrors the bug rather than fixing it, and it should be treated as buying days, not as remediation.

    Assume you need to look, not just to patch. In the Kestra UI and database, list flows and executions created since early June and reconcile them against what your team actually authored — an injected flow will typically be a single script task with no history. On the hosts, check worker containers for outbound connections to addresses you do not recognize and for requests to 169.254.169.254. If instance metadata was reachable from a worker, rotate the role credentials that metadata endpoint would have handed out, on the assumption that they were taken.

    Federal agencies should read the required action in full. It says to “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s ‘Forensics Triage Requirements’ (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable.” The forensic obligation and the discontinue-use clause are both in there, and neither is satisfied by an upgrade.

    Sourcing note

    The KEV dates, required action text, description, CWE list, CVSS metric sourcing, and vulnStatus come from NVD’s API record for CVE-2026-49869, which republishes CISA’s fields verbatim. The advisory title, affected and patched version numbers, the default-enabled script plugins, and the unfiltered Pebble http() function come from Kestra’s own GitHub Security Advisory GHSA-5vc5-wxxq-3fjx, published June 3, 2026.

    CISA’s alert page and its KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD — NIST republishing CISA, a government primary source, but one that lags the catalog by hours and is not the catalog itself. The reverse-shell and cryptocurrency-miner payloads are from trade coverage of the September 2 batch and are not confirmed against a primary source.

    Unresolved: when exploitation began, which CISA does not publish and Kestra has not stated; whether any 1.1.x or 1.2.x backport exists that the advisory does not name; and why a record marked “Analyzed” by NVD carries no NVD Primary CVSS score.