https://feed.craftedsignal.io/tags/juju/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioSat, 04 Apr 2026 12:00:00 +0000https://feed.craftedsignal.io/briefs/2026-04-juju-resource-poisoning/Sat, 04 Apr 2026 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-04-juju-resource-poisoning/An authenticated user, machine, or controller within a Juju controller can modify application resources due to a lack of authorization checks, potentially leading to resource poisoning and privilege escalation by uploading malicious resources.A resource poisoning vulnerability exists within Juju, a cloud orchestration tool. Any authenticated user, machine, or controller operating under a Juju controller can exploit this vulnerability to modify the resources of an application within the entire controller. The vulnerability stems from insufficient authorization checks in the resource handler, allowing unauthorized PUT and GET requests. A compromised workload with machine credentials can modify OCI resources for other models in the controller, such as replacing a legitimate Docker image with a trojan horse version. This vulnerability affects Juju versions prior to the fix in commit 26ff93c903d5, specifically in the go/github.com/juju/juju package. This can have significant consequences, including privilege escalation and unauthorized access to sensitive information.

Attack Chain

1. Attacker gains initial access to a Juju controller as an authenticated user, machine, or controller. This could be via compromised credentials or a vulnerable workload already within the Juju environment.
2. The attacker identifies the target model UUID, application name, and resource name they wish to poison. This information can be obtained through enumeration within the Juju environment or by leveraging publicly available charm information from Charmhub.
3. The attacker crafts a malicious resource, such as a trojan horse Docker image, that has the same file extension as the original resource.
4. The attacker sends a PUT request to the resource handler endpoint /:modeluuid/applications/:application/resources/:resources with the malicious resource.
5. The Juju controller’s resource handler, lacking proper authorization checks, accepts the malicious resource and overwrites the existing resource in its cache.
6. When the target application attempts to retrieve the resource, it receives the poisoned version from the controller’s cache.
7. The poisoned resource is executed or deployed within the target application’s environment, leading to compromise. In the case of a Docker image, this could lead to root access on the underlying system.
8. The attacker leverages the compromised application (e.g., a Kubernetes vault) to access sensitive information, such as vault secrets, and further expand their access within the environment.

Impact

This vulnerability allows an attacker to inject security vulnerabilities into other workloads managed by Juju. This can lead to privilege escalation, data breaches, and complete compromise of the Juju-managed environment. The most obvious impact is on deployments using OCI containers, where a malicious Docker image can grant an attacker execution escalation. In a Kubernetes environment managing vault secrets, an attacker could potentially gain root access to all vault secrets, seriously impacting the confidentiality and integrity of the data stored within. The specific impact depends on the type of resource poisoned and its role in the target application, but could be severe.

Recommendation

• Upgrade Juju to a version containing the fix for CVE-2025-68153 to address the underlying vulnerability.
• Implement additional authorization checks and access controls within the Juju environment to restrict resource modification to authorized users and processes.
• Enable and review Juju API server logs (category: webserver, product: linux) for suspicious PUT requests to resource handler endpoints, looking for unexpected resource modifications.
• Deploy the Sigma rule “Detect Unauthorized Juju Resource Modification” to your SIEM to detect unauthorized PUT requests to Juju resource endpoints.

]]>highadvisoryjujuresource-poisoningprivilege-escalationcloudhttps://feed.craftedsignal.io/briefs/2026-04-juju-tls-vuln/Thu, 02 Apr 2026 00:03:36 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-04-juju-tls-vuln/Juju controller versions 3.2.0 up to 3.6.20 and 4.0.5 are vulnerable to unauthorized database access due to improper TLS client/server authentication and certificate verification, allowing an attacker with network access to modify all information, escalate privileges, and open firewall ports.Juju, a service orchestration tool, contains a critical vulnerability related to improper TLS configuration within its Dqlite database cluster. This vulnerability affects Juju controller versions 3.2.0 up to 3.6.20 and 4.0.5. The lack of client certificate checking and server certificate verification allows an attacker with network route-ability to the Juju controller’s Dqlite cluster endpoint (port 17666) to join the cluster without proper authentication. This grants the attacker the ability to read and modify all information within the database, including sensitive user credentials and system configurations. Exploitation of this vulnerability enables privilege escalation, unauthorized access to resources, and potentially the ability to open firewall ports, leading to a complete compromise of the Juju controller and managed services. Patches are available in Juju versions 3.6.20 and 4.0.5.

Attack Chain

1. The attacker gains network access to the target Juju controller’s Dqlite cluster endpoint, typically port 17666.
2. The attacker uses a tool like dqlite-demo or a custom-built application leveraging the go-dqlite library to attempt to join the Dqlite cluster.
3. Due to the missing client certificate verification, the attacker’s connection is accepted without proper authentication.
4. The attacker switches to the controller database using the .switch controller command within the dqlite shell.
5. The attacker queries the user table to identify existing users and their associated privileges using select * from user;.
6. The attacker modifies the display_name of the admin user within the user table using an update SQL command, for example: update user set display_name='Compromised Admin' where name='admin';.
7. The attacker could further modify credentials, add new administrative users, or modify system configurations within the database.
8. The attacker leverages their unauthorized access to escalate privileges, compromise managed services, and potentially open firewall ports, gaining complete control over the Juju environment.

Impact

Successful exploitation of this vulnerability allows an attacker to completely compromise the Juju controller. The attacker can read and modify all information within the Juju database, including user credentials, application configurations, and system settings. This can lead to the compromise of all applications and services managed by the Juju controller. Privilege escalation allows the attacker to gain administrative control over the Juju environment. The ability to open firewall ports provides a pathway for lateral movement and further exploitation of the compromised network.

Recommendation

• Immediately upgrade Juju controllers to versions 3.6.20 or 4.0.5 to apply the patches that address this vulnerability.
• Implement restrictive firewall rules to limit access to port 17666 on Juju controllers, as recommended in the advisory. Ensure only other controller IP addresses can connect to this port.
• Deploy the following Sigma rule to detect unauthorized connections to the Dqlite database (see Sigma rule below).
• Monitor network connections to port 17666 for unexpected source IP addresses (see IOCs).

]]>criticaladvisoryjujudqlitetlsvulnerability