“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 plugins@wordpress.org 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 dashboard Haz 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-content y 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, _embed solo 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-ignore para excluir tests/, 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

1. Confirma contexto: ¿está llamada realmente activa o en un test/vendor? ¿Hay validación/saneamiento suficiente?
2. Aísla: desactiva el plugin en prod; revisa logs y archivos creados/modificados.
3. Informa: foro del plugin + plugins@wordpress.org con detalle (versión, ruta, fragmento).
4. Mitiga: bloquea la función a nivel de PHP (si procede), aplica WAF rules, y downgrade a versión segura.
5. 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