Cybersecurity glossary

What is a Zombie API?

Learn what a zombie API is, why retired versions stay online, how attackers prefer these weaker endpoints, and how deprecation telemetry and hard cutovers remove zombie risk.

Application securityUpdated July 23, 2026
Also known asDeprecated zombie APILingering legacy APIUndead API version

Definition

A zombie API is a deprecated, unused, or supposedly retired API—or API version—that remains reachable and functional in production without active ownership, patching, or monitoring, creating lingering attack surface that security programs often overlook.

Why zombie APIs matter

Deprecation emails are not enforcement. A zombie API keeps answering long after teams moved on—usually without the hardening applied to its replacement.

Attackers read changelogs too. “Fixed in v2” is an invitation to try v1.

How APIs become zombies

Soft deprecation only

Docs say retired, but gateways still route traffic.

Unknown residual clients

Teams fear breaking a partner and postpone cutover indefinitely.

Copy-paste deployments

Old services redeployed with forgotten ingress rules.

Metric blindness

Low-volume endpoints fall below monitoring thresholds.

Zombie lifecycle (and how to interrupt it)

1

New version ships

Security fixes land on vNext while vLegacy remains available.

2

Deprecation is announced

Dates are published; some clients migrate.

3

Cutover slips

Residual traffic or uncertainty delays hard removal.

4

Ownership fades

On-call and patching focus exclusively on the new API.

5

Attackers target legacy

Known weaknesses on the old version are exploited.

6

Incident rediscovers the zombie

Response teams learn the “retired” route still worked.

Shadow vs zombie vs active

TypeIn catalog?Intended stateRisk note
Active APIYesSupportedNormal patch/test cycle
Shadow APINoShould be onboarded or removedNo governance by default
Zombie APIOften yes (deprecated)Should be offlineLegacy weaknesses linger

Killing zombie APIs

  • Track deprecation to a hard disable date with executive visibility.
  • Instrument per-version traffic, including near-zero residual calls.
  • Revoke credentials and docs that only apply to legacy versions.
  • Remove code and infrastructure—not only DNS marketing pages.
  • Verify externally that retired hosts/paths return permanent failures.
  • Backport critical fixes if temporary extensions are unavoidable.
  • Alert when deprecated routes receive sudden traffic spikes.
  • Include zombie hunts in quarterly attack-surface reviews.

The practical takeaway

A zombie API is deprecated in name only. If it still responds, it is still attackable.

Finish deprecation with technical removal, traffic proof, and credential revocation—or budget it as living production risk.

Related security terms

Frequently asked questions

What is a zombie API in simple terms?

It is an old API everyone thinks is turned off, but it still answers requests—often with weaker security than the current version.

How is it different from a shadow API?

Shadow APIs were never properly inventoried. Zombie APIs were known and marked deprecated or unused, yet remain alive.

Why do zombies survive?

Fear of breaking a forgotten client, missing traffic dashboards, or deprecation that stops at documentation without technical cutover.

Why do attackers like them?

Legacy versions may lack modern auth, have known CVEs, or skip newer authorization fixes applied only to v2.

How do you detect zombie APIs?

Compare deprecated inventory entries against live gateway routes and observed traffic, including low-volume probes.

What is the fix?

Hard disable routes, remove code, revoke credentials scoped to old versions, and verify with external scans.

Can internal zombies matter?

Yes. Internal legacy APIs are frequent lateral-movement targets after an initial foothold.

References

Explore authoritative guidance and frameworks related to zombie api.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary