Shopify: bypass de confirmación de email → ATO

Qué pasa

@ngalog encontró este bug mientras verificaba el parche del reporte #791775 en Shopify (myshop.myshopify.com). El primer bug ya estaba cerrado. @ngalog comprobó la corrección, identificó que era incompleta, y reportó una segunda vulnerabilidad el mismo día — de ahí el título Part II.

La mecánica: el flujo de confirmación de email de Shopify tenía un bypass que permitía asociar un email ajeno a tu propia cuenta. Una vez verificado ese email, obtenías acceso a la cuenta del usuario legítimo sin contraseña ni segundo factor.

Esto es *privilege escalation* (escalada de privilegios — el atacante sube de nivel de acceso sin credenciales legítimas): pasas de usuario normal a controlar la cuenta de otra persona. El vector de entrada es un flujo de verificación de email, que intuitivamente parece de baja criticidad pero que es la llave de identidad del sistema.

Shopify respondió rápido: funcionalidad deshabilitada al momento, fix permanente en dos horas.

Por qué importa

El patrón "retestear un fix" es una de las fuentes más productivas en bug bounty. Programas maduros como Shopify tienen flujos de autenticación complejos y parchean bajo presión. Eso genera dos oportunidades recurrentes:

• Fix incompleto: el parche cierra el vector A pero deja expuesto el vector B en el mismo flujo.
• Regresión: el fix introduce un nuevo bug en código adyacente.

Los flujos de verificación de email son especialmente ricos porque implican tokens con scoping complejo (¿a qué cuenta está ligado ese token?), son fáciles de implementar mal — token predecible, reutilizable, sin binding a la sesión original — y su impacto suele ser ATO (Account Takeover — tomar el control completo de una cuenta ajena) directo.

En programas con millones de usuarios, incluso "un subconjunto pequeño" puede equivaler a miles de cuentas reales expuestas.

Qué hacer

Si cazas bugs en programas con historial público en HackerOne:

• Busca los reportes resueltos de tu misma clase de vuln (verificación de email, account linking, OAuth). Lee el título y el timeline.
• Mapea cuándo llegó el fix e identifica qué funcionalidad fue tocada en ese sprint o commit.
• Retestea el flujo completo, no solo el vector exacto reportado. Los parches cubren el happy path pero olvidan edge cases: tokens enviados a múltiples emails, flujo de cambio de email vs. verificación inicial, APIs internas vs. UI pública.
• Prueba siempre con dos cuentas: una atacante, una víctima. Los bugs de ATO por verificación de email requieren confirmar que el acceso cross-account es real, no un falso positivo.

En sistemas de identidad, el "email verificado" es el anchor de confianza para reset de contraseña, SSO y permisos de merchant. Cualquier bypass en la verificación es automáticamente crítico — y Shopify tenía dos en el mismo flujo.