Some of the most dangerous vulnerabilities in modern web apps are the default features left switched on where they were never meant to be reachable. The first entry in our Findings from the AP series looks at an exposed actuator endpoint.
On paper, this finding started the same way most do: an HTTP endpoint returned a 200. Nothing about that response looks unusual by itself. It’s the kind of line that gets logged, categorized, and moved past in most automated scans.
Two backend services sat behind an API gateway. Both exposed framework-level management endpoints, the kind meant for internal health checks and metrics, and both were reachable through the gateway without any authentication in front of them.
The management index for each service was fully browsable. Listed among the available actions was a shutdown endpoint. A single POST request to that path would kill the corresponding service immediately (rated CVSS 9.1).
In plain terms, anyone on the internet could take down core services, including authentication, with one request and no credentials.
What the Agent actually did
The first thing it noticed was that the management index itself was reachable without authentication. That alone leaked internal hostnames and ports that had no business being externally visible. From there, it sent a plain GET request to it first.
The response was a 405 Method Not Allowed, with an Allow: POST header attached,
the framework confirming the endpoint exists, is active, and only accepts POST requests. It’s a signal most tools wouldn’t think to interpret as meaningful on its own.
It then checked a second, unrelated endpoint on the same service: a metrics interface. That leaked internal details too: database connection pool counts, active session numbers, memory usage.
At that point, it had enough to be confident the vulnerability was real. It chose not to send the actual shutdown request. Proving something is exploitable and causing the outage to prove it are two different things, and the agent treated them that way.
How to Prevent This
This class of bug tends to show up wherever framework management interfaces get exposed through a gateway without a second thought.
A few things stop it before it becomes a finding:
- Block management/actuator-style paths explicitly at the gateway level, rather than relying on the service itself to handle authorization.
- Restrict management endpoints to localhost or an internal-only network path. They rarely need to be reachable from outside the service’s own host.
- Add an authorization layer in front of any endpoint capable of a destructive action (shutdown, restart, config changes), even if it’s “just” a management interface.
- Periodically audit what a gateway actually proxies through, not just what it’s intended to proxy.
The Takeaway
Actuator-based DoS bugs like this earn $3,000 to $7,500 on HackerOne, and in uptime-sensitive industries, every minute of downtime is estimated to cost thousands of dollars per minute. The point is that our agent pieced this together the way a skilled pentester would: a 200 that leaked the admin menu, a 405 that gave away the trigger, and a metrics endpoint that confirmed the root cause.
Curious what our agent would find in your environment?
Book a demo of Astra’s Autonomous Pentesting platform and see it reason through your stack the way a real pentester would.
This is one finding from one engagement in our ongoing Findings from AP series
