Seven new KEV entries, three of them in open developer components

CISA added seven new vulnerabilities to its catalogue of known exploited vulnerabilities on 2 September 2026, based on evidence of active exploitation. The entries are CVE-2026-9586, SQL injection in Sangoma Switchvox, CVE-2026-48710, HTTP request smuggling in Kludex Starlette, CVE-2026-49869, command injection in Kestra OSS, CVE-2026-59822, improper authentication in BerriAI LiteLLM, CVE-2026-82329, improper authentication in JFrog Artifactory, and CVE-2026-83548 and CVE-2026-83549, server side request forgery and command injection respectively in SonicWall SMA1000. CISA points at the same time to directive BOD 26-04, which sets requirements for how US federal agencies prioritise security updates by risk.

The catalogue does not say that a vulnerability is severe, but that it is being exploited, and that is a different fact from a CVSS score. CISA points at the same time to directive BOD 26-04, which requires US federal agencies to fix first where the system is exposed and exploitation grants total control, and which expects the agency to check whether anyone got in before the fix was installed. Three of the entries are not equipment, but building blocks. Starlette is the framework underneath FastAPI among others, Kestra runs and orchestrates workflows, and LiteLLM is the intermediary that offers one interface towards several model providers and therefore holds the API keys for all of them.

What this means for you if you prioritise updates

The pattern in the list is worth more than the individual entries. Vulnerabilities under active exploitation no longer sit only in firewalls and portals. They sit in the components developers and the AI team pull in, and those components rarely have an owner in the vulnerability process. No vendor sends you an advisory about Starlette. It arrives as a dependency of a dependency, and you find it only if you hold a component inventory.

The second point is the expectation to check whether somebody has already been inside. That part of the directive is worth carrying across even though it formally covers US agencies. When the vulnerability sits in the catalogue and your system was exposed, patching is half the job. Our assessment is that the catalogue works well as a priority list precisely because it is short and rests on observed exploitation. If you are covered by NIS2, this is Article 21 in practice.

Berigo recommends

• Use the catalogue of known exploited vulnerabilities as the first priority in the vulnerability process, ahead of general severity ratings.
• Obtain a component inventory for your own and purchased applications, so that libraries such as Starlette can actually be looked up.
• Map who owns AI intermediaries such as LiteLLM internally, and which keys they hold.
• After fixing an exposed system, check whether anyone got in before the fix, and preserve the logs.
• Set a deadline in your own procedure for catalogued vulnerabilities on exposed systems, and measure whether it holds.