Jenkins Configuration as Code Plugin 1.55 and earlier used a non-constant time comparison function when validating an authentication token allowing attackers to use statistical methods to obtain a valid authentication token.
Configuration as Code Plugin logs the changes it applies to the Jenkins system log. Secrets such as passwords should be masked (i.e. replaced with asterisks) in that log to prevent accidental disclosure. Configuration as Code Plugin inspects the type and looks for a field, getter, or constructor argument corresponding to the property, making the secret detection much more robust for the purpose of log message masking. This was implemented in the fix for SECURITY-1279 in the 2019-07-31 security advisory.
That fix was incomplete and did not cover a log message written to the logger io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.
Configuration as Code Plugin now uses the same secret detection for these log messages.
As a workaround, administrators can configure the logging level of the logger io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator to a level that does not include these messages. Configuration as Code Plugin 1.25 and earlier logs these messages at the INFO level, Configuration as Code Plugin 1.26 logs them at FINE. See the logging documentation for details.
Jenkins Configuration as Code Plugin 1.20 and earlier did not treat the proxy password as a secret to be masked when logging or encrypted for export.
Missing permission checks in Jenkins Configuration as Code Plugin 1.24 and earlier in various HTTP endpoints allowed users with Overall/Read access to access the generated schema and documentation for this plugin containing detailed information about installed plugins.
Jenkins Configuration as Code Plugin 1.24 and earlier did not escape values resulting in variable interpolation during configuration import when exporting, allowing attackers with permission to change Jenkins system configuration to obtain the values of environment variables.
Jenkins Configuration as Code Plugin 1.24 and earlier did not reliably identify sensitive values expected to be exported in their encrypted form.
Configuration as Code Plugin logs the changes it applies to the Jenkins system log. Secrets such as passwords should be masked (i.e. replaced with asterisks) in that log to prevent accidental disclosure.
Between Configuration as Code Plugin 0.8-alpha and 1.0, log messages contained values if the values were specified using properties in the YAML file (SECURITY-929).
Since Configuration as Code Plugin 1.1, log messages in Configuration as Code Plugin instead mask values of type Secret, which is used in Jenkins to store the values encrypted on disk. This did not work in many instances, as plugins could use the Secret type to store credentials encrypted on disk while not having the Secret type appear in their Java API.
Configuration as Code Plugin now inspects the type and looks for a field, getter, or constructor argument corresponding to the property, making the secret detection much more robust for the purpose of log message masking. As a workaround, administrators can configure the logging level of the logger io.jenkins.plugins.casc.Attribute to a level that does not include INFO messages. See the logging documentation for details.
A exposure of sensitive information vulnerability exists in Jenkins Configuration as Code Plugin 0.7-alpha and earlier in DataBoundConfigurator.java, Attribute.java, BaseConfigurator.java, ExtensionConfigurator.java that allows attackers with access to Jenkins log files to obtain the passwords configured using Configuration as Code Plugin.
A exposure of sensitive information vulnerability exists in Jenkins Configuration as Code Plugin 0.7-alpha and earlier in ConfigurationAsCode.java that allows attackers with Overall/Read access to obtain the YAML export of the Jenkins configuration.