Como auditar un plugin de WordPress antes de instalalo

Hai unha chamada que calquera que manteña webs WordPress recibiu algunha vez: “Google mostra a miña web con títulos en xaponés e anuncios de casinos”. A miúdo a orixe é un plugin instalado meses atrás, ás veces con miles de instalacións e boas valoracións, que tiña unha vulnerabilidade sen parchear ou directamente unha porta traseira.

Limpar un sitio así custa horas de traballo urxente e, sobre todo, confianza. Por iso non instalamos ningún plugin en produción sen pasar antes por un protocolo de auditoría.

O repositorio oficial de WordPress ten decenas de miles de plugins. Moitos son excelentes, algúns son perigosos e a maioría son mediocres. Saber distinguilos antes de instalar é imprescindible.

Por que os plugins son un risco especial

WordPress executa o código dos plugins cos mesmos privilexios que o núcleo. Un plugin pode:

• Ler e modificar calquera dato da base de datos.
• Enviar datos a servidores externos sen que o saibas.
• Inxectar código no frontend para roubar información dos usuarios.
• Crear usuarios administradores ocultos.
• Descargar e instalar máis malware se forma parte dunha cadea de infección.

Ademais, hai riscos de rendemento (plugins que fan máis lenta cada páxina), de compatibilidade (conflitos con outros plugins ou co tema) e de mantemento (plugins abandonados que deixan de funcionar coas actualizacións de WordPress).

Auditar antes de instalar non garante que non haxa problemas, pero elimina a maioría dos riscos evidentes.

Fase 1: avaliación no repositorio (antes de descargar)

Antes de tocar o código, revisamos a información pública do plugin:

Última actualización. Un plugin que leva máis dun ano sen actualizarse é sospeitoso. Preferimos plugins actualizados nos últimos 3 a 6 meses.

Compatibilidade coa túa versión de WordPress. Se o plugin indica que só se probou ata unha versión de hai varios anos, hai risco de incompatibilidades. Non é un veto automático, pero si un sinal de alerta.

Número de instalacións activas. Máis instalacións adoitan significar máis ollos revisando o código. A nosa regra: por debaixo de 1.000 instalacións activas, o plugin precisa unha revisión de código máis profunda; por debaixo de 100, desconfiamos agás que veña dun desenvolvedor coñecido. Ollo, porque a popularidade tampouco é garantía: os plugins máis instalados son tamén os máis atractivos para os atacantes.

Historial de vulnerabilidades. Consultamos bases de datos públicas como as de WPScan, Patchstack ou Wordfence. Ter tido vulnerabilidades non o descarta (pásalles a case todos os grandes); o que importa é canto se tardou en corrixilas. E se a ficha do plugin aparece pechada no repositorio, non o instales ata saber por que: WordPress.org pecha plugins, entre outros motivos, por fallos de seguridade sen resolver.

Opinións e soporte. Lemos as opinións negativas recentes e os fíos de soporte abertos. Un plugin con moitos “rompeume a web” ou “non responden no soporte” é un sinal de alarma, teña a valoración media que teña.

Desenvolvedor. É unha empresa consolidada ou un desenvolvedor descoñecido? Ten outros plugins con boa reputación e unha forma clara de contacto?

Se falla en varios destes criterios, nin sequera descargamos o código: en WordPress hai alternativas para case todo.

Fase 2: análise de código (para plugins novos ou pouco probados)

Para os plugins que superan a fase 1 pero son críticos para o proxecto ou veñen de fontes menos coñecidas, revisamos o código. Non fai falta ser experto en PHP para ver o máis evidente:

Funcións perigosas. Buscamos eval(), exec(), shell_exec() ou base64_decode(). A súa presenza non implica que o plugin sexa malicioso, pero precisa unha xustificación. Un plugin de SEO que usa eval() é sospeitoso.

Chamadas externas. Buscamos wp_remote_get(), wp_remote_post(), file_get_contents() con URL ou curl. A que servidores se conecta? Un plugin de formularios que envía datos a un dominio sen relación co servizo é un sinal de alarma.

Creación de usuarios ou roles. Crea usuarios administradores? Engade capacidades novas? Pode ser lexítimo (nun plugin de áreas para socios, por exemplo), pero ten que encaixar co que fai o plugin.

Código ofuscado. Código ofuscado ou codificado en base64 sen motivo aparente. Algúns plugins premium fano para protexerse; nun gratuíto é un sinal de alerta.

Escritura de ficheiros. O plugin tenta modificar ficheiros do núcleo de WordPress ou do tema? Rara vez é necesario e é unha vía de infección clásica.

Nesta fase combinamos ferramentas automáticas, como o plugin oficial Plugin Check ou PHP_CodeSniffer coas regras de WordPress Coding Standards, cunha revisión manual dos ficheiros principais.

Fase 3: proba nun ambiente illado

Nunca instalamos un plugin directamente en produción. O fluxo é este:

