Webhooks colgantes: Qué ocurre cuando un subdominio de túnel liberado sigue registrado en Stripe, GitHub o Shopify

Detienes el túnel, cierras el portátil y sigues adelante. Stripe, GitHub y Shopify no lo saben. Conservan la URL que les diste y siguen intentando entregar eventos a esa URL hasta que alguien elimine el registro o el proveedor se canse.

Ese registro sobrante es un webhook colgante: una suscripción del lado del proveedor que apunta a un hostname que ya no controlas. Si el nombre que usaste era un subdominio de túnel, la pregunta es simple e incómoda. ¿Quién puede reclamar ese nombre a continuación, y qué enviarán tus registros anteriores a esa persona?

Esta guía responde a ello para los tres proveedores que los desarrolladores conectan con más frecuencia. Luego te ofrece una lista de verificación de auditoría específica por proveedor y un orden seguro para cancelar suscripciones y rotar secretos.

Qué es un webhook colgante

Un registro de webhook vive en el panel del proveedor o en su API, no en tu código. Eliminar tu proyecto o dejar que una sesión de túnel expire no cambia nada allí. A diferencia de un registro DNS obsoleto, el emisor inicia: el proveedor envía eventos a la URL sin que nadie la visite.

En muchos equipos nadie es responsable del inventario, porque las registraciones se crean por quien estuvo depurando esa semana.

Los proveedores de seguridad ya lo tratan como un riesgo de toma de control. La guía de webhooks de Obsidian Security advierte que los endpoints que apuntan a URLs obsoletas crean oportunidades de apropiación cuando la infraestructura se migra o desmantela. Un subdominio de túnel liberado es el mismo problema en una escala de tiempo mucho más corta.

Por qué merece una auditoría ahora

Tres datos contextualizan el problema. Ninguno mide webhooks colgantes directamente, así que léelos como contexto, no como prueba.

Propagación de webhooks está mal documentada. Obsidian Security informa que la empresa promedio opera 47 endpoints de webhook activos, mientras que los equipos de seguridad solo pueden documentar el 23% de ellos en sus inventarios de integraciones. Ese es un estándar reportado por el proveedor, no un censo auditado.

Terceros están involucrados en casi la mitad de las brechas. El Verizon 2026 Data Breach Investigations Report (publicado en mayo de 2026) sitúa la implicación de terceros en el 48% de las brechas. Eso sube desde el 30% en la edición de 2025 y el 15% en 2024. “Tercero” es una categoría amplia. Verizon lo divide en tres arquetipos: una vulnerabilidad en el software de un proveedor que se usa como puerta de entrada, un proveedor que aloja tus datos comprometido y un proveedor conectado a tu entorno. Las configuraciones erróneas de webhooks son solo una pequeña parte.

La limpieza de credenciales filtradas es lenta. La edición 2025 encontró que el tiempo medio para remediar secretos filtrados descubiertos en repositorios de GitHub era de 94 días. La limpieza lenta de credenciales e integraciones es el hilo conductor.

¿Quién puede reclamar el nombre a continuación?

Esto depende de cómo tu proveedor de túneles nombre las cosas, y es donde se decide la mayor parte del riesgo.

• Nombres aleatorios (k8m9n2.example.dev) son difíciles de apuntar, pero una registración que apunte a uno sigue siendo colgante, y el proveedor puede reciclar el nombre.
• Nombres elegidos (stripe-webhook, oauth-dev, acme-qa) son mucho más fáciles de adivinar. Si el servicio permite que cualquier cuenta solicite un nombre que no esté en uso, quien lo solicite primero después de que te vayas lo obtendrá.
• Nombres reservados (retenidos para una cuenta incluso cuando no hay túnel en ejecución) cierran la brecha, pero solo mientras exista la reserva.

La facilidad de adivinación importa más de lo que la gente espera. Los nombres que aparecen en ejemplos de documentación son los que más probabilidades tienen de ser copiados, reutilizados y olvidados.

Lo que InstaTunnel documenta hoy

