Una vulnerabilidad ya corregida en Zimbra Collaboration (ZCS) está siendo explotada activamente en el mundo real, según el CERT Polska. El problema se identificó como CVE-2026-73570 y se asocia con una inyección de comandos que puede terminar en ejecución remota de código (RCE).
Lo que hace especialmente delicada esta falla es que el acceso no requiere autenticación. En este artículo te explicamos qué significa, en qué condiciones aparece, cómo se solucionó y qué pistas concretas puedes revisar para detectar intentos de explotación.
Qué es la falla y por qué importa
La vulnerabilidad CVE-2026-73570 tiene un CVSS de 8.9, una severidad alta. El fallo se relaciona con el procesamiento de notificaciones SNMP cuando está instalado el paquete zimbra-snmp y dichas notificaciones se encuentran habilitadas.
De acuerdo con la descripción del problema en bases de datos públicas, el origen del riesgo está en una falta de saneamiento de datos no confiables durante el manejo de notificaciones. En la práctica, un atacante puede enviar solicitudes especialmente diseñadas y conseguir que se ejecuten comandos del sistema operativo bajo el usuario de Zimbra.
Condiciones para que exista exposición
No todos los entornos de Zimbra quedan afectados de la misma manera. El escenario de riesgo se centra en instalaciones donde se cumplen estas condiciones:
- Versiones de Zimbra anteriores a 10.1.20.
- El paquete opcional zimbra-snmp está instalado.
- Las notificaciones SNMP están habilitadas.
Si tu sistema cumple con lo anterior, el camino hacia una RCE sin autenticación se vuelve posible mediante entradas manipuladas durante el flujo de notificación.
Impacto: de inyección de comandos a ejecución remota
El núcleo del problema es una inyección de comandos. Es decir, parte de la información no confiable llega al proceso de notificación SNMP y, al no estar correctamente tratada, puede derivar en la ejecución de comandos arbitrarios en el sistema.
Además, se menciona un vector de interacción: un atacante puede remitir solicitudes SMTP especialmente preparadas para desencadenar el comportamiento. Así, aunque el fallo se conecte con SNMP, el abuso puede materializarse usando tráfico que involucra componentes relacionados.
El parche ya existe: versión 10.1.20
La corrección fue publicada por Zimbra. El parche se aplicó con el lanzamiento de la versión 10.1.20, presentada como la solución a la brecha detectada.
Por lo tanto, la recomendación operativa es clara: actualiza a una versión que incluya el fix y revisa que el sistema ya no esté en el rango vulnerable. En un incidente real, el tiempo entre el aviso y la mitigación suele marcar la diferencia.
Señales para detectar explotación activa
Según un boletín reciente de CERT Polska, ya se están observando esfuerzos dirigidos a esta falla. Para aumentar las probabilidades de detección temprana, el organismo sugiere revisar evidencia en los entornos afectados.
En concreto, recomiendan:
- Comprobar el archivo /var/log/zimbra.log en busca de reinicios o reinicios sospechosos del servicio de Zimbra.
- Verificar la creación de archivos en los siguientes directorios durante los últimos 30 días:
- /opt/zimbra/jetty/webapps/
- /opt/zimbra/jetty_base/webapps/
- /tmp/
Cuando existe explotación, a menudo se observan rastros como cambios en ubicaciones donde podrían desplegarse recursos o escribir artefactos temporales. Por eso, cruzar el registro de servicio con los directorios mencionados ayuda a priorizar la investigación.
Por qué los atacantes suelen apuntar a Zimbra
Este caso no surge en el vacío. En los últimos meses, las vulnerabilidades de Zimbra han sido objetivo recurrente de actores de amenaza. En particular, se ha reportado que campañas relacionadas con Zimbra aprovecharon vulnerabilidades para obtener acceso y recolectar información.
En un contexto previo, se divulgó una campaña de phishing orquestada por un adversario vinculado a Rusia, conocida como Laundry Bear (también citada como CL-STA-1114, TA488, UNK_PitStop, Void Blizzard). Allí, los detalles indicaron que se empleó una vulnerabilidad diferente para entregar un payload malicioso en entornos de correo.
Aunque el método y la técnica no son los mismos, el patrón es consistente: cuando una plataforma de correo colabora con servicios web y componentes adicionales, los atacantes buscan eslabones que les permitan escalar de entrada a impacto.
Qué revisar hoy en tu infraestructura
Si administras un servidor Zimbra y te preocupa la explotación de Zimbra SNMP sin autenticación, puedes convertir la alerta en un plan de acción. A continuación, un enfoque práctico para reducir el riesgo:
1) Confirma tu versión
Verifica si tu despliegue está por debajo de 10.1.20. Si lo está, prioriza la actualización. No esperes a que aparezcan indicadores de compromiso.
2) Revisa si zimbra-snmp está instalado
El paquete opcional es parte de las condiciones descritas. Si no lo necesitas, estudia alternativas para deshabilitar componentes que amplían superficie de ataque.
3) Comprueba el estado de notificaciones SNMP
Si las notificaciones están habilitadas, asegúrate de que el sistema esté corregido. En entornos donde SNMP sea necesario, mantén una vigilancia reforzada en el registro.
4) Audita los logs y directorios recomendados
Concentra tu revisión en /var/log/zimbra.log y en los directorios de los últimos 30 días: /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ y /tmp/. Busca combinaciones de eventos: reinicios del servicio + cambios de archivos + tiempos que coincidan.
Conclusión
La alerta de CERT Polska deja una idea central: la vulnerabilidad CVE-2026-73570 en Zimbra Collaboration ya está siendo explotada. El problema se relaciona con Zimbra SNMP sin autenticación bajo condiciones específicas (paquete zimbra-snmp instalado y notificaciones habilitadas) y puede culminar en ejecución remota de código mediante inyección de comandos.
La buena noticia es que el fix está disponible en Zimbra 10.1.20. A partir de ahí, lo más importante es completar la actualización, y luego validar con evidencia real: revisa /var/log/zimbra.log y analiza los directorios señalados en los últimos 30 días. Con ese enfoque, reduces el riesgo y mejoras tus probabilidades de detectar actividad maliciosa.
Fuente: https://thehackernews.com/2026/08/attackers-exploit-zimbra-snmp-flaw-for.html