1. Instalación local. Instalamos o plugin nun ambiente de desenvolvemento local (Docker, LocalWP ou similar).
2. Proba de funcionalidade básica. Fai o que promete? Os axustes gárdanse correctamente?
3. Consumo de recursos. Con Query Monitor ou unha ferramenta similar comprobamos se engade consultas á base de datos, se carga scripts innecesarios en todas as páxinas ou se consome demasiada memoria.
4. Proba de conflitos. Cos plugins principais do sitio xa instalados, comprobamos que non aparezan erros de JavaScript, fallos de funcionamento nin avisos de PHP.
5. Revisión de seguridade básica. Escapa correctamente a saída? Valida e limpa as entradas? Usa nonces e comproba permisos nos seus formularios e peticións AJAX?

Só cando o plugin supera todas estas fases o pasamos a staging e, finalmente, a produción. Se afecta ao rendemento, revisa tamén como convive coa caché: explicámolo en como configurar un sistema de caché en WordPress correctamente.

Plugins premium: consideracións adicionais

Os plugins de pagamento teñen as súas propias regras:

Licenza e servidores de activación. Algúns plugins premium precisan conectarse ao servidor de licenzas do desenvolvedor para funcionar ou actualizarse. Se o desenvolvedor pecha, que pasa co teu plugin?

Actualizacións. Os plugins premium non se actualizan a través do repositorio oficial, senón co sistema propio do desenvolvedor, normalmente ligado a unha licenza activa. Se a licenza caduca, deixas de recibir parches de seguridade.

Código pechado. Algúns plugins premium teñen o código ofuscado ou cifrado con ferramentas como ionCube, o que impide unha auditoría completa. Nese caso dependes por completo da reputación do desenvolvedor.

Copias “nulled”. As versións pirateadas de plugins premium que circulan de balde por internet son unha das vías de infección máis habituais. Non hai aforro que compense ese risco.

Aquí a traxectoria do desenvolvedor pesa aínda máis: preferimos empresas con anos de percorrido ás licenzas “de por vida” de recén chegados.

Sinais que descualifican un plugin automaticamente

Hai sinais que, se aparecen, descartan un plugin ao instante, sen máis auditoría:

• Código ofuscado nun plugin gratuíto.
• Chamadas a dominios sospeitosos ou que cambian entre versións.
• Creación de usuarios administradores ocultos.
• Inserción de contido sen consentimento (por exemplo, ligazóns de afiliado ocultas).
• Datos introducidos polo usuario que chegan sen validar a consultas SQL.
• Máis de 2 anos sen actualizacións e incompatibilidade coas versións actuais de WordPress.
• Desenvolvedor sen datos de contacto nin identidade verificable.

Mantemento despois de instalar

Un plugin seguro hoxe pode ter mañá unha vulnerabilidade acabada de descubrir. Por iso:

• Mantemos un inventario de todos os plugins instalados e as súas versións.
• Estamos subscritos a alertas de seguridade (Wordfence, Patchstack, WPScan ou similares).
• Aplicamos as actualizacións de seguridade nun prazo de 24 a 48 horas.
• Cada trimestre revisamos se seguen facendo falta todos os plugins instalados.

E a seguridade dos plugins serve de pouco se o acceso ao panel é débil: contrasinais, 2FA e xestores son a outra metade do traballo.

Preguntas frecuentes

Canto tempo leva auditar un plugin?

A fase 1 leva uns 5 minutos. A fase 2, de 15 a 30 minutos en plugins sinxelos. A fase 3 depende da complexidade. En plugins do repositorio con máis de 1 millón de instalacións e bo historial, ás veces abóndanos coa fase 1 e a proba en staging.

Debería evitar os plugins gratuítos?

Non. Moitos plugins gratuítos do repositorio oficial son excelentes e mantéñenos equipos profesionais (Yoast SEO ou WooCommerce, por exemplo). Que sexa de balde non é o problema; que estea abandonado, si.

Podo fiarme dos plugins de CodeCanyon ou mercados similares?

Con máis cautela. Non pasan a mesma revisión que o repositorio oficial, así que requiren unha auditoría máis profunda. Sempre que podemos, compramos directamente ao desenvolvedor.

Que fago se xa instalei un plugin sen auditar e agora teño problemas?

Desinstalalo non sempre abonda. Algúns deixan código residual, táboas na base de datos ou usuarios creados. Revisa que cambiou, limpa o que deixou e valora unha auditoría de seguridade completa. Se xa hai indicios de ataque, segue esta guía de primeiros auxilios para unha web atacada.

Conclusión

O ecosistema de plugins é unha das maiores fortalezas de WordPress e tamén un dos seus maiores riscos. Instalar é un só clic, e iso agocha o que estás a permitir executar no teu servidor.

Un protocolo de auditoría non é paranoia, é profesionalidade. Leva minutos e pode aforrarche horas de limpeza ou o dano á túa reputación que deixa un ataque informático.

Se xestionas sitios WordPress e queres que revisemos os plugins que tes instalados, ou precisas axuda para limpar un sitio comprometido, cóntanos o teu caso. Iso si, preferimos axudarche a previr o problema antes que a solucionalo despois.