Severity Daily

IT and AI security incidents, checked against the primary source

Tag: open source

  • Mail Mint’s 9.8 was fixed in a release whose security note is about something else, and the record points the gadget chain at a bundled PostHog SDK

    Mail Mint’s 9.8 was fixed in a release whose security note is about something else, and the record points the gadget chain at a bundled PostHog SDK

    The unauthenticated deserialization was fixed on September 1 in a release whose only security bullet describes a different change, and the one file the record cites outside the plugin’s own code is a bundled third-party analytics SDK.

    What happened

    CVE-2026-10196 was published to the National Vulnerability Database at 12:16 p.m. UTC on Saturday, September 5, 2026, with Wordfence as the assigning CNA. It scores 9.8 on vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and is classified CWE-502, deserialization of untrusted data.

    The product is Mail Mint – Email Marketing, Newsletter, Email Automation & WooCommerce Emails, published by getwpfunnels, which WordPress.org lists at more than 4,000 active installations. The record’s description says the plugin “is vulnerable to PHP Object Injection in all versions up to, and including, 1.31.0 via deserialization of untrusted input in the ‘handle_form_submission’ function,” and adds the sentence that carries the score: “The additional presence of a POP chain allows attackers to execute code on the server.”

    That sentence is doing all the work. An unauthenticated attacker who can get arbitrary serialized data into unserialize() has object instantiation, which on its own is often a nuisance. It becomes remote code execution only when the running codebase also contains a property-oriented programming chain — a class whose magic methods, invoked as PHP tears the object down, do something useful to an attacker. Without a chain the finding is high; with one it is 9.8.

    The record does not say where the chain is. Its source-code references do point somewhere specific. Wordfence cites three files, each twice — once at the 1.21.0 tag and once at trunk:

    • app/API/Actions/Frontend/FormAction.php at line 59
    • app/Database/models/ContactModel.php at line 460
    • vendor/posthog/posthog-php/lib/Consumer/ForkCurl.php at line 96

    The first two are Mail Mint’s own code — the form handler named in the description, and the model it writes through. The third is not Mail Mint’s code at all. It is PostHog’s PHP analytics SDK, vendored into the plugin’s vendor/ directory by Composer. Upstream, that class builds a curl command as a string and hands it to PHP’s exec(); the version on PostHog’s master branch calls exec() twice, at lines 64 and 77, and defines no magic methods of its own. We could not read the copy bundled inside Mail Mint at line 96 — the WordPress plugin repository’s code browser refuses automated retrieval — so we cannot confirm what that specific line contains or that it is the chain.

    The fix exists. WordPress.org shows the current version as 1.31.1, released September 1, 2026, four days before the CVE was published. The affected range stops at 1.31.0, so 1.31.1 is the version to be on. Two changesets are referenced in the record, 3545065 and 3675453; both returned rate-limit errors to us and are unread.

    The 1.31.1 changelog does use the word “security.” It attributes it to something else: “Contact action links now use unguessable tokens,” a link-forgery fix. The entry covering the code this CVE is about is worded as an improvement to form submission error handling. Neither deserialization nor object injection appears.

    Why it matters

    The severity of a deserialization bug is not a property of the deserialization bug. It is a property of everything else that happens to be loaded in the same PHP process at the same time. That is the uncomfortable part of CWE-502 and it is why these findings are so hard to triage from a distance.

    Mail Mint’s own code, on the record’s own account, supplies the sink: a form handler that unserializes attacker-controlled input without authentication. What lifts that from a serious bug to a 9.8 is a chain — and the only file the record points at that Mail Mint’s developers did not write is a bundled analytics library whose entire purpose is to shell out to curl. We are not asserting that PostHog’s SDK is vulnerable; a class that calls exec() is not a vulnerability, it is a design choice appropriate to a library that ships HTTP payloads. The point is narrower and more awkward: a plugin author’s exposure to this class of bug is set partly by the contents of a vendor/ directory they did not audit and may not think of as theirs.

    This is a recurring shape in the WordPress ecosystem specifically, because plugins ship their dependencies rather than resolving them at runtime. Every plugin on a site contributes its vendored classes to one shared autoloader and one shared process. A gadget introduced by plugin A can be reachable from a sink introduced by plugin B. Nothing in a CVE record for either plugin will tell you that, and nothing in a scanner’s output will either.

    The practical consequence for a defender is that “we removed the vulnerable plugin” and “we are safe” are different claims. If the sink is gone, that install is fixed. But the same vendored SDK ships inside other plugins, and the presence of a usable chain on a given site is a function of the whole plugin set, not of any one entry in it.

    The changelog point is smaller but worth recording, because it is the second time today this site has run into it. This morning we covered three WordPress plugins that reintroduced comment XSS after core had sanitized it, none of whose changelogs said security. Mail Mint’s does say security — about a different change in the same release. A site owner reading the 1.31.1 notes to decide whether to update urgently would conclude the security content was a link-tokenization improvement, and would have no way to know that the same release closed an unauthenticated path to code execution. The four-day gap between the release and the CVE is the window in which the changelog was the only public description of what 1.31.1 did.

    What to do

    • Update Mail Mint to 1.31.1 or later. The affected range is everything up to and including 1.31.0, and 1.31.1 has been available since September 1, 2026. This is the whole fix for the sink.
    • Check WooCommerce sites first. The plugin’s transactional and abandoned-cart features mean it is most often installed on stores, where the same process also holds order and customer data.
    • Treat the pre-update window as reachable. The path is unauthenticated with no user interaction, so exposure did not require a logged-in user. If the site was on 1.31.0 or earlier and public, review web server logs for POSTs to the plugin’s form endpoint and look for unexpected files under wp-content.
    • Inventory vendored dependencies, not just plugins. Grep your plugin directory for vendor/posthog, and more usefully for any vendored class that calls exec, shell_exec, proc_open or system. That set is your site’s gadget surface and it does not appear in any plugin list.
    • Do not read the changelog as the severity signal. Read the CVE record and the affected range.

    Sourcing note

    Checked against primary sources: the NVD record for CVE-2026-10196, retrieved September 5, 2026, which supplied the description, score, vector, CWE, affected range and the full reference list quoted above; the WordPress.org listing and changelog for the mail-mint plugin, which supplied the current version, its release date and install count; and PostHog’s posthog-php repository on GitHub for the upstream contents of lib/Consumer/ForkCurl.php.

    Could not reach: the WordPress plugin repository’s code browser, which refuses automated retrieval, so none of the six trac source references in the record were read, including the ForkCurl.php line 96 that this story discusses. The two referenced changesets returned HTTP 429 rate-limit errors and are unread, so what 1.31.1 actually changed is taken from the changelog rather than from a diff. Wordfence’s own threat-intelligence entry for this vulnerability does not render to automated retrieval.

    Unresolved: the record states a POP chain is present but does not name it, and we have not confirmed that the chain runs through the bundled PostHog SDK — that reading is inferred from the record’s reference list and is stated as an inference, not a finding. getwpfunnels has published no security advisory we could find. There is no indication in any source that this flaw has been exploited, and it is not in CISA’s Known Exploited Vulnerabilities catalog.

  • AVideo’s statistics endpoint returns every viewer’s password hash, and the project’s own advisory says the hash logs you in

    AVideo’s statistics endpoint returns every viewer’s password hash, and the project’s own advisory says the hash logs you in

    Five more CVE records landed against the open-source video platform on Saturday afternoon, bringing the 30-day total to 46, and not one of them names a version to upgrade to.

    What happened

    Five CVE records for WWBN AVideo, the self-hosted open-source video-sharing platform, were published to the National Vulnerability Database at 1:18 p.m. UTC on Saturday, September 5, 2026. All five arrived within a second of one another. All five carry [email protected] as the source identifier, meaning VulnCheck assigned them as the CNA. Two are rated critical.

    The one that matters most is CVE-2026-86190, scored 9.1. NVD’s description reads: “WWBN AVideo contains a broken access control vulnerability in videoViewsInfo endpoints that returns complete user records including password hashes, recovery tokens, and live session identifiers to unauthenticated callers when a hash parameter is provided.”

    The project’s own advisory is more specific than the CVE record. GHSA-82q2-88mq-p44q, published by the AVideo maintainers on August 21, 2026, says the statistics endpoints serialize “the entire joined users record for every viewer, including the password hash, the password-recovery token, and the viewer’s live session identifier.” It puts a number on it: “An anonymous request therefore returns 52 fields per viewer, among them password, recoverPass, email, phone, address, birth_date, isAdmin and session_id.”

    The second critical, CVE-2026-86189 at 9.8, is a path traversal in notify.ffmpeg.json.php that lets an unauthenticated caller write a file to a path of its choosing. The authentication in front of it is a token called notifyCode. The project’s advisory, GHSA-cprx-fggj-7vpq, describes the check in one sentence: “notifyCode is tested for non-emptiness only. Its contents are never compared against anything.” AVideo mints those tokens as encryptString(time()), and accepts any string that decrypts to something non-empty — so any ciphertext the site has ever issued, including the video_id_hash values it publishes, satisfies the check.

    The other three published Saturday are lower-scored and still worth noting. CVE-2026-86186 (6.5) says the API “fails to enforce rate limits when clients send a bot User-Agent header,” defeating login brute-force protection. CVE-2026-86187 (5.9) says external-login account passwords are generated with rand() rather than a cryptographic generator, “producing only 31-bit integers,” and that “Attackers with access to password hashes can recover plaintext passwords in minutes.” CVE-2026-86188 (7.2) is cross-site scripting reachable by an unauthenticated caller when the YPTSocket plugin is enabled.

    The scale is hard to see from any single record. An NVD keyword search for AVideo, bounded to records published between August 6 and September 5, 2026, returns a totalResults of 46. Every one of the records visible in that result set carries VulnCheck as the source. The project’s own GitHub advisory list shows the same burst from the other side: pages of advisories dated August 27 through September 2, most of them credited to a single reporter, rajivraj.

    None of the 46 names a fixed version. AVideo’s most recent tagged release is 29.0, dated April 7, 2025 — seventeen months ago. NVD’s affected-version data for both criticals reads as versions 0 through 29.0 inclusive, and every GitHub advisory we read states its affected version as “current (e01e41ecc) and earlier” with “Patched versions: None.”

    The severity numbers do not agree, either. For the file-write flaw, the project rated it High at CVSS 8.2, the CVE record says Critical at 9.8, and VulnCheck’s own advisory page gives a CVSS v4.0 score of 9.3. For the data-exposure flaw the ranking inverts: the project called it Critical at 9.8, the CVE record says 9.1, and VulnCheck’s page again says 9.3. A reader checking all three sources gets three numbers per flaw, and the two flaws the maintainer scored 1.6 points apart come out identical under v4.0.

    Why it matters

    Read CVE-2026-86190 on its own and it is a bad information disclosure: an unauthenticated caller gets email addresses, phone numbers, birth dates and password hashes. Hashes are supposed to be the part you can afford to lose for a while, because cracking costs time and money.

    Two other AVideo advisories say that assumption does not hold here. GHSA-fq38-jp6c-q4cx, published by the project on September 1, 2026 and rated Critical at 9.8, states flatly: “Submitting the value of users.password as the password logs the account in. No encodedPass flag is needed; the ordinary browser login form is enough.” Its title says the rest — “any disclosure of users.password is a direct login with no cracking.” That advisory has no CVE identifier yet. And for accounts created through external login, CVE-2026-86187 says the underlying password is a 31-bit rand() value recoverable from its hash in minutes anyway.

    So the disclosure is not a step on the way to compromise. On the maintainer’s own account of its code, it is the compromise, and the session_id field in the same response skips the password question altogether by handing over a live administrator session. We have not tested that chain, and no one has published a combined exploit for it; what we are reporting is that three advisories written by the same project about the same codebase, taken together, describe it. Each half is the maintainer’s own statement, not an inference by a third party.

    The notifyCode defect is a different and more instructive kind of mistake. The code does real cryptography — it decrypts the token — and then treats the fact that decryption succeeded as proof that the caller was authorized. Nothing checks what came out. That is the same shape as two stories this site has run in the past two days: python-jose accepting a public key as an HMAC secret because the 2024 fix inspected the key’s format instead of its role, and Coolify logging a user in on an OAuth email match alone. In each case a security-relevant value is validated for shape and never for meaning.

    The version data deserves its own note, because it will mislead scanners. “Affected: 0 through 29.0” reads like a bounded range with a safe side above it. There is no safe side. 29.0 is the newest release AVideo has ever shipped, so the ceiling of the affected range and the current release are the same build — the same structure this site described in Coolify’s record earlier today, where the affected ceiling 4.3.17 is also the shipping version. A vulnerability-management tool that renders “≤ 29.0” as a range will imply an upgrade path that does not exist.

    Finally, the batch. Forty-six CVEs against one project in thirty days, from one CNA and largely one researcher, is the second such burst this week: MOOS-IvP took 33 VulnCheck-assigned CVEs at once on September 4. These bursts are good for the record and hard on defenders. They land as dozens of separate scanner findings against one asset, and the triage question stops being “which of these do I patch” and becomes “do I keep running this at all.” AVideo’s maintainers deserve some credit here: publishing your own advisories with “Patched versions: None” is more candid than the common alternative of sitting on them. Candor does not give an operator anything to install.

    What to do

    AVideo is self-hosted, so nobody will patch it for you and there is nothing to patch. Treat this as an exposure decision, not a patching one.

    • Find it. Look for AVideo installs by their /objects/ path prefix and endpoints such as notify.ffmpeg.json.php and the videoViewsInfo API. Shared hosting and marketing-department video portals are where these turn up unrecorded.
    • Take it off the public internet. With no fixed release available, network exposure is the only control you own. Put the instance behind a VPN or an authenticating proxy.
    • Block the two named endpoints at the reverse proxy if the instance must stay reachable. That is a mitigation standing in for a patch, and it addresses only the two flaws with CVEs today, not the other 44.
    • Assume every stored hash is already disclosed. Force a password reset for all accounts, invalidate all sessions, and rotate recovery tokens and stream keys. Because the hash functions as a password on this platform, a reset — not a “monitor for misuse” posture — is the containment step.
    • Do not triage on the CVE score alone. The maintainer and the CNA disagree by up to 1.6 points and in opposite directions on the two criticals; read the GitHub advisory, which is more specific than the CVE record in both cases.
    • Watch the repository’s advisory list, not its releases page. The releases page has not moved since April 2025. The advisory list moves several times a week.

    Sourcing note

    Checked against primary sources: the five NVD records for CVE-2026-86186 through CVE-2026-86190, retrieved from the NVD API on September 5, 2026; the AVideo project’s own GitHub Security Advisories GHSA-82q2-88mq-p44q and GHSA-cprx-fggj-7vpq (both published August 21, 2026) and GHSA-fq38-jp6c-q4cx (September 1, 2026); VulnCheck’s advisory pages for the two criticals; and the AVideo repository’s releases page. The 46-record count is NVD’s own totalResults for a keyword search bounded to August 6 through September 5, 2026, confirmed on two retrievals with different query forms.

    Not resolved: we could not confirm from a primary source whether AVideo has fixed any of these in unreleased code, because the repository’s tagged releases stop at 29.0 and the advisories scope affected versions by commit hash rather than version. We did not attempt to verify the hash-as-password chain against a running instance, and we are not aware of any public exploit that combines the three advisories. GHSA-fq38-jp6c-q4cx carried no CVE identifier at the time of writing. VulnCheck’s advisory pages give a CVSS v4.0 score but no disclosure timeline. No source indicates these flaws have been exploited.

  • python-jose still lets a public key serve as an HMAC secret, because the 2024 fix checked the key format instead of the key

    python-jose still lets a public key serve as an HMAC secret, because the 2024 fix checked the key format instead of the key

    VulnCheck published CVE-2026-85394 against the python-jose JOSE library on September 3, 2026, at 7:17 p.m. UTC. The record describes an algorithm-confusion bypass, and its last sentence is the story: “This is an incomplete fix for CVE-2024-33663.” The 2024 fix tried to stop a public key from being used as an HMAC secret by checking whether the key looked like a PEM or SSH key. A DER-encoded public key looks like neither. There is no patched release, the GitHub issue has been open since July, and python-jose has not shipped a version since May 2025.

    What happened

    The full NVD description, verbatim: “python-jose through 3.5.0 fails to properly validate asymmetric keys in HMAC initialization, accepting DER-encoded public keys that lack PEM armor or SSH prefixes. Attackers holding the service’s public key can forge HS256 tokens that pass verification when algorithms are not explicitly restricted. This is an incomplete fix for CVE-2024-33663.”

    The weakness is CWE-347, improper verification of cryptographic signature. VulnCheck scored it 9.1 under CVSS v3.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, and 9.3 under CVSS v4.0. The record’s vulnStatus was “Received” at the time of writing.

    Algorithm confusion is an old and well-understood class. A JSON Web Token carries its own algorithm identifier in the header. A service that verifies RS256 tokens holds an RSA public key, which is not a secret — it is typically published at a JWKS endpoint so that anyone can verify the service’s tokens. If an attacker can get the verification routine to treat that public key as an HMAC shared secret instead, the attacker can mint HS256 tokens signed with the key everybody already has, and the library will accept them. The canonical instance is CVE-2022-29217 in PyJWT.

    python-jose took this in April 2024 as CVE-2024-33663, filed on GitHub as GHSA-6c5p-j8vq-pqhj, titled “python-jose algorithm confusion with OpenSSH ECDSA keys,” affecting versions before 3.4.0 and patched in 3.4.0. The patch added a guard. In the library’s native backend the check reduces to this shape:

    if is_pem_format(key) or is_ssh_key(key):
    raise JWKError

    That is a formatting test, not a type test. is_pem_format looks for the -----BEGIN armor. is_ssh_key looks for the prefix that opens an OpenSSH public key line. Both are string patterns wrapped around the same underlying object: a DER-encoded key. PEM is base64-encoded DER with a header and footer glued on. Strip the armor and base64-decode it and you have the identical key material with none of the strings the guard is looking for.

    That is what GitHub issue 414 against mpdavis/python-jose reports. It is titled “Algorithm-confusion guard bypassed by DER-encoded public keys (incomplete CVE-2024-33663 fix),” was opened on July 6, 2026 by the account geo-chen, and is still open with no maintainer response recorded. The reporter demonstrates forging an HS256 token using the DER form of the service’s public key and having it verify successfully on decode. The recommended fix is to stop pattern-matching entirely: attempt to load the supplied HMAC secret as an asymmetric key and reject it if it parses. The reporter also recommends requiring explicit algorithm allowlists on verification.

    The release history is the other half. On PyPI, python-jose 3.3.0 was uploaded on June 5, 2021. Version 3.4.0 — the release carrying the incomplete fix — was uploaded on February 18, 2025. Version 3.5.0, the current release and the one the CVE names as vulnerable, was uploaded on May 28, 2025. Nothing since. The issue reporting the bypass has been open for roughly two months, and the CVE is now public.

    Why it matters

    The interesting failure here is not that a library had an algorithm-confusion bug. It is how the fix failed, and that failure mode generalizes past this library.

    The 2024 patch answered the question “is this key text that looks like an asymmetric public key?” The question it needed to answer was “is this key an asymmetric public key?” Those diverge the moment the same value can be spelled more than one way, and cryptographic key material can always be spelled more than one way: PEM, DER, JWK, OpenSSH, base64 of any of them. A validator built on string prefixes has to enumerate the spellings. A validator built on parsing has to enumerate nothing — if the bytes load as a public key, they are a public key, whatever they look like. The reporter’s recommendation is the structurally correct one, and it is also the one that does not need to be revisited when a sixth encoding shows up.

    This is the same shape as findings this publication has covered on other projects: a denylist bypassed because it enumerated bad inputs instead of defining good ones, an escape routine defeated because the grammar it escaped for was not the grammar the value ended up in. Guards that describe the attack rather than the property are the recurring cause. What makes this instance sharper is that the guard was written specifically as a security fix, carried a CVE number, and shipped in a release whose whole purpose was to close the hole.

    The second condition in the CVE — “when algorithms are not explicitly restricted” — is where an operator has leverage, and it is also where most of the real-world exposure sits. Passing an explicit allowlist to the decode call removes the attack entirely, because the token’s own header no longer gets a vote. Code that omits the allowlist is common, partly because omitting it works fine in testing and fails only against an attacker.

    The maintenance picture is what turns this from a bug into a decision. There is no patched version to move to. The last release predates the report by more than a year, the issue has drawn no maintainer response in two months, and the CVE is now published with the current version named as affected. That is not an accusation — python-jose is a volunteer project and nobody is owed a release — but it is the fact a team has to plan around. If your dependency graph contains python-jose, the realistic options are a mitigation you apply yourself, a fork, or a different library. Waiting is not one of them right now.

    Worth stating plainly: there is no reported exploitation, no KEV listing, and no federal deadline attached to this. The urgency here comes from the absence of a patch, not from anyone attacking it.

    What to do

    • Pass an explicit algorithms allowlist on every verification call. This is the mitigation, and it is complete. A decode that is told to accept only RS256 will not fall through to HMAC no matter what the token header claims or what encoding the key arrived in. Grep your codebase for decode calls that omit the parameter.
    • Audit what you hand in as the key. The attack needs the verification routine to be initialized with the public key as an HMAC secret. Code paths that pass a single key variable through to both asymmetric and symmetric verification are the ones to look at.
    • Treat your public key as public, because it is. The CVE’s precondition — “attackers holding the service’s public key” — is met by default for any service publishing a JWKS endpoint. Do not count that as a barrier.
    • Decide about the dependency. python-jose 3.5.0 is the current release and is the affected version. If you cannot guarantee the allowlist across every call site, including transitive callers, plan a migration rather than a wait.
    • Track GitHub issue 414. It is the only place a fix will surface first, and it is where a maintainer response, if one comes, will appear.

    Sourcing note

    Checked: the NVD record for CVE-2026-85394, retrieved from the NIST CVE API on September 4, 2026, from which the description, scores, vectors, and CWE are taken verbatim; GitHub issue 414 on mpdavis/python-jose, which supplied the guard shape, the report date, and the recommended fix; the GitHub Security Advisory GHSA-6c5p-j8vq-pqhj for the prior CVE-2024-33663, which supplied the affected and patched versions; the PyPI JSON metadata for python-jose, which supplied the upload dates for 3.3.0, 3.4.0, and 3.5.0.

    Unresolved: whether the maintainers have responded privately. The GitHub issue shows no public maintainer comment, which is not the same as no contact. Whether a fix is in progress. The CVE was assigned by VulnCheck as CNA rather than by the project, and VulnCheck’s advisory does not describe a coordination timeline; the report and the CVE come from two different parties, roughly two months apart. No exploitation has been reported by anyone, and no second party has independently reproduced the DER bypass in public.

  • MOOS marine autonomy middleware takes 33 CVEs at once, and the fix for the unauthenticated bus is an unmerged pull request

    MOOS marine autonomy middleware takes 33 CVEs at once, and the fix for the unauthenticated bus is an unmerged pull request

    Thirty-three CVE records landed on the MOOS robotics middleware family on September 3, 2026, in one contiguous block running from CVE-2026-85424 to CVE-2026-85456. All were assigned by VulnCheck as CNA and credited to a single researcher, Vlatko Kosturjak. They cover four separate repositories, and between them they describe a message bus with no authentication, a packet parser that trusts attacker-supplied lengths before any handshake, and several applications that pass bus contents into a shell. The proposed fix for the first of those exists. It is a pull request the researcher opened himself on September 2, and as of this writing no maintainer has commented on it.

    What happened

    MOOS is a publish/subscribe middleware. The themoos/core-moos repository describes it as “A very light weight, easy to use middleware. You will need core-moos above all other components.” The autonomy layer built on it, MOOS-IvP, is described by its own repository as “a set of modules for providing autonomy on robotic platforms, in particular autonomous marine vehicles.” It has a long academic trail behind it in unmanned marine vehicle research. The affected version strings across the batch are core-moos through 10.4.0, essential-moos through 10.0.1, MOOS-IvP through 24.8.1, and ui-moos through commit 50b9c6c.

    The anchor record is CVE-2026-85424, scored 9.8 under CVSS v3.1 in the NVD record and 9.3 under CVSS v4.0 on VulnCheck’s own advisory page — the same assigner, two scoring frameworks, not a dispute. VulnCheck’s text: attackers can “bypass the compile-time protocol string check and connect with arbitrary client names to execute privileged operations including DB_CLEAR which resets all variables and clears client mail queues.” The NVD description is blunter: core-moos “lacks authentication in the wire protocol, allowing unauthenticated clients to connect with full publish, subscribe, and database clear privileges.” CWE-306.

    The rest of the batch falls into recognizable groups.

    Pre-authentication memory corruption. CVE-2026-85440 is a heap overflow in MOOSCommPkt packet handling at 9.8, reachable before any client identifies itself. CVE-2026-85455, at 8.2, is a buffer over-read triggered by a four-byte packet — open a TCP connection to the MOOSDB port, send four bytes, read memory. CVE-2026-85441 and CVE-2026-85442 cover unvalidated serialized string lengths and unbounded packet-length allocation, both 7.5.

    Bus contents reaching a shell. CVE-2026-85425 (9.8) is remote code execution in iSay, which passes the text of the SAY_MOOS variable to shell commands unsanitized. CVE-2026-85426 (9.8) builds shell commands in uMemWatch out of client names the attacker chooses. CVE-2026-85439 (7.8) is the same class in alogsplit. CVE-2026-85427 (8.1) lets an unauthenticated attacker run an arbitrary program through pAntler via a MISSION_FILE message.

    Trusting the message instead of the connection. CVE-2026-85433 (9.8) lets any publisher reconfigure pShare network routes and listeners through unauthorized PSHARE_CMD messages. CVE-2026-85430 (9.1) has pShare accepting UDP datagrams from any source and republishing them onto the bus. CVE-2026-85434 (9.1) and CVE-2026-85435 (9.1) are the shore-side and vehicle-side halves of the same problem in uFldShoreBroker and uFldNodeBroker: node pings and TRY_SHORE_HOST messages are acted on without verifying who sent them. CVE-2026-85429 (7.5) has uFldNodeComms taking the source node identity from the message body rather than the connection.

    The autonomy decision path itself. CVE-2026-85437 and CVE-2026-85438, both 9.8, are buffer overflows in the IvP function string decoders. CVE-2026-85438 names the mechanism: StringToIvPFunction() uses attacker-supplied dimension, piece, and degree counts without validation. Those decoders parse the objective functions that the behavior engine uses to pick a course of action.

    Two more deserve a line. CVE-2026-85451 (7.1) covers SuicidalSleeper, which authorizes multicast termination commands with a hard-coded passphrase; any multicast-reachable peer can enumerate MOOS processes and shut them down. CVE-2026-85449 (7.5) lets an attacker exhaust pMarineViewer‘s memory with unbounded distinct node names in NODE_REPORT messages and, in NVD’s phrasing, “stall the operator display without authentication.”

    Pull request 84 against themoos/core-moos is titled “Add an optional shared key for MOOSDB admission.” It was opened on September 2, 2026 by the GitHub account kost, carries a single commit, and adds a shared key checked during the client handshake — configurable through a ServerKey mission-file entry or a --moos_key flag, defaulting to an empty key so existing deployments keep working, and compared in constant time. It reuses an unused auxiliary field in the name message so the wire format does not change. It is open. It has no reviews, no assignees, no labels, and no maintainer comments.

    Why it matters

    Thirty-three records is a number that invites the wrong reading. This is not thirty-three independent mistakes. It is closer to one architectural decision — a bus that assumes everything on it is trusted — enumerated thirty-three ways, plus a genuine second cluster of memory-safety bugs in the parsers that speak to that bus. Robotics middleware has been here before: ROS 1 shipped for years on the same assumption, and the industry’s answer was not to patch the bus but to build a successor with authentication in it.

    That history is why the shape of the disclosure matters more than the count. When a researcher enumerates a design assumption into three dozen CVE records, each record acquires a score, and the scores travel. Twelve of these carry critical severity. Every one of them uses “through <version>” phrasing with no fixed version named, which means each record stays open-ended until someone ships a release and updates it. A vulnerability management program that ingests this batch will see twelve criticals against software with no patched version, and there is no vendor PSIRT to call.

    The unmerged pull request is the part that will decide how this goes. The researcher did the unusual and generous thing: rather than publishing a finding and leaving the maintainers to design a fix, he wrote a backward-compatible one that does not break the wire format and defaults to off. That design choice is what makes it mergeable and also what limits it — an optional key that defaults to empty fixes nothing for anyone who does not set it. The value is that it gives operators a switch to throw. Right now they do not have one, and the pull request that would give them one has been sitting unreviewed for two days across a disclosure.

    There is a fair reading in which none of this is urgent. MOOS deployments are typically on a vehicle network or a research LAN, not the public internet, and the pre-authentication memory bugs need reachability to the MOOSDB port. That reading is exactly what the design assumed, and it holds until a vehicle network touches a shore network, a topside laptop is on both, or a bridge like pShare is configured to accept UDP — which CVE-2026-85430 says it does, from any source.

    What to do

    No fixed release exists for any of the 33 records. The available actions are network and configuration ones.

    • Treat the MOOSDB port as an administrative interface. It has no authentication, by design and now by CVE. Bind it to a loopback or vehicle-only interface and put an explicit deny in front of it from any network a person can reach.
    • Audit pShare and pMOOSBridge configurations for UDP listeners. CVE-2026-85430 and CVE-2026-85431 both turn on a listener accepting datagrams from any source; if you use one, source-restrict it at the firewall.
    • If you run the optional MOOSDB HTTP server, turn it off. Three separate records cover it — an authentication bypass allowing unauthenticated variable writes (CVE-2026-85428, 9.8), unbounded connections and threads (CVE-2026-85450, 7.5), and unescaped database contents rendered into the page (CVE-2026-85453, 6.1).
    • Review whether iSay, uMemWatch, or alogsplit are running in any configuration where a bus writer is not fully trusted. All three take bus content into a shell.
    • If you maintain a MOOS fork, pull request 84 is the change to evaluate. Setting a non-empty ServerKey is the only admission control on offer.

    Sourcing note

    Checked: NVD records for CVE-2026-85424 through CVE-2026-85456, retrieved from the NIST CVE API on September 4, 2026, with all descriptions and scores taken from those records; VulnCheck’s own advisory page for CVE-2026-85424, which supplied the researcher credit, the CVSS v4.0 score, and the DB_CLEAR language; the themoos/core-moos repository and pull request 84 on GitHub; the themoos organization page for the repository descriptions.

    Could not reach: moos-ivp.org, the project’s distribution site, which did not complete a TLS certificate check from this environment. That is a first-hand observation from one automated fetch and is not a claim that the site is broken for browsers.

    Unresolved: whether the maintainers were notified before publication and on what date — VulnCheck’s advisory states a disclosure date of September 3, 2026 but does not describe the coordination timeline or a vendor response. Whether pull request 84 will be merged, and whether a release will follow that lets the records name a fixed version. This is a single-researcher, single-CNA disclosure; no second party has independently confirmed the findings, and no exploitation has been reported.

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