CISA adds 7 CVE to KEV: remote execution and control failures require urgent patches

The US Agency for Infrastructure and Cybersecurity. US (CISA) recently incorporated seven vulnerabilities into its Known Exploited Vulnerabilities (KEV) catalogue, a sign that the failures are already being used in practice or represent imminent risk. The failures include critical problems with remote code execution capacity and administrative control in products ranging from VPN applications to artificial intelligence infrastructure components. CISA requires priority remediation in accordance with its operational directive, making these failures a priority for public and private organizations.

What is known and what is confirmed: CISA added the listed CVE (CVE-2026-83548, CVE-2026-83549, CVE-2026-9586, CVE-2026-82329, CVE-2026-48710, CVE-2026-49869 and CVE-2026-59822) to its public catalogue. Known Exploited Vulnerabilities. SonicWall confirmed active exploitation research for the two vulnerabilities in its applications SMA 1000 (CVE-2026-83548 and CVE-2026-83549). Security company reports - Horizon3.ai, watchTowr, Wiz and Microsoft - document active use of at least some of these failures to deploy reverse shells, cryptomoneda miners, administrative tokens creation and backend data exfiltration.

Technical description in practical terms: vulnerabilities cover several classic and dangerous vectors. CVE-2026-83548 is a SSRF (Server-Side Request Forgery) that allows an unauthenticated attacker to force the application to make internal requests or operate sensitive functions. CVE-2026-83549 is post-authentication command injection that allows command execution in the operating system with administrative privileges. CVE-2026-9586 is a SQL injection against Switchvox that allows an unauthenticated attacker to execute arbitrary SQL commands against PostgreSQL, with potential for scaling to remote execution. CVE-2026-82329 and CVE-2026-59822 are authentication weaknesses that facilitate obtaining administrative privileges or authenticated sessions without valid credentials. CVE-2026-48710 describes a request / HTTP response mismatch (request smuggling) that can lead to authentication leaps when URL reconstruction is manipulated. CVE-2026-49869 in Kestra allows to create and run arbitrary workflows without credentials, which has been associated with mine deployments and side movements.

Who it affects and why it matters: These failures affect application administrators SonicWall SMA, JFrog Artifactory users, Sangoma Switchvox implementations, responsible for flow orchestration platforms such as Kestra, and IA and LLM infrastructure deployments (Berri LiteLLM, LiteLLM and RAGFlow / LangChain ecosystem etc.). The real risk is double: immediate commitment (remote execution and obtaining administrative tokens) and exposure of secrets and keys from LLM providers, which allow an attacker to steal models, consume payment APIs and launch prompt injections or subsequent attacks aimed at model logic. In addition, monetization of resources (mining), persistance by modification of ~ / .ssh / authorised _ keys and exfiltration of PostgreSQL databases have been observed in recent campaigns.

Impacts observed in actual incidents: Microsoft reported an intrusion into a Kestra environment in which the attacker established a shell, explored the Docker socket, deployed a miner and used the workflow engine itself to collect and store results, reducing forensic devices. Wiz and Microsoft reports point to the chained use of vulnerabilities in LiteLLM (including CVE-2026-42271 and CVE-2026-48710) to deploy the XMRig mining, finish competing processes and pivote to LiteLLM PostgreSQL databases to steal configurations and supplier keys. Horizon3.ai and watchTowr documented the deployment of reverse shells and creation of tokens admin exploiting CVE-2026-9586 and CVE-2026-82329.

What is still uncertain or estimated: the full attribution (who is responsible in all cases) and the total number of victims are not publicly confirmed. Some correlations with groups (e.g. Qilin / Agenda) have been reported by security firms, but the details of scope, exact duration of intrusion in each victim and the complete list of compromised systems are still under investigation.

Specific measures and response prioritization (what a security officer should now do): 1) Prioritize patches: implement the official updates of the affected suppliers immediately. CISA and its BOD 26-04 set time limits for federal agencies; private organizations should align their responses with those time limits and speed up where there is public exposure. 2) Reduce the attack surface while it is patching: block external access to administration interfaces (SMA, Artifactory, AI web panels) through firewalls or control lists, require access by VPN or jump hosts and limit traffic to the minimum necessary. 3) Rotate credentials and keys: revoke and regenerate tokens, LLM supplier keys and administrative credentials if there has been a suspicion of commitment. 4) Review and harden Docker and containers: remove access to the Docker socket (docker.sock) to unreliable processes; use least privileged policies. 5) Find concrete commitment indicators: mining processes (XMRig), unusual ELF binaries, modifications to ~ / .ssh / authorised _ keys, unusual outgoing connections (C2), suspicious SQL entries and curl executions (124s); sh. 6) Monitoring and restricting egress: block suspicious destinations and apply outgoing TLS inspection to detect exfiltration. 7) Activate data layer detection: PostgreSQL audite logos for unusual queries or mass extraction of LiteLLM _ ProxyModelTable and LiteLLM _ VerificationToen tables as appropriate. 8) Implement MFA and robust logging: require multiple factor authentication to all administrative accesses and keep authentication logos and centralized syslog for research.

Product-specific recommendations (immediate practices): SonicWall SMA administrators: apply provided patches and, if connectivity cannot be closed, restrict management to the internal network or VPN. JFrog Artifactory users: patch and review administrative accounts and tokens; consider rotating access keys. LiteLLM operators and other IA infrastructure: reveal and revoke tokens from exposed suppliers, ensure that internal APIs are not directly accessible from the Internet, and treat models and endpoints as part of the control plane (monitoring, network separation). For Kestra: to park, to audit workflows created recently and to verify process artifacts as tasks that execute external commands.

Response teams should combine technical actions (parking, network blocking, key rotation) with a forensic investigation to determine whether there was already exfiltration. Keep in mind the manufacturers' releases and updated entries in the CISA catalogue to confirm mitigation and timelines: CISA KEV catalog. For context on observed commitments and techniques, the Microsoft security publication contains several operational details and practical recommendations to defend IA infrastructure: Microsoft Security Blog.

In short, the addition of these CVE to the KEV catalogue is not an administrative procedure: it confirms that operators already use these failures to gain access, move money through mining and steal valuable secrets. The opportunity window to contain the risk is narrow: park immediately, reduce critical interface exposure and treat IA platforms and orchestration as control components with security requirements equivalent to any other infrastructure service.