Catch-Up Bulletin, August 28 to September 12, 2026: GitLab and Artifactory Exploited Within Days, the Trinitite npm Worm, Starlette and LiteLLM on CISA KEV, Magento StyleSmuggler, and an Edge-Appliance Roll-Up

This bulletin covers the two weeks since the August 28 catch-up, ranked by how much of this audience each item touches. The lead is GitLab CVE-2026-85706 (CVSS 10.0): an unauthenticated arbitrary file read through the repository commits API, patched September 10 in 19.3.2, 19.2.6, and 19.1.8, with exploitation attempts seen by watchTowr and Horizon3 within hours of the advisory and a CISA KEV listing the next day. Close behind is JFrog Artifactory, where Wiz observed two exploitation paths: CVE-2026-42018 chained with CVE-2026-42016 from August 15, and CVE-2026-82329 alone from September 1, both through September 8, both ending in admin tokens on default-configured instances, rogue accounts, Groovy plugins, and a Rust backdoor. On npm, the Trinitite worm rode an exposed publish workflow into ten versions of a TanStack Query code generator on August 28 (with a wipe-on-revoke handler described by two independent analyses), and a byte-identical Shai-Hulud payload from May was republished on September 7 through npm's new malware scanner. CISA also added Starlette (the toolkit under FastAPI), LiteLLM (MCP auth bypass), and Kestra (unauthenticated root RCE) to KEV on September 2, all for bugs fixed months ago. Magento and Adobe Commerce were exploited for three days before Adobe's September 7 hotfix for CVE-2026-75650. Also inside: seven vLLM advisories (six fixed by 0.29.0, one still open), and a roll-up of exploited edge and management appliances (Cisco FMC, Citrix NetScaler, FortiGate CAPWAP, SonicWall SMA1000, MikroTik, N-central, ScreenConnect) plus two Chrome and two Windows zero-days. If you do nothing else: patch and audit any reachable GitLab or Artifactory, sweep npm lockfiles and hosts for the Trinitite indicators, and upgrade Starlette, LiteLLM, and Kestra.

Framing note: this is a round-up, not the usual single-incident bulletin, so each item gets the affected range, the fix, a check, and an action rather than a full response guide. Items are ordered by breadth of exposure for developers, ops, AI/ML infrastructure operators, and self-hosters, not by CVSS. Every item is sourced to a vendor advisory, a named research team, or CISA KEV; where a detail is available only through press coverage of a vendor's bulletin, the text attributes it that way. All "as of" statements are anchored to September 12, 2026. Registry and release-tag states were checked live on that date. No new Linux kernel local-root bugs were found in the sources reviewed for this window; GhostLock and RefluXFS from the previous bulletin remain the current kernel items.

Priorities, by what you run

The table maps each item to who needs to act. "Higher" means confirmed compromise or in-the-wild exploitation with a broad footprint in this audience; "Medium" means a real fix to apply on your normal cadence, or a narrower footprint; "Lower" means awareness or a niche check.

Prioritization is this bulletin's, based on breadth of exposure in its audience and on whether exploitation is confirmed by the vendor, a named research team, or CISA KEV; it is not a CVSS ranking.

1. GitLab CVE-2026-85706: unauthenticated arbitrary file read through the commits API, exploited within a day (September 10)

GitLab shipped patch releases 19.3.2, 19.2.6, and 19.1.8 on September 10, 2026 for CVE-2026-85706, a CVSS 10.0 path traversal in the repository commits API. Per GitLab's release post, "under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement." It affects self-managed CE and EE from 18.7 before 19.1.8, 19.2 before 19.2.6, and 19.3 before 19.3.2. GitLab.com and GitLab Dedicated were patched before disclosure. watchTowr published a Rapid Reaction on September 11 naming the endpoint (POST to /api/v4/projects/{id}/repository/commits/ with a file.path parameter) and reporting attacker activity against its honeypots immediately after disclosure; Horizon3 puts the first exploitation attempts at 06:00 UTC on September 11. CISA added it to KEV on September 11 with a September 14 federal due date, the shortest window in this bulletin's window along with the Kestra, Artifactory, and Magento entries. The same release fixes a second Critical, CVE-2026-87719, an insecure deserialization in the GraphQL subscription serializer affecting EE only, plus six High CVEs including CI/CD variable-scope and protected-variable authorization bugs.

On August 28 this bulletin covered GitLab CVE-2026-19478, which was also exploited within about two days of its advisory. Any self-managed instance that is reachable from the internet, or from a network you do not fully control, should be assumed probed for both.

Am I affected?

