Una puerta trasera de WordPress usa ocho puntos de recuperación para reconstruirse tras su eliminación

Una puerta trasera de WordPress documentada recientemente puede reconstruirse después de que los defensores eliminen sus archivos visibles. Para ello, recurre a copias redundantes repartidas entre el sistema de archivos, la base de datos y, en los servidores compatibles, la memoria compartida.

El malware recibió el nombre en clave SC por las marcas SC_ halladas en el contenido inyectado. Sucuri lo describe como una malla «autorregenerable» controlada mediante blockchain. El investigador Gabriel Barbosa informó de que su carga útil ocupa al menos ocho ubicaciones y de que los componentes que sobreviven pueden restaurar las partes eliminadas de la infección.

El informe sobre SC se publicó junto con información sobre la explotación de una vulnerabilidad distinta en el plugin wpForo Forum. Las pruebas disponibles no vinculan ese fallo con la distribución ni con el funcionamiento de SC. Ambos deben tratarse como problemas de seguridad independientes.

Ocho componentes forman un sistema circular de persistencia

La resistencia de SC se basa en varias vías de recuperación, no en un único archivo oculto. Eliminar el plugin visible puede servir de poco si sigue disponible un cargador, una copia en la base de datos, un archivo de restauración o un segmento de memoria compartida.

Sucuri identificó ocho componentes principales:

1. .user.ini establece la directiva auto_prepend_file de PHP, que hace que se ejecute un cargador antes de las solicitudes PHP dentro del árbol de directorios afectado.

2. wp-content/c1b12371.php carga un archivo oculto cuyo nombre comienza con un punto cuando está presente en la misma ubicación.

3. wp-content/.c1b12371.php actúa como cargador de primera fase. Busca el plugin falso y puede reconstruirlo en mu-plugins a partir de tres fuentes: una copia del plugin normal, un fragmento codificado en el directorio de caché o un paquete ZIP de restauración con un nombre hexadecimal aleatorio.

4. wp-content/db.php aprovecha el mecanismo de drop-ins de base de datos que WordPress carga automáticamente. Contiene la carga útil de la puerta trasera en formato comprimido y codificado en Base64, y vuelve a instalar el plugin si falta el archivo esperado o su tamaño no alcanza un umbral definido.

5. wp-content/advanced-cache.php se ejecuta antes que los plugins normales cuando el almacenamiento en caché está habilitado. Puede reconstruir el malware a partir de cinco ubicaciones: el plugin obligatorio, una copia convencional del plugin, código PHP almacenado en la memoria compartida System V, un paquete ZIP o la base de datos. Después, se engancha a plugins_loaded e incluye el plugin restaurado.

6. wp-content/themes/khorshidi/functions.php aporta persistencia a nivel del tema. Según Sucuri, contiene la misma puerta trasera y reescribe el plugin siempre que este no está presente.

7. wp-content/mu-plugins/hyper-engine-kit.php es el malware instalado como plugin obligatorio, una categoría que WordPress carga automáticamente.

8. wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php proporciona otra copia de la misma carga útil en el directorio estándar de plugins.

La puerta trasera oculta los nombres de sus funciones y usa un decodificador basado en un cifrado por sustitución para dificultar la interpretación del código. También se oculta en la pantalla de plugins del administrador de WordPress y en las comprobaciones de actualizaciones.

Con esta arquitectura, eliminar cada componente por separado no es una estrategia fiable. Un archivo que parezca secundario puede ser la copia que, en el siguiente ciclo de ejecución, reconstruya todo lo demás.

La memoria compartida amplía la persistencia más allá de los archivos y los registros SQL

En los servidores compatibles con la memoria compartida System V, SC escribe código PHP en un segmento al que se accede mediante una clave numérica fija. El informe no especifica el valor de esa clave.

Como el segmento reside en la memoria RAM, puede seguir disponible después de limpiar los archivos del sitio web y los registros de la base de datos. El drop-in malicioso advanced-cache.php puede recuperar el código PHP de ese segmento y usarlo para volver a crear el plugin.

El alojamiento compartido puede complicar la inspección y la eliminación. Según Sucuri, el segmento de memoria puede pertenecer a otra cuenta, lo que podría dejarlo fuera del alcance administrativo habitual del propietario del sitio comprometido.

La infección también registra hooks de cron de WordPress, incluidos nombres aleatorios y un hook de recuperación conocido. El material facilitado no identifica esos nombres. Una tarea cron del sistema ejecuta el archivo cron de WordPress, lo que permite programar la reinstalación sin depender del tráfico de visitantes.

Por tanto, los archivos, el contenido de la base de datos, los archivos de restauración, las tareas programadas y la memoria compartida funcionan como partes de un mismo mecanismo de recuperación. Limpiar solo el directorio de plugins de WordPress deja intactas varias fuentes potenciales de reconstrucción.

El control basado en Ethereum permite ampliar el compromiso

Sucuri describe SC como una puerta trasera controlada mediante blockchain que se comunica con la infraestructura de mando y control a través de la blockchain de Ethereum. El informe disponible no incluye identificadores de carteras de Ethereum, direcciones de mando y control ni otros indicadores de infraestructura similares.