A continuación, lo que la documentación pública de InstaTunnel, su página de precios y sus términos dicen a fecha del 14 de noviembre de 2026, y lo que dejan fuera.

Documentado:

• Subdominios personalizados están incluidos en el plan gratuito, pero debes iniciar sesión para elegir uno. Túneles anónimos obtienen un nombre aleatorio de seis caracteres y duran 24 horas. El CLI establece un nombre con --subdomain (o -s), por ejemplo instatunnel 3000 -s myapp.
• Los nombres se asignan por orden de llegada para usuarios conectados, y la documentación indica que el plan gratuito no tiene reserva. Un nombre ya ocupado devuelve un error “subdominio ya tomado”.
• Nombres de primera mano y sensibles de seguridad como api, login y support están reservados y no pueden ser reclamados.
• Las sesiones del plan gratuito duran 24 horas, por lo que un túnel puede terminar sin que hagas nada.
• Las conexiones autenticadas deben pertenecer al propietario del túnel, y desde CLI 1.1.24 un segundo cliente ya no puede reemplazar silenciosamente al activo. Mientras tu túnel esté activo, alguien más no puede secuestrarlo.
• instatunnel --list muestra tus túneles, y instatunnel --kill <subdominio> detiene uno.
• El plan Business lista ‘reservas de subdominios personalizados’ como una característica. Las características del plan Pro no lo incluyen.
• Los ejemplos de la documentación usan nombres como stripe-webhook, oauth-dev, acme-qa, myapp y myapp-dev. La guía de solución de problemas también recomienda un subdominio fijo para que los paneles de los proveedores conserven una URL estable. Ambas cosas hacen que estos nombres tengan más probabilidad de registrarse con los proveedores.

No documentado:

• Cuánto tiempo un nombre del plan gratuito permanece sin poder reclamarse después de que tu túnel se detiene o tu sesión expira. La documentación dice solo que los nombres gratuitos no están reservados.
• Si las comprobaciones de propiedad de las conexiones sobreviven a la sesión, y si un usuario anterior tiene prioridad sobre un nombre.
• Qué sucede con los nombres cuando se termina una cuenta. Los términos dicen que los túneles activos se cierran al terminar, pero no dicen nada sobre los nombres.

Hasta que esos puntos estén documentados, la suposición segura para cualquier nombre que no estés reservando explícitamente es que puede ser reclamado por alguien más una vez que dejes de usarlo. Planifica la limpieza en torno a ello, con cualquier proveedor de túneles. La auditoría a continuación funciona independientemente de cómo responda un servicio dado.

Qué recibiría un ocupante indebido

Supón que alguien ahora controla el hostname. Cada proveedor le entrega algo distinto.

	Stripe	GitHub	Shopify
Contenido del evento	Los eventos instantáneos llevan una copia completa del recurso afectado. Los eventos ligeros llevan menos, y tú obtienes el resto a través de la API	Datos de repositorio, rama y commit, nombres y correos de autores; repos privados incluidos	Datos de pedido y cliente, que pueden incluir nombres, correos y direcciones
Firma	Stripe-Signature, incluye una marca de tiempo	X-Hub-Signature-256, sin marca de tiempo	X-Shopify-Hmac-SHA256, sin marca de tiempo
Limpieza del lado del proveedor si el endpoint falla	Reintentos de hasta 3 días en modo en vivo, 3 veces en unas pocas horas en un sandbox	No hay eliminación automática documentada	Reintentos de hasta 8 veces en 4 horas; las suscripciones específicas de la tienda se eliminan, las específicas de la aplicación no

A grandes rasgos, un ocupante obtiene:

