The “Dangling Worker” Vulnerability: Tracking Expired Cloudflare Workers and Edge Functions

Edge computing has changed how backends are built. Teams deploy serverless code to a CDN’s global network, which gives them low latency, flexible routing and fast scaling. Cloudflare Workers, Vercel’s Edge runtime, AWS CloudFront Functions and Lambda@Edge, and Fastly Compute (formerly Compute@Edge) let developers intercept traffic, rewrite headers and run API logic close to the user.

That convenience has a cost: the Dangling Worker problem.

Edge scripts are easy to deploy and easy to forget. They often outlive the backends, API keys and data stores they depend on. When a microservice is decommissioned or a credential is rotated without updating the edge tier, the script stays live on a public hostname. Symptoms range from silent application failures to security exposure.

The security risk is real but needs precise framing. A Worker calling a dead service is mainly an availability problem. It becomes a security problem when something the Worker depends on can be claimed by someone else, or when stale permissions and secrets stay attached to it.

This guide explains where dangling workers come from, which failure modes are documented and which are logical extrapolations, and how to audit them with current tooling.

What Is a “Dangling Worker”?

“Dangling Worker” is an industry shorthand, not an official vulnerability class. It means a serverless edge script that is still deployed and reachable, but whose dependencies are missing, rotated, decommissioned or no longer owned by the team that runs it.

The term borrows from “dangling DNS”. A dangling DNS record points at a resource that no longer exists. A dangling Worker is the same kind of leftover, one layer up.

  Client app
      |
      v
+---------------------------+          +---------------------------------+
|  Edge script (still live) |  ------> |  Upstream / binding that is     |
|  on a public hostname     |          |  deleted, rotated or unowned    |
+---------------------------+          +---------------------------------+
      |
      v
  Possible results: errors, silently wrong responses,
  or (if the upstream hostname can be claimed) traffic sent to a third party

Edge functions execute separately from your origin servers. If an upstream returns a 404, a 401 or times out, the function’s own error handling decides what the client sees. A script that catches the error and returns an empty 200, or retries aggressively, can hide an outage that would be obvious at a central gateway.

Platform differences matter

The risk differs by platform, so it is worth being specific:

• Cloudflare Workers can call external APIs and use bindings such as KV, D1 and R2. A Worker’s routes, Custom Domains and bindings can all go stale.
• Vercel has deprecated Edge Functions as a standalone product. Functions using the Edge runtime now run on unified Vercel Functions, and Vercel recommends the Node.js runtime for new work. Existing edge code still runs, so legacy functions are an audit target.
• AWS CloudFront Functions are lightweight JavaScript functions for header manipulation, redirects and cache-key normalization. They cannot make network calls, so the “dead upstream” scenario applies to Lambda@Edge, not CloudFront Functions. CloudFront Functions can still go stale through KeyValueStore data and associations.
• Fastly Compute (formerly Compute@Edge) runs WebAssembly at the Fastly edge and has its own backend definitions that can go stale.

Primary Manifestations of a Dangling Edge Script

1. Orphaned bindings

A Worker bound to a KV namespace, D1 database or R2 bucket that has since been deleted or replaced keeps running, but calls against that binding fail at runtime. If the code doesn’t handle that failure, clients get errors or empty responses.

2. Expired or revoked upstream credentials

A Worker proxying to a service such as a payments API, an SMS provider or an LLM provider keeps accepting traffic after the upstream key was revoked. Every request then produces an authorization error that the script may hide or retry.

3. Claimable upstream hostnames

This is the most serious case. If a Worker forwards requests, including Authorization headers or cookies, to a hostname whose DNS record points at a deleted cloud resource, an attacker who claims that resource receives the traffic.

The underlying attack is well documented. Infoblox’s research on the Hazy Hawk threat actor describes hijacking subdomains through dangling CNAME records that point to decommissioned cloud resources, including Azure, AWS, GitHub and Cloudflare. The activity dates to at least December 2023, and victims included a U.S. CDC subdomain. Infoblox’s recommended prevention is to remove CNAME records when cloud resources are retired.

Hazy Hawk’s reported targets were dangling DNS records, not Workers specifically. The Worker scenario is an extension of that attack: a Worker that forwards credentials to a claimable hostname is a ready-made data source for whoever claims it.

4. Stale routes, Custom Domains and workers.dev exposure

Cloudflare’s documentation shows several leftovers that persist after a project ends:

• When you create a Worker, a workers.dev route is set up automatically. It stays live until you disable it, for example with workers_dev = false.
• Custom Domains point all paths of a hostname to a Worker. Deleting a Custom Domain does not automatically delete the associated Advanced Certificate.
• Zone-level route patterns can match many hostnames at once. A forgotten wildcard route from an old experiment can intercept traffic you assumed was served elsewhere.

Why Agencies and Larger Teams Accumulate Edge Sprawl

Agencies and multi-team organizations tend to create edge sprawl for structural reasons.

Decoupled pipelines. Edge deployments often run from separate CI/CD pipelines from the origin application. When a backend is retired, the edge script may not be part of the same teardown.

Temporary environments that persist. Preview, staging and client-testing deployments are created quickly and are often never cleaned up once a project launches or a client relationship ends.

No central inventory. Virtual machines and containers are usually tracked in Terraform or Pulumi state. Edge scripts created from the command line during troubleshooting often are not, which creates untracked “shadow IT” at the network tier.

Ownership drift. The person who deployed a Worker may have left, changed roles, or been the client’s contractor rather than your employee. The script keeps running under an account no one reviews.

Impact Analysis

