WooCommerce: cómo comprobar si tu tienda es vulnerable

La pregunta «¿es vulnerable mi WooCommerce?» casi nunca se responde mirando solo la versión de WooCommerce. En una tienda real tienes el núcleo de WooCommerce, entre cinco y veinte extensiones (pasarelas, transportistas, facturación, cupones, sincronización con el ERP) y un tema que además sobrescribe las plantillas del proceso de compra. El riesgo está repartido entre todo eso. Aquí tienes cómo hacer el inventario en diez minutos, qué mirar en pedidos y pasarela, y cómo actualizar sin dejar la tienda tirada un martes por la mañana.

Si vas con prisa, empieza por estos tres sitios: WooCommerce > Estado, Plugins > Plugins instalados y WooCommerce > Ajustes > Pagos. Con esas tres pantallas ya sabes el 80% de lo que necesitas.

Cómo ver la versión de WooCommerce y la de cada extensión

El sitio bueno para mirar es WooCommerce > Estado (pestaña Estado del sistema). Ahí tienes, en una sola página y sin instalar nada:

La versión de WooCommerce y la de la base de datos de WooCommerce, que a veces se quedan desacompasadas después de una actualización a medias.
El listado de plugins activos con su versión y, muy importante, con la última versión disponible al lado. Cuando ves algo como 1.4.2 (hay una actualización a 1.9.0 disponible), eso es un plugin que lleva mucho tiempo sin tocarse.
Un apartado de plantillas que te dice si tu tema está sobrescribiendo plantillas de WooCommerce y si alguna de esas copias está desfasada. Apunta esa lista: es exactamente la parte de tu tienda que no se actualiza sola.
El botón Obtener informe del sistema, que copia todo eso al portapapeles. Guárdalo en un archivo antes de tocar nada; es tu foto del «antes».

Completa la foto en Plugins > Plugins instalados. Ahí verás dos cosas que la pantalla de estado no te cuenta: los plugins desactivados (que siguen en el disco y siguen siendo archivos accesibles) y los que muestran el aviso «este plugin ya no está disponible» o «no se ha probado con las últimas versiones de WordPress». Un plugin retirado del repositorio oficial es una señal seria: a veces se retira precisamente por un fallo de seguridad sin parchear.

Un apunte para tiendas veteranas: si alguna extensión de pago la instaló tu desarrollador subiendo un ZIP a mano, esa no avisa de actualizaciones y puede llevar años ahí sin que nadie lo note.

Por qué el riesgo real está en las extensiones y en el tema

El núcleo de WooCommerce lo mantiene un equipo grande. Se le encuentran fallos, como a todo, pero se parchean rápido y la actualización llega sola a mucha gente.

El problema son las capas de alrededor:

Extensiones de terceros. El plugin del transportista, el que conecta con tu programa de facturación, el de cupones avanzados. Muchos los mantiene una persona, algunos ya no los mantiene nadie, y son los que tocan datos de pedidos.
El tema de la tienda. Si es un tema comprado en un marketplace, es probable que traiga plugins incluidos dentro y que sobrescriba las plantillas de carrito y finalizar compra. Esos plugins incluidos solo se actualizan cuando actualizas el tema, y solo si el autor del tema se ha molestado en meter la versión nueva.
Los plugins de infraestructura de los que depende medio ecosistema. Si un plugin de campos personalizados del que dependen tus fichas de producto se queda sin parchear, arrastra a la tienda entera; ese patrón lo explicamos en detalle en el artículo sobre el riesgo de depender de un plugin del que cuelga toda la web.

Si quieres el mapa completo de cómo funcionan estos fallos y cómo decidir cuáles te afectan de verdad, la guía de referencia es la de vulnerabilidades en plugins de WordPress.

Qué puede tocar un atacante en una tienda

Conviene tener claro qué se pone en juego, porque en una tienda no es lo mismo que en un blog. Con acceso suficiente, alguien puede:

Leer los pedidos. Nombre, dirección, teléfono, correo y qué compró cada cliente. Eso es un fichero de datos personales, con las obligaciones que eso implica si se filtra.
Modificar el proceso de pago. El caso más rentable para el atacante no es robarte a ti, es cobrar en tu lugar: cambiar el número de cuenta de la transferencia bancaria, o inyectar un script en la página de finalizar compra que copie los datos de la tarjeta mientras el cliente los teclea.
Crear cupones o pedidos. Cupones del 100% para uso propio, o pedidos marcados como pagados que no lo están.
Usar las claves de API. Si tu tienda tiene claves de API REST para el ERP o para una app, esas claves son un acceso completo a pedidos y clientes sin pasar por el panel.

Dicho con honestidad: si usas una pasarela seria (Redsys, Stripe, PayPal) los datos de tarjeta no pasan por tu servidor, y eso te protege mucho. Lo que no te protege es de un script inyectado en tu propia página de pago que capture lo que el cliente escribe antes de que salga de ahí. Por eso lo importante no es solo «dónde se guardan las tarjetas», sino «quién puede modificar el HTML de mi checkout».

Cómo actualizar WooCommerce sin dejar la tienda fuera de servicio

El orden importa, y la prisa es mala consejera cuando estás actualizando la parte que cobra.