1. Todo en la solicitud. Cuerpo, cabeceras y la ruta URL completa y la cadena de consulta. La guía de GitHub no recomienda colocar claves API u otras credenciales en la URL del payload. Si alguna vez incrustaste un token o credenciales de autenticación básica en una URL de webhook, pasaron al nuevo dueño.
2. Una vista de tu actividad. Nombres de repos, correos de clientes y volúmenes de pedidos son útiles para phishing y reconocimiento sin un solo evento falsificado.
3. Una conexión TLS operativa. Los proveedores verifican el certificado del destino, pero el hostname sigue siendo servido por el edge del proveedor de túneles con un certificado válido, por lo que la verificación pasa. Las verificaciones de certificado no informan al proveedor que el nombre cambió de manos.
4. Una razón para responder con 200. Los proveedores tratan una respuesta no-2xx o un timeout como fallo; Shopify cuenta cualquier respuesta fuera del rango 200, incluidos los redireccionamientos. Un ocupante que devuelve 200 hace que las entregas parezcan saludables, lo que suprime el comportamiento de reintento y eliminación que de otro modo limpiaría el registro. Eso es una inferencia de cómo se define el fallo, y significa que el registro puede sobrevivir indefinidamente.

Lo que un ocupante no puede hacer por sí solo es forjar un evento firmado para tu endpoint real. No tienen tu secreto de firma, y los payloads que reciben no lo contienen. Esa protección solo se mantiene si tu manejador de producción aplica firmas. GitHub, por ejemplo, no envía ninguna cabecera de firma a menos que hayas configurado un secreto en el webhook. La verificación de firmas no garantiza la confidencialidad de lo que se envió al lugar equivocado.

Una advertencia sobre repeticiones: las bibliotecas oficiales de Stripe rechazan los eventos anteriores a cinco minutos por defecto, pero las firmas de GitHub y Shopify no llevan marca de tiempo. Desduplicar también por el ID de entrega: X-GitHub-Delivery para GitHub y X-Shopify-Webhook-Id para Shopify.

No cuentes con la limpieza del lado del proveedor

La documentación de Stripe cubre una ventana de reintento automático de tres días en modo en vivo y tres reintentos en unas pocas horas en un sandbox. Guías de terceros (Svix, Hookdeck) informan que Stripe desactiva un endpoint tras tres días de fallos continuos. Las páginas de Stripe que revisé no dicen esa regla, así que mírala como un comportamiento reportado, no una garantía.

GitHub te permite desactivar (reversible) o eliminar (permanente) webhooks de repositorio y de organización. Cada App de GitHub tiene un webhook único que puedes desactivar pero no eliminar. No encontré documentación de GitHub que elimine automáticamente un webhook que falla.

Shopify requiere la lectura más exacta. Las entregas se reintentan hasta ocho veces en cuatro horas, y una falla persistente elimina las suscripciones creadas mediante la Admin API (shop-specific). La tabla de comparación de Shopify dice que las suscripciones específicas de la app que fallan, las que están en shopify.app.toml, no se eliminan. Una URL obsoleta allí permanece hasta que la edites y ejecutes shopify app deploy.

La limpieza solo se ejecuta cuando el endpoint falla, y un ocupante puede impedirlo.

La lista de verificación del panel de control del proveedor

Ejecuta esto antes de liberar un nombre de túnel y de nuevo como una revisión trimestral. Verifica entornos de prueba y en vivo por separado, porque la gente suele olvidar uno de ellos.

Stripe

• Abre la pestaña Webhooks en Workbench y enumera cada endpoint, en modo en vivo y en cada entorno de sandbox o prueba, además de cualquier configuración Connect o multi-cuenta que gestiones.
• O usa la API: curl -G https://api.stripe.com/v1/webhook_endpoints -u \"$STRIPE_SECRET_KEY:\" -d limit=100. Ejecutarlo una vez por entorno con la clave de ese entorno. Las entradas incluyen url, status y enabled_events.
• Marca cualquier URL en un dominio de túnel o en un host que no reconozcas, incluyendo las de status: disabled, que siguen registradas.
• Verifica quién tiene claves restringidas con el permiso webhook_write. Stripe señala que esa clave puede crear destinos que reciben payloads para cualquier tipo de evento, incluso sin permiso para leer los objetos subyacentes.

GitHub

• Webhooks de repositorio: Configuraciones, luego Webhooks, para cada repositorio que administres. Vía CLI: gh api --paginate repos/OWNER/REPO/hooks --jq '.[] | {id, active, url: .config.url}'.
• Webhooks de organización (solo propietarios): gh api orgs/ORG/hooks.
• Cada App de GitHub que posees tiene un webhook URL; verifica la configuración de la app.
• Entregas recientes: fallas repetidas suelen indicar que el destino ya no existe.

