Resumen
El origen del fallo no estaba en el código de la tienda, sino en otro reporte. Leyendo un reporte ya divulgado del programa de divulgación de vulnerabilidades de AWS (aws_vdp), el investigador se dio cuenta de que contenía, sin tachar, los códigos promocionales de envío gratuito de la tienda de merchandising de AWS: uno para un país concreto y otro para pedidos internacionales.
Free Shipping Promo Code (pick one):
United [REDACTADO]: [REDACTADO]
International: [REDACTADO]Al probarlos, los códigos seguían activos. Y lo más importante: la tienda los aceptaba una y otra vez, en cualquier número de pedidos. Según el análisis del investigador, el servidor solo comprobaba que la cadena del cupón existiera y estuviera activa, pero no cuántas veces se había canjeado. Cada vez que se aplicaba, recalculaba el envío a cero, sin caducidad ni registro de canjes.
El programa calificó el problema como de severidad baja y lo dio por resuelto. El reporte se envió el 15 de noviembre de 2025 y se divulgó el 9 de febrero de 2026.
Pasos de reproducción
- Localizar el reporte divulgado en el que aparecían los códigos de envío gratuito sin tachar y copiar el que corresponda al destino del envío (nacional o internacional).
- Entrar en la tienda de merchandising de AWS, añadir productos al carrito y avanzar hasta el pago. Anotar el coste de envío que se muestra: en la prueba del investigador rondaba los 43 dólares.
- Introducir el código promocional en el campo de cupón y aplicarlo.
- Comprobar que el coste de envío pasa a ser 0.
- Repetir el proceso en un pedido nuevo con el mismo código: la tienda vuelve a aceptarlo y el envío vuelve a salir gratis, sin límite de usos.
Impacto
- Cualquiera que leyera el reporte público podía ahorrarse los gastos de envío en todos sus pedidos, sin fecha de caducidad.
- Como el código no tenía límite de canjes, era posible automatizar la creación de pedidos en masa sin pagar envío.
- La pérdida para la tienda es directa: el importe del envío de cada pedido (unos 43 dólares en el ejemplo del investigador).
- Al tratarse de productos físicos, abría la puerta a revender la mercancía aprovechando el ahorro.
Remediación
El investigador atribuye el fallo a la falta de una comprobación de usos en el servidor: el cupón debería validarse no solo por existir y estar activo, sino también por el número de veces que se ha canjeado. El reporte figura como resuelto, pero el original no detalla qué cambio aplicó el programa.
Qué aprender de este caso
- Antes de divulgar un reporte, revisa también las capturas y los bloques de texto en busca de códigos promocionales, enlaces de invitación o vales: no son contraseñas, pero dan acceso a algo con valor económico. Si alguno se filtra, desactívalo en lugar de solo tacharlo después.
- Al auditar un checkout, aplica el mismo cupón en dos pedidos seguidos (y desde dos cuentas distintas): si el servidor solo valida que el código existe y está activo, el límite de usos no se está aplicando.
- Los cupones de uso general deberían llevar un límite de canjes por cliente y en total, una fecha de caducidad y un registro de cada redención en el servidor, para que un código filtrado no se convierta en un descuento permanente.
- Repasar los reportes ya divulgados de un programa es una vía legítima de encontrar fallos: secretos, códigos o datos internos que alguien olvidó ocultar.