Severity Daily

IT and AI security incidents, checked against the primary source

Tag: kev-due-2026-09-05

  • 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.

  • Artifactory’s 9.8 bypass is KEV-listed and due September 5, five days before the medium-severity CVE whose fixed build is inside its affected range

    Artifactory’s 9.8 bypass is KEV-listed and due September 5, five days before the medium-severity CVE whose fixed build is inside its affected range

    CISA added CVE-2026-82329 to the KEV catalog on September 2, 2026 with a September 5 due date — five days earlier than the deadline on an Artifactory CVE listed a week before it, whose fixed build sits inside the new one’s affected range.

    What happened

    On September 1, 2026 this site reported that JFrog Artifactory’s unauthenticated administrative bypass, CVE-2026-82329, was being exploited on a single firm’s say-so and was not in the KEV catalog. Both halves of that have changed.

    The NVD record now carries CISA’s fields: cisaExploitAdd of 2026-09-02, cisaActionDue of 2026-09-05, and a cisaVulnerabilityName of “JFrog Artifactory Improper Authentication Vulnerability.” The record’s status moved to Analyzed, NVD attached CPE ranges to it, and it was last modified at 1:06 p.m. UTC on September 3, 2026. The CVE Program record’s CISA-ADP block, updated September 2, carries SSVC values of Exploitation: active, Automatable: yes, and Technical Impact: total, at SSVC version 2.0.3.

    That is the government confirming exploitation. Until September 2 the only public claim was watchTowr’s, made on September 1, that it was “already seeing exploitation of the JFrog Artifactory Auth Bypass (CVE-2026-82329), with attackers minting themselves admin tokens.” JFrog has still published no in-the-wild statement of its own; the vendor advisory description remains the single sentence it was on August 28: “JFrog Artifactory contains an authentication weakness that, under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges.” CVSS 3.1 base score 9.8, CWE-287, scored by JFrog as its own CNA. NVD has not added a primary score of its own.

    The federal deadline is Saturday, September 5, 2026. Three days from listing.

    The two deadlines are now in the wrong order

    Artifactory already had a KEV entry. CVE-2026-66384 — “An authenticated user may write data outside the intended Docker cache path under specific remote-repository conditions,” CWE-22, CVSS 3.1 base score 5.3, again scored by JFrog — was added to the catalog on August 27, 2026 with a cisaActionDue of 2026-09-10.

    So the medium-severity path traversal, listed first, is due last. The critical unauthenticated bypass, listed six days later, is due five days sooner. Nothing about that is an error. BOD 26-04 derives deadlines from internet exposure, KEV listing, exploit automation, and technical impact rather than from listing order, and a flaw CISA marks as actively exploited, automatable, and total in impact lands in a shorter band than one requiring authentication and specific repository conditions. But an agency working a queue sorted by date added is working it in the wrong order, and the compliance artifact will not say so.

    The version numbers make it worse than a scheduling nuisance. JFrog fixed CVE-2026-66384 in 7.146.35 and 7.161.16. It fixed CVE-2026-82329 in 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20. NVD’s CPE ranges for the newer CVE now encode that: 7.146.0 to below 7.146.38, and 7.161.0 to below 7.161.20. So 7.146.35 and 7.146.36 and 7.146.37 are all inside the affected range of the September 5 vulnerability. An administrator who upgrades to 7.146.35 to satisfy the September 10 deadline has moved onto a build that is unauthenticated-admin-bypassable, and has done it four days after the deadline for the flaw that makes it so.

    This site flagged that gap on September 1, when it was a severity argument. It is now a conflict between two federal deadlines on the same product.

    Why it matters

    There is a second, quieter problem in how the two records model versions, and it decides what “patched” means for anyone not on the newest branch.

    NVD gives CVE-2026-82329 six per-branch ranges, one for each supported release line. It gives CVE-2026-66384 something different: a single open-ended range with no lower bound, everything below 7.146.35, plus 7.161.0 to below 7.161.16. Read literally, that says an Artifactory instance on 7.133.29 — a build JFrog names as fixed for the critical bypass — is still affected by the older path traversal, because 7.133.29 is less than 7.146.35. And it is not obviously wrong: JFrog shipped the 66384 fix on two branches only. There is no 7.133 build that closes it.

    Put the two together and the arithmetic has exactly one answer. An organization on the 7.133 line cannot satisfy both KEV entries on its own branch at all. It has to move to 7.146, and if it moves to 7.146.35 it lands inside the range of the CVE due first. 7.146.38 and 7.161.20 are the only builds that clear both deadlines. Every other combination leaves one of the two open, and a vulnerability scanner keyed to CPE will report it honestly if you ask it about both CVEs and misleadingly if you ask it about either one.

    This is the second time in six days that Artifactory has produced this shape, and it is worth naming as a general test rather than a JFrog complaint. A product that supports six release branches concurrently will, sooner or later, ship two advisories days apart whose fix levels differ on the same branch. When the older advisory is the one that reaches the KEV catalog first, its named fix version becomes a remediation target that was already superseded. The check is mechanical: whenever a KEV entry names a fixed version, look for any later advisory against the same branch before you set that version as the target. Ivanti, Fortinet, and Citrix all ship parallel branches and are all capable of the same thing.

    One more thing worth watching on this record. JFrog’s own CNA data lists the lowest affected range as version 0 up to 7.111.21 — everything below that build, with no floor. NVD’s CPE for the same branch starts at 7.111.4. That narrowing is NVD’s transcription, not a JFrog statement, and it excludes older 7.111 builds that the vendor’s own record describes as affected. If you are on a 7.111 build below 7.111.4, trust the vendor record over the CPE.

    What to do

    • Upgrade to 7.146.38 or 7.161.20. These are the only builds that satisfy both KEV entries. 7.111.21, 7.117.28, 7.125.20, and 7.133.29 close CVE-2026-82329 but leave CVE-2026-66384 open per NVD’s range for it.
    • Federal agencies: CVE-2026-82329 is due Saturday, September 5, 2026, and its required action pairs remediation with CISA’s forensic triage obligation. CVE-2026-66384 is due September 10. Work them in deadline order, not listing order.
    • Do not treat 7.146.35 or 7.161.16 as a remediation target. Both are inside the affected range of the September 5 CVE.
    • Configure a join key. watchTowr’s account of the mechanism is that instances without an additional join key configured receive a “phantom” join key an attacker can use to forge access. That is one firm’s description of the bug, not JFrog’s, and JFrog’s advisory names no workaround — but it is the only mitigation description in public.
    • Assume compromise on any internet-reachable instance that was unpatched after August 28. Look for administrator tokens you did not create, then for enumeration of users, groups, credential sets, and federated access topologies — the post-exploitation behavior watchTowr described.

    Sourcing note

    The KEV fields, CVSS scores, CWE, status, and CPE ranges for both CVEs were read from the NVD API records (CVE-2026-82329 lastModified 2026-09-03T13:06:15.630; CVE-2026-66384 lastModified 2026-08-28T12:21:47.053). The CNA record for CVE-2026-82329 was read from the CVE Program API — assigner JFROG, updated September 2, 2026, with the CISA-ADP SSVC block quoted above. cisa.gov returns HTTP 403 to automated fetching from this container, so the catalog page and the September 2 alert were not read directly; CISA’s fields come from NIST’s republication of them in NVD.

    The exploitation mechanism and the post-exploitation description are watchTowr’s, published September 1, 2026, and remain single-sourced. What is new since our September 1 story is that CISA has independently listed the CVE as exploited and attached the ADP values; that is corroboration of the fact of exploitation, not of watchTowr’s account of how it works. JFrog has not published an in-the-wild statement and did not respond to press inquiries reported on September 1.

    Unresolved: whether JFrog intends to backport the CVE-2026-66384 fix to branches below 7.146, which would give 7.111, 7.117, 7.125, and 7.133 users a way to clear both deadlines without a branch move. Its advisory names no such build. Also unresolved, and carried over from our September 1 story: JFrog’s advisory notation for affected ranges does not state whether the right-hand build is inclusive, so 7.146.36 and 7.146.37 are described by the vendor as neither affected nor fixed. NVD resolves it conservatively. Act on NVD’s reading.

  • Switchvox draws a September 5 federal deadline, and Sangoma’s release notes mark the cloud edition fixed while NVD’s record covers only on-premises

    Switchvox draws a September 5 federal deadline, and Sangoma’s release notes mark the cloud edition fixed while NVD’s record covers only on-premises

    CISA added CVE-2026-9586 to the Known Exploited Vulnerabilities catalog on September 2, 2026 with a September 5 due date, and Sangoma’s own release notes check “Cloud” alongside “On-Prem” for the fix — while the only CPE on the NVD record ends in on-premises.

    What happened

    The NVD record for CVE-2026-9586 carries CISA’s fields verbatim: cisaExploitAdd of 2026-09-02, cisaActionDue of 2026-09-05, and a cisaVulnerabilityName of “Sangoma Switchvox SQL Injection Vulnerability.” Federal civilian agencies have until Saturday, September 5, 2026 to act.

    The cisaRequiredAction is the standard BOD 26-04 text. Two clauses matter below: agencies must “Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable,” and they are “responsible for evaluating each asset’s internet exposure.” It also invokes CISA’s “Forensics Triage Requirements.”

    From the record: “An unauthenticated SQL injection vulnerability exists in Sangoma Switchvox SMB Edition 8.3 (104997). The /pa endpoint processes XML content beginning with <PolycomIPPhone> and directly concatenates the user-controlled PhoneIP value into PostgreSQL queries without sanitization or parameterization. An unauthenticated remote attacker can execute arbitrary SQL statements against the backend PostgreSQL database using a single crafted request, including database operations and remote code execution.” The class is CWE-89. Horizon3, which analyzed the code path, places it in PhoneAppsHandler.pm and says the queries run as a PostgreSQL superuser.

    Two scores sit on the record. SRA, the CNA that assigned the CVE, scored it CVSS 4.0 at 9.3 critical; NVD’s own analysts scored it CVSS 3.1 at 9.8 critical as the primary source. Most coverage has carried the 9.3. The two are on different scales rather than in dispute — but a triage rule keyed to “9.5 and above” sorts this vulnerability differently depending on which field it reads.

    Sangoma shipped the fix on July 14, 2026, in Switchvox 8.4.0.2, and published no security advisory. What exists is a release-notes page on Sangoma’s knowledge base with a resolved-issues table; the word “security” does not appear anywhere on it. The table has an “Issue” column and two check columns headed “On-Prem” and “Cloud.” Every row is checked in both.

    The rows, verbatim: “CWE-89 – Improper Neutralization of Special Elements used in an SQL Command”; “CWE-22 – Improper Limitation of a Pathname to a Restricted Directory”; “CWE-78 – Improper Neutralization of Special Elements used in an OS Command”; “CWE-269 – Improper Privilege Management”; “CWE-918 – Server-Side Request Forgery”; “CVE-2026-9588 – Authenticated Stored Cross-Site Scripting (XSS) in Switchvox Web Portal”; “CVE-2026-9587 – Authenticated Local File Inclusion (LFI) in Switchvox Web Portal”; “CVE-2026-9586 – Unauthenticated RCE via SQL Injection in SwitchVox 8.2.2.1”; “CVE-2026-9585- Unauthenticated Reflected Cross-Site Scripting (XSS) in Switchvox Web Portal.”

    Five CWE rows and four CVE rows, and they do not describe the same set of fixes. CWE-79 — cross-site scripting, the class of two of the four listed CVEs — is not in the CWE list. CWE-78, CWE-269, and CWE-918 map to none of the four CVE descriptions. Horizon3 says it reported twelve distinct vulnerabilities to Sangoma on April 10, 2026. Four CVE IDs exist for this release, all assigned by SRA and all credited to Cam Lischke of SRA. Severity Daily could not match the three unaccounted-for CWE rows to any published CVE.

    The disclosure ran on two tracks. Horizon3 reported its twelve findings on April 10, 2026 and had a patched pre-release build from Sangoma by April 21. SRA submitted its four between May 11 and May 26 and says Sangoma acknowledged them on June 2. The patch shipped July 14; SRA published the CVEs on July 17.

    Exploitation came six weeks after the fix. Horizon3, running honeypots with Defused Cyber since May 8, 2026, says it saw exploitation on August 30, 2026 — netcat reverse shells and enumeration commands, artifacts landing in /var/log/switchvox/db-quirks.log, and one address, 176.65.148.184, moving across multiple sensors. That is a single research firm’s honeypot data. Horizon3 published on September 1; CISA listed the CVE on September 2, and the record’s CISA-ADP block now carries Exploitation: active, Automatable: yes, and Technical Impact: total. Horizon3 puts internet-exposed instances at roughly 4,000 by Shodan count, mostly in the United States — one vendor’s scan, and it should be read as one.

    Why it matters

    The cloud column is the part with an action attached to it. CISA’s required action tells agencies to “Follow applicable BOD 26-04 guidance for cloud services.” Sangoma’s release notes check Cloud alongside On-Prem, which is a vendor statement that the hosted edition was affected. NVD’s record disagrees by omission: its single CPE is cpe:2.3:a:sangoma:switchvox:*:*:*:*:on-premises:*:*:*, versions 8.2.2.1 up to but excluding 8.4.0.2, and there is no cloud or hosted CPE on the record at all.

    CPE strings are what asset-matching tools consume. An organization running the hosted edition and matching its inventory against this record gets no hit, produces a clean report, and never asks the question the required action is telling it to ask. It cannot patch a hosted service in any case — but it can demand written confirmation that the fix reached its tenant, and the KEV entry is the reason to ask this week rather than next quarter. The vendor’s own bug list is currently better evidence of cloud exposure than the federal vulnerability record is.

    The second thing worth sitting with is how this fix was communicated. There is no advisory page, no security mailing-list entry, no vendor CVSS score, and no use of the word “security” on the page that announces the fix. The CVE identifiers are present — Sangoma did list them — but as bug rows in a changelog. An operator who subscribes to vendor security advisories learned nothing; an operator who diffs release notes learned everything. Six weeks later, roughly 4,000 instances were still reachable, and attackers found them before most defenders read the changelog.

    Then the version numbers. Three statements of where the affected range begins, and no two agree. SRA’s CVE record and advisory both say “8.3 (104997)” through versions before 8.4.0.2. NVD’s CPE says 8.2.2.1 through 8.4.0.2 exclusive. Sangoma’s release-notes row names the flaw as being “in SwitchVox 8.2.2.1.” NVD’s range is the widest, and the widest is the one to act on — but an administrator on an 8.2 build reading the CVE description alone would reasonably conclude the record does not describe their system.

    Finally, the clock. This CVE was published on July 17, 2026 and drew a three-day deadline on September 2 — the shortest band BOD 26-04 defines, and one that obliges agencies to carry out a forensic triage of the asset rather than merely patch it. The record now carries CISA’s own machine-readable values for three of the four variables the directive uses: exploitation, automation, and technical impact are all in the ADP block. The fourth, internet exposure, is left to the agency, which is exactly what the required action says. What is not published in machine-readable form is the schedule those variables feed into. CISA distributes that mapping as Table 1 in Appendix A, as PNG images with no alt text, and the vendors who transcribed it by eye disagree with each other about which combinations earn three days. The inputs are in the record; the function is a picture. Do not reason backward from this deadline to the table.

    What to do

    • Upgrade to Switchvox 8.4.0.2 or later — the only fixed build named by the vendor, the CVE record, and NVD alike.
    • Federal agencies: the due date is Saturday, September 5, 2026, and the required action pairs remediation with CISA’s forensic triage obligation. Patching alone does not close it.
    • Hosted-edition customers: ask Sangoma in writing whether the fix has been applied to your tenant. The release notes check “Cloud”; the NVD record has no cloud CPE, so inventory tooling will not raise this for you.
    • Check /var/log/switchvox/db-quirks.log for anomalous SQL and shell commands. This is Horizon3’s stated artifact location, from honeypot data rather than from the vendor.
    • The /pa endpoint should not be reachable from the internet. It accepts unauthenticated XML by design. Restricting it to the phone VLAN removes the attack path regardless of version.
    • 176.65.148.184 is the one address Horizon3 named — a single campaign’s infrastructure, not an indicator list.

    Sourcing note

    CISA’s KEV fields, the CVSS scores, the CWE, the CPE range, and the description were read from the NVD API record for CVE-2026-9586 (lastModified 2026-09-03T13:06:25.427), retrieved twice with different query forms; the CPE scope claim — that no cloud or hosted CPE exists on the record — was confirmed on both. The CNA record was read from the CVE Program API: assigner SRA, published July 17, 2026, updated September 2, 2026, credit to Cam Lischke of SRA, and CISA-ADP values of active exploitation, automatable, total technical impact. Sangoma’s release notes for 8.4.0.2 were fetched twice with different prompts; the resolved-issues table, the On-Prem and Cloud columns, and the absence of the word “security” were consistent across both. SRA’s advisory at labs.sra.io supplied the disclosure timeline and the other three CVEs. Horizon3’s disclosure page supplied the honeypot timeline, the log artifact, the attacker address, and the Shodan count — all single-sourced to Horizon3, none verified independently here, and the exposure figure is a scan estimate, not a count of vulnerable systems.

    cisa.gov returns HTTP 403 to automated fetching from this container, so the KEV catalog page and the September 2 alert were not read directly; CISA’s fields were taken from NIST’s republication of them in NVD, the standing practice on this site. Unresolved: whether the three CWE rows with no matching CVE — CWE-78, CWE-269, and CWE-918 — correspond to any of the twelve vulnerabilities Horizon3 says it reported, and whether identifiers were ever assigned for them. Sangoma has published no security advisory for this release, so there is no vendor document in which to look.

  • 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.

  • SonicWall’s third SMA1000 zero-day pair draws a September 5 federal deadline, and its own CVE records name no fixed version

    SonicWall’s third SMA1000 zero-day pair draws a September 5 federal deadline, and its own CVE records name no fixed version

    CISA added both SMA1000 flaws to the Known Exploited Vulnerabilities catalog on September 2, 2026 with a September 5 remediation deadline, and the CVE records SonicWall assigned itself list affected builds without naming a fixed one.

    What happened

    SonicWall published two CVEs for its SMA1000 secure access appliances on September 1, 2026, and CISA added both to the Known Exploited Vulnerabilities catalog the following day. NVD’s records carry CISA’s own fields verbatim: cisaExploitAdd of 2026-09-02 and cisaActionDue of 2026-09-05 on each. That is a three-day federal clock, and it expires this Saturday.

    The first, CVE-2026-83548, is scored 10.0. SonicWall’s own description is short: “A Pre-authentication SSRF vulnerability exists in the SMA1000 Appliance Work Place interface due to an unintended alternate access path.” The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — network reachable, no privileges, no user interaction, and a changed scope, which is what carries it to a perfect ten. The record is classified CWE-918 for the request forgery and CWE-441, confused deputy, for the access path itself. CISA catalogs it as “SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability.” The finder credited on the record is Adam Babis of SonicWall PSIRT.

    The second, CVE-2026-83549, is scored 7.8 and sits in the Appliance Management Console rather than the user-facing Work Place. SonicWall describes it as a “Post-authentication Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) vulnerability … which in specific conditions could potentially enable a remote authenticated attacker as administrator to execute arbitrary OS commands, resulting in remote code execution.”

    Read on its own, that second record does not look like a three-day emergency. Its vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. AV:L means local attack vector. PR:L means low privileges required. But the prose in the same record says “remote” and says “as administrator.” The vendor’s sentence and the vendor’s vector, on one record, describe two different attacks. Neither NVD nor CISA reconciles them; both simply republish what the CNA supplied.

    The two records together do resolve into something coherent. A pre-authentication request forgery with a changed scope in the Work Place interface is a way to reach things the appliance can reach but you cannot. An administrator-context command injection in the management console is a way to run code once you are there. That is a chain, and CISA’s decision to add both on the same day under the same deadline is consistent with the pair being used together rather than each being used alone.

    The remediation action CISA attached to both is its current standard text: “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk guidance and CISA’s ‘Forensics Triage Requirements’.” That last clause is not decoration. BOD 26-04’s three-day band includes entries that carry an additional obligation, and the directive states it plainly: “The text ‘& forensic triage’ means that the agency must complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised.” Patching is half of what is being asked here.

    Why it matters

    The version ranges are the part worth sitting with. SonicWall’s CNA record lists the affected builds for the September pair as “12.4.3-03453 (platform-hotfix) and older” and “12.5.0-02835 (platform-hotfix) and older.” In July, the same appliance line took a nearly identical pair: CVE-2026-15409, also a pre-authentication SSRF in the Work Place interface, also scored 10.0 on an identical vector, added to KEV on July 14, 2026 with a cisaActionDue of 2026-07-17 — also three days. That record’s affected ranges topped out at 12.4.3-03434 and 12.5.0-02800.

    Compare the ceilings. July’s affected range ended at build 03434. September’s affected range includes everything up to and including 03453. An administrator who did exactly what the July advisory asked — moved past 03434 onto a later build — landed inside the range that the September advisory now calls vulnerable. The remediation was real and the exposure returned anyway, in the same interface, with the same root class of flaw, seven weeks later.

    This is the third round in nine months for this product line. It is worth being precise about what is and is not established across those rounds. The July pair was attributed by Volexity to an actor it tracks as UTA0533, with a named malware set; that attribution belongs to July and to Volexity, and nothing published so far ties the September pair to the same actor. Trade coverage of the September round also reports that attackers in the earlier intrusions extracted TOTP seed material, and that SonicWall’s guidance advised log review and reimaging rather than patching alone. We could not read SonicWall’s advisory page to confirm that language, and we are not treating it as confirmed. The reason to mention it is that it explains why CISA’s forensic-triage clause is attached rather than a bare patch instruction: on an appliance that terminates remote access, the question of whether the box was already used is separate from the question of whether the hole is closed.

    The second thing worth noting is where the fixed build number lives. Both NVD records point at one authoritative vendor source, SNWLID-2026-0016 on SonicWall’s PSIRT portal. That page returns a document containing a title and no advisory body; the content is assembled by JavaScript after load. Automated tooling — and any reader without a browser — gets nothing from it. SonicWall’s own CVE records, which are machine-readable and which the company controls, list the affected versions and carry no fixed-version field at all. The result is that the build numbers an administrator needs on a three-day clock reach them through third-party transcription. Beazley Security’s advisory gives them as 12.4.3-03526 and 12.5.0-02952. That is very probably right. It is also a security firm reading a vendor’s rendered web page on the vendor’s behalf, which is not where a remediation deadline should get its version numbers.

    Correction, September 3, 2026, 4:10 p.m. CT: The paragraph above is wrong on its central point. SonicWall does publish the fixed builds in a document a non-browser client can read — a product notice carrying the same SNWLID-2026-0016 identifier at sonicwall.com/support/notices/, distinct from the psirt.global.sonicwall.com page the CVE records name as the authoritative reference. That notice, dated September 1, 2026, lists 12.4.3-03526 and 12.5.0-02952 as the remediation builds. The build numbers therefore do not reach administrators only through third-party transcription, and Beazley Security’s advisory agrees with the vendor rather than standing in for it. What remains accurate: SonicWall’s CVE records still carry no fixed-version field, and the reference those records point to is the page that does not render. The same notice also confirms in SonicWall’s own words the guidance this story treated as unverified trade coverage: “Contact SonicWall Technical Support for assistance reviewing the system for indicators of compromise (IoCs). If IoCs are detected: Re-image (hardware) or re-deploy (virtual) appliances. Change all user and administrator passwords. Reset TOTP tokens.”

    This publication has now seen the same shape three times in a week: HPE’s Aruba bulletin, whose fixed-version page did not render; Amelia’s changelog, which described a critical fix as routine; and now a vendor whose structured record omits the one field that closes the deadline. The fix keeps arriving before the record of it does.

    What to do

    Identify SMA1000 6210, 7210, and 8200v appliances and read the platform-hotfix build, not the marketing version. If it is at or below 12.4.3-03453 or 12.5.0-02835, it is in the affected range on SonicWall’s own record. Move to 12.4.3-03526 or 12.5.0-02952. [Corrected September 3, 2026: these builds are confirmed against SonicWall’s own product notice for SNWLID-2026-0016 at sonicwall.com/support/notices/. The original sentence here told readers to verify them in a browser because we believed only a third-party transcription existed. That was wrong.]

    Federal agencies are past the point where patching alone satisfies the requirement. The required action names forensic triage; plan for the asset assessment alongside the upgrade, not after it.

    Everyone else should treat the appliance as a candidate for review rather than a box that is now fine. Pull Work Place and management console logs back through June and look for requests that reached internal addresses the appliance should never have contacted, and for administrative sessions that do not match a known change. If you find evidence of pre-patch access, reissue MFA enrollment rather than resetting passwords: a rotated password invalidates a stolen password, and neither invalidates a stolen seed.

    Sourcing note

    KEV dates for CVE-2026-83548, CVE-2026-83549, and CVE-2026-15409 were taken from NVD’s API records, which republish CISA’s cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, and cisaRequiredAction fields verbatim. Affected version ranges, CVSS vectors, descriptions, and the finder credit come from SonicWall’s CNA records retrieved from the CVE Program API — SonicWall is the assigner for all of these, so that is the vendor’s own text.

    [Corrected September 3, 2026: we could not read the psirt.global.sonicwall.com vulnerability-detail page for SNWLID-2026-0016, which returns no advisory body without JavaScript execution and which this newsroom does not execute scripts for. We did not find, and should have found, SonicWall’s product notice for the same advisory ID on sonicwall.com, which renders as static HTML and carries the fixed builds, the CVSS scores, and the IoC and TOTP guidance. It was retrieved twice on September 3, 2026 with different prompts and returned the same values both times. The original text of this paragraph follows.] We could not read SNWLID-2026-0016 directly. The page returns no advisory body without JavaScript execution, and this newsroom does not execute page scripts. CISA’s own alert page and KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD rather than directly; that is NIST republishing CISA and is a government primary source, but it lags the catalog by hours and is not the catalog itself. The fixed build numbers 12.4.3-03526 and 12.5.0-02952 are transcribed from Beazley Security’s advisory BSL-A1201 and are not confirmed against a SonicWall document we could read.

    The July attribution to UTA0533 is Volexity’s, reported through trade coverage, and applies to the July pair only. The TOTP seed extraction and the reimaging guidance are from trade coverage and are unconfirmed against a primary source; they are reported here as claims and were not used to establish any fact about the September pair. Unresolved: whether the internal conflict on CVE-2026-83549 between “remote … as administrator” in the description and AV:L/PR:L in the vector reflects an error in the vector or an imprecise description, and whether builds between 12.4.3-03434 and 12.4.3-03453 were ever a complete remediation for the July pair.