payever WooCommerce quedó expuesto por CVE-2026-93754, y el fallo no pide contraseña. Cualquier visitante puede empujar un archivo PHP ejecutable hasta el directorio público de subidas de una tienda que use el plugin en su versión 4.8.0 o una anterior, y con ese archivo el servidor queda a su orden. La nota del registro oficial es 9,8 sobre 10, la más alta que se repite en esta historia.
El registro del CVE-2026-93754 se publicó este sábado 7 de noviembre en la base nacional de vulnerabilidades de Estados Unidos, con Wordfence como autoridad asignadora. payever WooCommerce es la pasarela que conecta una tienda con los pagos a plazos y las tarjetas de socios como Santander, Openbank, Allianz Trade y Verifone. La propia ficha del plugin en el directorio de WordPress habla de más de 5.000 comercios en 9 países y suma 19.861 descargas. No es un gigante del ecosistema, pero cada instalación guarda claves de pago, datos de pedidos y acceso al panel de la tienda.
Tres puertas de la API quedaron sin llave
El problema vive en tres respuestas automáticas que el plugin registra dentro de la API de WooCommerce: payever_set_sandbox_api_keys, payever_toggle_subscription y payever_synchronization_incoming. Las tres quedaron inscritas sin autenticación, sin revisión de permisos y sin el código temporal de un solo uso que WordPress emplea para confirmar que una petición viene de un administrador. Traducido: el servidor atiende esas llamadas venga de quien venga.
La segunda mitad del hueco está en la rutina upload_image(), la función que importa imágenes de producto. Esa rutina toma un archivo alojado en otra dirección, lo escribe en la carpeta pública de subidas con un nombre que controla el atacante y recién después revisa qué tipo de archivo es. El orden importa. Si la validación llega tarde, un archivo PHP disfrazado entra como si fuera una foto, queda publicado en una ruta adivinable y cualquiera puede abrirlo desde el navegador para ejecutar órdenes en el servidor. El registro clasifica el fallo como CWE-434, subida de archivos de tipo peligroso sin restricción.
Hay una pieza más, y funciona sola. El mismo registro describe una sobrescritura de identidad sin autenticación apoyada en credenciales escritas en el propio código, un error clasificado como CWE-798. Esa vía no depende del archivo subido: permite pisar la identidad configurada en el plugin sin pasar por el panel. Otra parte de la cadena, la recuperación del token, sí depende de una llamada saliente del plugin al servicio de payever para validar credenciales. Son dos caminos distintos hacia el mismo sitio, la administración de la pasarela de pago.
El vector publicado lo resume sin adornos: ataque por red, complejidad baja, cero privilegios previos, cero interacción del usuario y daño completo a la confidencialidad, la integridad y la disponibilidad. Una tienda con el plugin viejo no necesita que su dueño haga clic en nada. Basta con que la tienda esté en línea y reciba la petición preparada. El registro, al momento de su publicación, no reporta explotación activa contra tiendas reales; la calificación de 9,8 se sostiene en lo que el fallo permite, no en una campaña contada.
El patrón se repite en el ecosistema. Esta misma semana, una falla del núcleo de WordPress entró al catálogo de vulnerabilidades explotadas de la CISA con plazo federal de corrección. El núcleo recibe escrutinio constante; los plugins pequeños, con equipos reducidos y ciclos de revisión cortos, concentran buena parte de los casos que terminan en tiendas tomadas.
La versión 4.9.0 ya trae el arreglo
La corrección existe y lleva días publicada, aunque el CVE salió hoy. El directorio oficial de WordPress sirve la versión 4.9.0 del plugin, actualizada el 23 de octubre, y su registro de cambios dice en dos líneas lo que el fallo aprovechaba: las acciones de administración ahora exigen el permiso de gerente de tienda y el código de un solo uso, la importación de imágenes de producto solo acepta imágenes verificadas, el registro de actividad quedó reforzado y los extremos que trabajan con tokens fueron endurecidos. Quien tenga instalada una versión anterior debe mirar el número completo antes de relajarse: el registro marca como afectadas las versiones hasta la 4.8.0 incluida, y las dos intermedias, la 4.8.1 y la 4.8.2, solo traían una traducción y una corrección en la descripción del pago, sin correcciones de seguridad en su propio registro de cambios.
Actualizar a la 4.9.0 cierra las tres puertas y la rutina de subida en un solo movimiento. Para una tienda que no pueda actualizar hoy, la salida práctica es desactivar el plugin hasta completar el cambio y revisar la carpeta de subidas en busca de archivos PHP que no pertenezcan a la instalación; un archivo extraño ahí, con fecha reciente, vale más que cualquier tranquilidad declarada. También conviene rotar las claves de la pasarela tras la actualización si aparece cualquier archivo sospechoso, porque una clave copiada no se vence sola.
El detalle incómodo queda en el calendario. El arreglo se publicó el 23 de octubre y el identificador del fallo, el 7 de noviembre: durante dos semanas, la única señal para los administradores fue un registro de cambios con la frase «correcciones de seguridad». Las tiendas con actualización automática ya van cubiertas; las que actualizan a mano dependen de leer esa frase a tiempo.
Fuente: CVE.org