On cost, Cloudflare’s own charges for an idle or failing Worker are small. The Free plan includes 100,000 requests per day. The Paid plan is $5 per month with 10 million requests and 30 million CPU-milliseconds included, then $0.30 per additional million requests and $0.02 per additional million CPU-ms. The larger bill risk is usually the external API the Worker calls, not the Worker itself.

Step-by-Step: Auditing and Cleaning Up Edge Deployments

Step 1: Inventory Workers, Custom Domains and routes

Start from the account’s own records. These Cloudflare API endpoints list Workers scripts, Custom Domains and per-zone routes:

export CF_ACCOUNT_ID="your_account_id"
export CF_ZONE_ID="your_zone_id"
export CF_API_TOKEN="your_api_token"   # use a read-only token for audits

# Deployed Workers
curl -s "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/workers/scripts" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq '.result[] | {id, created_on, modified_on}'

# Custom Domains attached to Workers
curl -s "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/workers/domains" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq '.result[] | {hostname, service, zone_name}'

# Routes for one zone (repeat per zone)
curl -s "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/workers/routes" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq '.result[] | {pattern, script}'

A Worker whose modified_on date is old is a candidate for review, not proof of abandonment. Plenty of healthy scripts are stable for years.

Then list the resources the Workers may be bound to. Wrangler’s current syntax uses a space, not a colon: the older kv:namespace form has been deprecated since Wrangler 3.60.0.

npx wrangler kv namespace list
npx wrangler d1 list
npx wrangler r2 bucket list
npx wrangler deployments list     # run inside a Worker project directory
npx wrangler secret list          # shows secret names only, not values

Note that wrangler dispatch-namespace list is not a route listing. It lists Workers for Platforms dispatch namespaces, so use it only if your account uses that product.

Step 2: Check the upstreams

For every Worker that proxies to something, confirm the upstream still exists, still resolves to infrastructure you own, and still returns what the Worker expects. The script below checks public health endpoints.

// edge-upstream-audit.ts (Node.js 18+, uses the built-in fetch)
interface Upstream {
  name: string;
  url: string;
  expectedStatus: number;
}

const upstreams: Upstream[] = [
  { name: "auth-proxy", url: "https://api.example.com/v1/auth/health", expectedStatus: 200 },
  { name: "image-optimizer", url: "https://cdn.example.com/render/health", expectedStatus: 200 },
];

async function audit(list: Upstream[]) {
  for (const u of list) {
    try {
      const res = await fetch(u.url, { signal: AbortSignal.timeout(5000) });
      if (res.status !== u.expectedStatus) {
        console.warn(`[ALERT] ${u.name} returned HTTP ${res.status}`);
      } else {
        console.log(`[OK] ${u.name}`);
      }
    } catch (err) {
      console.error(`[CRITICAL] ${u.name} unreachable`, err);
    }
  }
}

audit(upstreams);

An HTTP check does not tell you whether a hostname is claimable. Also resolve the DNS records behind each upstream hostname and flag any that return NXDOMAIN, or that point at a cloud service you no longer have an account on. Infoblox notes that identifying vulnerable cloud records is harder than spotting unregistered domains, because every provider handles deleted resources differently, so review those records by hand.

Step 3: Declare configuration explicitly and shrink the exposed surface

Cloudflare recommends wrangler.jsonc for new projects, and some newer Wrangler features are available only with JSON config. A minimal example:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "secure-edge-service",
  "main": "src/index.ts",
  "compatibility_date": "2026-10-01", // set to a recent date when you deploy
  "workers_dev": false,               // don't leave an unused workers.dev route live
  "observability": { "enabled": true },
  "vars": { "ENVIRONMENT": "production" },
  "kv_namespaces": [
    { "binding": "CONFIG_STORE", "id": "<NAMESPACE_ID>" }
  ]
}

Keep secrets out of this file. Use wrangler secret put, or Cloudflare Secrets Store, which holds account-level secrets that Workers can bind to. It was still in open beta in Cloudflare’s documentation when this article was written. Check its status before making it a production dependency.

Prevention Checklist

• Define edge scripts in code. Put every Worker, route and Custom Domain in Terraform, Pulumi or a Wrangler config in version control, so a deleted project leaves a visible diff.
• Automate teardown. When a preview or staging environment is closed, run wrangler delete (or the platform equivalent) in the same pipeline.
• Disable what you don’t use. Turn off workers.dev routes on production Workers. Remove Custom Domains and their leftover Advanced Certificates when a project ends.
• Remove DNS before resources. When retiring a cloud resource, delete the DNS record that points at it first, so the hostname can never point at something you no longer own.
• Use a central secret manager and review deploy access. Short-lived credentials limit how long a stale key is useful, and offboarding should include removing deploy permissions on edge accounts.
• Review DNS and routes on a schedule. Check CNAMEs and Worker routes regularly, for example quarterly, for targets that no longer resolve to infrastructure you own.
• Log and alert on errors. Turn on Workers Logs, and note that retention is 3 days on Free and 7 days on Paid. For longer retention, use Logpush (Paid plan only) or a log platform such as Datadog or Grafana Loki, and alert on 5xx spikes and unhandled promise rejections.
• Record who owns each script. For every production Worker, keep a named owner, the client or project it serves, and a planned review date.

Summary for Technology Leaders

Edge platforms give teams speed and reach. They also spread operational responsibility across many small, independently deployed scripts, domains and credentials.

A dangling Worker is usually a quiet failure: a broken feature, a hidden error, a stale credential. It becomes a security incident when it forwards sensitive data to a hostname that someone else can claim, or when old access is never removed. The countermeasures are ordinary but need to be applied to the edge tier too:

• Keep an inventory of scripts, routes, domains and bindings.
• Define them in code.
• Tear them down with the projects they belong to.
• Remove DNS records before the resources behind them.
• Assign an owner to every production script.