
| Nombre del complemento | Visibilidad de Contenido para Divi Builder |
|---|---|
| Tipo de vulnerabilidad | Ejecución de Código Arbitrario |
| Número CVE | CVE-2026-1829 |
| Urgencia | Medio |
| Fecha de publicación de CVE | 2026-06-04 |
| URL de origen | CVE-2026-1829 |
Ejecución Remota de Código de Contribuidor Autenticado en la Visibilidad de Contenido para Divi Builder (CVE-2026-1829) — Lo que los Propietarios de Sitios de WordPress Deben Hacer Ahora
Autor: Equipo de seguridad de WP-Firewall
Fecha: 2026-06-04
Resumen
- Vulnerabilidad: Ejecución Arbitraria de Código (ejecución remota de código) en el plugin de WordPress Visibilidad de Contenido para Divi Builder, afectando versiones <= 4.02.
- CVE: CVE-2026-1829
- Gravedad: Alto / CVSS 8.8 (clasificación de Patchstack)
- Privilegio requerido: Usuario autenticado con rol de Contribuidor
- Corregido en: 5.00
- Riesgo: Los atacantes pueden escalar una cuenta de bajo privilegio para ejecutar código arbitrario en el servidor — utilizado en campañas de compromiso masivo.
Como equipo de seguridad de WP-Firewall, tratamos esta vulnerabilidad como una amenaza real e inmediata para los sitios de WordPress que utilizan el plugin Visibilidad de Contenido para Divi Builder. A continuación, explico qué significa la falla, cómo los atacantes pueden abusar de ella, cómo mitigar rápidamente el riesgo, cómo detectar la explotación y cómo recomendamos tanto la remediación de emergencia como la a largo plazo y el endurecimiento.
Si gestionas sitios de WordPress, lee esto cuidadosamente y actúa ahora — especialmente si tu sitio permite a los usuarios de nivel Contribuidor iniciar sesión.
¿Qué sucedió? Resumen de alto nivel
Una vulnerabilidad en el plugin “Visibilidad de Contenido para Divi Builder” (versiones hasta 4.02) permite a un atacante autenticado con privilegios de Contribuidor realizar ejecución de código arbitrario en el entorno de alojamiento. Esto no es una simple inyección de contenido — es la capacidad de hacer que el sitio ejecute código proporcionado por el atacante que se ejecuta en el servidor. Cuando se explota, los atacantes pueden instalar puertas traseras, pivotar a otros sitios en el mismo servidor, robar credenciales o realizar desfiguraciones y campañas de spam.
La vulnerabilidad ha sido divulgada públicamente y se le ha asignado CVE-2026-1829. Un parche de seguridad está disponible en la versión 5.00 del plugin. Sin embargo, muchos sitios se retrasan en las actualizaciones o pueden no ser capaces de actualizar inmediatamente debido a personalizaciones, pruebas de integración o restricciones de alojamiento. Ahí es donde la mitigación y detección rápidas son esenciales.
Por qué esta vulnerabilidad es peligrosa
Una cuenta de Contribuidor está comúnmente disponible en blogs de múltiples autores, sitios comunitarios y plataformas que aceptan contenido de contribuyentes no confiables. Normalmente, se permite a los Contribuidores crear y editar sus propias publicaciones, pero no pueden instalar plugins ni modificar temas. Cuando un plugin permite a un atacante a nivel de Contribuidor alcanzar la ejecución del lado del servidor, efectivamente elude el modelo de privilegios:
- Los atacantes no necesitan credenciales de administrador para comprometer completamente un sitio.
- Las explotaciones son triviales de escalar — un script automatizado puede convertir en arma cualquier sitio que exponga el plugin vulnerable.
- Una vez que se logra la ejecución de código, los atacantes pueden mantener acceso persistente incluso después de las actualizaciones del plugin a menos que se eliminen las puertas traseras.
- La vulnerabilidad se mapea a patrones OWASP A3 (Inyección); el plugin permite que la entrada insegura influya en el comportamiento del servidor.
Debido a que las cuentas de Contribuidor son más fáciles de obtener que las cuentas de administrador y los sitios a menudo tienen muchos contribuyentes, la superficie de explotación es grande. Los escáneres de explotación automatizados y los bots típicamente escanean en busca de tales vulnerabilidades e intentan la explotación inmediatamente después de la divulgación pública.
Análisis técnico (lo que probablemente salió mal)
Los avisos públicos describen la ejecución de código arbitrario desencadenada por un contribuidor autenticado. Aunque no nombraremos rutas de código interno específicas, estas son las causas raíz comunes que producen esta clase de vulnerabilidad:
- El plugin acepta entrada controlada por el usuario (meta de publicación, atributos de shortcode, cargas AJAX o cargas de archivos) y luego incluye o ejecuta esos datos en el servidor sin la debida sanitización y escape.
- Una rutina del lado del servidor puede evaluar directamente el contenido (por ejemplo, a través de eval de PHP o incluyendo una ruta de archivo o plantilla construida a partir de la entrada del usuario).
- El plugin puede exponer una acción AJAX de estilo administrativo o un endpoint REST que no verifica las capacidades correctamente, permitiendo que roles con menos privilegios realicen operaciones destinadas a editores o administradores.
- Controladores de carga de archivos que permiten archivos PHP (o archivos que pueden transformarse en código ejecutable) sin validar tipos MIME o restringir la ubicación de almacenamiento.
Debido a que la vulnerabilidad permite la ejecución de código, es efectivamente un defecto de inyección: la entrada incorrecta influye en el flujo de la aplicación de una manera que conduce a comandos arbitrarios o a la ejecución de código PHP.
Importante: incluso si el plugin no llama a eval explícitamente, un atacante a veces puede encadenar varios comportamientos (por ejemplo, escribir en un archivo de tema o plugin a través de una API de escritura de archivos, engañar al código para incluir ese archivo, o plantar una puerta trasera a través de plantillas personalizadas) para lograr RCE.
¿A quién afecta?
- Cualquier sitio de WordPress que ejecute versiones del plugin Content Visibility for Divi Builder 4.02 o anteriores.
- Sitios que tienen cuentas de Colaborador (o roles de usuario que se mapean a la capacidad de Colaborador) y donde esos usuarios pueden acceder a la funcionalidad vulnerable.
- Redes multisite donde el plugin está activado en la red y existen Colaboradores en sub-sitios.
Si alojas plataformas CMS con contenido generado por usuarios (autores invitados, envíos abiertos, blogs de múltiples autores), trata esto como crítico incluso si piensas que los Colaboradores son “confiables”: los atacantes crean cuentas de colaborador falsas de manera rutinaria.
Acciones inmediatas: haz esto ahora (ordenado)
-
Verifica la versión del plugin.
- Inicia sesión y verifica la versión del plugin. Si es <= 4.02, el sitio es vulnerable.
-
Actualiza el plugin
- Si es posible, actualiza Content Visibility for Divi Builder a la versión 5.00 o posterior de inmediato. Esta es la solución más simple y recomendada.
-
Si no puedes actualizar de inmediato, reduce el riesgo:
- Desactiva temporalmente el plugin (desactívalo) hasta que esté disponible una actualización o una línea de tiempo segura.
- Limita el acceso de los Colaboradores: cambia los roles de usuario para que los nuevos o no verificados colaboradores no puedan iniciar sesión o publicar hasta que el sitio esté seguro.
- Elimina o restringe los endpoints del plugin utilizando reglas de WAF o reglas de acceso del servidor web (sigue la guía de ejemplo).
- Refuerza los directorios de carga de archivos: prohíbe la ejecución de PHP desde /wp-content/uploads/ a través de .htaccess o configuración del servidor.
-
Activa la protección proactiva (WAF / parcheo virtual)
- Despliega un firewall de aplicaciones web que pueda aplicar un parche virtual o bloquear patrones de explotación. Configúralo para bloquear POSTs/parámetros sospechosos y poner en cuarentena solicitudes de colaboradores desconocidos que toquen endpoints vulnerables.
-
Rotar credenciales y claves
- Si se sospecha de un compromiso o para estar seguro después de aplicar el parche, rota las contraseñas de administrador, claves API y cualquier clave almacenada en wp-config.php que sea accesible o que probablemente se reutilice.
-
Escanea el sitio de inmediato.
- Realiza un escaneo completo de malware e integridad del sitio (archivos y base de datos) para verificar la existencia de puertas traseras, archivos PHP inesperados, archivos centrales cambiados o entradas de base de datos no autorizadas.
Sugerencias rápidas de reglas WAF (ejemplos: prueba antes de implementar)
A continuación se presentan reglas de ejemplo genéricas para reducir el riesgo de explotación cuando no es posible realizar actualizaciones inmediatas de plugins. Prueba primero en un entorno de staging; las reglas demasiado amplias pueden romper la funcionalidad.
- Bloquear solicitudes POST a puntos finales específicos de plugins de usuarios de nivel Contributor:
- Identificar acciones AJAX específicas de plugins o rutas REST (por ejemplo, /wp-admin/admin-ajax.php?action=PLUGIN_ACTION_NAME o /wp-json/PLUGIN_NAMESPACE/*) y bloquear solicitudes de sesiones no administrativas.
- Bloquear cargas útiles sospechosas:
- Denegar solicitudes que contengan nombres de funciones PHP comunes en campos de formulario (exec, shell_exec, system, passthru, base64_decode, eval) cuando provengan de cuentas de contributor.
- Prevenir la carga de archivos que se ejecuten como PHP:
- Denegar solicitudes que intenten crear o modificar archivos PHP en /wp-content/uploads/.
Regla de ejemplo de nginx (conceptual):
location ~* /wp-content/uploads/.*\.(php|phtml|php5|phar)$ {
Ejemplo de .htaccess para detener la ejecución de PHP en uploads:
<FilesMatch "\.(php|php5|phtml)$"> Order Deny,Allow Deny from all </FilesMatch>
Nota: Estas son capas preventivas; no reemplazan el parche. Algunas explotaciones utilizan cadenas creativas que pueden eludir reglas simples, así que combina el parcheo virtual con actualizaciones de plugins y monitoreo.
Detección: signos de explotación
Si el plugin fue explotado, aquí hay indicadores a buscar:
- Archivos nuevos o modificados que no colocaste, especialmente archivos PHP en:
- /wp-content/subidas/
- /wp-content/plugins/ (archivos inesperados)
- Directorios de temas: /wp-content/themes/[theme]/ (archivos desconocidos)
- Usuarios administradores desconocidos o cuentas de usuario contributor creadas recientemente.
- Tareas programadas sospechosas (trabajos wp-cron) o hooks desconocidos en la base de datos.
- Conexiones salientes desde el servidor a IPs o dominios desconocidos (balizas y C2).
- Alto uso de CPU o procesos generados por PHP que aparecen inusualmente a menudo.
- Los registros del servidor web o los registros de la aplicación muestran solicitudes POST inusuales a puntos finales de plugins, envíos que contienen cargas útiles codificadas (base64 / gzip) o solicitudes repetidas desde la misma IP.
- Archivos centrales alterados (compara con copias limpias) o filas de base de datos con código inyectado (por ejemplo, etiquetas o <?php en contenido almacenado en opciones o postmeta).
Si ves alguno de estos, asume compromiso y sigue la lista de verificación de respuesta a incidentes a continuación.
Manual de respuesta a incidentes (si sospechas o confirmas compromiso)
-
Aislar
- Llevar el sitio fuera de línea o ponerlo en modo de mantenimiento.
- Restringe el acceso a wp-admin a tus IPs a través de reglas del servidor web o autenticación HTTP.
-
Preservar las pruebas
- Realiza copias de seguridad de todo el sitio (archivos + DB) para análisis forense antes de hacer cambios.
- Descarga los registros relevantes (servidor web, PHP, registros de base de datos) y preserva las marcas de tiempo.
-
Identificar el alcance
- Escanea en busca de webshells y puertas traseras utilizando escáneres de malware de confianza e inspección manual.
- Busca modificaciones inesperadas en archivos de núcleo/plugin/tema y contenido sospechoso en las tablas de opciones y postmeta.
-
Elimina puertas traseras y restaura archivos.
- Reemplaza los archivos centrales de WordPress y los plugins/temas conocidos como buenos de fuentes oficiales.
- Elimina archivos PHP desconocidos y cualquier webshell descubierto.
- Si tienes una copia de seguridad limpia de antes del compromiso, considera restaurarla, luego actualiza todo.
-
Rotar credenciales y secretos
- Restablece las contraseñas de todas las cuentas de administrador y privilegiadas.
- Rota las claves API y cualquier credencial en archivos de configuración o servicios externos.
- Fuerza el restablecimiento de contraseñas por correo electrónico a todos los usuarios si los datos de usuario pueden verse afectados.
-
Parchea y actualiza
- Actualiza el plugin vulnerable a la versión corregida (5.00+) y actualiza todos los demás plugins, temas y el núcleo de WordPress a las últimas versiones compatibles.
-
Fortalecimiento y monitoreo
- Reinstala o aplica una capa de WAF/parcheo virtual.
- Habilita el registro y alertas para actividades sospechosas en wp-admin, cambios de archivos e intentos de inicio de sesión.
- Escanea regularmente y realiza verificaciones de integridad semanales.
-
Informe
- Si los datos o cuentas de usuario pueden haber sido expuestos, sigue las pautas de notificación legal/regulatoria.
- Informa al proveedor de alojamiento para que pueda verificar el movimiento lateral hacia otros clientes.
Lista de verificación de remediación y endurecimiento a largo plazo
Realice estos cambios para reducir el riesgo de problemas similares en el futuro:
-
Principio de mínimo privilegio
- Reconsidere si los colaboradores necesitan acceso de inicio de sesión. Utilice formularios de envío, publique por correo electrónico o importe manualmente si es posible.
- Conceda solo las capacidades mínimas requeridas para cada rol de usuario.
-
Restringir la edición de plugins y temas
- Establecer
define('DISALLOW_FILE_EDIT', true)enwp-config.phppara evitar la edición a través de la interfaz de administración. - Considere limitar la instalación de plugins/temas solo a administradores de confianza.
- Establecer
-
Asegurar el directorio de cargas
- Bloquee la ejecución de PHP dentro de las cargas, caché y otros directorios escribibles en el servidor web.
-
Audite y reduzca la superficie de plugins
- Elimine los plugins que no utiliza activamente. Cada plugin aumenta la superficie de ataque.
- Evalúe los plugins antes de instalarlos; prefiera plugins mantenidos activamente y bien revisados.
-
Aplique un monitoreo robusto de la integridad de archivos
- Mantenga sumas de verificación de archivos principales y alerte cuando ocurran cambios inesperados.
-
Implemente una autenticación más fuerte.
- Use contraseñas fuertes, cuentas de administrador únicas y fomente la autenticación de dos factores para cuentas de administrador/editor.
-
Despliegue un WAF y parches virtuales
- Un buen WAF puede bloquear intentos de explotación incluso antes de que un plugin sea parcheado.
-
Copias de seguridad regulares y pruebas de restauración
- Asegúrese de que las copias de seguridad estén disponibles fuera del sitio, inmutables cuando sea posible, y que pruebe las restauraciones periódicamente.
-
Manual de incidentes y libros de ejecución
- Documente un proceso interno para que las personas sigan en caso de notificación de una vulnerabilidad o compromiso activo.
Cómo WP-Firewall ayuda: protección inmediata y continua
En WP-Firewall ayudamos a los propietarios de sitios a proteger sus instalaciones de WordPress contra este tipo exacto de amenaza. Nuestro enfoque en capas cubre:
-
WAF gestionado con parcheo virtual
- Cuando se publica una nueva vulnerabilidad como esta, nuestro equipo de inteligencia de amenazas construye y despliega firmas para bloquear intentos de explotación para los clientes, incluso antes de que cada sitio sea actualizado.
- Los parches virtuales están ajustados para minimizar falsos positivos y bloquear patrones comunes de explotación para la vulnerabilidad.
-
Escaneo y limpieza de malware
- Escaneo de archivos completo a través de temas, plugins y cargas para detectar webshells, puertas traseras de PHP e indicadores de compromiso.
- Opciones de limpieza automáticas y manuales para archivos infectados y modificaciones maliciosas.
-
Mitigación de OWASP Top 10
- Conjuntos de reglas básicas para reducir inyecciones y otros vectores comunes (XSS, SQLi, abuso de carga de archivos).
- Limitación de tasa y bloqueo basado en comportamiento para detener campañas de explotación masiva automatizadas.
-
Monitoreo y alertas
- Detección de cambios en archivos con alertas.
- Monitoreo de inicio de sesión y acciones de administrador para alertar sobre actividad sospechosa de contribuyentes.
-
Soporte de incidentes y manuales de procedimientos.
- Orientación y escalamiento a través de nuestros canales de soporte, incluyendo opciones para forense y recuperación del sitio.
Estas capacidades están diseñadas para brindarte protección inmediata mientras actualizas plugins y realizas una remediación completa. En otras palabras: incluso si una actualización no es posible en el momento en que lees esto, tienes opciones de mitigación confiables.
Reglas de WAF de emergencia recomendadas que desplegamos para problemas similares.
Cuando nuestro equipo ve una vulnerabilidad que permite RCE de bajo privilegio, normalmente aplicamos una combinación de estas protecciones (personalizadas por sitio):
- Bloquear solicitudes que intentan escribir archivos PHP en directorios escribibles.
- Bloquear llamadas AJAX y REST sospechosas a rutas específicas de plugins cuando provienen de sesiones no administrativas.
- Detectar y bloquear cargas útiles que contengan cadenas codificadas en base64 o nombres de funciones PHP comunes en campos de formularios.
- Limitar la tasa de solicitudes POST a puntos finales administrativos para prevenir abusos automatizados.
- Geo-bloqueo para picos repentinos en el tráfico de explotación cuando sea apropiado.
Estas reglas están destinadas a ser parches virtuales temporales hasta que el plugin sea parcheado y probado. Reducen la ventana de exposición sin requerir tiempo de inactividad para el propietario del sitio.
Manual de detección — consultas y escaneos para ejecutar ahora mismo
-
Búsqueda de archivos en el servidor (ejemplos)
- Encuentra archivos PHP en uploads:
find /path/to/wp-content/uploads -type f -iname "*.php"
- Archivos modificados recientemente:
encontrar /path/to/wordpress -type f -mtime -14 -ls
- Encuentra archivos PHP en uploads:
-
Verificaciones de base de datos
- Buscar etiquetas PHP en postmeta/opciones:
SELECT * FROM wp_options WHERE option_value LIKE '%<?php%' LIMIT 50;
- Buscar etiquetas PHP en postmeta/opciones:
-
Análisis de registros
- Buscar POSTs repetidos a admin-ajax.php o puntos finales REST provenientes de las mismas IPs.
- Buscar solicitudes que contengan “base64_decode”, “eval(“, o cargas útiles codificadas largas.
-
Red / saliente
- Verificar búsquedas de DNS salientes inusuales o conexiones que indiquen beaconing:
netstat -plant | grep php - Inspeccionar los registros DNS del servidor en busca de resoluciones de dominio inusuales.
- Verificar búsquedas de DNS salientes inusuales o conexiones que indiquen beaconing:
-
Cuentas de usuario
- Listar usuarios y cuentas creados recientemente con roles de Colaborador o superiores.
Si no está seguro o encuentra elementos sospechosos, recolecte evidencia, haga una copia de seguridad y contacte a su proveedor de hosting o equipo de seguridad.
Escenarios de explotación en el mundo real (ilustrativos)
- Escenario A: Un sitio que acepta publicaciones de colaboradores invitados permite a un atacante crear parámetros de postmeta o shortcode que son aceptados por el plugin y luego evaluados por el servidor. El atacante planta un pequeño webshell que persiste en las cargas y se activa más tarde a través de una solicitud elaborada. Esto resulta en la ejecución arbitraria de comandos en el host.
- Escenario B: El plugin expone un punto final REST que no verifica correctamente la capacidad. Un script itera a través de sitios de WordPress, identifica el punto final y lo explota utilizando cuentas de Colaborador que se registran automáticamente o se compran de volcado de credenciales. La explotación escribe un backdoor PHP en el directorio del tema y lo utiliza para crear una cuenta de administrador.
Estos no son teóricos: el abuso de cuentas de colaboradores y puntos finales de plugins mal protegidos es un patrón común que observamos durante campañas de explotación masiva.
Guía de comunicación para propietarios y administradores de sitios
Si su sitio permite colaboradores externos, tome estos pasos para comunicarse internamente o externamente (si es necesario):
- Interno: Informe a sus equipos de editores y administradores de inmediato sobre la vulnerabilidad y las medidas temporales que está tomando (desactivación, restricciones de rol, aplicación de reglas WAF).
- Contribuidores: Si los flujos de trabajo de los colaboradores se ven afectados, explique la suspensión temporal de los derechos de publicación hasta que el sitio esté asegurado y acepte contenido a través de canales alternativos.
- Clientes / Partes interesadas: Si gestionas sitios para clientes, notifícales rápidamente sobre el riesgo y el plan de remediación. Si ocurrió un compromiso, sé transparente sobre la detección, contención y pasos de remediación.
Ten cuidado de no divulgar prematuramente detalles técnicos de explotación públicamente; compartir demasiado puede ayudar a los atacantes a crear exploits más específicos.
Proteja su sitio hoy mismo: comience con el plan gratuito de WP-Firewall.
Si buscas protección gestionada inmediata mientras actualizas y realizas la remediación, considera comenzar con el plan WP-Firewall Basic (Gratis). Nuestro plan gratuito proporciona las protecciones esenciales que necesita cada sitio de WordPress: un firewall gestionado con reglas WAF, ancho de banda ilimitado para tráfico de protección, un escáner de malware y mitigación para los riesgos del OWASP Top 10. Para sitios que necesitan eliminación automática o controles más estrictos, nuestros niveles de pago añaden eliminación automática de malware, listas negras/blancas de IP, informes mensuales, parches virtuales automáticos y servicios de seguridad totalmente gestionados.
Comienza ahora y aplica parches virtuales a tu sitio mientras aplicas actualizaciones permanentes.
Después de la remediación: postura de seguridad continua.
Parchear este plugin es necesario pero no suficiente. La seguridad es un proceso continuo:
- Mantén los plugins, temas y el núcleo de WordPress actualizados; establece una cadencia de mantenimiento.
- Usa entornos de staging para validar actualizaciones antes de implementarlas en producción.
- Audita regularmente los roles de usuario y reduce el número de cuentas con privilegios elevados.
- Mantén copias de seguridad automáticas y prueba los procedimientos de restauración.
- Suscríbete a feeds de vulnerabilidades y mantén un WAF con capacidades de parches virtuales para reducir las ventanas de exposición.
- Revisa los registros y alertas semanalmente; configura alertas por correo electrónico/SMS para eventos de alta gravedad.
En nuestra experiencia, los sitios que combinan parches oportunos con protecciones proactivas de WAF y higiene de roles son mucho menos propensos a ser completamente comprometidos durante las primeras semanas después de una divulgación pública.
Recomendaciones finales (lista de verificación práctica en la que puedes actuar en las próximas 24 horas).
- Verifica la versión del plugin. Actualiza a 5.00 o más reciente ahora si es posible.
- Si no puedes actualizar de inmediato: desactiva el plugin, restringe los inicios de sesión de los colaboradores y aplica reglas WAF.
- Realiza un escaneo completo de archivos y base de datos en busca de indicadores de compromiso.
- Rota credenciales y claves API si sospechas exposición.
- Preserva registros y copias de seguridad para la investigación si se sospecha explotación.
- Considera implementar nuestro plan WP-Firewall Basic (Gratis) para protección gestionada inmediata: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
- Después de eliminar la vulnerabilidad, adopte prácticas de endurecimiento a largo plazo: desactive el editor de archivos, no permita la ejecución de PHP en las cargas y reduzca los complementos innecesarios.
Acerca de este aviso
Este análisis está escrito por el equipo de seguridad de WP-Firewall para ayudar a los propietarios de sitios de WordPress, webmasters y desarrolladores a comprender y responder al problema de ejecución remota de código de Contributor autenticado en la Visibilidad de Contenido para Divi Builder (CVE-2026-1829). Nuestras recomendaciones son prácticas y están diseñadas para ser aplicadas por operadores de sitios con niveles comunes de acceso técnico. Si necesita asistencia práctica, nuestros planes gestionados incluyen respuesta a incidentes, limpieza y monitoreo continuo.
Si prefiere una mitigación inmediata y una remediación experta, explore las protecciones y servicios gestionados disponibles a través de WP-Firewall y asegure su sitio hoy: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Si necesita una lista de verificación de remediación personalizada para su sitio específico (tema, personalizaciones, entorno multisite), responda con:
- Versión de WordPress
- Versión del complemento de Visibilidad de Contenido para Divi Builder
- Tipo de alojamiento (compartido, VPS, gestionado)
- Si permite cuentas de contributor y cómo se registran
Prepararemos un plan a medida que cubra la mitigación de emergencia, los pasos de detección y un camino de actualización seguro.
