A zombie API is an old, forgotten, or deprecated API endpoint that is still deployed and still accepting traffic even though nobody is actively maintaining or monitoring it, which makes it one of the most reliably exploited blind spots in modern application security. The name fits: the endpoint should be dead, but it keeps shuffling along, out of sight and out of the patch cycle. This post explains where zombie APIs come from, why attackers love them, and how to hunt them down before someone else does.
Where zombie APIs come from
Zombie APIs are a byproduct of normal software evolution, which is why almost every organization has some. A few common origins:
- Versioning without cleanup. You ship
/api/v2, migrate clients over, and never actually decommission/api/v1. It keeps running because turning it off felt risky, and years later it is still there. - Deprecated features. A capability gets removed from the UI, but the backend endpoint that powered it is never deleted.
- Staff turnover and lost knowledge. The engineer who built an internal integration leaves, the integration is forgotten, and the endpoint outlives everyone's memory of it.
- Abandoned experiments. A proof of concept or a partner integration that never went anywhere, left deployed "just in case."
Zombie APIs are cousins to shadow APIs, endpoints that exist without ever being officially documented. The distinction is that a zombie was once known and sanctioned but has since fallen out of maintenance, while a shadow API was never in the inventory to begin with. Both share the fatal property of being outside your governance.
Why they are so dangerous
The danger of a zombie API is precisely that it is unmonitored. Every problem stems from that.
First, they do not get patched. When a vulnerability is disclosed in a framework or library, your patching effort targets the systems you know about. A zombie endpoint running an old, unpatched version of that framework sits there accumulating known CVEs that nobody is tracking. It becomes an easy, well-documented way in.
Second, they often run outdated authentication and authorization logic. An old /v1 endpoint may predate the security controls you added later, missing the rate limiting, the token validation, or the access checks that the current version enforces. Attackers know that old versions of an API are frequently the weakest, so probing for /v1 after finding /v2 is a standard move.
Third, they leak data through obsolete contracts. A deprecated endpoint might return fields that the current API deliberately stopped exposing, quietly handing out data that policy says should no longer be reachable.
Fourth, they evade monitoring. Because nobody expects traffic to a forgotten endpoint, attacks against it do not trip the alerts tuned to your active surface. An attacker can work against a zombie API for a long time without setting off anything.
How to find your zombie APIs
You cannot secure what you do not know exists, so the first job is discovery. Combine several sources, because no single one is complete.
Inventory from traffic. API gateways, load balancers, and reverse proxies log every request. Pull the logs and enumerate every path that is actually receiving requests, then compare that against your documented API surface. Paths receiving traffic that are not in your docs are candidates, both zombie and shadow.
Inventory from code and specs. Parse your OpenAPI or Swagger definitions and your route registrations in source. Endpoints defined in code but absent from current documentation, or documented as deprecated but still routed, are prime suspects.
Active discovery scanning. Dynamic testing tools can crawl and probe an application to enumerate reachable endpoints, including ones no client links to anymore. This is where dynamic scanning earns its keep against APIs specifically; our DAST product page covers endpoint discovery and testing.
Watch for version patterns. If /api/v3 is your current version, explicitly check whether /api/v1 and /api/v2 still respond. They frequently do.
A useful cross-check is to diff the set of endpoints your gateway sees against the set your current codebase intends to expose. The delta is your problem list.
Killing a zombie API safely
Discovery without decommissioning just produces a nicer list of liabilities. Retire them deliberately:
- Confirm it is truly unused. Check recent traffic. If it still gets legitimate calls, you have a migration problem to solve before you can remove it, not just a deletion.
- Announce deprecation with a timeline for any consumers you do find, and return deprecation signals so clients notice.
- Restrict before you remove. If immediate deletion is risky, lock the endpoint behind authentication, rate limits, and monitoring so it stops being a soft target while you plan removal.
- Remove the route and the code, not just the documentation. An endpoint that is undocumented but still deployed is exactly how a zombie is born.
- Add it to a recurring inventory process. Zombie APIs regenerate. A one-time cleanup that is not repeated will be undone by the next year of shipping.
Keeping the underlying components patched matters too, since an outdated framework on a live endpoint is what turns a forgotten API into an exploitable one. An SCA tool such as Safeguard can flag when a deployed service is running a dependency with a known vulnerability, which helps surface the risk on endpoints you might otherwise overlook. The Safeguard Academy has more on building continuous inventory into your process.
FAQ
What is a zombie API?
A zombie API is a deprecated or forgotten endpoint that remains deployed and continues to accept traffic without being maintained, monitored, or patched. It should be retired but keeps running, creating an unmonitored slice of attack surface.
How is a zombie API different from a shadow API?
A zombie API was once official and sanctioned but has fallen out of maintenance, while a shadow API was never documented or governed in the first place. Both are dangerous because they sit outside your security oversight, but they arise differently.
Why are zombie APIs a security risk?
They go unpatched, often run outdated authentication and authorization logic, can leak data through obsolete response contracts, and evade monitoring because nobody expects traffic to them. Attackers routinely probe old API versions because they are frequently the weakest link.
How do I find zombie APIs in my environment?
Combine gateway and proxy traffic logs, code and OpenAPI spec analysis, and active discovery scanning to enumerate every reachable endpoint. Compare that against your current documented API surface, and specifically test whether older version paths like /v1 still respond.