CVEasy Weekly

This Week in Exposure

Week 44 · 2026-W44 · October 26 to November 1, 2026

The theme this week is that the number on a finding is not the risk. One item carries a CVSS 9.9 whose real danger turns on where your orchestrator listens and who holds a read-only login, and the other has no CVE at all yet ran on every Python start on the hosts it reached.

This week's checklist

1. Arista VeloCloud Orchestrator (CVE-2026-114625, CISA KEV): apply 5.2.3.18, 6.1.3.10, or 6.4.2.12 today, because the federal deadline is October 26; if a window pushes you past it, take the web interface off the public internet behind a jump host with MFA for every account.
2. LiteLLM 1.107.0 (PyPI and Docker, no CVE): revert to 1.106.2 on fresh interpreters rather than upgrading in place, and rotate every cloud, AI and developer credential on any host that ran it during the October 21 window.

Top Exposures This Week

1. A read-only VeloCloud login that reaches operator superuser

CVE-2026-114625 · Arista VeloCloud Orchestrator, on-prem · authenticated SQL injection, Enterprise Read Only to operator superuser, CVSS 9.9 · CISA KEV October 23, federal deadline October 26

Exposed: any on-prem VeloCloud Orchestrator reachable by a web session at Enterprise Read Only or above, at its worst when the web interface answers on a public IP; Cloud Hosted and Dedicated orchestrators were patched by Arista directly.

What happened: a SQL injection (CWE-89) in an internal API the orchestrator web interface calls lets a crafted field from an authenticated session reshape a query against operator records and impersonate a local operator superuser, the role that pushes config and update bundles to every connected SD-WAN edge. Arista published Security Advisory 0199 on October 22 reporting exploitation in the wild, and CISA added the CVE to KEV on October 23 with a federal deadline of October 26. It is the first of three VeloCloud Orchestrator flaws exploited since July 2026 to require any authentication at all.

Do this:

• Apply the Arista fixed builds today, per SA 0199: 5.2.3.18 on 5.2.x, 6.1.3.10 on 6.1.x, and 6.4.2.12 on 6.4.x. Cloud Hosted and Dedicated orchestrators are already patched.
• If a maintenance window pushes patching past the deadline, pull the web interface off the public internet and gate it behind a jump host with SSO and MFA for every account, including Enterprise Read Only.
• Rotate every orchestrator account active while the box was internet-reachable, including Enterprise Read Only logins, plus shared SSH keys for edge appliances, API tokens issued from the orchestrator, and any update bundle signing material that transited it.
• Hunt audit logs for sessions that look like a normal customer user but hit paths they do not usually touch, with encoded characters in parameters or request rates outside human pacing; Aviatrix published two attacker IPs as a starting point. Then diff each edge's running config against known-good and verify recent update bundles against Arista's published hashes.

Why it ranks here: vendor-confirmed in-the-wild abuse with a same-day KEV deadline, a jump from dashboard reader to platform administrator in one SQL fragment, top exposure band on any internet-facing on-prem orchestrator, and a blast radius that reaches every connected edge from one asset.

Read how one SELECT walks a read-only badge to superuser →

2. The credential stealer that shipped through the real pipeline with no CVE

No CVE · LiteLLM 1.107.0 on PyPI, plus the v1.107.0, latest, main-latest and main-stable tags on Docker Hub and GHCR · credential stealer that ran on every Python start · exploited October 21

Exposed: any host that installed litellm==1.107.0 from PyPI or pulled the affected Docker tags between 11:39 and roughly 14:20 UTC on October 21, 2026, including CI runners and laptops, and worst on a LiteLLM proxy host, where the backing database holds the organization's upstream provider credentials.

What happened: the 1.107.0 wheel placed three files beside the litellm package in site-packages (cook.pth, cook.py, and sitecustomize.py). CPython's site module runs cook.pth and sitecustomize.py at every interpreter start, so the stealer ran on any python invocation without anyone importing litellm, beaconed hourly, and POSTed encrypted cloud, AI and developer credentials to www.litellm[.]dev/healthcheck. The build went out through LiteLLM's real release workflow using three engineers' stolen GitHub CLI OAuth tokens against a lookalike repository named Berri-AI/litellm, so the attestation verified. The last clean release is 1.106.2.

Do this:

• Grep install logs and build caches for a litellm-1.107.0 wheel; any CI job pinned to it puts that runner in scope.
• Enumerate every site-packages for cook.pth, cook.py and sitecustomize.py, and check for /tmp/remote_code_loader.lock and /tmp/.pc_once_72129118c59f5636c0bb; either marker confirms the loader ran.
• In egress logs, hunt POSTs to www.litellm[.]dev/healthcheck and GETs to raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt.
• Rebuild, do not upgrade in place: revert to 1.106.2 on fresh interpreters and rebuild images from clean base digests, because pip install --upgrade on a compromised interpreter re-runs cook.pth. Rotate everything the stealer reached: cloud keys including IMDS role credentials, all AI provider keys, SSH keys, .git-credentials and Vault tokens, and on a proxy host every upstream provider key in the database plus every downstream virtual key it issued.

Why it ranks here: a live payload with observed command and control, reproduced by Datadog, Chainguard and others, execution wired into the Python site bootstrap so it ran without importing the package, a proxy-host blast radius of every downstream LLM key, and no CVE at all, so a severity-sorted queue files it below every scored advisory.

Read how three files ran before anyone imported litellm →

Threat actor to watch

The operator behind the LiteLLM compromise is the one to watch this week, and the honest note is that public reporting from Datadog, Chainguard, Socket and others has not tied it to a named group. What the reporting does establish is the tradecraft: stolen GitHub CLI OAuth tokens from three engineers, a release published through the genuine BerriAI pipeline against a lookalike repository that differs from the real one by a single hyphen (Berri-AI against BerriAI), and signed provenance that pointed at the fork, so every downstream signature and attestation check reported green. Hardening action: audit the upstream repository identity recorded in build provenance against an allowlist of exact organization names, because a one-hyphen lookalike passed SLSA level three attestation, and verifying the signature alone never catches it.

Signed CVEasy threat-intel IOC bundle current as of 2026-10-26. The desktop app verifies the ED25519 signature before import.

Neither of this week's leads was ranked by its CVSS. The Arista bug is a 9.9 that still lands differently on a public orchestrator than on one behind a bastion, and the LiteLLM stealer has no score to sort on at all, so what moved both to the top was exposure crossed with what attackers are doing today, the loop our CTEM platform runs with TRIS. Start with the Arista orchestrator, where the federal deadline is today and a read-only login was enough to reach operator superuser.

Patch well,
CVEasy Threat Research
Cofounder, CVEasy AI