Cómo auditar un plugin de WordPress antes de instalarlo

Hay una llamada que cualquiera que mantenga webs WordPress ha recibido alguna vez: «Google muestra mi web con títulos en japonés y anuncios de casinos». A menudo el origen es un plugin instalado meses atrás, a veces con miles de instalaciones y buenas valoraciones, que tenía una vulnerabilidad sin parchear o directamente una puerta trasera.

Limpiar un sitio así cuesta horas de trabajo urgente y, sobre todo, confianza. Por eso no instalamos ningún plugin en producción sin pasar antes por un protocolo de auditoría.

El repositorio oficial de WordPress tiene decenas de miles de plugins. Muchos son excelentes, algunos son peligrosos y la mayoría son mediocres. Saber distinguirlos antes de instalar es imprescindible.

Por qué los plugins son un riesgo especial

WordPress ejecuta el código de los plugins con los mismos privilegios que el núcleo. Un plugin puede:

• Leer y modificar cualquier dato de la base de datos.
• Enviar datos a servidores externos sin que lo sepas.
• Inyectar código en el frontend para robar información de los usuarios.
• Crear usuarios administradores ocultos.
• Descargar e instalar más malware si forma parte de una cadena de infección.

Además, hay riesgos de rendimiento (plugins que ralentizan cada página), de compatibilidad (conflictos con otros plugins o con el tema) y de mantenimiento (plugins abandonados que dejan de funcionar con las actualizaciones de WordPress).

Auditar antes de instalar no garantiza que no haya problemas, pero elimina la mayoría de los riesgos evidentes.

Fase 1: evaluación en el repositorio (antes de descargar)

Antes de tocar el código, revisamos la información pública del plugin:

Última actualización. Un plugin que lleva más de un año sin actualizarse es sospechoso. Preferimos plugins actualizados en los últimos 3 a 6 meses.

Compatibilidad con tu versión de WordPress. Si el plugin indica que solo se ha probado hasta una versión de hace varios años, hay riesgo de incompatibilidades. No es un veto automático, pero sí una señal de alerta.

Número de instalaciones activas. Más instalaciones suelen significar más ojos revisando el código. Nuestra regla: por debajo de 1.000 instalaciones activas, el plugin necesita una revisión de código más profunda; por debajo de 100, desconfiamos salvo que venga de un desarrollador conocido. Ojo, porque la popularidad tampoco es garantía: los plugins más instalados son también los más atractivos para los atacantes.

Historial de vulnerabilidades. Consultamos bases de datos públicas como las de WPScan, Patchstack o Wordfence. Haber tenido vulnerabilidades no lo descarta (les pasa a casi todos los grandes); lo que importa es cuánto se tardó en corregirlas. Y si la ficha del plugin aparece cerrada en el repositorio, no lo instales hasta saber por qué: WordPress.org cierra plugins, entre otros motivos, por fallos de seguridad sin resolver.

Reseñas y soporte. Leemos las reseñas negativas recientes y los hilos de soporte abiertos. Un plugin con muchos «me ha roto la web» o «no responden en soporte» es una señal de alarma, tenga la valoración media que tenga.

Desarrollador. ¿Es una empresa consolidada o un desarrollador desconocido? ¿Tiene otros plugins con buena reputación y una forma clara de contacto?

Si falla en varios de estos criterios, ni siquiera descargamos el código: en WordPress hay alternativas para casi todo.

Fase 2: análisis de código (para plugins nuevos o poco probados)

Para los plugins que superan la fase 1 pero son críticos para el proyecto o vienen de fuentes menos conocidas, revisamos el código. No hace falta ser experto en PHP para ver lo más evidente:

Funciones peligrosas. Buscamos eval(), exec(), shell_exec() o base64_decode(). Su presencia no implica que el plugin sea malicioso, pero necesita una justificación. Un plugin de SEO que usa eval() es sospechoso.

Llamadas externas. Buscamos wp_remote_get(), wp_remote_post(), file_get_contents() con URLs o curl. ¿A qué servidores se conecta? Un plugin de formularios que envía datos a un dominio sin relación con el servicio es una señal de alarma.

Creación de usuarios o roles. ¿Crea usuarios administradores? ¿Añade capacidades nuevas? Puede ser legítimo (en un plugin de membresías, por ejemplo), pero tiene que encajar con lo que hace el plugin.

Código ofuscado. Código ofuscado o codificado en base64 sin motivo aparente. Algunos plugins premium lo hacen para protegerse; en uno gratuito es una señal de alerta.

Escritura de archivos. ¿El plugin intenta modificar archivos del núcleo de WordPress o del tema? Rara vez es necesario y es una vía de infección clásica.

En esta fase combinamos herramientas automáticas, como el plugin oficial Plugin Check o PHP_CodeSniffer con las reglas de WordPress Coding Standards, con una revisión manual de los archivos principales.

Fase 3: prueba en un entorno aislado

Nunca instalamos un plugin directamente en producción. El flujo es este:

