Upgrading Jenkins to Mitigate CVE-2024-23897 and Refactoring CI/CD Infrastructure

Background

Recently I needed to migrate and upgrade Jenkins because of the critical vulnerability CVE-2024-23897, which allows unauthenticated attackers to read arbitrary files on the Jenkins controller by abusing the CLI command parser.

Therefore Jenkins must be upgraded to at least 2.442 (or LTS 2.426.3) and the opportunity is taken to refactor unsatisfactory parts of the previous setup.

Jenkins Before Upgrade

The pre‑upgrade environment used Jenkins 2.346.3, the last version supporting Java 8, and could not move to Java 17 due to the old operating system.

Good practices already in place:

Infrastructure as Code via Docker Compose deployment.

Configuration as Code using a Jenkins Shared Library to manage all pipelines.

Multibranch Pipeline for building and testing projects.

Shortcomings identified:

No fixed domain name for the Jenkins server; it was accessed via an IP address, causing webhook updates when the host changed.

Docker Cloud not used; agents were not dynamically created with Docker JNLP.

The Shared Library name and structure were team‑specific and needed refactoring.

No Windows Docker containers were employed.

Obsolete plugins remained installed.

Jenkins and plugins lagged behind due to agent version constraints.

Jenkins After Upgrade

Building on the existing good practices, the following optimizations were applied:

Continued Infrastructure as Code, adding Nginx as a reverse proxy and assigning a stable domain name.

Maintained Configuration as Code principles.

Retained Multibranch Pipeline usage.

Leveraged Docker Cloud for builds wherever possible.

Renamed the Shared Library to pipeline-library to align with Jenkins naming conventions and refactored many Jenkinsfile and Groovy scripts.

Introduced Windows Docker containers for building Windows components.

Adopted the Jenkins Configuration as Code plugin for regular configuration backups.

Installed only essential plugins and exported the plugin list via the plugin command.

Implemented pre‑upgrade plugin backups to enable quick rollback on failure.

Conclusion

The goal is to manage infrastructure maintenance and pipeline development through a GitOps approach, continuously exploring and applying best practices so that CI/CD becomes a healthy, sustainably maintained, self‑improving DevOps system.

References

[1] CVE‑2024‑23897: https://nvd.nist.gov/vuln/detail/CVE-2024-23897