sudo gitlab-rake gitlab:env:info 2>/dev/null | grep -A2 'GitLab information'
head -1 /opt/gitlab/version-manifest.txt
curl -s -H "PRIVATE-TOKEN: $GITLAB_TOKEN" https://gitlab.example.com/api/v4/version
# candidate requests (Omnibus paths, run as root; adjust for Helm / Docker)
# nginx logs the request line only, so this finds every POST to the endpoint, with or without file.path
grep -E 'POST /api/v4/projects/[^ ]+/repository/commits/? ' /var/log/gitlab/nginx/gitlab_access.log*
# api_json.log records API params, so this narrows to requests that carried file.path
grep -F '/repository/commits' /var/log/gitlab/gitlab-rails/api_json.log* | grep -F '"method":"POST"' | grep -F 'file.path'

Any 18.7 through 19.1.7, 19.2.0 through 19.2.5, or 19.3.0 through 19.3.1 is vulnerable. The log searches follow watchTowr's guidance to look for POSTs to the commits endpoint carrying file.path. They produce candidates, not verdicts: a legitimate commit created through the API carries the same parameter, so read the file.path values and the source addresses. A path that climbs out of the repository, or a request from an address you do not recognize against an instance that was not yet patched, is the thing to act on.

Response

1. Upgrade to 19.3.2, 19.2.6, or 19.1.8 now. GitLab published no workaround. If you cannot upgrade today, watchTowr's fallback is to remove public access to the instance until you can; restricting /api/v4/projects/*/repository/commits to trusted networks at the reverse proxy is a narrower version of the same idea and will break API-driven commits from outside that network.
2. Treat an unexplained hit against a then-unpatched instance as a secrets exposure. The read runs as the GitLab application user, so the files at risk are the ones that user can read: on Omnibus that includes the Rails secrets and database configuration under /var/opt/gitlab/gitlab-rails/etc/. If you find such a request, follow GitLab's documented secrets-rotation procedure and rotate the PostgreSQL password, then review personal and project access tokens created since September 10.
3. Re-check CI/CD variable exposure after upgrading. CVE-2026-13210 (environment variable scope matcher) and CVE-2026-79708 (scheduled pipeline execution policy test) in the same release let lower-privileged users reach protected CI/CD variables. If you keep deploy credentials in protected variables, rotate the ones a Developer-role user could have reached.

2. JFrog Artifactory: three flaws chained in the wild for admin control, Rust backdoors left behind (Wiz, September 10)

Wiz Research reported on September 10 that attackers have been exploiting three Artifactory vulnerabilities, along two separate paths, to gain administrative control of self-hosted instances. CVE-2026-82329 (published August 28) is the serious one: under Artifactory's default configuration, an unauthenticated POST to /access/api/v1/registry/join can return an administrator-scoped token. Wiz observed it exploited from September 1 through September 8. The older pair, CVE-2026-42018 (an internal anonymous-user token exposed to unauthenticated requesters even with anonymous access disabled, published August 12) and CVE-2026-42016 (token scope not enforced, so a low-privilege token can be traded up, published July 27), were chained from August 15 through September 8. CISA added CVE-2026-82329 to KEV on September 2 and the other two on September 11. Post-exploitation activity in Wiz's telemetry: persistent admin accounts, malicious Groovy plugins for code execution, configuration and cluster join-key theft, and a Rust-based backdoor. Wiz's exposure numbers: about two thirds of organizations running Artifactory had at least one vulnerable instance at each disclosure. If your build system pulls from or publishes to a self-hosted Artifactory, this is the item to act on first after GitLab.

Am I affected?

