Amenaza del Storage Zone Controller de Progress ShareFile: Qué significa para el riesgo de almacenamiento de archivos en las instalaciones
Un aviso de seguridad de un solo proveedor obligó a organizaciones de todo el mundo a apagar físicamente los servidores de archivos que contienen parte de su contenido compartido más confidencial.
Progress Software envió un correo electrónico a los clientes de ShareFile el 10 de julio de 2026, advirtiendo sobre una «amenaza de seguridad externa creíble» dirigida a los Storage Zone Controllers, el componente de servidor local que permite a las empresas mantener archivos almacenados físicamente en su propia infraestructura mientras siguen usando la capa de intercambio en la nube de ShareFile, según Help Net Security. La instrucción fue clara: apaga inmediatamente los servidores Windows que alojan SZC y mantenlos apagados hasta nuevo aviso.
Para el 13 de julio, Progress había deshabilitado el acceso general a las cuentas de ShareFile como medida de precaución y reportó no tener evidencia de que algún atacante hubiera accedido a cuentas o archivos. La empresa también comenzó a restaurar gradualmente el acceso a la nube para los clientes que no dependen del componente de almacenamiento local.
Pero la recomendación principal no ha cambiado: si tu organización ejecuta un Storage Zone Controller, debe permanecer fuera de línea hasta que Progress indique lo contrario, y la vulnerabilidad subyacente sigue sin parchear ni confirmarse.
Esa combinación —una amenaza activa, una causa raíz sin resolver y sin parche disponible— es lo que hace que este incidente valga la pena analizar en detalle, incluso para organizaciones que no usan ShareFile. Kiteworks no estuvo involucrado en este incidente ni administra los datos de ShareFile de ninguna manera; ShareFile es una plataforma competidora e independiente.
A continuación, encontrarás el análisis de Kiteworks sobre los hechos reportados públicamente del incidente y por qué el patrón de exposición subyacente es algo a lo que las empresas que evalúan su arquitectura de transferencia e intercambio de archivos deben prestar mucha atención, especialmente la diferencia entre un servidor de almacenamiento operado por el cliente y una implementación reforzada y gestionada por el proveedor.
Puntos Clave
1. Progress deshabilitó el acceso a ShareFile Storage Zone Controller tras detectar una amenaza creíble. El proveedor envió un correo a los clientes el 10 de julio instruyéndoles apagar manualmente los servidores Windows que alojan sus implementaciones locales de Storage Zone Controller (SZC).
2. No se ha confirmado compromiso de datos según la última actualización, pero la investigación continúa. Progress indicó el 13 de julio que no tiene indicios de acceso no autorizado a cuentas o datos de ShareFile, pero aún solicita a los clientes mantener sus servidores SZC fuera de línea mientras se restaura gradualmente el acceso a la nube.
3. Es posible que dos CVE previamente divulgados se hayan encadenado para lograr ejecución remota de código antes de la autenticación. En discusiones de seguridad en línea se mencionan CVE-2026-2699 y CVE-2026-2701 como el mecanismo probable, aunque Progress no ha confirmado oficialmente la causa raíz.
4. La exposición está directamente en la infraestructura gestionada por el cliente, no en la nube de Progress. Los Storage Zone Controllers son servidores Windows locales que las organizaciones implementan, exponen a internet y actualizan por sí mismas, separados del servicio en la nube multi-tenant de ShareFile. Una evaluación de riesgos que inventarie cada componente de almacenamiento gestionado por el cliente y expuesto a internet —mapeado contra su estado de parches y exposición de firewall— es el primer paso que cualquier organización debería dar ante incidentes de esta clase.
5. Este es un patrón recurrente, no un evento aislado. Los componentes de almacenamiento e intercambio de archivos autogestionados y expuestos a internet han sido el punto de entrada en una serie de incidentes de alto perfil, y es exactamente el tipo de riesgo que una arquitectura reforzada y parcheada centralmente busca eliminar.
¿Cuáles son los mejores casos de uso de intercambio seguro de archivos en distintas industrias?
Descúbrelo ahora
Amenaza de seguridad en ShareFile Storage Zone Controller: ¿Qué ocurrió?
ShareFile es una plataforma ampliamente utilizada por empresas que necesitan almacenar e intercambiar archivos con partes externas —clientes, socios, contratistas, auditores—. La mayoría de las implementaciones de ShareFile funcionan completamente en la nube de Progress. Pero un subconjunto de clientes, normalmente aquellos con requisitos de residencia de datos, cumplimiento o rendimiento, utilizan Storage Zone Controllers: servidores Windows gestionados por el cliente que alojan el almacenamiento de archivos localmente mientras la interfaz en la nube de ShareFile gestiona el intercambio, permisos y colaboración.
Esa arquitectura crea un modelo de responsabilidad dividida. Progress actualiza y protege su propia infraestructura en la nube, pero el servidor SZC en sí —el sistema operativo, los binarios de la aplicación, la exposición de red, la frecuencia de parches— es responsabilidad del cliente. Cuando Progress envió el aviso del 10 de julio, no estaba pidiendo a los clientes que esperaran una solución. Les estaba pidiendo que desconectaran la máquina, porque al parecer Progress aún no podía cerrar la brecha por sí misma.
La actualización del 13 de julio suavizó un poco el tono. Progress dijo que su investigación no había encontrado indicios de acceso no autorizado a cuentas o datos de ShareFile, y comenzó a restaurar el acceso a la nube para los clientes que no ejecutan SZC.
Eso es una posición considerablemente mejor que la que alcanzan muchas divulgaciones en esta etapa. Pero el hecho de que los servidores SZC sigan con la instrucción de permanecer fuera de línea, días después de la advertencia inicial y sin una causa raíz confirmada publicada, habla por sí solo: sea cual sea la vía de vulnerabilidad, Progress no confía lo suficiente en una corrección o mitigación como para permitir que los clientes vuelvan a encender esos servidores.
Para una plataforma de la que dependen las empresas para mantener el intercambio de archivos externo sin interrupciones, «mantén el servidor apagado» es la recomendación más severa posible. Significa que el proveedor consideró la vía de explotación lo suficientemente grave como para que la exposición continuada superara el costo operativo de una interrupción de varios días para cada cliente afectado.
Storage Zone Controllers: Por qué el componente local es el eslabón más débil
La razón por la que este incidente se centra en los Storage Zone Controllers y no en el servicio en la nube de ShareFile se reduce a la arquitectura, y el mismo patrón aparece en todo el mercado de transferencia gestionada de archivos y de intercambio empresarial de archivos.
Los Storage Zone Controllers existen porque algunos clientes no quieren que su contenido de archivos resida únicamente en la nube multi-tenant de un proveedor. Tiene sentido: la residencia de datos, la regulación sectorial o la política interna pueden justificar mantener el almacenamiento de archivos localmente.
Pero esa decisión transfiere una parte significativa de la carga de seguridad al equipo de TI y seguridad del cliente. El servidor SZC debe actualizarse según el calendario del cliente, no el del proveedor. Debe ser protegido y monitorizado por los propios controles de acceso y herramientas de detección del cliente.
Y si está expuesto a internet —como ocurre en muchas implementaciones de SZC, por diseño, ya que las partes externas necesitan acceder a los archivos—, se convierte en un objetivo directamente accesible que queda fuera del refuerzo y la gestión de parches del proveedor.
Esto no es una crítica exclusiva a ShareFile. Es una característica estructural de cualquier producto en el que el proveedor entrega un componente de servidor autogestionado y deja la actualización, exposición y configuración en manos del cliente.
Una configuración de seguridad incorrecta o una ventana de parches perdida en un componente como este no pone en riesgo solo un archivo: pone en riesgo toda la zona de contenido que ese servidor fue diseñado para almacenar, porque normalmente la plataforma confía en ese servidor para operar en el perímetro de la red gestionando operaciones autenticadas de archivos.
La clasificación de datos aplicada al contenido almacenado en estas zonas —etiquetando qué archivos contienen datos regulados como información personal identificable, información de salud protegida o información confidencial empresarial— al menos permite identificar qué organizaciones enfrentan mayores obligaciones de notificación y remediación si se confirma el acceso al contenido del servidor.
La causa raíz sospechosa: CVE encadenados y ejecución remota de código antes de autenticación
Progress no ha publicado una causa raíz oficial hasta el momento, y esa distinción es importante. Lo que circula en la investigación de seguridad y en discusiones en línea es la teoría de que los atacantes encadenaron dos vulnerabilidades previamente divulgadas, identificadas como CVE-2026-2699 y CVE-2026-2701, para lograr ejecución remota de código antes de la autenticación contra servidores SZC expuestos a internet que no habían sido parchados contra ambas fallas.
La ejecución remota de código antes de la autenticación es de lo peor que puede haber en cuanto a vulnerabilidades. Significa que un atacante no necesita credenciales válidas, un token de sesión robado ni ningún acceso previo: puede alcanzar el servicio vulnerable directamente a través de la red y ejecutar código arbitrario en el servidor.
Si esa teoría se confirma, y la propia recomendación de Progress de apagar físicamente los servidores afectados es coherente con tomarse en serio una vía de RCE previa a la autenticación, entonces cualquier servidor SZC sin parches y accesible desde internet era un objetivo viable para cualquiera que lo encontrara mediante escaneos rutinarios.
Esto es lo que está realmente confirmado y lo que no. Progress ha confirmado la amenaza creíble, las suspensiones de cuentas y la instrucción de apagar los servidores SZC. No ha confirmado que CVE-2026-2699 y CVE-2026-2701 sean el mecanismo, ni si alguna explotación tuvo éxito en un entorno de cliente.
Las empresas deben tratar la teoría del encadenamiento de CVE como la principal hipótesis de trabajo en la comunidad de seguridad, no como una declaración oficial del proveedor, hasta que Progress publique sus propias conclusiones post-incidente.
Un patrón conocido: los servidores de archivos locales siguen siendo el punto de entrada
Si este incidente te resulta familiar, es porque la categoría de transferencia e intercambio empresarial de archivos ya ha vivido esto antes. Los servidores de transferencia e intercambio de archivos gestionados por el cliente y expuestos a internet se han convertido repetidamente en el punto de acceso inicial para campañas a gran escala, precisamente porque están diseñados para aceptar conexiones externas, suelen almacenar años de contenido sensible acumulado y no siempre se actualizan con la misma frecuencia que infraestructuras críticas como el correo electrónico o los sistemas de identidad.
El hilo común en estos incidentes no es un error de un solo proveedor. Es la arquitectura: un servidor independiente, expuesto a internet por diseño, actualizado según el calendario del cliente, ejecutando software que no fue construido bajo la suposición de que cada implementación enfrentaría intentos de explotación automatizados desde el primer día.
Cuando ese servidor se ve comprometido, el alcance del daño no es solo un buzón o un enlace compartido: es todo lo que el servidor tenía autorización para almacenar y transferir, que en la infraestructura de intercambio de archivos suele ser la información más sensible que una organización comparte con el exterior: contratos, registros financieros, información de salud protegida y datos regulados por marcos como GDPR o HIPAA.
Una filtración confirmada que implique un servidor de almacenamiento de archivos autogestionado con datos regulados desencadena obligaciones de notificación obligatoria: la exposición de cumplimiento se suma a la interrupción operativa.
Los equipos de seguridad que evalúan cualquier plataforma de intercambio de archivos, ya sea ShareFile u otra, deben plantear una pregunta directa sobre cada componente autogestionado en la arquitectura: ¿quién lo actualiza, con qué frecuencia y qué ocurre con los datos de ese componente si aparece una vulnerabilidad zero-day antes de que llegue el parche? La respuesta a esa pregunta es la verdadera medida de exposición, más allá de cualquier comparación de funcionalidades.
La categoría de transferencia e intercambio empresarial de archivos ya ha pasado por varias versiones ampliamente reportadas de esta misma historia: dispositivos o servidores autogestionados y expuestos a internet que fueron explotados mucho antes de que las organizaciones afectadas supieran siquiera que existía una vulnerabilidad.
Cada uno de esos incidentes involucró software que los clientes implementaron y operaron por sí mismos, expuesto a socios externos por diseño, y cada uno generó una carrera similar a la que experimentan ahora los clientes de ShareFile SZC: instrucciones de parcheo de emergencia, tiempo de inactividad forzado y una espera incómoda para confirmar si un atacante realmente accedió a algo.
Nada de ese historial dice nada específico sobre la causa del incidente actual de Progress. Pero sí explica por qué los equipos de seguridad tienden a tratar «servidor de archivos autogestionado y expuesto a internet» como una categoría de riesgo distinta y elevada, independientemente del nombre del proveedor.
Los programas de administración de riesgos de terceros que evalúan formalmente este tipo de riesgo —no solo el SLA en la nube del proveedor, sino los componentes gestionados por el cliente que el proveedor entrega junto con él— son el mecanismo de gobernanza que convierte este patrón de sorpresa recurrente en una exposición gestionada y documentada.
¿Qué deben hacer ahora las empresas que ejecutan ShareFile SZC?
Las organizaciones que actualmente ejecutan Storage Zone Controllers deben seguir directamente la guía de Progress en lugar de tomar una decisión de riesgo independiente. Eso significa mantener los servidores afectados apagados hasta que Progress confirme explícitamente que es seguro restaurarlos, monitorear los canales oficiales de comunicación de Progress en vez de depender de resúmenes de terceros y revisar los registros previos al apagado en busca de indicadores del patrón de RCE previa autenticación que la comunidad de seguridad ha señalado, aunque Progress no haya confirmado esa vía. Ingresar esos registros en una plataforma SIEM para correlacionarlos con indicadores conocidos de actores de amenazas es la forma más rápida de detectar si hubo accesos anómalos antes del apagado.
Más allá de la respuesta inmediata, este es un buen momento para que cualquier organización que gestione infraestructura de almacenamiento o transferencia de archivos autogestionada —ShareFile SZC u otra— inventarie cada servidor de esa categoría expuesto a internet, confirme el estado de parches contra todos los CVE conocidos y evalúe si los planes de respuesta a incidentes contemplan un escenario en el que la propia recomendación del proveedor sea «no tenemos solución aún, apágalo». No todas las organizaciones cuentan con un plan de respuesta a incidentes documentado que cubra una vulnerabilidad sin parche del proveedor y sin plazo de resolución, y este incidente es un buen detonante para cerrar esa brecha.
Los equipos de compras y gestión de riesgos de proveedores también deben participar en esta conversación, no solo operaciones de seguridad. Una amenaza creíble sin causa raíz confirmada ni parche disponible es tanto una cuestión contractual y de gobernanza como técnica: ¿qué dice el SLA del proveedor sobre los plazos de divulgación?, ¿la organización tiene una vía alternativa para compartir archivos con externos si la plataforma principal permanece fuera de línea por un periodo prolongado?, ¿y quién autoriza la reanudación de operaciones una vez que llega la solución?
Desarrollar esa capacidad ahora, antes de la próxima divulgación, es más barato que improvisarla bajo presión. Las políticas de gobernanza de datos que especifican qué categorías de contenido requieren una plataforma reforzada y parchada centralmente —en lugar de un componente gestionado por el cliente— dan a los equipos de compras los criterios necesarios para evaluar este equilibrio antes de que un aviso de amenaza creíble fuerce la conversación.
Cómo la arquitectura de Kiteworks reduce este tipo de exposición
Kiteworks no estuvo en la ruta de datos de este incidente. ShareFile es una plataforma de terceros que Kiteworks no opera, administra ni tiene visibilidad sobre ella, y nada de esto debe interpretarse como un comentario sobre las prácticas de ingeniería de Progress o su respuesta a incidentes, que según la cronología pública ha sido ágil y proactiva.
Lo que este incidente sí ilustra claramente es el perfil de riesgo de un servidor de almacenamiento local operado por el cliente y situado en el perímetro de la red, con el parcheo a cargo del cliente. Precisamente ese es el tipo de exposición que el intercambio seguro de archivos de Kiteworks y el modelo de dispositivo virtual reforzado de la plataforma Kiteworks están diseñados para eliminar. En lugar de un servidor Windows de propósito general ejecutando software de almacenamiento que los clientes actualizan a su ritmo, Kiteworks se entrega como un dispositivo reforzado de tenencia única con un sistema operativo bloqueado, una frecuencia de parches gestionada por el proveedor y sin superficie de ataque innecesaria expuesta a internet.
La gobernanza centralizada de accesos es la otra mitad de la ecuación. En vez de un servidor de almacenamiento independiente tomando sus propias decisiones de autorización en el perímetro de la red, Kiteworks enruta el acceso a archivos a través de una arquitectura de confianza cero unificada con controles de acceso basados en roles y políticas definidas centralmente, visibles en el CISO Dashboard y respaldadas por un registro de auditoría unificado que documenta cada acceso, intercambio y cambio de permisos en un solo lugar.
Las políticas de control de acceso basado en atributos (ABAC) evalúan el rol del usuario, la clasificación del contenido y el contexto de la solicitud en cada evento de acceso —asegurando que una sesión o credencial comprometida no pueda acceder silenciosamente a contenido fuera de su alcance autorizado. El contenido en reposo está protegido con cifrado validado FIPS 140-2, y las organizaciones que necesitan que los datos permanezcan en una jurisdicción específica pueden cumplir con ese requisito mediante opciones de implementación soportadas, sin tener que levantar un servidor de almacenamiento autogestionado y parchado por su cuenta.
Si el contenido confidencial de este escenario hubiera estado gobernado bajo ese modelo en vez de un Storage Zone Controller autogestionado de ShareFile, la arquitectura de parches y control de acceso descrita arriba aplicaría para reducir esta clase específica de exposición: un servidor gestionado por el cliente, expuesto a internet y con su propio calendario de parches independiente.
Esa afirmación depende de la configuración, frecuencia de parches y elecciones de implementación de cada organización dentro de Kiteworks, y no dice nada sobre la causa raíz que Progress confirme finalmente para este incidente. Ninguna plataforma es inmune a las vulnerabilidades; la pregunta relevante siempre es cuánta carga de parches y control de acceso recae en el proveedor frente al cliente, y cuán rápido y centralmente se puede abordar esa carga cuando surge una amenaza creíble.
La lección más amplia para líderes de seguridad y cumplimiento de datos
Este incidente sigue en desarrollo, y la lectura responsable hoy es mesurada: un proveedor detectó una amenaza creíble, actuó de forma decidida deshabilitando el acceso e instruyendo a los clientes a apagar los servidores afectados, y aún no ha encontrado evidencia de una filtración exitosa. Es una respuesta razonable ante una situación incierta, y Progress merece reconocimiento por actuar rápido tanto en la advertencia inicial como en el seguimiento.
La lección duradera para los equipos de seguridad y cumplimiento empresarial no trata de ShareFile en sí. Trata sobre el cálculo de riesgos detrás de cada decisión de operar un componente de almacenamiento o transferencia de archivos autogestionado y expuesto a internet en lugar de una plataforma reforzada y gestionada centralmente por el proveedor.
Los requisitos de residencia de datos y cumplimiento son reales y no desaparecen porque un servidor autogestionado implique más riesgo de parches. Lo que cambia es la pregunta que vale la pena hacer a cualquier proveedor antes de implementar: cuando —no si— surge una amenaza creíble contra este componente, ¿quién es responsable de cerrar la brecha y cuánto tiempo toma?
La administración de riesgos de terceros y de cadena de suministro ligada a la infraestructura de intercambio de archivos como esta es un área de enfoque creciente para los equipos de seguridad y cumplimiento, y es un tema analizado en el Informe Anual de Pronóstico de Riesgos de Seguridad y Cumplimiento de Datos 2026 de Kiteworks. Incidentes como este son un adelanto de por qué ese enfoque sigue intensificándose.
Para saber más sobre cómo reducir la exposición creada por servidores de almacenamiento de archivos autogestionados y expuestos a internet, solicita una demo personalizada hoy.
Preguntas frecuentes
Un Storage Zone Controller es un servidor Windows gestionado por el cliente que permite a un cliente de ShareFile almacenar archivos en su propia infraestructura mientras sigue usando la interfaz en la nube de ShareFile para intercambio y colaboración. Como el cliente, y no Progress, es responsable de actualizar y proteger ese servidor, se convirtió en el centro de este incidente una vez que Progress identificó una amenaza creíble dirigida a él. Este modelo de responsabilidad dividida aparece tanto en plataformas empresariales de intercambio de archivos como ShareFile como en productos de transferencia de archivos gestionada, y por eso los componentes locales tienden a tener más exposición directa que la propia infraestructura en la nube del proveedor. Las organizaciones que dependen de componentes de servidor de archivos autogestionados deben ampliar su revisión de administración de riesgos de terceros para evaluar explícitamente los componentes gestionados por el cliente junto con el servicio en la nube del proveedor: el SLA y la postura de seguridad de cada uno suelen ser diferentes, y este incidente demuestra que la brecha entre ambos puede ser decisiva.
Según la actualización del 13 de julio, Progress indicó que no tiene indicios de acceso no autorizado a ninguna cuenta o dato de ShareFile, y su investigación sigue en curso. Es una señal positiva, pero no una conclusión final: Progress sigue instruyendo a los clientes a mantener los Storage Zone Controllers fuera de línea, lo que sugiere que la vía de explotación subyacente sigue abierta. Las organizaciones deben dar seguimiento a esto a través de su propio proceso de administración de riesgos de proveedores y seguir las comunicaciones oficiales de Progress directamente en vez de depender de reportes de terceros para actualizaciones sobre este punto. Cualquier organización cuyo SZC almacenara datos regulados —información personal identificable, información de salud protegida o registros empresariales confidenciales— debe consultar ya con su asesoría legal si corresponde realizar una evaluación de notificación de filtración preventiva, dado que la investigación sigue abierta y aún no hay un alcance confirmado.
No. Esos dos CVE se han mencionado en discusiones de seguridad en línea como una posible vía de explotación encadenada capaz de ejecución remota de código antes de la autenticación contra servidores SZC sin parches, pero Progress no ha confirmado oficialmente esto como la causa raíz. Las empresas deben tratarlo como la principal teoría de trabajo y seguir monitoreando las divulgaciones oficiales de Progress para su confirmación, mientras aplican la precaución general de seguir la guía de respuesta a incidentes para cualquier componente con un perfil de exposición similar. Ingresar los registros de autenticación y acceso de SZC del periodo previo al apagado en un SIEM para correlación de anomalías es la forma más rápida de detectar si hay indicadores de explotación presentes, independientemente de cuál sea el mecanismo de CVE confirmado finalmente.
No. Kiteworks no estuvo en la ruta de datos de este incidente, y ShareFile es una plataforma independiente y competidora que Kiteworks no administra ni tiene acceso a ella. La relevancia para clientes y prospectos de Kiteworks es arquitectónica: este incidente resalta la categoría de riesgo asociada a servidores de almacenamiento de archivos autogestionados y locales, que es la exposición que una implementación reforzada, parchada por el proveedor y de tenencia única de intercambio seguro de archivos de Kiteworks está diseñada para reducir. La Red de Contenido Privado de Kiteworks proporciona la capa de gobernanza centralizada —controles de acceso unificados, registros de auditoría inmutables y parches gestionados por el proveedor— que elimina la brecha de responsabilidad dividida que este incidente ilustra.
Empieza por un inventario: identifica cada servidor de almacenamiento o transferencia de archivos gestionado por el cliente y expuesto a internet en el entorno, confirma el estado actual de parches y verifica que las reglas de firewall limiten la exposición solo a lo estrictamente necesario. Luego evalúa si el plan de respuesta a incidentes de la organización contempla un escenario en el que un proveedor divulga una amenaza creíble sin parche inmediato, ya que esa es precisamente la situación que enfrentan hoy los clientes de Progress. A largo plazo, compara la carga continua de parches y monitoreo de los componentes autogestionados frente a una alternativa reforzada y gobernada centralmente, basada en arquitectura de confianza cero y registros de auditoría unificados. Una evaluación de riesgos que modele explícitamente el escenario «el proveedor emite una amenaza creíble, sin parche disponible» para cada componente de servidor de archivos gestionado por el cliente —cuantificando el alcance del daño según la sensibilidad del contenido almacenado— da a la dirección la base de evidencia para priorizar la remediación arquitectónica sobre la autogestión continua.
Recursos adicionales
- Artículo del Blog
5 mejores soluciones de intercambio seguro de archivos para empresas - Artículo del Blog
Cómo compartir archivos de forma segura - Video
Kiteworks Snackable Bytes: Intercambio seguro de archivos - Artículo del Blog
12 requisitos esenciales para software de intercambio seguro de archivos - Artículo del Blog
Opciones más seguras de intercambio de archivos para empresas y cumplimiento