CVE-2019-16542 in Anchore Container Image Scanner Plugin
Summary
by MITRE
Jenkins Anchore Container Image Scanner Plugin 1.0.19 and earlier stores credentials unencrypted in job config.xml files on the Jenkins master where they can be viewed by users with Extended Read permission, or access to the master file system.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/22/2019
The vulnerability identified as CVE-2019-16542 affects the Jenkins Anchore Container Image Scanner Plugin version 1.0.19 and earlier, presenting a critical security risk within container image scanning workflows. This flaw represents a classic case of insecure credential storage where sensitive authentication information is persisted in plaintext within the Jenkins configuration files, specifically within the job config.xml files that reside on the Jenkins master server. The vulnerability stems from the plugin's failure to implement proper encryption mechanisms for credential handling, creating a persistent exposure point that undermines the security posture of container image scanning operations.
The technical implementation of this vulnerability involves the plugin's storage mechanism for anchore server credentials, which are written directly to the job configuration files without any form of encryption or obfuscation. When Jenkins processes container image scanning jobs, it serializes the plugin configuration including authentication tokens, usernames, and passwords into the config.xml file, making these credentials accessible to any user who possesses Extended Read permission on the Jenkins job or has direct access to the master file system. This design flaw directly violates security best practices for credential management and represents a failure to implement proper access controls and encryption mechanisms.
From an operational perspective, this vulnerability creates significant risk exposure for organizations using Jenkins for container image security scanning. Attackers who gain Extended Read access to Jenkins jobs or achieve file system access to the Jenkins master can directly extract anchore server credentials and potentially gain unauthorized access to container image repositories and scanning capabilities. This compromises not only the container scanning functionality but also potentially exposes underlying container registries, image repositories, and associated scanning infrastructure. The impact extends beyond immediate credential theft to potential lateral movement within containerized environments and unauthorized access to sensitive container images and their associated security data.
The vulnerability aligns with CWE-312 (Cleartext Storage of Sensitive Information) and CWE-522 (Insufficiently Protected Credentials), both of which address the improper handling of sensitive data in storage contexts. From an ATT&CK framework perspective, this vulnerability maps to T1552.001 (Unsecured Credentials) and T1078.004 (Valid Accounts) as it enables adversaries to obtain valid credentials through insecure storage mechanisms. The attack surface is particularly concerning in environments where Jenkins masters are shared across multiple development teams or where extended read permissions are granted more broadly than necessary. Organizations implementing container security pipelines using this plugin face increased risk of credential compromise, potentially leading to unauthorized access to container registries, image analysis capabilities, and associated security intelligence.
Mitigation strategies should focus on immediate plugin updates to versions that properly encrypt credentials, implementation of strict access controls limiting Extended Read permissions, and regular auditing of Jenkins configuration files for credential exposure. Organizations should also consider implementing additional monitoring for unauthorized access to Jenkins master file systems and credential usage patterns. The recommended approach includes upgrading to plugin versions that implement proper credential encryption, enabling Jenkins' built-in credential storage mechanisms, and conducting comprehensive security reviews of all Jenkins plugins to identify similar insecure credential storage patterns. Additionally, implementing network segmentation and access controls around Jenkins masters can limit the attack surface and reduce the impact of credential exposure incidents.