curl -s -u "$ART_USER:$ART_TOKEN" https://artifactory.example.com/artifactory/api/system/version
# exploitation of CVE-2026-82329: successful joins from outside your own nodes
grep -E 'POST /access/api/v1/registry/join' /var/opt/jfrog/artifactory/log/*request*.log* | grep -E ' (200|201) '
# accounts, tokens, and plugins to review
curl -s -u "$ART_USER:$ART_TOKEN" https://artifactory.example.com/artifactory/api/security/users
curl -s -u "$ART_USER:$ART_TOKEN" https://artifactory.example.com/access/api/v1/tokens
curl -s -u "$ART_USER:$ART_TOKEN" https://artifactory.example.com/artifactory/api/plugins
ls -la /var/opt/jfrog/artifactory/etc/artifactory/plugins/ /tmp/.z 2>/dev/null

Log paths are the defaults for a Linux archive or RPM install; container and Helm installs put them under the mounted $JFROG_HOME/artifactory/var/log. Wiz's detection hints for the older two: for CVE-2026-42018, a 401 on a bare path followed within seconds by a 200 on a variant of it from the same client; for CVE-2026-42016, a low-privilege identity minting tokens at POST /access/api/v1/tokens or touching /artifactory/api/plugins.

Response

1. Upgrade to the fixed release for your line (7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20 and later). If the instance is internet-reachable and you cannot upgrade today, block /access/api/v1/registry/join from anything that is not one of your own cluster nodes at the load balancer; that closes only the CVE-2026-82329 path, so an instance still exposed to the older two flaws also needs its access API restricted to trusted networks until it is patched.
2. Audit before you trust the patched instance. Patching does not remove an admin account, a Groovy plugin, or a backdoor that was planted before the patch. Compare the user list and the plugins directory against what you provisioned, revoke every access token you cannot attribute, and check the hosts for the /tmp/.z payload and connections to the C2 addresses above.
3. If anything is found, rotate everything Artifactory holds and rebuild. That means the cluster join key, the master key, every integration token (CI runners, Docker clients, package managers), and any upstream remote-repository credentials stored in the configuration. Wiz observed configuration theft, so credentials in the config are the attacker's next move.

3. npm: the Trinitite worm in a TanStack Query code generator (August 28), and a Shai-Hulud payload that came back after 111 days (September 7)

Two npm events, neither on the scale of the August 4 keyv wave, but both instructive. On August 28 between 20:00 and 20:21 UTC, ten versions of @7nohe/openapi-react-query-codegen (a TanStack Query code generator with roughly 150,000 weekly downloads) were published carrying a Mini Shai-Hulud variant that calls itself Trinitite. StepSecurity traced the entry point: the package's release workflow was triggered by an issue_comment event and required only that a comment on a pull request read exactly npm publish, with no author-association gate. A GitHub user opened two pull requests from a fork, commented, and the workflow checked out the fork, ran pnpm install, and published through npm Trusted Publishing. Every malicious version therefore shipped with valid provenance. JFrog and StepSecurity both report that it did not spread to any other package. As of September 12 all ten versions have been removed from the registry and the latest tag resolves to 3.0.2.

The payload runs from a preinstall hook (node 3FWCvzduYZg.js, a 6.4 MB obfuscated file) with a binding.gyp fallback, downloads Bun into a /tmp/trinnyyyy-* directory, and harvests GitHub tokens (via gh auth token and git credential managers), npm, PyPI and RubyGems tokens, AWS, Azure and GCP credentials including instance metadata, Kubernetes and Vault tokens, SSH keys, Docker configuration, .env files, wallets, and Claude credentials. Stolen data is committed to public repositories created under the victim's own GitHub token. It persists as a user systemd service or macOS LaunchAgent named sysvinit-detect-fash or systemd-detect-fash, plants IDE hooks in .vscode/tasks.json and .claude/settings.json, and runs a token monitor. Per JFrog's analysis, that monitor polls GitHub once a minute and, when the token starts returning 4xx, "the stored handler can wipe ~/ and ~/Documents." Socket's writeup describes the same behavior. Unlike CHAINDROP, where two vendors disagreed, here two independent static analyses describe the same handler, so the response order below matters.

Separately, on September 7 at 09:25 UTC, four unrelated packages (feishu-docx-mcp@0.3.2, bmc-i18n-extract-cli@1.1.1, blueai-cli@0.7.0, bmc-translate-utils@1.1.1) were published from one account carrying the byte-identical Shai-Hulud payload from the May 19 wave, SHA-256 e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6, a hash already indexed across 319 earlier malicious versions. Aikido's point is that npm's publish-time malware scanning, introduced in July, let a known hash through. The registry replaced all four with 0.0.1-security placeholders about four and a half hours later. Download counts were small; the relevance is that one of them is an MCP server package, exactly the kind of thing an AI coding agent installs on a developer's say-so.

Am I affected?

# lockfiles and manifests, from the root of each checkout
grep -rEn "(@7nohe/openapi-react-query-codegen|feishu-docx-mcp|bmc-i18n-extract-cli|blueai-cli|bmc-translate-utils)[@\"'/:]" --include=package-lock.json --include=pnpm-lock.yaml --include=yarn.lock --include=package.json .
# persistence and dropper files on any machine that ran npm install since August 28
# run as root so every user's home is covered; add CI workspace roots to the path list
find /home /root /Users /tmp /var/tmp \( -name '3FWCvzduYZg.js' -o -name 'is_it_this_simple.js' -o -name 'nu.js' -o -name 'updater.py' -o -name 'poopy.py' -o -name 'sysvinit-detect-fash.service' -o -name 'systemd-detect-fash.service' -o -name 'com.user.*-detect-fash.plist' -o -name 'trinnyyyy-*' -o -name '.shit' \) 2>/dev/null
# binding.gyp is a normal file name; inspect any found under a package that should not need native builds
grep -rl '3FWCvzduYZg' --include=binding.gyp /home /root /Users 2>/dev/null
systemctl --user list-units --all 2>/dev/null | grep -i detect-fash
grep -rl 'trinnyyyy\|3FWCvzduYZg\|m-kosche' .vscode/tasks.json .claude/settings.json 2>/dev/null
# exfil repos created under your GitHub account (requires an authenticated gh CLI)
gh repo list --limit 300 --json name,createdAt,visibility --jq '.[] | select(.createdAt > "2026-08-28")'

The first grep matches the package name followed by an @, a quote, a slash, or a colon, which covers the npm, pnpm, and yarn lockfile spellings; read the version on each hit. A version pinned to 0.5.3, 1.6.2, 2.2.0, or 3.0.2 is clean; any of the ten listed versions in a lockfile means that lockfile was resolved during the roughly one-day window before removal and the install host needs the file sweep. The gh repo list line is the fastest way to see whether a token from that host was used to create exfiltration repositories.

Response

1. Isolate first, revoke second. If the file sweep finds the monitor (poopy.py, the detect-fash service or LaunchAgent), disconnect the host or stop the unit before revoking the GitHub token it holds. Per both analyses, the token returning 4xx is what the handler waits for; no victim report of an actual wipe was found, but there is no reason to test it.
2. Rotate from a clean host: GitHub PATs and any OAuth apps, npm, PyPI and RubyGems tokens, cloud keys reachable from that machine, Kubernetes and Vault tokens, SSH keys, and AI tool credentials. Delete the exfiltration repositories and any forks. Then rebuild the workstation or runner; removing the service and the IDE hooks is necessary but a rebuild is the only clean end state.
3. Pin and turn on a minimum release age. The fourteen malicious versions listed above were removed within hours (Shai-Hulud republish) to about a day (Trinitite). A min-release-age of a few days in npm 11.10+, or the pnpm 11 default, would have skipped all of them on a fresh resolution; it does not help an install that reuses a lockfile or cache already pointing at a bad version.
4. If you maintain packages: search your workflows for issue_comment and pull_request_target triggers that check out a PR head or run an install. Gate them on github.event.comment.author_association being OWNER or MEMBER, or better, do not let a comment publish anything. Trusted Publishing proves the workflow ran; it does not prove the workflow was safe.

4. Starlette "BadHost" (CVE-2026-48710): a moderate FastAPI-ecosystem bug that is now on CISA KEV (added September 2)

Starlette is the ASGI toolkit under FastAPI, which makes it the substrate for a large share of the Python API services this audience runs, including many self-hosted LLM gateways and inference front-ends. GHSA-86qp-5c8j-p5mr, published May 21 and fixed in Starlette 1.0.1, describes a Host-header validation gap: when Starlette rebuilds request.url by concatenating the Host header with the path, a Host value containing /, ?, or # shifts the parsed path, so request.url.path no longer matches the path the router actually dispatched. Middleware that gates access on request.url.path (a common pattern for "everything under /admin needs auth") sees the attacker's chosen path while the real handler runs. The advisory rates it 6.5. What changed on September 2 is that CISA added it to KEV, which by CISA's own criteria means reliable evidence of exploitation; no public writeup of that exploitation was found while preparing this bulletin, so the "who and how" is unknown. FastAPI does not pin a fixed Starlette; its maintainers' position in the project's discussion is that upgrading Starlette is the application developer's job.

Am I affected?

pip show starlette 2>/dev/null | grep -i '^version'
uv pip list 2>/dev/null | grep -i starlette
docker exec "$APP_CONTAINER" python -c "import starlette; print(starlette.__version__)"   # set APP_CONTAINER to the container name
# code that makes decisions on the reconstructed path
grep -rn 'request.url.path' --include='*.py' .

Anything at or below 1.0.0 is affected. Deployments behind a reverse proxy that rejects or normalizes malformed Host headers, and that do not trust X-Forwarded-Host, have less exposure, per the advisory; a Starlette app listening directly, or behind a proxy that passes Host through untouched, has the full exposure.

Response

1. Upgrade Starlette to 1.0.1 or later in every service and image, and add an explicit starlette>=1.0.1 constraint so a FastAPI upgrade cannot quietly resolve back to an older one.
2. Until then, gate on the routed path, not the reconstructed one. The advisory's description is that the router still dispatches on the wire path; middleware that compares request.scope["path"] is comparing what was actually routed. Also have your reverse proxy reject Host values that contain /, ?, or #.

5. Two AI and orchestration platforms added to KEV with three-day deadlines: LiteLLM CVE-2026-59822 and Kestra CVE-2026-49869 (September 2)

Both of these were disclosed and fixed in June; both landed on CISA KEV on September 2 with a September 5 federal remediation date, which is CISA's signal for "this is being used now."

LiteLLM (GHSA-7488-6r32-c95q, published June 30, CVSS 8.8, fixed in 1.84.0): the proxy's MCP Streamable HTTP endpoint supported OAuth2 passthrough to upstream MCP servers, and the fallback path replaced a failed LiteLLM key check with an empty UserAPIKeyAuth() object. A fabricated Authorization header was enough to list and call every MCP tool the proxy had configured, and through them whatever those tools reach. If your LiteLLM instance is older than 1.84.0 and exposes MCP tools that touch anything (databases, file systems, internal APIs), assume those tools were reachable without a key. Note also the March 2026 LiteLLM PyPI compromise; anyone still on a 1.82.x line has two separate reasons to move.

Kestra (GHSA-2q47-568g-9h4f, published June 3, CVSS 10.0, fixed in 1.0.45 and 1.3.21): the OSS authentication filter treated any request path ending in /configs as the public configuration endpoint, so an attacker who creates a flow named configs in a namespace named configs can create and execute it unauthenticated. Kestra ships shell and Python script plugins enabled by default, so this is remote code execution as root inside the worker container. Affected: OSS 1.0.x before 1.0.45 and 1.1.0 through 1.3.20, running server standalone or server webserver with Basic Auth in front (which is the normal production state).

Am I affected?

# LiteLLM
pip show litellm 2>/dev/null | grep -i '^version'
docker inspect --format '{{.Config.Image}}' "$LITELLM_CONTAINER"   # set to the running container's name
grep -n 'mcp_servers' /path/to/litellm/config.yaml
# Kestra: the running container's image, or the same unauthenticated configs endpoint the bug abuses, which returns a version field
docker inspect --format '{{.Config.Image}}' "$KESTRA_CONTAINER"
curl -s http://kestra.example.com/api/v1/configs

Response

1. LiteLLM: upgrade to 1.84.0 or later, which removes the fallback. If you cannot, the advisory's workaround is to disable MCP routes or block /mcp/ and related paths at the reverse proxy. Then review the proxy's request logs for MCP tool calls that do not map to a known key, and rotate credentials held by any MCP server the proxy could reach.
2. Kestra: upgrade to 1.0.45 or 1.3.21, then check the flow list for a configs namespace or any flow you did not author, and check execution history for runs of it. A worker that ran attacker-supplied shell as root should be rebuilt, and any secrets the worker could reach (its own secrets backend, mounted credentials) rotated. Keep the API off the internet regardless; there is no reason for an orchestration control plane to be publicly reachable.

6. Magento and Adobe Commerce "StyleSmuggler" (CVE-2026-75650): unauthenticated RCE exploited three days before the patch (September 4 to 7)

Sansec observed the first exploitation of CVE-2026-75650 at 22:20 UTC on September 4, 2026; Adobe published APSB26-146 and the emergency hotfix VULN-39341 at 20:20 UTC on September 7, stating that it "is aware of CVE-2026-75650 being exploited in the wild." CISA added it to KEV on September 8 with a September 11 due date. The bug is a CVSS 10.0 injection through Magento's email template engine: PHP smuggled into a template's styles property is executed when the store renders a failed-payment notification, so the attacker needs no account, no session, and no interaction. Adobe's affected list per BleepingComputer's report of the bulletin: Adobe Commerce 2.4.4 through 2.4.9, Adobe Commerce B2B 1.3.3 through 1.5.3, Magento Open Source 2.4.6 through 2.4.9; Sansec says every version from 2.4.4 through 2.4.9 is affected and that unsupported 2.2, 2.3, and 2.4.0 to 2.4.3 are vulnerable too. Sansec's confirmed intrusions installed a persistent Rust backdoor disguised as a kernel thread plus PHP web shells under the product image cache. If you run a storefront on any of these, this is a compromise assessment as much as a patch.

Am I affected?

# run from the Magento root as the PHP / web-server user (only the installed edition returns a result below)
bin/magento --version
composer show magento/product-community-edition 2>/dev/null | grep -E '^(name|versions)'
composer show magento/product-enterprise-edition 2>/dev/null | grep -E '^(name|versions)'
grep -ril 'x_trace_' var/report/
find pub/media/catalog/product/cache -name 'sync_*.php'
ps -o user,pid,comm,args -e | grep -E 'kworker/u:8:0|fc-cache|chronyd' | grep -v -e '^root' -e 'grep -E'
ls -la ~/.cache/fontconfig/fc-cache /tmp/.chrony-* 2>/dev/null

The process and file checks are leads, not verdicts: fc-cache and chronyd are real program names. A hit matters when the process runs as the web user, its executable lives under the home directory or /tmp, or it holds a connection to one of the C2 addresses.

Response

1. Apply hotfix VULN-39341 (or the equivalent in a patched release) to every affected store today. Sansec's reading is that the hotfix closes the bug; Aikido separately offers its own patched composer packages and suggests disabling GraphQL as a stopgap. That suggestion is Aikido's, not Adobe's or Sansec's.
2. Run the indicator checks before declaring the store clean. A corroborated hit (a sync_*.php file in the image cache, a var/report entry containing x_trace_, or a fake system process owned by the web user) means the store was compromised before the patch. Sansec's and Adobe's post-compromise steps agree: suspend cron, rotate the encryption key and every secret (admin passwords, GraphQL integration tokens, OAuth client secrets, payment gateway credentials, database credentials, SSH and API keys), remove the web shells and backdoor, and prefer rebuilding from a known-good deploy over cleaning in place.

7. vLLM: a trust_remote_code bypass, a one-request engine crash, and five resource-exhaustion bugs across seven advisories (August 28 to September 12)

vLLM published seven security advisories in this window. Per each advisory's own patched-version field: four are fixed in 0.28.0 (released August 26), two in 0.29.0 (released September 9), and one is not fixed in any release as of September 12. Two are rated High, both fixed in 0.28.0. GHSA-3c86-2m5g-59q7 (August 28, CVSS 7.8): the LlavaOnevision2ForConditionalGeneration processor loader passed trust_remote_code to a transformers function that has no such parameter, so the value was "swallowed into **kwargs and ignored" and attacker-supplied processor code from a model repository ran unconditionally, even with trust_remote_code=False. The advisory's own framing: arbitrary Python "with the vLLM process's / container's authority, in the exact situation trust_remote_code=False exists to protect." GHSA-25q3-v2hm-8vpf (September 3, CVSS 7.5): a single unauthenticated request to /v1/embeddings or /pooling carrying a negative token id in the token-id input form trips a CUDA device-side assertion and kills the engine for every client; the advisory notes that process supervision is not a workaround because the request can be repeated. The other five are Moderate denial-of-service bugs. Fixed in 0.28.0 (both published August 28): an audio-extraction bomb in NanoNemotronVL video processing (GHSA-936p-m5pv-vvjf) and a speech-to-text duration-limit bypass via a forged header sample rate (GHSA-99f2-hwrc-gvq8). Fixed in 0.29.0 (both published September 12): unbounded cache_salt length (GHSA-wpww-v874-ph2p) and multimodal chat audio decoding that ignores VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (GHSA-jcq2-4gch-5qhf). Not fixed as of September 12: GHSA-p6g9-7v3x-m8mv (September 12), in which remote media is fully downloaded before the documented size and item-count limits are enforced across four ingress paths including an unauthenticated /tokenize route in the Rust frontend; its advisory lists every release through 0.29.0 as affected. As of September 12 none of the seven has a CVE and none is reported exploited.

Adjacent, and from just before this window: Traefik CVE-2026-85596 (advisory August 21, CVSS 8.2, fixed in v3.7.11) lets two Kubernetes Ingress objects sharing a host, client CA secret, and auth mode under the Ingress NGINX provider collide on TLS option names, at which point Traefik falls back to the entry point's default TLS and stops requesting client certificates. Only v3.7.0 through v3.7.10 are affected, and only when the Ingress NGINX provider is enabled and mTLS is expected. If you rely on Traefik-enforced mTLS in a multi-tenant cluster, upgrade.

Status check on an open item from the June and August bulletins: libssh2 still has no tagged release after 1.11.1 as of September 12, 2026 (GitHub tag list checked that day), so the CVE-2026-55200 guidance in the June 23 bulletin stands.

Am I affected?

pip show vllm 2>/dev/null | grep -i '^version'
docker inspect --format '{{.Config.Image}}' "$VLLM_CONTAINER"
curl -s http://vllm.example.com:8000/version
# Traefik
kubectl get deploy -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].image}{"\n"}{end}' | grep -i traefik

Response

1. Upgrade vLLM to 0.29.0. If a server below 0.28.0 has loaded any LlavaOnevision2 checkpoint from a repository you did not author, treat that server as having run untrusted code regardless of the trust_remote_code setting, and review what credentials the process could reach.
2. Until upgraded, front the embeddings and pooling endpoints. The advisory's interim options: reject request bodies containing negative integers at the reverse proxy, accept only string input (not token ids) from untrusted callers, or restrict network access to those two paths.
3. For the still-open remote-media item, cap request bodies and media fetches in front of vLLM. The advisory's impact is availability only; a reverse-proxy body-size limit and a rule that only trusted callers may pass audio_url, image_url, or video_url references removes most of the exposure until a fix ships.

8. Edge and network appliances that landed on CISA KEV this window

Five appliance families were confirmed exploited in the wild between August 28 and September 12. Each is listed with the vendor's fixed release and the compromise indicators the vendor or a named team has published. Each is either a management plane that should not be internet-reachable at all (FMC, RouterOS SSH) or a remote-access listener that has to be (NetScaler Gateway, SMA1000, FortiGate) and therefore has to be patched on the day; either way, patch and then hunt.

Cisco Secure Firewall Management Center, CVE-2026-20079 (KEV September 9). An authentication bypass in the FMC web interface, CVSS 10.0, that lets an unauthenticated attacker execute script files and obtain root. Cisco's advisory (cisco-sa-onprem-fmc-authbypass-5JPp45V2) was first published March 4 and updated September 9 to state that "in August 2026, the Cisco PSIRT became aware of active exploitation." No workaround. Fixed by hotfix per line: 7.0 GB-7.0.9.1-3, 7.2 HL-7.2.11.1-4, 7.4 HG-7.4.7.1-3, 7.6 CY-7.6.5.1-2, 7.7 AM-7.7.12.1-2, 10.0 P-10.0.1.1-2. Cisco's cloud-delivered Security Cloud Control has been patched by Cisco. The same hotfix list closes the item the previous bulletin could not fill in: Cisco's page for CVE-2026-20316 (the FMC static credential, exploited since July, advisory cisco-sa-fmc-static-cred-BET3Cjh) was reachable this time and names the identical hotfixes, with a Cisco CVSS of 5.3. One hotfix per line resolves both.

Citrix NetScaler ADC and Gateway, CVE-2026-19490 (KEV September 9). Authentication bypass, CVSS v4 9.3, disclosed August 19 in CTX696939. Precondition per Citrix: the appliance is configured as a Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or an AAA virtual server, with version-specific SAML conditions. Affected: 14.1 before 14.1-73.32, 13.1 before 13.1-63.21, FIPS before 14.1-73.32 FIPS, FIPS/NDcPP before 13.1-37.277. Citrix's bulletin does not itself claim exploitation; Rapid7 and Help Net Security reported attempts from late August and CISA's listing confirms it. After upgrading, terminate active sessions, since a bypassed session survives the patch.

FortiOS and FortiSwitchManager, CVE-2025-25249 (KEV September 9). A heap overflow in the cw_acd CAPWAP daemon (UDP 5246), CVSS 9.8, unauthenticated RCE, disclosed by Fortinet on January 13 as FG-IR-25-084 with no known exploitation at the time. SOCRadar reported on September 9 that exploitation has been under way since at least July, delivering a Node.js post-exploitation implant it calls PivotC2 (interactive shell, tunneling into the LAN, config and credential harvesting) to 178 devices after scanning about 30,000. Fixed per Arctic Wolf's summary of the advisory: FortiOS 7.6.4, 7.4.9, 7.2.12, 7.0.18, 6.4.17; FortiSwitchManager 7.2.7, 7.0.6. Fortinet's workaround is to remove fabric access or block reachability to the CAPWAP daemon. Fortinet's PSIRT page was behind a bot check when this bulletin was prepared, so the version table is second-hand.

SonicWall SMA1000 (6210, 7210, 8200v), CVE-2026-83548 and CVE-2026-83549 (KEV September 2). An unauthenticated SSRF (CVSS 10.0) in the Work Place interface chained with an authenticated command injection (7.8) in the management console for unauthenticated root. SonicWall's notice SNWLID-2026-0016 (September 1) says the pair "have been confirmed as being actively exploited in the wild." Affected 12.4.3-03453 and 12.5.0-02835 and earlier; fixed 12.4.3-03526 and 12.5.0-02952. SonicWall's post-patch guidance: request an indicator review from support, and if compromised, re-image, reset every user and admin credential, and reset TOTP tokens.

MikroTik RouterOS "MikroTrick", CVE-2026-86060 and CVE-2026-67277 (KEV September 10). CERT Polska coordinated six RouterOS fixes and named the chain it saw exploited from September 2: CVE-2026-67276 (SSH authentication bypass) with CVE-2026-86060 (SSH login argument handling that lets the policy mask be rewritten), giving full unauthenticated control of any device with SSH reachable from the internet. CISA's KEV entries are 86060 and 67277 (an unauthenticated btest state confusion); the discrepancy is between the two sources, not an error here. Fixed: 6.49.21 (long-term), 7.23.4 (long-term), 7.24.2 (stable), 7.25beta3. MikroTik is withholding details to give operators time and recommends SSH be closed to untrusted networks with management reached only over a VPN such as WireGuard. CERT Polska's compromise indicators: log lines reading "login failure for user -2 from <ip> via ssh", a privileged user named ops you did not create, and a "Flagged" marker in /system/device-mode/print. Attack sources observed: 82.192.72[.]4 and 103.102.31[.]18.

Am I affected?

# Cisco FMC (FMC CLI): version, then installed hotfixes from the expert shell
show version
expert
sudo rpm -qa | grep -i hotfix

# Citrix NetScaler (nscli)
show ns version
show ns feature

# FortiGate (FortiOS CLI)
get system status
diagnose sys process list | grep cw_acd

# MikroTik (RouterOS CLI)
/system/resource/print
/log/print where message~"login failure for user -2"
/user/print
/system/device-mode/print

Response

1. Patch every one of these that is reachable from a network you do not control, today, in the order they appear on your perimeter: VPN and gateway surfaces (NetScaler, SMA1000, FortiGate CAPWAP) first, management planes (FMC, RouterOS SSH) second.
2. Then hunt, using the vendor's indicators. Every item above was exploited before or within days of its KEV listing, and three of the five vendors (Cisco, SonicWall, MikroTik) document post-compromise steps that amount to re-image and rotate. Patching an appliance that already has a second admin account or an implant does not remove either.
3. Take administrative surfaces off the internet. FMC's web UI and RouterOS SSH have no reason to be reachable from outside; a VPN or bastion in front of them removes those two items from your exposure. The gateway products exist to be reachable, so for them the control is patch cadence plus the vendor's post-compromise checks.

9. RMM and remote-support tools: N-able N-central and ConnectWise ScreenConnect

N-able N-central, CVE-2026-86218 (KEV September 8). A pre-authentication remote code execution on the N-central server, CVSS 10.0, patched in 2026.3 Hotfix 4 (build 2026.3.1.14) on September 6. Arctic Wolf reports exploitation before disclosure and exploit reproduction by independent researchers; N-able's own status post says its hosted N-central Online environments were patched by N-able. Arctic Wolf notes scanning from 23.234.64.0/18. Because an RMM server holds agents on every managed endpoint, an internet-facing N-central that sat unpatched between exploitation and Hotfix 4 should be treated as a compromise of the fleet it manages, not just of the server.

ConnectWise ScreenConnect, CVE-2026-84869 (KEV September 11). A client-side authorization gap, CVSS 9.9, in which files could be transferred to and executed on the Host machine through an active session without Host confirmation, including elevated execution. ConnectWise published interim guidance on September 3 (remove the TransferFiles permission from open sessions) and the fix in 26.6.5 around September 8; Cloud instances were patched by ConnectWise. Servers are not affected; the fix is to the client, so every installed client needs the update.

Am I affected?

# N-central: Administration > Product Version in the UI (2026.3.1.14 or later is patched)
# ScreenConnect client version on a Windows host (PowerShell; both 64-bit and 32-bit uninstall views)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' | Where-Object DisplayName -like 'ScreenConnect Client*' | Select-Object DisplayName, DisplayVersion

Response

1. N-central: apply Hotfix 4 and then review the server for new agents, scripts, and scheduled tasks created since late August. If the server was internet-facing, rotate the credentials it stores for managed endpoints and integrations.
2. ScreenConnect: push client 26.6.5 or later to every Host machine and, until that is complete, remove TransferFiles from active session permissions as ConnectWise advised.

10. Workstation items, briefly

Chrome: two V8 zero-days in five days. CVE-2026-85046 (type confusion) was fixed September 3 in Chrome 152.0.7977.82/.83 and added to KEV September 4; CVE-2026-87491 (out-of-bounds write) was fixed September 8 in 153.0.8010.36/.37 and added September 9. Google says exploits for both exist in the wild. Version numbers are from Help Net Security's and BleepingComputer's reports of the Chrome release notes. Chromium derivatives (Edge, Brave, Vivaldi, Electron-based apps) are affected if they embed a V8 older than the fixed builds; check each vendor's release notes.

Windows: two exploited local privilege escalations in the September 8 Patch Tuesday. CVE-2026-81963 (link following in the Windows Update Stack) and CVE-2026-85880 (heap overflow in ALPC), both CVSS 7.8, both to SYSTEM from a local foothold, both on KEV September 8. The release is Microsoft's largest to date by CVE count (reports range from 964 to 995 depending on how advisories are counted). For developer workstations and build agents the two zero-days are the reason to not defer the September 2026 update.

Flutter on pub.dev: universal_file_viewer 0.1.5 shipped XCSSET build hooks. Aikido reported September 8 that the maintainer published from a machine infected with XCSSET, so the package's example project carries a Gradle preBuild hook and Xcode PBXBuildRule entries that run obfuscated shell (printf xAxd | tr -d A style) and contact C2 domains (5yotmxcc54l9xda[.]ru, qdgs232i-q[.]ru, ejntin6hkjt7gj2[.]ru) during a build. Ordinary consumers of the package are not affected; developers who cloned and built the example app are. Grep your Flutter example projects for the obfuscation pattern and for git pre-commit hooks with double base64.

The broader pattern

Two things stand out in a short window. The first is that the n-day gap is now measured in hours for developer infrastructure. GitLab's advisory went out September 10 and probes arrived by 06:00 UTC the next morning; Artifactory's CVE-2026-82329 was published August 28 and exploited from September 1; Magento was exploited three days before its patch existed. The previous bulletin said "patch within 30 days" does not survive contact with 2026; this one says the same about "patch within a week" for anything with a pre-auth surface that holds credentials for other systems.

The second is that CISA's September 2 additions of Starlette, LiteLLM, and Kestra are a different kind of signal. All three bugs were fixed in May and June; none carried a vendor exploitation claim; one is rated Moderate. Their KEV listings, with three-day federal deadlines for two of them, mean CISA has evidence of exploitation; as of September 12 no public writeup of it was found while preparing this bulletin. When the exploitation happened is unknown; what the listings establish is that the Python web layer, the LLM gateway, and the orchestration tier now appear on the same list as the edge appliances that used to be the only things on it.

On the supply-chain side, the Trinitite entry point is worth a look at your own workflows even if you never installed the package. A comment-triggered publish job with no author check, running Trusted Publishing with id-token: write, turned a fork PR into ten signed malicious releases in twenty minutes. Provenance attests that the pipeline ran; it does not attest that the pipeline was sound.