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.

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.

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.