Guacamole, MeshCentral, AWX: the panels that run commands on your machines

Most exposed panels leak data. A public phpMyAdmin hands over a database. A public Grafana hands over your dashboards. The panels in this article are different in kind: they don't show you records, they run commands. Their whole job is to reach into other machines and execute things, hold the credentials to do it, and proxy a live session into your network. So when one of these answers an anonymous request from the open internet, the prize behind the login isn't a table of rows. It's a shell.

Apache Guacamole, MeshCentral, AWX, Rundeck, and self-hosted GitLab all sit on that list. They're the operator tools you stand up to manage a fleet, and they end up public the same lazy way everything else does: spun up on a reachable host "to manage things remotely," fronted by a quick admin password, and never walled off afterward. The difference is the blast radius. One weak login here is not a breach of one system. It's an operator session across all of them.

What's actually behind each login

Read these by the verb, not the name. Each one does something to a machine you own.

• Apache Guacamole (/guacamole/) is a clientless remote-desktop gateway. It proxies RDP, SSH, and VNC over the browser, so a login here is a live terminal or desktop session on whatever internal hosts it's configured to reach. The gateway is, by design, a bridge from the public internet into your private network, which is why an exposed one is critical.
• MeshCentral (/) is full remote management of every enrolled device: screen, files, and a terminal on each one. An operator can watch a desktop, pull files, and run commands on the whole fleet of agents. Getting in means getting all of them.
• AWX / Ansible Tower (/api/) orchestrates Ansible across your fleet using stored machine credentials. That's the dangerous part. AWX already holds the SSH keys and sudo passwords for every managed node, and its reason to exist is running playbooks against them. A login is effectively remote code execution on every host it manages, no further pivot required.
• Rundeck (/user/login) is a job runner with stored SSH keys and node credentials. Same shape as AWX: it keeps the keys and exists to run jobs across nodes, so an attacker inside runs arbitrary commands wherever Rundeck can reach.
• GitLab self-hosted (/users/sign_in) holds private source repos plus CI/CD secrets. Source code is bad enough on its own, but the pipeline variables, deploy keys, and registry tokens stored alongside it are usually the real loot, and they're a straight line to production.

The common thread: "logged in" here means "can run commands on machines." These tools were built to execute against a fleet, so an attacker who gets in inherits exactly that ability.

Why a single login is the whole game

Walk the chain on AWX, because it's the sharpest. A reachable AWX API invites credential-stuffing and brute force like any login, but the payoff is total. AWX stores the machine credentials for every node it manages, and a playbook is arbitrary commands by design. So an attacker who gets in doesn't need to find a vulnerability on each host or solve a lateral-movement puzzle. They write one playbook and it runs everywhere, with the access you already granted Ansible. The same logic holds for Rundeck's stored SSH keys, for MeshCentral's per-device terminal, and for Guacamole bridging the public web straight to an internal RDP session.

The AWX API even tells you what it is before you log in.

GitLab is a half step down in immediacy but not in damage. The login itself doesn't run a shell, but the repos behind it hold your source and the CI/CD secrets hold the keys to deploy it, and a self-hosted instance left public is a standing target for every CVE that lands against GitLab. The reason these get exposed is always the same: they're built to be reached remotely, and the default "reachable" is wider than the person who set it up assumed.

Take the operator tools off the open internet

The fix is a network decision before it's a password decision. These panels should not answer the public internet at all.

# AWX, Rundeck, MeshCentral, GitLab answering a public host
# anyone on the internet reaches the login
# the tool already holds keys to the whole fleet

Put the tool on an internal network or VPN and reach it through an SSH tunnel. If remote access is genuinely unavoidable, lock it to your team's IPs at a reverse proxy and require authentication there too. Behind that wall, use a strong unique admin password and two-factor, and keep the thing patched. Guacamole, AWX, and GitLab all accrue critical CVEs precisely because they're high value, and an exposed-and-outdated orchestrator is the single worst thing on the whole site.

Reading it from outside

Whether your remote-access gateway answers the public internet is something a stranger settles by loading its URL, which is exactly what SurfaceCheckr does, from outside, with no credentials. Each probe requires the tool's own distinctive markup to match before it counts as a hit, so a page that merely mentions a product name doesn't trip it. GitLab is a good example of how careful that gating is: it requires two tokens together, the word GitLab and the string https://about.gitlab.com, because either alone is too common to trust and the bare word would cause false positives. The scan reads only what the panel serves anonymously and then stops. No login attempt, no playbook, no job, nothing active. It tells you the door is on the street; it never tries the handle. This isn't a pentest, it's the view an attacker gets for free before they've typed anything.

Scan your domain and see whether any of these are reachable. The closest cousins are the PaaS deploy controllers that own every app you run, and the Kubernetes dashboard and infra consoles one layer deeper into the stack.