CVE-2025-53513
📋 TL;DR
This vulnerability allows any authenticated user on a Juju controller to upload malicious charms via the /charms endpoint due to insufficient authorization checks. Combined with a Zip Slip vulnerability in the uploaded charm, attackers could gain access to machines running affected units. All Juju deployments with the vulnerable endpoint exposed are affected.
💻 Affected Systems
- Juju
📦 What is this software?
Juju by Canonical
Juju by Canonical
⚠️ Risk & Real-World Impact
Worst Case
Full compromise of machines running Juju units through arbitrary file write leading to remote code execution, potentially allowing lateral movement within the infrastructure.
Likely Case
Unauthorized charm upload leading to file system manipulation on target machines, potentially enabling data theft, service disruption, or further exploitation.
If Mitigated
Limited to authenticated users only, with proper network segmentation reducing attack surface to internal trusted users.
🎯 Exploit Status
Exploitation requires authentication to the Juju controller and creation of a malicious charm with Zip Slip payload. The vulnerability chain (auth bypass + Zip Slip) makes exploitation feasible for attackers with basic Juju knowledge.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Check the GitHub security advisory for specific fixed versions
Vendor Advisory: https://github.com/juju/juju/security/advisories/GHSA-24ch-w38v-xmh8
Restart Required: Yes
Instructions:
1. Update Juju to the latest patched version. 2. Restart Juju controller services. 3. Verify the fix by testing charm upload authorization.
🔧 Temporary Workarounds
Restrict access to /charms endpoint
linuxImplement network access controls to limit which users/systems can reach the Juju controller API endpoint.
# Use firewall rules to restrict access to Juju controller port
sudo ufw deny from any to <juju_ip> port <api_port> except trusted_networks
Implement API gateway authentication
allAdd additional authentication layer in front of Juju controller API to validate user permissions.
# Configure reverse proxy with additional auth (example for nginx)
location /charms {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://juju-controller:port;
}
🧯 If You Can't Patch
- Implement strict network segmentation to isolate Juju controllers from untrusted networks.
- Review and restrict user accounts on Juju controllers to only necessary personnel with minimal privileges.
🔍 How to Verify
Check if Vulnerable:
Attempt to upload a charm via the /charms endpoint with a user account that should not have upload permissions. If successful, the system is vulnerable.Check Version:
juju versionVerify Fix Applied:
After patching, attempt the same charm upload with unauthorized user - it should be rejected with proper authorization error.📡 Detection & Monitoring
Log Indicators:
- Unauthorized charm upload attempts in Juju controller logs
- Failed authorization checks for /charms endpoint
- Unexpected charm uploads from non-admin users
Network Indicators:
- Unusual POST requests to /charms endpoint from unexpected sources
- Large file uploads to charm endpoint followed by unit deployment
SIEM Query:
source="juju-controller.log" AND ("charm upload" OR "/charms") AND NOT user="admin"