Una vez en funcionamiento, el malware puede obtener una huella del sitio web infectado, descargar cargas útiles adicionales y crear una cuenta oculta de administrador de WordPress. Entre las capacidades atribuidas a sus operadores se encuentran:

• Descargar JavaScript arbitrario para inyectarlo en las páginas del sitio web.
• Distribuir skimmers u otro malware mediante scripts inyectados.
• Ejecutar código PHP en el servidor comprometido.
• Desactivar o eliminar plugins concretos.
• Repetir la reinfección cuando se eliminan componentes.

Estas capacidades ponen en riesgo tanto el sitio web como a sus visitantes. La ejecución de PHP en el servidor ofrece al operador un amplio control sobre la instalación de WordPress, mientras que la inyección de JavaScript arbitrario permite insertar código malicioso en las páginas que se muestran a los usuarios.

El informe citado no identifica al actor que opera SC. También señala que se desconoce el método de acceso inicial. Los componentes de WordPress vulnerables, las credenciales débiles, las cadenas de suministro de plugins comprometidas y las funciones de carga de archivos inseguras se mencionan solo como posibilidades habituales, no como vías de acceso confirmadas para este malware.

La inyección SQL explotada en wpForo es un problema independiente

El fallo del plugin divulgado al mismo tiempo es CVE-2026-1581, una vulnerabilidad de inyección SQL ciega basada en el tiempo y sin autenticación que afecta a wpForo Forum en sus versiones de la 0 a la 2.4.14, ambas incluidas.

La vulnerabilidad está expuesta a través del parámetro wpfob. El escape insuficiente de los datos controlados por el usuario, junto con la preparación inadecuada de una consulta SQL existente, permite que un atacante sin autenticar añada consultas SQL y extraiga información confidencial de la base de datos.

El registro del programa CVE emitido por Wordfence identifica a tomdever como proveedor y atribuye el descubrimiento del fallo a Youssef Elouaer. El registro se publicó el 19 de febrero de 2026 y se actualizó el 8 de abril de 2026.

CVE-2026-1581 tiene una gravedad ALTA, una puntuación CVSS 3.1 de 7,5 y el siguiente vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

El vector describe una vulnerabilidad explotable de forma remota, con baja complejidad de ataque, sin necesidad de privilegios ni de interacción del usuario. El impacto evaluado es alto para la confidencialidad; no se indica ningún impacto para la integridad ni la disponibilidad. El fallo se clasifica como CWE-89, neutralización incorrecta de elementos utilizados en un comando SQL.

La telemetría de Previdian registró menos de 20 intentos de explotación desde el 3 de julio de 2026. La actividad procedía de cinco direcciones IP únicas de atacantes, geolocalizadas en Bulgaria, Suiza, Francia, Estados Unidos y Yemen. No se facilitaron las direcciones concretas.

El informe no identifica a los atacantes responsables de esos intentos ni establece una relación entre CVE-2026-1581 y la puerta trasera SC.

La respuesta a incidentes debe abarcar todas las fuentes de restauración

Ante la sospecha de un compromiso por SC, eliminar hyper-engine-kit.php o uno de los cargadores no basta para confirmar que la infección se ha erradicado. Los equipos de respuesta deben investigar las ocho rutas de componentes identificadas y las fuentes de recuperación adicionales a las que hacen referencia.

La revisión debe incluir:

• Los directorios de plugins normales y obligatorios.
• Los drop-ins db.php y advanced-cache.php.
• El archivo functions.php del tema afectado.
• .user.ini y su configuración auto_prepend_file.
• El contenido de la caché y los paquetes ZIP de restauración con nombres aleatorios.
• Los datos maliciosos almacenados en la base de datos de WordPress.
• La actividad de cron de WordPress y del sistema.
• Los segmentos de memoria compartida System V en los servidores compatibles.

El informe disponible no proporciona un procedimiento validado para eliminar SC, la clave numérica de la memoria compartida, los nombres completos de los hooks de cron ni indicadores concretos de mando y control. Por tanto, los administradores no deberían dar por limpio un sitio solo porque el plugin visible ya no aparezca.

En el caso de CVE-2026-1581, los operadores deben comprobar si alguna instalación de WordPress ejecuta wpForo Forum 2.4.14 o una versión anterior. Los registros de vulnerabilidad facilitados no identifican una versión corregida ni una solución provisional, por lo que no permiten señalar una versión concreta como remedio. Los administradores deberían consultar las indicaciones actuales del proveedor y revisar la actividad web y de la base de datos en busca de solicitudes sospechosas relacionadas con wpfob.

Los dos incidentes requieren investigaciones distintas. SC exige buscar mecanismos de persistencia en varias capas de almacenamiento y ejecución, mientras que CVE-2026-1581 requiere evaluar la exposición del plugin e investigar posibles extracciones de datos de la base de datos. Confundirlos podría llevar a los equipos de defensa a centrarse en una vía de acceso o una estrategia de limpieza equivocadas.