Shopify

• Suscripciones específicas de la app: abre shopify.app.toml y verifica cada uri dentro de [[webhooks.subscriptions]].
• Suscripciones de tienda: consulta webhookSubscriptions(first: 50) { edges { node { id topic uri } } } a través de la GraphQL Admin API, para cada tienda y tienda de desarrollo en la que tu app está instalada. Esta consulta cubre solo suscripciones creadas por la API, no las gestionadas por TOML, por lo que necesitas ambas comprobaciones.
• Verifica los registros de entrega y métricas en el Dev Dashboard para suscripciones que fallan o se eliminan. Los registros de entrega cubren sólo los últimos siete días.

Todo lo demás

• Repite para Slack, Twilio, Meta/WhatsApp, PayPal, herramientas al estilo Zapier, sistemas CI y cualquier app OAuth que almacene un URI de redirección. Las URL de retorno para flujos de inicio de sesión son un riesgo relacionado, que ya cubrimos en The OAuth Tunnel Trap.

Suscribirse primero, luego rotar

El orden importa, porque el objetivo es evitar que los datos salgan antes de preocuparse por lo que el nuevo dueño ya tiene.

1. Desactiva, aún no elimines. Desactiva el webhook de GitHub (gh api -X PATCH repos/OWNER/REPO/hooks/HOOK_ID -F active=false) o desactiva el endpoint de Stripe en Workbench. Esto es reversible si la URL resulta importante.
2. Confirma el silencio. Vigila el registro de entregas del proveedor durante un día. Si algo dependía del endpoint, lo descubrirás ahora y no durante un incidente.
3. Eliminar. Usa curl -X DELETE https://api.stripe.com/v1/webhook_endpoints/we_XXXX -u \"$STRIPE_SECRET_KEY:\", gh api -X DELETE repos/OWNER/REPO/hooks/HOOK_ID, o la mutación webhookSubscriptionDelete para suscripciones de Shopify específicas de la tienda. Para suscripciones de Shopify gestionadas por TOML, elimina la entrada y ejecuta shopify app deploy. La eliminación de GitHub no se puede deshacer.
4. Rotar todo lo que la URL anterior podría haber expuesto. Trata estos como comprometidos solo si se compartieron con el antiguo endpoint:
   • Secretos incrustados en la URL, en la cadena de consulta o en cabeceras personalizadas.
   • Un secreto de firma que reutilizaste en otro lugar, como un manejador de producción. Stripe crea un secreto distinto por endpoint, pero el secreto de GitHub es uno que elegiste, así que verifica que no pegaste el mismo valor en varios lugares. Shopify firma con el secreto del cliente de tu app, que se comparte en toda la app. Si ese se reutilizó, rotarlo es un trabajo mayor, y Shopify dice que el nuevo digest puede tardar hasta una hora en tomar efecto.
   • Claves API o tokens que tu manejador de desarrollo usó para llamar de vuelta al proveedor.
5. Elige la ventana de rotación adecuada. En Workbench, rotar un secreto de firma de Stripe te permite expirar el antiguo de inmediato o mantenerlo válido hasta 7 días. El retraso facilita la rotación planificada. Tras una exposición sospechosa, expíralo de inmediato, ya que el periodo de gracia mantiene válido el valor antiguo.
6. Vuelve a verificar con un evento de prueba al endpoint real, y luego registra la fecha en tu inventario.

Para los secretos de GitHub, genera un valor aleatorio largo (por ejemplo openssl rand -hex 32) y guárdalo en un gestor de secretos.

Prevén el próximo webhook colgante

La limpieza es la solución, pero algunos hábitos reducen el problema:

• Lanza nombres deliberadamente. Haz que “eliminar registros del proveedor” forme parte de desmantelar un entorno de desarrollo. Con InstaTunnel, ejecuta --kill en el subdominio y elimina sus registros en la misma sesión.
• No reutilices nombres de ejemplos de documentación. Si una guía usa stripe-webhook o oauth-dev, elige algo específico para ti.
• Reserva nombres de los que dependes en lugar de esperar que nadie los pida. En InstaTunnel eso significa el plan Business, que es el único que lista reservas. En el plan gratuito, recuerda que las sesiones terminan tras 24 horas.
• Deja que las herramientas gestionen las URL de desarrollo cuando sea posible. La documentación de Shopify señala que la URL del túnel de la CLI cambia en cada ejecución de shopify app dev, y sugiere un uri relativo (por ejemplo /webhooks) para no volver a registrar cada vez.
• Limita lo que puede recibir un endpoint extraviado. Las opciones include_fields y filter de Shopify limitan la carga útil y qué entregas se activan, y Stripe permite suscribirte solo a los tipos de eventos que necesitas.
• Asigna un propietario y una expiración a cada registro de desarrollo. Los campos description y metadata de Stripe están hechos para ello.
• Mantén secretos separados por entorno, para que una URL obsoleta nunca se convierta en un problema de producción.
• Coloca los registros en código, para que los olvidados se hagan visibles en las pull requests.

Una solución tentadora no funciona: la protección por contraseña en tu túnel te protege solo mientras posees el nombre. Requiere un plan Pro o Business y, de todos modos, un proveedor no puede completar un formulario de contraseña del navegador. Un ocupante en el mismo hostname simplemente no lo habilitará.

Preguntas frecuentes

¿Qué es un webhook colgante?
Una suscripción de webhook en un proveedor como Stripe, GitHub o Shopify que todavía apunta a una URL que ya no controlas, típicamente un subdominio de túnel liberado.

¿Alguien puede hacerse con mi antiguo subdominio de túnel?
Depende del servicio de túneles. Si permite que cualquier cuenta solicite un nombre específico y no mantiene nombres liberados, entonces sí. La documentación de InstaTunnel describe los nombres del plan gratuito como por orden de llegada sin reserva, y listan reservas solo bajo el plan Business. Revisa la documentación de tu proveedor, y no des por seguro que un nombre es seguro a menos que esté expresamente reservado.

¿Puede un atacante forjar eventos de Stripe o GitHub usando un webhook colgante?
No frente a un punto final de producción que verifica firmas. No reciben tu secreto de firma. Lo que pueden hacer es leer los payloads, cabeceras y URL enviados, y mantener el registro activo devolviendo 200.

¿Necesito rotar secretos después de eliminar un webhook?
Rota cualquier cosa expuesta a la antigua URL, como tokens en la cadena de consulta o un secreto de firma que reutilizaste en otros lugares.

Conclusión

Un subdominio de túnel es barato y temporal. Un registro que apunta a él sigue funcionando hasta que alguien lo elimine. Realiza una auditoría de cada proveedor cuando liberes un nombre y haz una revisión trimestral.

---

Fuentes

• Qué es la seguridad de Webhook: asegurando integraciones SaaS en 2026 (Obsidian Security)
• Principales conclusiones del Verizon 2026 DBIR (SpyCloud)
• Las brechas de la cadena de suministro aumentan 60% hasta la mitad de todos los incidentes (Expert Insights)
• Verizon 2025 DBIR: la implicación de terceros se duplica (ASIS Security Management)
• Gestiona endpoints de webhook (Stripe Docs)
• Configura eventos (Stripe Docs)
• Revisión de webhooks de Stripe (Svix)
• Guía de Stripe Webhooks: Características y buenas prácticas (Hookdeck)
• Buenas prácticas para usar webhooks (GitHub Docs)
• Desactivando webhooks (GitHub Docs)
• Validando entregas de webhooks (GitHub Docs)
• Solución de problemas de webhooks (Shopify)
• Gestiona suscripciones de webhooks (Shopify)
• Verifica entregas de webhooks (Shopify)
• InstaTunnel [docs de subdominios personalizados], [banderas CLI], [solución de problemas], [precios] e [términos], verificado el 14 de noviembre de 2026