Copia de seguridad completa (archivos y base de datos) hecha hoy, y comprueba que se puede descargar. Una copia que no has probado a descargar no cuenta.
Elige la hora. Mira en Analíticas > Pedidos a qué horas te entran menos pedidos. Actualizar a las once de la mañana de un lunes es buscarse el problema.
Primero en pruebas. Casi todos los hostings tienen un botón de «clonar a staging» o similar. Actualiza ahí y haz una compra completa de principio a fin, incluida la pasarela en modo de pruebas.
Orden en producción: primero el núcleo de WordPress, después WooCommerce, después las extensiones de WooCommerce, y el tema al final. Actualizar el tema antes que WooCommerce es una forma habitual de romper el carrito.
De una en una. Si actualizas doce extensiones a la vez y algo falla, no sabes cuál ha sido. Después de cada una, carga la página de un producto, añádelo al carrito y llega hasta finalizar compra.
Actualizador de la base de datos. Después de una actualización mayor de WooCommerce aparece un aviso azul pidiendo actualizar la base de datos. Púlsalo y espera a que termine antes de seguir con nada más.

Si esta parte es la que te da miedo y por eso llevas meses sin actualizar (te pasa a ti y a mucha gente), el procedimiento con red de seguridad completo está en la guía de cómo actualizar los plugins de WordPress sin romper la web. Y si lo que tienes es una lista larga de actualizaciones pendientes y no sabes por dónde empezar, el criterio de orden lo tienes en cómo priorizar los parches en una pyme.

Qué revisar después de actualizar

Actualizar cierra el agujero, pero no deshace lo que hayan podido hacer antes. Estas cuatro comprobaciones son rápidas y valen mucho:

Usuarios administradores

En Usuarios > Todos, filtra por Administrador y por Gestor de tienda. El rol de gestor de tienda se olvida con frecuencia y da acceso a todos los pedidos y clientes. Ordena por fecha de registro y mira si hay alguna cuenta nueva que no esperabas.

Claves de API REST

En WooCommerce > Ajustes > Avanzado > API REST tienes la lista de claves creadas, con su descripción, el usuario al que pertenecen y los permisos (lectura, escritura o ambos). Revoca todas las que no reconozcas o que ya no uses. Si tenías una clave de una integración que dejaste de usar hace dos años, sigue siendo una llave válida.

Webhooks

En WooCommerce > Ajustes > Avanzado > Webhooks. Cada webhook envía datos de pedidos a una URL cuando pasa algo. Comprueba a qué dominio apunta cada uno. Un webhook activo apuntando a un dominio que no reconoces es una fuga de datos de pedidos en directo, y es de las cosas que más se pasan por alto.

Datos de pago

En WooCommerce > Ajustes > Pagos, entra en cada método activo. Si tienes transferencia bancaria directa, comprueba el IBAN carácter a carácter. Es un cambio de dos dígitos que nadie mira y que puede estar desviando cobros desde hace semanas.

Señales de que ya han manipulado tu proceso de compra

Estas son las que llegan del mundo real, normalmente por boca de un cliente antes que por un panel:

Clientes que dicen que han pagado y a ti no te consta el pedido, o al revés.
Pedidos con importe cero, con cupones que tú no has creado, o pedidos de prueba de importe pequeño y repetidos (es la forma de comprobar que una tarjeta robada funciona).
Un cliente que te avisa de que su banco le ha bloqueado la tarjeta después de comprar en tu web.
La página de finalizar compra tarda más que antes o parpadea, o aparece un campo de tarjeta donde antes redirigía a la pasarela.
Correos de pedido que salen con un remitente o un texto distinto.
La tienda se ve normal para ti pero un cliente te manda una captura de otra cosa. Muchas manipulaciones solo se activan para visitantes que llegan de Google o desde móvil.

Una comprobación que puedes hacer tú ahora mismo: abre tu tienda en una ventana de incógnito, llega hasta finalizar compra, pulsa Ctrl+U para ver el código fuente y busca <script src=. Todos los dominios que aparezcan ahí deberían ser tuyos, de tu pasarela o de una herramienta que hayas instalado tú a conciencia. Si hay un dominio que no sabes qué es, ahí tienes el hilo del que tirar.

Qué hacer si una extensión de pago te bloquea la actualización

Es una situación real y frecuente: no puedes actualizar WooCommerce porque el plugin de tu pasarela (o el del ERP) no es compatible con la versión nueva y llevas la tienda parada en una versión antigua desde hace meses. No hay solución mágica, pero sí un orden sensato:

Escribe al proveedor de la extensión y pon fecha. Pregunta directamente: «¿tenéis prevista compatibilidad con la versión X y para cuándo?». La respuesta, o la ausencia de respuesta, ya es información.
Comprueba si tu banco o pasarela tiene una alternativa oficial. Muchas entidades han publicado plugins propios mantenidos, y a menudo el que tienes es un desarrollo antiguo de un tercero.
Actualiza lo que sí puedas. Que no puedas subir WooCommerce no impide actualizar el resto de plugins y el núcleo de WordPress. Cada uno que actualizas es un frente menos.
Reduce la exposición mientras tanto. Verificación en dos pasos para todos los administradores, elimina roles y cuentas que no se usen, revoca claves de API viejas y limita el acceso al panel.
Ponle fecha de caducidad al parche. Si en tres meses el proveedor no ha respondido, la decisión ya no es técnica: es cambiar de extensión. Sale más barato que una tienda comprometida en plena campaña.

Y mientras tanto, vigila. Una tienda que no puede actualizarse necesita, como mínimo, que alguien mire los archivos nuevos y los usuarios nuevos con cierta frecuencia.

Si después de esta revisión te queda la duda de si ya te han tocado algo, pasa tu tienda por PathScan y comprueba gratis si hay señales de compromiso. Se analiza desde fuera, como la ve un cliente, sin registro y sin instalar nada en tu WooCommerce.

Seguir leyendo en esta sección

Ver todo en Avisos de plugins concretos → · Mapa completo del sitio