WooCommerce: fallo crítico permite plantar web shells PHP

Un plugin de terceros, la puerta que nadie vigilaCuando hablamos de seguridad de servidores, la atención suele ir al núcleo del CMS, al firewall perim...

Un plugin de terceros, la puerta que nadie vigila

Cuando hablamos de seguridad de servidores, la atención suele ir al núcleo del CMS, al firewall perimetral o a las contraseñas. Sin embargo, el eslabón que más veces cede es el más discreto: un plugin de terceros que nadie revisa desde hace meses. Es justo lo que ha ocurrido con WooCommerce Wholesale Lead Capture, una extensión premium cuya versión 2.0.3.1 y anteriores arrastra un fallo crítico (CVE-2026-27540, CVSS 9.8) que ya se está explotando de forma activa.

El vector es engañoso por lo sencillo: una acción AJAX accesible sin iniciar sesión, wwlc_file_upload_handler, valida las extensiones con una lista que el propio atacante puede manipular mediante el parámetro file_settings. Dicho de otro modo, el atacante decide qué tipos de archivo se consideran aceptables y cuela un shell.php como si fuera una imagen. A partir de ahí, ejecutar código en el servidor es cuestión de segundos.

Por qué una web shell es peor de lo que parece

Subir un archivo PHP malicioso no es el final del ataque, es el principio. Esa web shell se convierte en una puerta trasera desde la que el intruso puede:

Desplegar más carga maliciosa cuando le convenga.
Robar credenciales de bases de datos, clientes o pasarelas de pago.
Instalar mecanismos de persistencia para sobrevivir a limpiezas superficiales.
Usar el servidor como nodo de una campaña mayor contra otros objetivos.

La telemetría de los últimos meses apunta a decenas de miles de intentos automatizados, con picos de actividad concentrados en determinadas fechas y con IPs reincidentes capaces de lanzar miles de peticiones en pocas horas. No es un ataque dirigido: es un barrido masivo que busca instalaciones vulnerables en todo el mundo, incluidas las de empresas catalanas y españolas que quizá ni saben que tienen ese plugin activo.

El error de pensar que «mi web está bien mantenida»

Muchas pymes de Lleida, Barcelona o Girona confían en que su web está segura porque el núcleo de WordPress se actualiza solo. El problema es que las actualizaciones automáticas rara vez cubren plugins premium de terceros, y menos aún cuando la licencia ha caducado o nadie recuerda quién los instaló. Un solo componente desactualizado basta para abrir una brecha en una infraestructura por lo demás impecable.

La corrección existe: el desarrollador publicó la versión 2.0.3.2 el 20 de febrero de 2026. Si no puedes actualizar de inmediato, la recomendación es tajante: desactiva o retira el plugin hasta poder aplicar el parche, porque el fallo permite entrar sin credenciales.

Qué revisar en las primeras horas

Si sospechas que tu instalación ha podido ser alcanzada, no pierdas tiempo buscando un único archivo sospechoso. Las backdoors rara vez viven solas. Prioriza estas comprobaciones:

Busca archivos .php inesperados o con fecha reciente, prestando especial atención a wp-content/uploads, una ruta donde no debería haber scripts ejecutables.
Audita las peticiones a /wp-admin/admin-ajax.php con action=wwlc_file_upload_handler y cruza los resultados con picos de tráfico, errores 200 inusuales o cargas con nombres extraños.
Revisa si existen cuentas de administrador que no reconoces y rota todas las credenciales, incluidas las de base de datos y las claves de API.
Comprueba la integridad de los archivos del núcleo y de los temas frente a una copia limpia.

En el perímetro, un WAF bien configurado puede frenar parte del ruido si aplicas reglas específicas contra cargas maliciosas en admin-ajax.php y bloqueas IPs con comportamiento repetitivo. No es una cura, pero reduce la superficie expuesta mientras terminas la limpieza.

De la reacción a la prevención: centralizar el bloqueo

El patrón se repite demasiado: un plugin vulnerable, un endpoint olvidado y una campaña automatizada que aprovecha la ventana entre la publicación del parche y su aplicación. La respuesta no puede ser solo reaccionar más rápido, sino reducir el número de puertas abiertas y tener visibilidad sobre quién llama a tu servidor.

Aquí es donde tiene sentido una capa de protección gestionada. Con Abuse Shield centralizas la defensa de todos tus servidores: bloqueo automático de IPs maliciosas, fail2ban gestionado en múltiples máquinas y un feed de reputación compartido entre todos tus servidores. Si una IP ataca una máquina, el resto de tu infraestructura la reconoce y la bloquea sin que tengas que intervenir manualmente. Para administradores de sistemas, empresas de hosting y pymes con servidores propios, esto marca la diferencia entre apagar fuegos uno a uno y tener una política coherente de reputación de IP.

La lección de CVE-2026-27540 no es solo «actualiza el plugin». Es que la seguridad de servidores exige inventario actualizado, parcheo disciplinado y un sistema de bloqueo que actúe en milisegundos, no cuando alguien revisa los logs al día siguiente.

Relacionado

¿Tus servidores bajo ataque constante?

Centraliza fail2ban y la reputación de IPs en todos tus servidores. Descubre Abuse Shield de ALMC. Contáctanos para una demo personalizada.

Resultados sin salir de la página.