--- title: "Plugins “seguros” en WordPress.org: qué revisa realmente el repositorio, por qué se cuelan cosas como shell_exec y cómo proteger tu sitio (hoy)" description: "“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 comprensibl..." url: https://wpdirecto.com/plugins-seguros-wordpress-org-que-revisa-realmente-el-repositorio-por-que-se-cuelan-cosas-como-shell_exec-y-como-proteger-tu-sitio-hoy/ date: 2025-10-26 modified: 2026-09-09 author: "Editor WPDirecto" image: https://wpdirecto.com/wp-content/uploads/2017/07/tags-mas-populares.png categories: ["Seguridad"] tags: ["código fuente", "seguridad"] type: post lang: es --- # Plugins “seguros” en WordPress.org: qué revisa realmente el repositorio, por qué se cuelan cosas como shell_exec y cómo proteger tu sitio (hoy) > “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. [![](https://wpdirecto.com/wp-content/uploads/2025/10/taxopress-seguridad-1024x655.png)](https://wpdirecto.com/wp-content/uploads/2025/10/taxopress-seguridad.png) 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. https://twitter.com/GuillermoVersus/status/1912821446746812704 --- ## 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](https://wordpress.org/support/topic/latest-update-contains-file-that-triggers-maldetect-quarantine/#post-18383610)