Una falla de 10 sobre 10 en Magento y Adobe Commerce: qué pasó realmente

Primero, la respuesta directa: el 4 de septiembre de 2026, los atacantes empezaron a explotar una falla sin parchear en Magento Open Source y Adobe Commerce, registrada como CVE-2026-75650 con una puntuación de gravedad de 10.0, la más alta posible. La falla permite ejecutar comandos en el servidor de la tienda sin iniciar sesión y sin ningún privilegio, y Adobe publicó su corrección la noche del 7 de septiembre. Eso deja tres días completos durante los cuales las tiendas estuvieron expuestas sin protección alguna. Precisamente por eso instalar el parche no basta: si tu tienda funciona con esta plataforma, lo prudente es suponer que pudiste haber sido comprometido antes de que existiera la corrección, y la respuesta correcta es buscar señales de intrusión y rotar tus claves de cifrado y todas las credenciales, no instalar la actualización y seguir con tu día.

A quién afecta exactamente

La lista es inusualmente amplia, porque incluye la versión más reciente disponible en el momento del descubrimiento:

  • Magento Open Source y Adobe Commerce: versiones de la 2.4.4 a la 2.4.9, incluidas todas las actualizaciones de parches hasta agosto de 2026.
  • Adobe Commerce B2B: versiones de la 1.3.3 a la 1.5.3, hasta la actualización de agosto de 2026.
  • Cualquier versión anterior a la 2.4.4: ya sin soporte, y la categoría más peligrosa porque el hotfix oficial no la cubre.

Dicho sin rodeos: si el 1 de septiembre tenías un Magento totalmente actualizado, estabas expuesto. No es el conocido escenario de negligencia sobre el que solemos advertir: es un verdadero zero-day al que nadie tenía forma de adelantarse.

Cómo funciona el ataque sin contraseña

El ataque se desarrolla en dos etapas y abusa de la capacidad de Magento para construir plantillas de correo electrónico. En la primera etapa, el atacante envía una solicitud manipulada a una ruta de respuesta de pago, y el contenido completo de esa solicitud se escribe en un archivo de informe de errores en el servidor. En la segunda etapa, una solicitud al endpoint de GraphQL apunta de nuevo a ese archivo envenenado, y su contenido se ejecuta mientras se prepara un correo de recordatorio de pago fallido.

Lo que merece la atención de un dueño de negocio no es el detalle técnico, sino lo que revela: rutas públicas que parecen totalmente inocentes (la respuesta de una pasarela de pago, un endpoint de consultas para la tienda, un correo automático) se combinaron en un camino completo hacia el servidor. Las vulnerabilidades graves rara vez son una sola puerta abierta de par en par; con mucha más frecuencia son una cadena de puertas pequeñas, cada una de las cuales parece perfectamente razonable por sí sola.

Qué plantaron los atacantes una vez dentro

Aquí es donde se nota la diferencia entre un vándalo y una operación organizada. Las cargas maliciosas observadas no eran ruidosas notas de ransomware, sino herramientas silenciosas de persistencia:

  • Una puerta trasera escrita en Rust que se disfraza de uno de los procesos del kernel del sistema operativo, para no llamar la atención de quien revise por encima una lista de procesos.
  • Tráfico de mando y control camuflado a través del puerto de sincronización horaria, de modo que la actividad parece un ajuste rutinario del reloj en los registros de red.
  • Web shells en PHP escritas dentro de las carpetas de caché de imágenes de productos, lugares que normalmente nadie inspecciona porque están llenos de archivos temporales.
  • Herramientas adicionales de acceso remoto de un segundo atacante con herramientas no relacionadas, lo que significa que la falla estaba siendo explotada por más de un grupo al mismo tiempo.

El objetivo de cargas como estas en una tienda en línea conocida es quedarse mucho tiempo y leer los datos de pedidos y pagos a medida que pasan, no tumbar el sitio. Una tienda infectada sigue funcionando con total normalidad, y eso es lo inquietante.

Por qué instalar la actualización no basta

