“Pensaba que los plugins del repositorio eran superseguros… ¿no los revisa un equipo?”
— Sí… pero no como muchos imaginan.
Tu sorpresa con TaxoPress (y el aviso de maldet / shell_exec) es comprensible. El repositorio de WordPress.org tiene procesos de revisión inicial, políticas y automatismos, pero no existe una auditoría línea a línea de cada actualización de los más de 60.000 plugins. En la práctica:
- Alta / revisión inicial: el equipo de Plugin Review hace comprobaciones manuales y automáticas para nuevas incorporaciones (directrices de seguridad, licencias, readme, saneamiento básico…).
- Actualizaciones: las publica el autor. Hay scanners y revisiones puntuales, pero no una auditoría exhaustiva en cada versión. Si se reporta un problema serio, el equipo puede cerrar un plugin y pedir una corrección.
- Tiempo de reacción: depende de voluntarios, del volumen de reports y de la gravedad. A veces un fichero de tests u otro artefacto “de desarrollo” no debería ir en el ZIP y se cuela; otras veces aparece código peligroso (como llamadas a
shell_exec,exec,system,passthru,proc_open,popen, backticks, evaluaciones dinámicas…) que debería saltar alarmas.
Que tú pudieras descargar 3.33.0 con ese código tras “estar corregido” puede deberse a:
- El autor subió la corrección, pero quedó cacheada otra build, o no se aplicó a todas las ramas/paquetes.
- Se retiró el fichero en la copia de WordPress.org, pero algún mirror/instalación guardó el ZIP anterior.
- Se eliminó solo un archivo y no la familia de funciones peligrosas.
Más allá de la casuística, aquí tienes un plan práctico para equipos WordPress (especialmente medios y sitios críticos) que quieren seguir en WordPress pero reducir su exposición a sorpresas.
1) Revisión express de tu plugin (TaxoPress o cualquiera)
Busca funciones peligrosas (local o en staging):
# inspección rápida de funciones de ejecución de sistema
rg -n "shell_exec|exec\(|system\(|passthru\(|proc_open\(|popen\(|`" wp-content/plugins/taxopress -S
# si no tienes ripgrep:
grep -RniE 'shell_exec|exec\(|system\(|passthru\(|proc_open\(|popen\(|`' wp-content/plugins/taxopress
Lenguaje del código: PHP (php)- Revisa también uploads y carpetas de cache si sospechas compromisos.
- Si usas Composer, mira si han empaquetado vendor/tests y archivos “de desarrollo” que no deberían distribuirse (suele resolverse con
.gitattributes export-ignore).
Verifica checksums (cuando existan):
# WP-CLI puede comprobar sumas de los plugins del repo
wp plugin verify-checksums taxopress
Lenguaje del código: PHP (php)Si el checksum no cuadra o aparecen archivos extraños (tests, bootstrap.php ajeno, etc.), no lo ignores.
Acción inmediata si ves algo raro
- Desactiva el plugin y vuelve a una versión anterior “buena” (usa Rollback o WP-CLI):
wp plugin install taxopress --version=3.32.2 --force - Contacta al autor en el foro de soporte y envía un reporte a
[email protected]si crees que es vulnerabilidad (asunto: Security report: [plugin-slug]).
2) Cómo operar WordPress “como si no te fiaras de nadie” (sin dejar de usarlo)
A. Gobernanza y actualizaciones
- Producción inmutable: en sitios críticos, define:
// wp-config.php define('DISALLOW_FILE_EDIT', true); define('DISALLOW_FILE_MODS', true); // sin instalaciones/actualizaciones desde el dashboardHaz updates vía CI/CD o WP-CLI en ventana controlada. - Staging/canary: prueba plugins/updates en entornos previos y promociona a producción tras escaneos (SAST/DAST) y smoke tests.
- Lista blanca de plugins: menos es más. Elimina los que no uses. Evalúa historial del autor, ritmo de updates y respuestas a reports.
B. Endurece PHP y el servidor
- Deshabilita funciones peligrosas (si tu stack lo permite):
; php.ini disable_functions = exec,passthru,shell_exec,system,proc_open,popen(nota: algunos plugins legítimos podrían necesitarlas; decide caso a caso) - open_basedir, UID dedicado para PHP-FPM, WAF (Cloudflare/WP-security), mod_security donde aplique.
- Permisos mínimos en
wp-contenty separa propietario/usuarios de servicio.
C. Monitoriza integridad y malware
- File integrity: Wordfence, Patchstack, WPScan API o tu EDR.
- Maldet/ClamAV en servidores que lo soporten; watch de rutas calientes (
wp-content/uploads,wp-content/plugins). - Alertas por cambios en ficheros de plugin fuera del ciclo de despliegue.
D. CORS y salida de datos
- Limita qué endpoints pueden servir datos (REST
_fields,_embedsolo si lo necesitas). - Si usas headless, añade CORS solo para tu frontend y rate limiting.
3) Qué puedes esperar (realistamente) del repositorio de WordPress.org
- Sí hay un equipo que revisa y cierra plugins cuando toca.
- No hay garantía de auditoría exhaustiva en cada release.
- Los autores pueden subir versiones con ficheros de pruebas o código basura por error. O, peor, con código peligroso.
- Los tiempos de reacción dependen de reports, gravedad y disponibilidad.
Buenas prácticas para autores (y que puedes exigir en tus RFP):
- Usar
.gitattributes export-ignorepara excluirtests/,examples/, CI y otros artefactos de la build. - Evitar/justificar funciones críticas (exec, shell…).
- Mantener changelogs claros, sign-off de revisiones y static analysis (PHPStan/Psalm).
- Responder rápido en foros ante reports como el que compartes.
4) Qué hacer si detectas shell_exec u otra llamada crítica
- Confirma contexto: ¿está llamada realmente activa o en un test/vendor? ¿Hay validación/saneamiento suficiente?
- Aísla: desactiva el plugin en prod; revisa logs y archivos creados/modificados.
- Informa: foro del plugin +
[email protected]con detalle (versión, ruta, fragmento). - Mitiga: bloquea la función a nivel de PHP (si procede), aplica WAF rules, y downgrade a versión segura.
- Post-mortem interno: añade regla a tu escáner para detectar esa firma en adelante.
Conclusión
El repositorio WordPress.org no es un auditor de seguridad de tus plugins; es un gran directorio con políticas, automatismos y un equipo que reacciona a reports. Para un sitio serio (y más en medios), la seguridad de la cadena de suministro es tu responsabilidad:
- opera con staging/canary y CI/CD,
- limita plugins,
- deshabilita funciones peligrosas si puedes,
- monitoriza integridad y malware,
- y reporta sin dudar cuando encuentres código sospechoso.
Así, cuando algo como un shell_exec se cuela, no dependes de la suerte: lo detectas, lo mitigas y sigues publicando.
vía: Taxopress
