Zimbra ya se explota sin credenciales: 10.1.20 corta la vía SNMP
El 21 de agosto de 2026, CISA incorporó CVE-2026-73570 a su catálogo de vulnerabilidades explotadas tras conocerse ataques contra Zimbra Collaboration. La cobertura de BleepingComputer recoge además el 24 de agosto como fecha límite de mitigación para las agencias federales civiles de Estados Unidos.
La entrada del 21 de agosto afecta a instalaciones anteriores a Zimbra Collaboration 10.1.20 que combinan el paquete opcional zimbra-snmp con las notificaciones SNMP habilitadas. La ficha de NVD confirma que una solicitud SMTP preparada puede ejecutar comandos sin autenticación como el usuario zimbra; actualizar cierra ese recorrido, pero no demuestra que un servidor expuesto antes del parche siga limpio.
Qué instalaciones quedan dentro del alcance
Una versión antigua no basta por sí sola para acreditar que el servidor era explotable mediante esta vulnerabilidad. Deben coincidir una versión anterior a 10.1.20, la instalación de zimbra-snmp y las notificaciones SNMP activadas. La presencia de otros componentes SNMP o de herramientas de monitorización no demuestra automáticamente que se cumpliera esa configuración.
En los sistemas afectados, los datos de una solicitud SMTP alcanzan el procesamiento de las notificaciones SNMP sin una neutralización suficiente. El atacante no necesita credenciales ni la intervención de un usuario del correo: puede provocar la ejecución de comandos del sistema operativo con los permisos de la cuenta zimbra.
Para reconstruir el alcance de la exposición importa la configuración que tenía cada nodo antes de actualizar, no solo su estado actual. Los datos decisivos son la versión que estuvo instalada, la presencia del paquete zimbra-snmp y el estado de las notificaciones SNMP durante ese periodo. Si la intervención ya se realizó, el historial del gestor de paquetes, las copias de configuración y los registros conservados pueden ayudar a reconstruirlos.
El parche cierra el fallo, no borra una intrusión anterior
Zimbra Collaboration 10.1.20 elimina la vulnerabilidad, de modo que las nuevas solicitudes ya no deberían recorrer la ruta de inyección descrita. Esa corrección modifica el software vulnerable, pero no elimina necesariamente archivos, procesos o mecanismos de persistencia que un atacante hubiera creado antes.
El aviso de CERT Polska recomienda examinar los últimos 30 días y señala rastros concretos para la búsqueda:
- Entradas de /var/log/zimbra.log con «Service status change» y cambios inesperados entre los estados detenido y activo, sobre todo si el campo destinado al servicio contiene una carga ajena a un nombre normal.
- Archivos creados por el usuario zimbra en /opt/zimbra/jetty/webapps/.
- Archivos recientes en /opt/zimbra/jetty_base/webapps/.
- Contenido creado por ese usuario en /tmp/.
Una coincidencia en esas rutas es un indicio que requiere análisis, no una prueba aislada del alcance completo del incidente. Conviene contrastar propietario, fecha, contenido y diferencias frente a una copia fiable, además de relacionar los archivos con los cambios de estado registrados. Del mismo modo, no encontrar una cadena exacta no permite declarar limpio un servidor si los registros se rotaron, se perdieron o pudieron ser alterados.
Cómo separar contención, actualización y búsqueda forense
La respuesta tiene tres objetivos distintos: detener la exposición, instalar la corrección y determinar si la vulnerabilidad ya fue utilizada. Confundirlos puede producir una falsa sensación de cierre: el parche resuelve la primera causa técnica, mientras que el análisis del periodo anterior responde a la pregunta de si hubo compromiso.
- Conservar, cuando sea posible sin prolongar el riesgo, la versión previa, la lista de paquetes, la configuración SNMP, los procesos activos y los registros disponibles.
- Actualizar cada nodo afectado a 10.1.20 o una versión posterior que incluya la corrección y verificar que la operación terminó correctamente.
- Preservar y revisar zimbra.log, los dos directorios webapps de Jetty y /tmp dentro del intervalo indicado por CERT Polska.
- Relacionar cambios de estado anómalos con archivos creados por zimbra y con procesos o conexiones que no pertenezcan a la operación habitual del servidor.
- Si aparecen indicios, aislar el nodo y tratarlo como un posible incidente. Eliminar un archivo sospechoso no determina por sí solo qué ejecutó el atacante ni si dejó otros accesos.
En una instalación distribuida, la conclusión debe establecerse por servidor. Dos nodos con la misma versión actual pueden haber tenido paquetes, configuración, exposición a Internet y conservación de registros diferentes. Una actualización centralizada tampoco prueba que el análisis forense se haya completado en todos ellos.
Qué acredita KEV y qué permanece sin respuesta
La inclusión en Known Exploited Vulnerabilities significa que existe evidencia de explotación real, no solo una posibilidad deducida del análisis del fallo. El vencimiento del 24 de agosto se aplica a los organismos federales civiles estadounidenses sujetos a la directiva correspondiente; no convierte esa fecha en un plazo legal universal para administradores de otros países.
Los avisos públicos permiten confirmar el vector SMTP, las condiciones ligadas a SNMP, la ejecución como usuario zimbra y la corrección en 10.1.20. No ofrecen, en cambio, una atribución fiable de toda la campaña, una lista exhaustiva de cargas maliciosas ni una cifra definitiva de organizaciones comprometidas.
El estado de la noticia es, por tanto, doble: la vulnerabilidad dispone de una corrección concreta, pero el riesgo histórico sigue abierto para los servidores que reunieron las condiciones afectadas antes de actualizar. En ellos, comprobar la versión 10.1.20 responde si el vector continúa disponible; revisar registros, directorios y procesos responde si alguien pudo aprovecharlo antes.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.