An engineer attaches their IDE's debugger to a JVM running inside a Docker container on a remote host, sets a breakpoint, and it works exactly the way it would locally. What is actually happening over the network to make that possible, and why is an open debug port on a production host a real security hole rather than just a convenience feature left on?

The debugger and the JVM running the program are almost always two separate processes, even when both happen to be on the same machine — remote debugging just makes that separation visible, because now they're on genuinely different machines talking over a real network socket instead of a local one. The JVM is started with a flag that opens a socket and speaks a defined wire protocol (JDWP) for exactly the operations a debugger needs: set a breakpoint at this line, give me this variable's value, step to the next line, resume. That protocol has no authentication built into it — anyone who can reach the socket can attach a debugger, read every value sitting in memory including credentials, and redirect what the program does next. On a production or internet-facing host, an open debug port is effectively an unauthenticated door into the running process's entire memory and control flow.