Your Jenkins Server Joined a Botnet. You Probably Haven't Noticed.

#The server nobody watches is the one doing the most damage.

Every company that runs its own Jenkins server has the same story. Somebody set it up two years ago. It builds the code, runs the tests, maybe pushes a deployment. It works. Nobody touches it. Nobody patches it. Nobody reviews who has access. It sits in a corner of the network, or worse, on a cloud instance with a public IP, doing its job.

And now it's doing somebody else's job too.

Honeypot research published in May 2026 found attackers actively scanning the internet for exposed Jenkins servers, logging in with default or weak credentials, and using Jenkins' built-in Groovy script console to execute arbitrary code on the host. The payload? DDoS botnet malware. Your build server is now launching denial-of-service attacks against targets you've never heard of.

The attackers didn't need a zero-day. They didn't need a CVE. They needed a Jenkins instance with a default password and a management interface reachable from the internet. That's it.

#Why Jenkins is a perfect botnet recruit.

If you were designing the ideal machine to participate in a DDoS attack, you'd want exactly what a CI server already has.

High outbound bandwidth. CI servers pull large container images, push artifacts to registries, download dependencies. They're provisioned with fast, unthrottled network connections. That same bandwidth makes them excellent DDoS nodes.

Elevated privileges. Jenkins typically runs as root or with broad system access. It needs to build Docker containers, access credentials stores, deploy to production. An attacker who gets code execution on Jenkins gets code execution with those same permissions.

Nobody's watching. Your SOC dashboard, if you have one, is tracking endpoints. User workstations. Servers that handle customer data. Nobody is watching outbound traffic from the build server. Nobody has an alert for "Jenkins is sending 10 Gbps of UDP traffic to a game server in Eastern Europe."

A built-in remote code execution feature. This is the part that should concern you. Jenkins ships with a Groovy script console at /script and /scriptText. It's designed to let administrators run arbitrary code on the Jenkins host from a web browser. It's a feature, not a bug. But if an attacker can reach that console and authenticate, they have full remote code execution without uploading a single exploit. They just type commands into a text box.

#"But our Jenkins isn't on the internet."

Are you sure?

I've run assessments where the client swore their Jenkins was internal-only. Then we checked. It was on a cloud VM with a public IP, port 8080 wide open, login page visible to the entire internet. Sometimes because it was set up in a hurry and nobody went back to lock it down. Sometimes because a developer needed to trigger builds from home and the fastest solution was "just open the port." Sometimes because the cloud provider's default security group allows all inbound traffic and nobody changed it.

Even if it's genuinely internal, "internal" isn't always as protected as you think. If an attacker compromises any device on your network, an unprotected Jenkins server is one of the first things they'll look for. It's a privilege escalation goldmine: credentials, deployment keys, access tokens, and a built-in code execution console.

#What the attackers are doing with your server.

The campaign observed by researchers was using compromised Jenkins servers as DDoS nodes targeting game servers. That sounds almost trivial until you think about what it means.

Your IP address is attacking someone. When the DDoS target investigates, your company's IP shows up in the attack traffic. That's a conversation you don't want to have with your ISP, your hosting provider, or law enforcement.

Your bandwidth is being consumed. A DDoS node generating attack traffic is using your network capacity. If your CI server is in a cloud environment, you're paying for that egress traffic. If it's on-premises, it's saturating your connection.

Your server is compromised. The DDoS payload is just what the attackers chose to deploy first. They have code execution on your CI server. They have access to everything Jenkins can reach. Build artifacts. Environment variables with API keys. Deployment credentials. Database connection strings. Source code. The DDoS botnet is the least of your problems.

It's a pivot point into your infrastructure. CI servers typically have network access to your production environment, your code repositories, your artifact registries, and your secrets management. An attacker on your Jenkins server is one hop away from your production database.

#What to do.

1. Check if your Jenkins is internet-exposed right now. Look up your Jenkins server's public IP on Shodan or Censys. If port 8080 (or whatever port you use) shows a Jenkins login page, the attackers can find it too. And based on this research, they're actively looking.

2. Remove Jenkins from the public internet. The management interface should not be reachable from outside your network. Put it behind a VPN. Put it behind a firewall. Put it on a private subnet with no public IP. However you do it, the Jenkins web UI should not be accessible from the internet. If developers need remote access, they connect through a VPN first.

3. Disable the Groovy script console for non-admins. Go to Manage Jenkins, then Configure Global Security. Restrict access to the script console (/script, /scriptText) to only the accounts that absolutely need it, which is probably zero accounts in daily use. If you're not actively using the console for administration, disable it entirely. It's the single most dangerous feature on the server.

4. Stop using default credentials. If your Jenkins admin account is "admin/admin" or "admin/password" or "jenkins/jenkins," change it right now. Use a strong, unique password stored in your password manager. Better yet, integrate Jenkins with your SSO or LDAP so authentication is centralized and you can enforce MFA.

5. Enable authentication on everything. Jenkins can be configured to allow anonymous read access. That means anyone who can reach the server can see your build configurations, your job names, your environment variable names, and sometimes your build logs. Lock it down. Require authentication for all access.

6. Audit your Jenkins user accounts. Log in and look at the user list. Do you recognize every account? Are there test accounts, former employee accounts, or accounts with generic names? Remove anything that shouldn't be there.

7. Review your build logs for unexpected script execution. Check the Jenkins system log and the script console log for commands you didn't run. If someone has been using the Groovy console, there will be entries. If those entries aren't from your team, you have a problem that goes beyond changing passwords.

8. Update Jenkins and all plugins. Jenkins publishes security advisories regularly. Plugins are an even bigger attack surface. Run the update manager. Apply everything pending. Set a calendar reminder to check monthly.

9. Monitor outbound traffic from your CI server. Your build server should be talking to your code repository, your artifact registry, and your deployment targets. If it's sending traffic to IP addresses you don't recognize, especially high-volume UDP traffic, investigate immediately.

#The pattern keeps repeating.

Printers. Firewalls. Now CI servers. The devices and systems that get compromised are never the ones you're watching. They're the ones you set up, configured just enough to work, and then forgot about.

Your Jenkins server runs your deployments, stores your credentials, and has network access to your production infrastructure. It deserves at least as much security attention as the laptops you hand to new hires.

Go check yours. Today. Not next quarter.

#Further reading

• Darktrace: Jenkins Honeypot Reveals Emerging Botnet - the honeypot research behind this campaign
• SC Media: New Botnet Targets Gaming Servers via Misconfigured Jenkins - campaign coverage
• Jenkins Security Advisories - official Jenkins security updates
• Shodan - check if your Jenkins is internet-exposed
• OWASP CI/CD Security Guide - top 10 CI/CD security risks