Top 5 Cybersecurity News Stories June 19, 2026
The five stories in this week’s Cybersecurity News Stories June 19, 2026 do not describe attacks that broke through the perimeter. They describe the infrastructure organisations depend on to stay connected, productive, and operational being compromised or left permanently undefended. An AI API gateway routing requests to OpenAI and Anthropic, now exploitable without credentials. An IDE plugin ecosystem that harvested developer AI keys for eight months without detection. A network switching platform whose vendor has explicitly declined to patch a known-exploited vulnerability. A data centre power management system with a CVSS 9.8 authentication bypass that lets an attacker force a server shutdown. And 74,000 Fortinet admin credentials cracked by a GPU cluster — from devices that were already patched. The common thread is not a shared attack technique. It is the assumption that operational infrastructure, the systems organisations rely on rather than consciously defend, has been adequately secured.
1) LiteLLM CVE-2026-42271: Your AI API Gateway Is Running Unauthenticated Remote Code Execution
On June 8, 2026, CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog with a federal remediation deadline of June 22. The vulnerability is a command injection flaw in LiteLLM, the open-source AI gateway and proxy used by organisations to route API traffic to OpenAI, Anthropic, Azure OpenAI, Cohere, Google Gemini, and dozens of other LLM providers. Two MCP server preview endpoints — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — accept full server configuration in the request body, including command, arguments, and environment variables, and spawn the supplied command as a subprocess on the proxy host when called. Alone, the vulnerability requires authenticated access. Chained with CVE-2026-48710, a host-header bypass vulnerability in Starlette (the underlying ASGI framework), authentication is bypassed entirely. The combined chain carries a CVSS score of 10.0 and enables unauthenticated remote code execution on any internet-exposed LiteLLM deployment. Affected versions span 1.74.2 through pre-1.83.7. Active exploitation has been confirmed. Fix: LiteLLM 1.83.7 and Starlette 1.0.1.
LiteLLM is not simply an application with a vulnerability. It is the aggregation layer through which an organisation connects every application it has built on AI to every AI provider it has contracted with. A compromised LiteLLM deployment gives an attacker simultaneous access to all stored AI API keys — OpenAI, Anthropic, Azure OpenAI, and whatever else the gateway has been configured to route. Those keys are not just billing credentials. Depending on the provider and configuration, they represent access to production AI features, fine-tuned model endpoints, embedding pipelines, and the data flowing through them. Organisations that deployed AI infrastructure rapidly over 2025 — many of which chose LiteLLM precisely because it abstracts multi-provider complexity — are the organisations most likely to be running the gateway on an internet-accessible endpoint without a dedicated security review of what that exposure means.
The pattern this story continues is one that began with Langflow in May 2026 and is now confirmed across at least two platforms in the same category: AI orchestration and gateway infrastructure carries a structural risk profile that enterprise security programmes have not yet modelled. The gateway sits between production and AI providers, holds credentials for both directions, is often accessible via HTTP to developers inside the organisation, and sometimes via the internet to facilitate multi-cloud or multi-site deployments. Each of those characteristics, individually manageable in a traditional application context, combines into an exposure that traditional perimeter controls were not designed to address.
Read more on: The Hacker News
2) JetBrains Marketplace: 15 Malicious AI Plugins Stole Developer API Keys for Eight Months
On June 16, 2026, JetBrains confirmed that 15 third-party plugins on JetBrains Marketplace had been building to steal AI provider API keys from developers since October 2025. The plugins — including two with more than 25,000 downloads each (CodeGPT AI Assistant and DeepSeek AI Assist) — appeared fully functional and delivered their advertised features. The attack mechanism was precise: when a developer entered their AI provider API key into the plugin’s configuration settings and clicked Apply, the plugin executed an unauthorised backend function that transmitted the key as a plaintext JSON payload over unencrypted HTTP to a hardcoded command-and-control IP (39.107.60[.]51). To prevent detection, the plugins silently installed a JVM-wide X509TrustManager that disabled standard TLS certificate warnings. The keys stolen included credentials for OpenAI, Anthropic, DeepSeek, and other major AI providers. Total installs across all 15 plugins: more than 70,000. JetBrains removed all 15 plugins, blocked the publisher accounts, and remotely disabled them in installed IDEs on June 16.
The eight-month window between first publication (October 2025) and removal (June 2026) is the governance story. JetBrains Marketplace does not apply the same level of automated security scanning that the npm ecosystem has developed over years of supply chain attacks. The developer who installed a JetBrains plugin to enhance their AI coding workflow had no available signal that the plugin was harvesting their credentials — the plugin worked as advertised, passed no visible validation step, and generated no alert in the IDE. The specific target — AI provider API keys — has direct financial and operational implications beyond a stolen password. AI API keys are the billing mechanism for LLM usage; stolen keys are exploited for compute cost fraud at scale. They are also, for keys with production access, a path into AI-integrated workflows and potentially the data those workflows process.
The broader signal is that the IDE plugin marketplace has become the next unguarded surface in the developer supply chain attack arc. Previous supply chain attacks in 2026 targeted npm preinstall hooks, PyPI packages, GitHub Actions runners, and Visual Studio Code extensions. JetBrains Marketplace adds IntelliJ IDEA, PyCharm, WebStorm, GoLand, and every other JetBrains IDE to that list. Developers who rely on AI-enhanced productivity tools are now also the primary target of the credential theft mechanism those tools create.
Read more on: BleepingComputer
3) Arista EOS CVE-2026-7473: CISA Added It to the Exploited Catalog — The Vendor Won’t Patch It
On June 9, 2026, CISA added CVE-2026-7473 to its Known Exploited Vulnerabilities catalog with a federal remediation deadline of June 23. CVE-2026-7473 is a tunnel decapsulation logic flaw in Arista EOS, the operating system running the 7020R, 7280R/R2, and 7500R/R2 data centre switch series. When a decapsulation configuration is present — VXLAN, decap-groups, or a GRE tunnel interface — the affected switches incorrectly decapsulate and forward unexpected tunnelled packets with a destination IP matching the configured decapsulation IP, because the switch does not verify tunnel protocol type. The result is that untrusted external tunnel traffic can be injected into internal network segments that the operator believed were protected by decapsulation controls. Arista has explicitly stated that no patch will be issued for CVE-2026-7473, citing the risk that a firmware fix could break existing configurations on production deployments. The recommended remediation is to implement access control lists on upstream devices or on the affected switches themselves to selectively block unexpected tunnel traffic.
The governance implication of a CISA Known Exploited Vulnerabilities entry where the vendor has explicitly declined to patch is structurally different from any other KEV entry. In every other case, the remediation path for an organisation is to apply the vendor’s fix. Here, the vendor has determined that the operational risk of patching outweighs the security risk of the vulnerability, and has transferred remediation responsibility entirely to the operator. Arista is not a fringe networking vendor. The affected switch series are deployed in hyperscale data centre environments, large enterprise core networks, and financial infrastructure. Operators who do not understand the precise decapsulation configuration on each affected switch, and who cannot implement granular upstream ACLs without disrupting production traffic, have no available vendor-supplied resolution.
The pattern this extends is not simply “patch your network gear.” It is a more uncomfortable question: what is an organisation’s governance model for a confirmed exploited vulnerability in critical network infrastructure where no patch is forthcoming and the mitigation requires surgical network configuration changes? The answer for most organisations is that this scenario was not in their vulnerability management programme’s design envelope, and the policy gap it exposes is one that affects every piece of network infrastructure in their environment, not just Arista.
Read more on: SecurityWeek
4) Vertiv UPS Management Cards: Authentication Bypass and RCE That Can Physically Shut Down Your Data Centre
On June 12, 2026, Claroty’s Team82 disclosed two critical vulnerabilities in Vertiv Liebert IS-UNITY-DP and Liebert RDU101 network management cards — the components that provide remote management, monitoring, and control of Vertiv uninterruptible power supply systems deployed in data centres and critical infrastructure. CVE-2025-46412 (CVSS 9.8) is an authentication bypass that allows an attacker to access the UPS management web interface without any credentials. CVE-2025-41426 (CVSS 9.8) is a stack-based buffer overflow enabling remote code execution on the management module itself. Used together, an unauthenticated attacker with network access to the management card can execute arbitrary code on a device that controls the power state of every server connected to that UPS circuit. The practical result: an attacker can execute a forced shutdown of server racks during normal operations, or manipulate the UPS state during an actual power event in a way that causes equipment damage or uncontrolled outages. Vertiv has issued fixed firmware versions: Liebert RDU101 to v1.9.1.2_0000001 and IS-UNITY to v8.4.3.1_00160.
The strategic exposure here is not the specific vulnerability mechanism. It is the category of infrastructure these vulnerabilities affect: the power continuity layer. Enterprise data centres, hospital IT environments, manufacturing OT facilities, and financial infrastructure all rely on UPS systems to maintain operations during power events and to allow controlled shutdown procedures when mains power fails. The management cards for these systems are network-connected — they are what allows a data centre operator to monitor battery health, configure runtime parameters, and execute controlled shutdowns remotely. That network connectivity, which exists for operational reasons, creates the attack surface Claroty disclosed. The management card network segment is rarely treated as part of the IT security perimeter; it is often managed by facilities teams, powered separately from IT infrastructure, and outside the scope of standard vulnerability management processes.
The signal this story sends is consistent with a pattern 2026 has established across multiple sectors of operational infrastructure. Ransomware operators learned to target Veeam backup servers (June 12) because owning the backup removes the recovery option. The logical extension of that reasoning is to target the power layer, because owning the UPS management removes the physical resilience option. Claroty’s disclosure is research, not confirmed ransomware deployment. But it establishes the capability and the attack surface in a way that operational security programmes should treat as current risk, not future hypothetical.
Read more on: SecurityWeek
5) FortiBleed: 74,000 Fortinet Admin Credentials Cracked — From Devices That Were Already Patched
On June 18, 2026, the Australian Cyber Security Centre issued a critical alert regarding FortiBleed, an active credential harvesting campaign targeting Fortinet FortiGate firewalls and VPN gateways across 194 countries. A Russian-speaking criminal group systematically extracted SSL VPN configuration files from internet-facing FortiGate devices, then cracked the administrator credential hashes contained in those files using a 45-GPU Hashtopolis cluster executing 1.16 billion attempts. The result: 73,932 verified, working administrator credentials for Fortinet devices across Fortune 500 companies, government agencies, and confirmed NATO contractors. There is no CVE. The vulnerability exploited is not in the current FortiOS codebase. The exposure arises from the mechanism by which Fortinet migrated its password hashing algorithm. Fortinet introduced PBKDF2-based password hashing — replacing the legacy SHA-256 mechanism — in FortiOS versions 7.2.11, 7.4.8, and 7.6.1. The critical detail: when an organisation upgrades to a PBKDF2 version, existing administrator credential hashes are NOT automatically migrated. They remain stored as SHA-256 until each administrator account successfully logs in after the upgrade. An organisation that patched to FortiOS 7.4.8 and has not subsequently required every administrator to re-authenticate is still storing admin credentials in the weaker hash format — and those credentials are the ones FortiBleed has been cracking. Hudson Rock has published a free credential lookup tool.
The governance insight FortiBleed surfaces is one that applies far beyond Fortinet. Security improvements to credential storage — stronger hashing algorithms, salting schemes, key derivation functions — routinely require an active trigger to apply to existing credentials. Simply patching the platform that stores those credentials does not automatically re-hash them. Organisations that performed the FortiOS upgrades, checked the patch compliance dashboard, and moved on have almost certainly not completed the follow-through step of verifying that every administrator account has re-authenticated since the upgrade. In a large organisation with dozens of Fortinet devices and multiple administrative accounts on each, that follow-through is not trivial. The ACSC alert makes the required response explicit: force re-authentication for all Fortinet administrator accounts across the entire fleet, and verify that re-authentication has been completed before treating the credential migration as done. Post-authentication impact for any cracked credential is full administrative access to the FortiGate — with confirmed deployment of LDAP, RADIUS, and Active Directory network sniffers on all traffic.
The Fortinet story arc in 2026 has now run to four distinct events: AI-assisted automated exploitation of FortiGate in February, the FortiClient EMS CVE-2026-35616 endpoint manager takeover in June 1, the FortiSandbox CVE-2026-39813 security appliance exploitation beginning June 15, and FortiBleed’s credential campaign on June 18. None of these events is a continuation of the prior one. They represent four independent research teams and criminal actors finding four different ways to compromise four different Fortinet products. The strategic reading is not that Fortinet is a uniquely vulnerable vendor. It is that any vendor whose products hold administrative network access at scale has become a systematic research target, and that organisations with deep Fortinet deployments cannot address each incident in isolation.
Read more on: Help Net Security
If this week tells us anything, it’s this:
The five stories in this week’s Cybersecurity News Stories June 19, 2026 share a structural characteristic that becomes visible only when you view them as a set rather than as five independent incidents. In each case, the compromised or at-risk system is not a target an organisation consciously deployed to address a specific security risk. It is infrastructure — the AI gateway connecting production applications to LLM providers, the IDE that developers spend their working day in, the switching hardware running the data centre core, the power management system keeping that hardware online, the firewall protecting the perimeter. These systems exist to enable operations. Security governance for them has, in most organisations, been an afterthought relative to the security governance applied to the applications they support.
The operational implication is not a patching checklist. The LiteLLM and Arista stories have different remediation characters: one has a patch, one explicitly does not. The JetBrains and Vertiv stories require security controls in environments — IDE plugin governance and physical infrastructure management — that most enterprise security programmes have not formally modelled. The FortiBleed story requires not a patch but a process: forcing re-authentication across an entire device fleet and verifying completion. The governance pattern these five stories expose is the same one that underlies the most consequential breaches of 2026: the attack surface has expanded into layers that security architectures were not designed to cover, and the gap between where organisations look for threats and where threats now arrive is the space in which 2026’s incidents are occurring.
For more information, please contact us now!