Porque si un atacante entró antes del 7 de septiembre, ahora tiene una copia de tus claves de cifrado y de las credenciales almacenadas. El parche cierra la puerta por la que entró; no lo expulsa de dentro. La propia guía de Adobe fue explícita en este punto: aplicar la corrección y después rotar las claves de cifrado, las contraseñas del panel de administración, los tokens de API, las credenciales de la pasarela de pago, las contraseñas de la base de datos y las claves de acceso al servidor.

El parche detiene la hemorragia. Rotar las claves es lo que saca de la casa al invitado no deseado.

Un plan de acción práctico para el dueño de una tienda

  • Primero: confirma que la corrección está realmente instalada, no que alguien dijo que lo estaba. Pide a tu equipo una prueba del registro de parches en el propio servidor, no un mensaje tranquilizador.
  • Segundo: busca rastros de intrusión: procesos en ejecución sospechosos con nombres que imitan procesos del sistema, archivos PHP dentro de las carpetas de medios e imágenes, y archivos de informe de errores inusuales.
  • Tercero: revisa el registro de correos salientes. Un aumento repentino de correos de recordatorio de pago fallido es un indicador directo de intentos de explotación, y cualquier responsable de operaciones puede leerlo sin conocimientos profundos de seguridad.
  • Cuarto: rota todas las claves sin excepción, sobre todo las credenciales de la pasarela de pago. Esto requiere una ventana de mantenimiento planificada, no una decisión improvisada en horas punta.
  • Quinto: si tu versión es anterior a la 2.4.4, deja de esperar un parche oficial que no va a llegar. Fija un plan de actualización con una fecha real y, mientras tanto, pon la tienda detrás de un firewall de aplicaciones web.
  • Sexto: documenta lo que hiciste. Si resulta que se filtraron datos de clientes, necesitarás una cronología de qué hiciste y cuándo.

El ángulo regulatorio en Arabia Saudí: los datos de los clientes no son solo un asunto técnico

Una tienda en línea que guarda nombres, direcciones, números de móvil e historial de pedidos de sus clientes está tratando datos personales regidos por la Ley de Protección de Datos Personales. Una brecha no se queda en un asunto interno entre la tienda y su proveedor de hosting; genera obligaciones ante la autoridad competente y ante los propios titulares de los datos. Por eso, la pregunta que un dueño de tienda debería hacerse hoy no es solo "¿se ha parcheado el servidor?", sino "¿puedo demostrar que no se tocaron los datos de mis clientes?".

Si tu tienda funciona en una plataforma gestionada en la nube como Salla o Zid, quedas fuera del alcance de esta falla en particular, porque aplicar parches a la plataforma no es tu responsabilidad. Pero la misma lección se aplica a cualquier extensión o integración de terceros que hayas conectado a tu tienda: la responsabilidad de aplicar parches recae en quien es dueño del servidor.

Cómo gestionamos incidentes como este en Origami

El principio sobre el que construimos los sistemas de nuestros clientes es que un incidente de seguridad no es una posibilidad remota, sino un evento aplazado. En la práctica eso significa tres cosas: credenciales fuera del código, en un almacén separado, para que rotarlas sea una tarea de minutos y no un proyecto de una semana; registros operativos guardados fuera del propio servidor, para que un atacante no pueda borrar sus huellas; y copias de seguridad que se han probado de verdad restaurándolas, no simplemente programadas.

Y si tienes una tienda Magento sin un equipo técnico dedicado, lo correcto hoy es sencillo: pide a tu proveedor de hosting o a tu socio técnico un informe por escrito que responda solo tres preguntas: cuándo exactamente se instaló la corrección, qué encontró el análisis de compromiso y si se rotaron las claves. Esas tres preguntas revelan más sobre la preparación de un socio técnico que cualquier presentación.

Fuentes

  • Anuncio oficial de Adobe Commerce sobre la actualización de seguridad APSB26-146 y el hotfix urgente: experienceleague.adobe.com
  • Análisis técnico de Sansec sobre la CVE-2026-75650 y los indicadores de compromiso: sansec.io/research/stylesmuggler-0day
  • Catálogo de vulnerabilidades explotadas conocidas de la CISA: cisa.gov
  • Ley de Protección de Datos Personales (PDPL) — Autoridad Saudí de Datos e Inteligencia Artificial (SDAIA): sdaia.gov.sa