xdebug is a PHP extension for debugging code, it allows settings breakpoints, view and modify the contents of variables/objects and to execute code. Usually xdebug is installed locally for debugging purposes.

By default, xdebug will listen on port 9000 on the developers machine. In order to activate xdebug the paremeter ‘XDEBUG_SESSION=name’ has to be present in a get/post-parameter or as a cookie. The value of the parameter can be randomly chosen since it is only used for development environments where multiple developers work on same machine simultaneously and each developer has its own session. Once xdebug is active, it connects back to the configured IP on port 9000 and waits for instructions.

The following gif from xdebug.org demonstrates the connection-flow.

xdebug-flow!

As seen in the gif a typical xdebug configuration might look like this:

xdebug.remote_enable= true
xdebug.remote_host= 10.0.1.42

In this case the developers IP is set in the configuration, allowing only the specified IP to use xdebug. This would be a secure setup of xdebug.
There is however the configuration option ‘xdebug.remote_connect_back’, setting it to true disables the configured ‘xdebug.remote_host’ IP and connects back to any host that activates xdebug.

xdebug.remote_enable= true
xdebug.remote_connect_back= true
xdebug.remote_host= 10.0.1.42 # ignored/disabled

Once xdebug is configured this way and publicly reachable on the internet, anyone can execute arbitrary code. This can be used to steal the database, install backdoors and other malicious things.

It sounds obvious that this is bad and I thought only a handful servers were configured this way. So I went out to scan the Alexa top 1 million, thinking that I would find only a 1-digit number of vulnerable hosts.
I was wrong :(.

I discovered 50 vulnerable hosts accounting for ~400 domains. 38 of the 50 hosts used the standard-port. In order to listen for all incoming connections I set up iptables with nat-prerouting to route all incoming traffic to port 9000.

While trying to get contact information for the affected sites I stumbled upon a domain where the host had ~75 domains that appeared to have nothing in common. It turned out that a hoster mistakenly enabled xdebug on this server. The hoster was quick to fix this vulnerability but doesn’t want to have its name mentioned.

Admins can fix this issue by updating the xdebug-config with the following settings or completely remove xdebug from publicly reachable servers.

xdebug.remote_enable= false
xdebug.remote_connect_back= false