CVE-2026-4370 (CVSS 10): Critical Juju Flaw Grants Attackers Total Infrastructure Control

The cybersecurity community is on high alert following the discovery of a critical security flaw in Juju, the popular open-source application orchestration engine. Labeled as CVE-2026-4370, the vulnerability has been assigned a CVSS score of 10.0—the highest possible rating for severity—indicating a total breakdown in security protocols that could leave entire infrastructures exposed.

Juju is designed to simplify complex application operations across any infrastructure using special operators called “charms”. However, a fundamental error in how Juju controllers verify identities has turned this efficiency into a liability.

The core of the issue lies in the Dqlite cluster endpoint, which handles database replication for Juju. According to the security advisory, the system suffers from improper TLS authentication. Specifically, the server fails to check client certificates, and in a dangerous “anything goes” scenario, the client also fails to check the server’s certificate.

“An attacker with only route-ability to the target juju controller Dqlite cluster endpoint may join the Dqlite cluster, read and modify all information, including escalating privileges, open firewall ports etc,” the advisory warns.

This lack of mutual verification makes Man-in-the-Middle (MITM) attacks trivial for anyone who can reach the network port.

The impact is broad, affecting any Juju controller since version 3.2.0. Because Juju is often used to manage large-scale production environments and Kubernetes clusters, the ability for an unauthorized user to “join the cluster” and “modify all information” poses a catastrophic risk to data integrity and system availability.

Security experts are urging administrators to prioritize updates immediately. Official patches have been released to close this massive security hole:

• Juju 3.6.20
• Juju 4.0.5

If updates cannot be applied immediately, several “last resort” mitigations can be implemented to shield the vulnerable port 17666:

• Restrict Network Access: Implement strict firewall rules so that port 17666 can only be accessed by other known Juju controller IP addresses.
• Disable High Availability (HA): For environments where HA isn’t strictly required, reducing the cluster to a single controller eliminates the need for the dangerous Dqlite replication entirely.
• Kubernetes Protections: Since HA is not supported for Kubernetes controllers, administrators should apply network policies to block all external access to port 17666, effectively isolating it to itself.

While these manual steps provide a temporary shield, the advisory warns that modifying configuration files can interfere with future automated upgrades. The only permanent and “strongest protection” is the immediate application of security updates.