CVE-2025-32755 Overview
CVE-2025-32755 is a cryptographic vulnerability affecting Jenkins SSH-Slave Docker images based on Debian. The vulnerability arises from SSH host keys being generated during image creation rather than at container runtime, resulting in all containers based on the same image version sharing identical SSH host keys. This flaw enables network-positioned attackers to perform man-in-the-middle (MITM) attacks by impersonating SSH build agents to the Jenkins controller.
Critical Impact
Attackers who can position themselves in the network path between Jenkins controllers and SSH build agents can impersonate build agents, potentially compromising CI/CD pipeline integrity and accessing sensitive build artifacts and credentials.
Affected Products
- Jenkins SSH-Slave Docker images (Debian-based)
- Containers deployed using jenkins/ssh-slave Docker images
- CI/CD environments utilizing Jenkins SSH build agents via Docker
Discovery Timeline
- 2025-04-10 - CVE-2025-32755 published to NVD
- 2025-05-02 - Last updated in NVD database
Technical Details for CVE-2025-32755
Vulnerability Analysis
This vulnerability is classified under CWE-338 (Use of Cryptographically Weak Pseudo-Random Number Generator), though the core issue relates to the timing of SSH host key generation in Docker image builds. When Docker images are built, the SSH host keys are generated once during the image creation process. These keys are then baked into the image layer and distributed to all containers instantiated from that image version.
The fundamental security assumption of SSH host keys is that each host has a unique key pair that identifies it to clients. This uniqueness is what allows clients to detect MITM attacks by comparing the presented host key against known keys. When multiple containers share identical host keys, this security guarantee is completely undermined.
Root Cause
The root cause is an insecure default configuration in the Jenkins SSH-Slave Docker image build process. The SSH server package installation or configuration step generates host keys at image build time rather than deferring key generation to container initialization. This means:
- The ssh-keygen commands that create /etc/ssh/ssh_host_* keys run during docker build
- These generated keys become part of the immutable image layers
- Every container started from the image inherits the same private and public key pairs
- No runtime mechanism exists to regenerate unique keys per container
Attack Vector
This vulnerability is exploitable over the network without requiring authentication or user interaction. An attacker must be able to intercept network traffic between the Jenkins controller (SSH client) and the SSH build agent container. This could be achieved through:
- Network-level attacks: ARP spoofing, DNS hijacking, or BGP hijacking to redirect traffic
- Compromised network infrastructure: Access to switches, routers, or network taps
- Cloud environment attacks: Exploitation of shared networking in cloud or container orchestration environments
Once positioned, the attacker can present the shared SSH host key (which is publicly available in the Docker image) to the Jenkins controller. Since the key matches what the controller expects, the attacker can successfully impersonate the build agent.
The attacker can then intercept build commands, inject malicious code into builds, exfiltrate build artifacts or credentials passed to the build agent, and manipulate build outputs before forwarding them to the actual agent.
Detection Methods for CVE-2025-32755
Indicators of Compromise
- Unexpected SSH session reconnections or authentication failures in Jenkins controller logs
- Network traffic anomalies between Jenkins controllers and build agents
- SSH host key fingerprint mismatches detected by clients not yet trusting the compromised key
- Unusual build behavior or artifacts that differ from expected outputs
Detection Strategies
- Audit deployed Jenkins SSH-Slave containers for duplicate SSH host key fingerprints across instances
- Implement network monitoring to detect ARP spoofing or other MITM positioning techniques
- Review Jenkins controller SSH known_hosts entries for consistency with expected build agents
- Deploy intrusion detection systems to monitor Jenkins-to-agent communication patterns
Monitoring Recommendations
- Enable detailed SSH logging on both Jenkins controllers and build agent containers
- Implement centralized log aggregation to correlate connection events across infrastructure
- Set up alerts for SSH host key change events that may indicate ongoing exploitation
- Monitor network flows for unexpected traffic patterns between CI/CD components
How to Mitigate CVE-2025-32755
Immediate Actions Required
- Regenerate SSH host keys on all deployed Jenkins SSH-Slave containers immediately
- Update container deployment scripts to generate fresh SSH host keys at container startup
- Review Jenkins controller known_hosts files and remove or update stale entries
- Consider network segmentation to limit exposure of build agent traffic
Patch Information
Jenkins has published a security advisory addressing this vulnerability. Refer to the Jenkins Security Advisory SECURITY-3565 for official guidance on patched image versions and remediation steps. Ensure you pull the latest patched Docker images from the official Jenkins repository.
Workarounds
- Add a container entrypoint script that regenerates SSH host keys using ssh-keygen -A before starting the SSH daemon
- Build custom images that remove existing host keys and include a startup script for key generation
- Implement strict network controls and mutual TLS between Jenkins controllers and build agents
- Consider alternative agent connectivity methods such as Jenkins JNLP agents that don't rely on SSH
# Configuration example: Container entrypoint script to regenerate SSH host keys
#!/bin/bash
# Remove any existing host keys baked into the image
rm -f /etc/ssh/ssh_host_*
# Generate fresh unique host keys for this container instance
ssh-keygen -A
# Start SSH daemon
exec /usr/sbin/sshd -D
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

