Port 33848: Jenkins Auto-Discovery — The Broadcast That Learned to Whisper

Port 33848 carries something unusual: a call into the void. When a Jenkins server listened on this port, it was waiting to be found. Send any UDP packet to port 33848, even a single byte, and Jenkins would respond with an XML message announcing itself: its version, its URL, its identity. A lighthouse on the network, flashing "I'm here, I can help you build."

This is the story of how a feature designed to make life easier became a weapon, and why Jenkins eventually chose silence over convenience.

What Port 33848 Does

Port 33848 is Jenkins' UDP auto-discovery port.¹ When enabled, Jenkins listens for incoming UDP packets on this port and responds with an XML payload containing metadata about the Jenkins instance: its version number, server ID, and URL.

The discovery mechanism works two ways:

1. UDP Broadcast: Send a packet to 255.255.255.255:33848, and every Jenkins server on the local network responds
2. UDP Multicast: Send a packet to 239.77.124.213:33848 for the same effect via multicast

The payload of the incoming packet doesn't matter. Jenkins responds to anything, even an empty packet. The response looks something like this:

<hudson>
  <version>2.218</version>
  <url>http://jenkins.example.com:8080/</url>
  <server-id>abc123...</server-id>
</hudson>

UDP multicast support was added in Jenkins version 1.335, and UDP broadcast support goes back even further to version 1.282.¹

The Origin Story

Jenkins began as Hudson, a project started by Kohsuke Kawaguchi at Sun Microsystems in 2004.² The story of its creation is wonderfully human.

Kawaguchi was a Java developer at Sun who kept getting phone calls from his colleagues: "Hey, I think you broke the build, because I updated my workspace and it doesn't compile. Can you check?"³ Sure enough, his work was often half-baked. He'd committed incomplete changes.

Rather than be more careful (the human solution), Kawaguchi wrote a program that would catch problems before his colleagues did. That program became Hudson, then Jenkins, and eventually the most widely used continuous integration server in the world, with over 147,000 active installations.⁴

The auto-discovery feature on port 33848 was part of making Jenkins friendly. In an enterprise environment with dozens of Jenkins servers, administrators shouldn't have to maintain a list of every instance. Just send a broadcast, and the servers announce themselves. Simple. Elegant. Dangerous.

The Problem with Being Too Friendly

In January 2020, Dr. Adam Thorn at the University of Cambridge discovered something troubling about port 33848.⁵

UDP is a connectionless protocol. When you send a UDP packet, you can lie about where it came from. This is called IP spoofing, and it's the foundation of amplification attacks.

Here's how it works:

1. Attacker sends a tiny UDP packet to Jenkins, but spoofs the source IP to be the victim's address
2. Jenkins dutifully sends its ~150 byte XML response to the victim
3. The attacker sends one byte, the victim receives 150 bytes
4. Multiply by thousands of Jenkins servers, and you have a DDoS attack

The bandwidth amplification factor (BAF) for most amplification attacks is significant but finite. DNS amplification gives you about 50x. NTP monlist can hit 500x. But Jenkins on port 33848 would respond to a zero-length payload.⁶

A zero-byte request producing a 150-byte response. The amplification factor is mathematically infinite.

But the real genius of CVE-2020-2100 wasn't the amplification. It was the infinite loop.

Send a spoofed UDP packet from Jenkins server A to Jenkins server B, with the source port also set to 33848. Server B responds to server A on port 33848. Server A receives it, thinks it's a discovery request, and responds back. Forever.⁶

Two Jenkins servers, locked in an eternal conversation, each triggering the other, until they exhaust themselves into denial of service.

The Security Response

Jenkins 2.219 and LTS 2.204.2, released on January 29, 2020, disabled the UDP auto-discovery service by default.⁷ The DNS multicast discovery service (which operated on port 5353) was also disabled.

For administrators who still need network discovery, the features can be re-enabled with system properties:

-Dhudson.DNSMultiCast.disabled=false    # DNS multicast
-Dhudson.udp=33848                       # UDP broadcast/multicast

But the Jenkins project's recommendation is clear: if you don't need it, leave it off. And if you do need it, firewall port 33848 from the public Internet.

The auto-discovery feature was removed entirely from Jenkins starting with version 2.200.¹

Related Ports

Jenkins uses several ports for different purposes:

The inbound agent port (50000) is where the real work happens. This is the port that Jenkins agents use to connect back to the controller, receiving build instructions and sending back results. Unlike the ephemeral discovery protocol on 33848, port 50000 carries the actual continuous integration traffic.⁸

Modern Jenkins deployments increasingly use WebSocket transport instead of dedicated TCP ports. WebSocket connections tunnel through standard HTTP(S) ports, eliminating the need for special firewall rules and additional attack surface.⁹

Security Considerations

Auto-discovery is disabled by default. As of Jenkins 2.219 and later, port 33848 is not listening unless explicitly enabled. This is the correct default.

If you enable it, firewall it. Port 33848 should never be exposed to the public Internet. The amplification attack vector is well-documented and actively exploited.

Use WebSocket for agents. Modern Jenkins supports WebSocket transport for inbound agents, eliminating the need for port 50000 and reducing attack surface.

The JNLP agent port has its own history. Port 50000 (the inbound agent port) has had multiple security vulnerabilities over the years, including secret verification bypass (2015) and master cryptographic key exposure (2013).¹⁰ The Jenkins project now recommends SSH-based outbound agents or WebSocket transport where possible.