1. Instalación local. Instalamos el plugin en un entorno de desarrollo local (Docker, LocalWP o similar).
2. Prueba de funcionalidad básica. ¿Hace lo que promete? ¿Los ajustes se guardan correctamente?
3. Consumo de recursos. Con Query Monitor o una herramienta similar comprobamos si añade consultas a la base de datos, si carga scripts innecesarios en todas las páginas o si consume demasiada memoria.
4. Prueba de conflictos. Con los plugins principales del sitio ya instalados, comprobamos que no aparezcan errores de JavaScript, fallos de funcionamiento ni avisos de PHP.
5. Revisión de seguridad básica. ¿Escapa correctamente la salida? ¿Valida y limpia las entradas? ¿Usa nonces y comprueba permisos en sus formularios y peticiones AJAX?

Solo cuando el plugin supera todas estas fases lo pasamos a staging y, finalmente, a producción. Si afecta al rendimiento, revisa también cómo convive con la caché: lo explicamos en cómo configurar un sistema de caché en WordPress correctamente.

Plugins premium: consideraciones adicionales

Los plugins de pago tienen sus propias reglas:

Licencia y servidores de activación. Algunos plugins premium necesitan conectarse al servidor de licencias del desarrollador para funcionar o actualizarse. Si el desarrollador cierra, ¿qué pasa con tu plugin?

Actualizaciones. Los plugins premium no se actualizan a través del repositorio oficial, sino con el sistema propio del desarrollador, normalmente ligado a una licencia activa. Si la licencia caduca, dejas de recibir parches de seguridad.

Código cerrado. Algunos plugins premium tienen el código ofuscado o cifrado con herramientas como ionCube, lo que impide una auditoría completa. En ese caso dependes por completo de la reputación del desarrollador.

Copias «nulled». Las versiones pirateadas de plugins premium que circulan gratis por internet son una de las vías de infección más habituales. No hay ahorro que compense ese riesgo.

Aquí la trayectoria del desarrollador pesa todavía más: preferimos empresas con años de recorrido a las licencias «de por vida» de recién llegados.

Señales que descalifican un plugin automáticamente

Hay señales que, si aparecen, descartan un plugin al instante, sin más auditoría:

• Código ofuscado en un plugin gratuito.
• Llamadas a dominios sospechosos o que cambian entre versiones.
• Creación de usuarios administradores ocultos.
• Inserción de contenido sin consentimiento (por ejemplo, enlaces de afiliado ocultos).
• Datos introducidos por el usuario que llegan sin validar a consultas SQL.
• Más de 2 años sin actualizaciones e incompatibilidad con las versiones actuales de WordPress.
• Desarrollador sin datos de contacto ni identidad verificable.

Mantenimiento después de instalar

Un plugin seguro hoy puede tener mañana una vulnerabilidad recién descubierta. Por eso:

• Mantenemos un inventario de todos los plugins instalados y sus versiones.
• Estamos suscritos a alertas de seguridad (Wordfence, Patchstack, WPScan o similares).
• Aplicamos las actualizaciones de seguridad en un plazo de 24 a 48 horas.
• Cada trimestre revisamos si siguen haciendo falta todos los plugins instalados.

Y la seguridad de los plugins sirve de poco si el acceso al panel es débil: contraseñas, 2FA y gestores son la otra mitad del trabajo.

Preguntas frecuentes

¿Cuánto tiempo lleva auditar un plugin?

La fase 1 lleva unos 5 minutos. La fase 2, de 15 a 30 minutos en plugins sencillos. La fase 3 depende de la complejidad. En plugins del repositorio con más de 1 millón de instalaciones y buen historial, a veces nos basta con la fase 1 y la prueba en staging.

¿Debería evitar los plugins gratuitos?

No. Muchos plugins gratuitos del repositorio oficial son excelentes y los mantienen equipos profesionales (Yoast SEO o WooCommerce, por ejemplo). Que sea gratis no es el problema; que esté abandonado, sí.

¿Puedo fiarme de los plugins de CodeCanyon o marketplaces similares?

Con más cautela. No pasan la misma revisión que el repositorio oficial, así que requieren una auditoría más profunda. Siempre que podemos, compramos directamente al desarrollador.

¿Qué hago si ya instalé un plugin sin auditar y ahora tengo problemas?

Desinstalarlo no siempre basta. Algunos dejan código residual, tablas en la base de datos o usuarios creados. Revisa qué cambió, limpia lo que dejó y valora una auditoría de seguridad completa. Si ya hay indicios de hackeo, sigue esta guía de primeros auxilios para una web hackeada.

Conclusión

El ecosistema de plugins es una de las mayores fortalezas de WordPress y también uno de sus mayores riesgos. Instalar es un solo clic, y eso esconde lo que estás permitiendo ejecutar en tu servidor.

Un protocolo de auditoría no es paranoia, es profesionalidad. Lleva minutos y puede ahorrarte horas de limpieza o el daño a tu reputación que deja un hackeo.

Si gestionas sitios WordPress y quieres que revisemos los plugins que tienes instalados, o necesitas ayuda para limpiar un sitio comprometido, cuéntanos tu caso. Eso sí, preferimos ayudarte a prevenir el problema antes que a solucionarlo después.