Los hackers están encadenando dos vulnerabilidades de SharePoint para tomar el control total del servidor
Una cadena de explotación de prueba de concepto contra Microsoft SharePoint Server en las instalaciones ya está siendo utilizada en ataques reales, y el tiempo entre «el investigador publica una técnica» y «el atacante la aprovecha» fue de un día. Ese es el plazo que reportó el investigador Defused para la CVE-2026-55040, la vulnerabilidad de omisión de autenticación en el centro de la última ola de explotación de SharePoint, según la cobertura de BleepingComputer.
La cadena combina dos fallos distintos. La CVE-2026-55040 es una omisión de autenticación mediante token JWT que permite a un atacante no autenticado actuar como usuario de un sitio SharePoint, o incluso como administrador del sitio, sin presentar credenciales válidas. La CVE-2026-63520 es una vulnerabilidad diferente en los Business Connectivity Services (BCS) de SharePoint que, una vez que el atacante ha eludido la autenticación, puede encadenarse para lograr la ejecución remota de código completa en un servidor sin parchear. Stephen Fewer de Rapid7 publicó el código de prueba de concepto para la CVE-2026-55040 el 11 de agosto. Jonathan Peterson de VulnCheck publicó el código de prueba de concepto para la CVE-2026-63520 el 24 de agosto. En aproximadamente dos semanas desde la primera divulgación, la industria ya tenía documentada una ruta funcional desde cero acceso hasta la ejecución de código en un servidor SharePoint.
Para cualquier organización que aún utilice SharePoint Server en las instalaciones para intercambiar, almacenar o colaborar con datos sensibles, esto no es una advertencia lejana para archivar. Es la confirmación de que la plataforma sigue siendo una superficie activa y viva para atacantes que entienden sus capas de autenticación e integración mejor que la mayoría de las organizaciones que la operan. La CVE-2026-55040 fue parcheada el 14 de julio de 2026, como parte de una oleada de correcciones de SharePoint Server que también generó cinco entradas en el catálogo de vulnerabilidades explotadas conocidas de CISA. El hecho de que el parche exista desde julio no impidió la explotación de prueba de concepto de este mes, porque aún hay instancias sin parchear accesibles, y porque la nueva vulnerabilidad revelada en BCS ofrece a los atacantes una vía adicional para convertir esa omisión antigua en una brecha total.
Este artículo explica qué hacen realmente las dos CVE, por qué el plazo de un día para la explotación importa más que la puntuación CVSS, y qué significa este patrón a nivel arquitectónico para CISOs y responsables de cumplimiento que deben demostrar, y no solo afirmar, que los datos sensibles que circulan por plataformas como el intercambio seguro de datos de Kiteworks permanecen bajo control sin importar lo que ocurra en infraestructuras adyacentes.
Conclusiones clave
1. Ahora existe una cadena de explotación funcional para SharePoint Server en las instalaciones.
La CVE-2026-55040 (omisión de autenticación JWT) y la CVE-2026-63520 (vulnerabilidad en Business Connectivity Services) pueden combinarse para pasar de cero acceso a ejecución remota de código en servidores sin parchear.
2. La explotación se produjo en aproximadamente un día.
El investigador Defused documentó que el código de prueba de concepto de la CVE-2026-55040 ya estaba siendo utilizado en ataques reales un día después de que Rapid7 lo publicara. La publicación y la explotación ahora son prácticamente simultáneas.
3. Parchear cierra la CVE. No cierra la arquitectura.
La CVE-2026-55040 se parcheó el 14 de julio de 2026, pero el patrón subyacente —omisión de autenticación encadenada a deserialización o ejecución remota de código en la capa de integración— sigue repitiéndose en SharePoint Server en las instalaciones porque la superficie de ataque de la plataforma es estructural.
4. Esto es SharePoint Server en las instalaciones, no SharePoint Online.
Confundir ambas es un error de hecho que lleva a las organizaciones a sacar conclusiones erróneas sobre su propia exposición; SharePoint Online no fue el objetivo de esta cadena de explotación.
5. La cuestión del cumplimiento importa tanto como la técnica.
Para CISOs y responsables de cumplimiento, el riesgo real no es solo la toma de control del servidor; es la incapacidad de aportar pruebas, cuando se requiera, de que el contenido sensible que pasó por una plataforma afectada permaneció autorizado, cifrado y registrado durante la ventana de exposición.
Qué hacen realmente la CVE-2026-55040 y la CVE-2026-63520
La CVE-2026-55040 reside en cómo SharePoint Server en las instalaciones valida la autenticación JWT (JSON Web Token). Una canalización de validación de tokens correctamente implementada debería hacer computacionalmente inviable que un tercero externo falsifique una sesión válida. Esta vulnerabilidad rompe esa suposición. Un atacante sin privilegios, sin credenciales válidas y sin acceso previo puede construir una solicitud que SharePoint Server trata como si viniera de un usuario legítimo del sitio o, en el peor de los casos, de un administrador. Es una omisión de autenticación completa, no una escalada de privilegios desde una cuenta de bajo nivel existente.
La CVE-2026-63520, calificada con CVSS 8.1 (Alta) según la explicación técnica de VulnCheck, se encuentra en otra parte de la plataforma, los Business Connectivity Services, la capa de integración que SharePoint utiliza para conectarse a fuentes de datos empresariales externas como bases de datos, sistemas ERP y aplicaciones personalizadas. La causa raíz es una instanciación insegura de un tipo .NET que permite a un atacante aprovechar una cadena de gadgets de deserialización basada en la clase System.Web.UI.LosFormatter para ejecutar código arbitrario en el servidor. BCS es potente por diseño; existe para que SharePoint lea y escriba datos en sistemas externos en nombre del usuario. Esa misma intención de diseño es lo que lo hace peligroso una vez que un atacante ya ha eludido la autenticación. Un componente creado para intermediar el acceso a sistemas externos, combinado con entrada controlada por el atacante, se convierte en una vía para la ejecución remota de código en el propio servidor.
Ninguna de las dos vulnerabilidades por sí sola es inusual. Las omisiones de autenticación y los fallos de deserialización o inyección en la capa de integración han aparecido repetidamente en plataformas de colaboración empresarial. Lo que hace significativa esta combinación es sencillo: la CVE-2026-55040 permite al atacante entrar sin necesidad de credenciales, y la CVE-2026-63520 le da una vía para ejecutar código una vez dentro. Por separado, cada una es un hallazgo grave. Encadenadas, representan una ruta completa y no autenticada hacia la toma del servidor, que es precisamente el tipo de hallazgo que primero aparece como prueba de concepto y luego, a menudo en cuestión de días, como campaña de explotación activa.
Confías en que tu organización es segura. Pero ¿puedes demostrarlo?
Lee ahora
De la prueba de concepto a la explotación real en días
El tiempo es el aspecto de esta historia que merece más atención que los números individuales de CVE. Stephen Fewer de Rapid7 publicó el código de prueba de concepto para la CVE-2026-55040 el 11 de agosto. Según el investigador Defused, ese código ya fue observado siendo aprovechado en ataques reales al día siguiente. Jonathan Peterson de VulnCheck publicó el código de prueba de concepto para la CVE-2026-63520 el 24 de agosto, proporcionando a los atacantes la segunda mitad de la cadena aproximadamente dos semanas después.
Esta aceleración no es nueva en 2026, pero sigue acortándose, y SharePoint Server en las instalaciones se ha convertido en un campo de pruebas recurrente para este fenómeno. Un parche que existe en el calendario de lanzamientos de Microsoft no sirve de nada si no se ha aplicado realmente, y la cadencia de Patch Tuesday nunca estuvo pensada para competir con una ventana de explotación en el mismo día. Los equipos de seguridad que tratan la publicación de una prueba de concepto como una señal para empezar a planificar el ciclo de parches, en la práctica, la están tratando como una señal que ya ha caducado cuando leen la advertencia.
Unit42 de Palo Alto Networks, al analizar la campaña de explotación «ToolShell» de SharePoint de 2025, una cadena anterior de omisión de autenticación a ejecución remota de código en la misma plataforma en las instalaciones, lo expresó claramente: «Parchear por sí solo no es suficiente para erradicar completamente la amenaza». Esa conclusión se alcanzó en el contexto de atacantes que, una vez dentro mediante una omisión de autenticación, se movieron lateralmente y en algunos casos robaron material de clave de máquina IIS, credenciales que sobreviven a un parche y a la eliminación de web shells porque nunca se rotaron. Es la misma lección que enseña la cadena de este mes. Un servidor puede estar completamente parcheado hoy y seguir comprometido si las credenciales tocadas por una intrusión anterior nunca se invalidaron. Parchear responde a «¿sigue siendo explotable esta vulnerabilidad específica?». No responde a «¿es este servidor, y todo lo conectado a él, aún confiable?».
Esto es un patrón, no un incidente aislado
Si ampliamos la perspectiva más allá de estas dos CVE, se observa un patrón en la historia reciente de SharePoint Server en las instalaciones: vulnerabilidades en autenticación y en la capa de integración, encadenadas, que producen ejecución remota de código sin autenticación, seguidas de una rápida explotación de prueba de concepto. La ola de julio de 2026 que parcheó la CVE-2026-55040 también generó la alerta de refuerzo de SharePoint de CISA del 14 de julio de 2026 y múltiples entradas en el catálogo de vulnerabilidades explotadas conocidas de CISA, cada una con su propio plazo de remediación medido en días, no meses. El análisis de Resecurity sobre esa cadena de ataques documentó una progresión desde el acceso inicial sin autenticación, pasando por la ejecución de código, la instalación de web shells, el robo de credenciales y el movimiento lateral hasta la toma del dominio.
La CVE-2026-63520 amplía esa misma historia estructural hacia una nueva superficie de integración. Es una ruta de código diferente a las vulnerabilidades de deserialización documentadas en julio, pero produce el mismo resultado mediante el mismo mecanismo general: una capa de autenticación que puede ser eludida, alimentando a un segundo componente que fue construido para confiar en solicitudes autenticadas y por tanto nunca fue reforzado contra entradas controladas por un atacante que llegan por una puerta principal rota. El FAQ de Tenable sobre las CVE relacionadas de SharePoint Server apunta en la misma dirección: no se trata tanto de errores aislados de codificación como de síntomas recurrentes de una plataforma donde autenticación, deserialización e integración tienen cada una su propia superficie de ataque, y donde una vulnerabilidad en cualquiera de ellas puede combinarse con otra para lograr una brecha total.
Para un CISO, la pregunta útil no es «¿parcheamos la CVE-2026-55040 y la CVE-2026-63520?». Es «¿cuántos componentes más en esta plataforma presentan el mismo tipo de riesgo, y cómo lo sabríamos antes de que la próxima prueba de concepto nos lo muestre?». Esa es una pregunta de arquitectura, no de gestión de parches, y no tiene una respuesta desde la gestión de parches.
Por qué parchear no cierra la brecha
Tres cosas son ciertas al mismo tiempo, y las organizaciones que solo se quedan con la primera son las que siguen expuestas meses después. Primero, Microsoft sí lanzó un parche para la CVE-2026-55040 el 14 de julio de 2026, y las organizaciones que lo aplicaron ya no son vulnerables a esa omisión específica. Segundo, la ventana de explotación de un día significa que cualquier organización que no hubiera aplicado el parche antes de que el código de prueba de concepto se hiciera público estuvo expuesta a explotación real casi de inmediato, sin periodo de advertencia entre «esto es teóricamente explotable» y «esto está siendo explotado». Tercero, y menos discutido, parchear una vulnerabilidad no invalida retroactivamente nada a lo que un atacante ya haya accedido, copiado o persistido durante una ventana de compromiso anterior.
Por eso, el lector de cumplimiento y auditoría tiene una pregunta diferente, y probablemente más urgente, que el lector de ingeniería de seguridad. La pregunta de seguridad es «¿está el servidor parcheado?». La pregunta de cumplimiento es «¿podemos aportar pruebas de que cada pieza de contenido sensible que tocó este servidor durante la ventana de exposición solo fue accedida por identidades autorizadas y, si no, tenemos un registro probatorio y de calidad de exactamente qué se expuso?». HIPAA, CMMC y ITAR no distinguen entre «fuimos vulnerados porque no parcheamos» y «fuimos vulnerados un día después de que el parche estuviera teóricamente disponible». Los reguladores, auditores y abogados de la parte contraria en litigios van a preguntar qué datos había en la plataforma, quién podía acceder y qué muestra la traza de auditoría. Un entorno de SharePoint Server en las instalaciones que requiere instrumentación personalizada para responder a esa pregunta parte con desventaja en cuanto ocurre un incidente como este.
La pregunta arquitectónica que deben hacerse los responsables de cumplimiento y seguridad
Kiteworks no estuvo literalmente en la ruta de datos de este incidente. SharePoint Server en las instalaciones es una plataforma nativa de Microsoft que Kiteworks no protege directamente, y nada de esto debe interpretarse como una afirmación de que Kiteworks habría evitado exactamente esta cadena de ataque. La alineación es arquitectónica, no contrafactual.
El intercambio seguro de datos de Kiteworks no expone una canalización de validación de tokens JWT como la explotada en la CVE-2026-55040, ni depende de una capa de integración tipo Business Connectivity Services para el acceso a datos. Cada solicitud de contenido, sea humana o de máquina, se media a través del Control Plane de Kiteworks, que aplica políticas por solicitud, en un modelo de confianza cero en vez de otorgar confianza duradera basada en sesiones a quien presente un token. Esa distinción importa precisamente porque los fallos de falsificación de tokens y confianza en sesiones son los que hicieron posible la cadena de explotación de este mes.
La capa de cumplimiento debajo de esa arquitectura importa tanto como la arquitectura misma. Kiteworks cuenta con la designación FedRAMP High In-Process y ha mantenido la autorización FedRAMP Moderate de forma continua desde 2017, nueve años consecutivos de validación de controles por terceros que el software gestionado por el cliente en las instalaciones no puede acreditar por sí solo; la autorización FedRAMP se aplica a un servicio gestionado, no a software que una organización implementa y asegura de forma independiente. Kiteworks también cumple con el 90% de los requisitos de CMMC Nivel 2 de forma nativa, utiliza cifrado validado FIPS 140-3 y mantiene certificaciones SOC 2 Tipo II e ISO 27001 junto con soporte para ITAR, HIPAA BAA, GDPR y CCPA. Nada de esto significa que Kiteworks sea inmune a toda categoría de vulnerabilidades; ninguna plataforma puede afirmar eso con honestidad. Es una declaración sobre qué categorías de superficie de ataque —omisión de JWT no autenticada y ejecución remota de código en la capa de integración encadenada a través de una plataforma de colaboración generalista— no aplican a cómo se diseñó Kiteworks.
Para las organizaciones que evalúan qué hacer con los flujos de trabajo sensibles que aún operan en SharePoint Server en las instalaciones, la pregunta práctica no es si abandonar SharePoint por completo. Es cuáles flujos de trabajo contienen contenido regulado o sensible que estarían mejor protegidos en una plataforma donde los controles de acceso, RBAC y el registro probatorio son nativos de la arquitectura y no añadidos después mediante instrumentación personalizada.
Qué deben hacer ahora las organizaciones reguladas
Confirma inmediatamente el estado de los parches para la CVE-2026-55040 y la CVE-2026-63520 si operas SharePoint Server 2016, 2019 o Subscription Edition en las instalaciones; esto no afecta a SharePoint Online. No te detengas en confirmar que el parche está aplicado. Rota las claves de máquina IIS y cualquier credencial a la que el servidor tuviera acceso, ya que el hallazgo de Unit42 de Palo Alto de que «parchear por sí solo no es suficiente para erradicar completamente la amenaza» se refería específicamente a la persistencia de credenciales y claves tras un parche. Revisa los registros de autenticación y de Business Connectivity Services para la ventana de exposición entre la divulgación inicial y la aplicación del parche, y trata cualquier brecha en ese registro como un hallazgo en sí mismo, no solo como una molestia técnica. Por último, haz un inventario de qué flujos de trabajo sensibles o regulados siguen operando en SharePoint Server en las instalaciones y evalúa si cada uno necesita la respuesta a incidentes y la carga probatoria que ahora implica esta plataforma, o si debería migrarse a una infraestructura diseñada desde cero para el intercambio de datos regulados y gobernados.
Para saber más sobre cómo mediar cada solicitud de datos mediante un Control Plane de confianza cero en lugar de una canalización de autenticación basada en sesiones, solicita una demo personalizada hoy.
Preguntas frecuentes
No. La CVE-2026-55040 y la CVE-2026-63520 afectan a SharePoint Server en las instalaciones, específicamente a las versiones 2016, 2019 y Subscription Edition que las organizaciones implementan y parchean por sí mismas. SharePoint Online es un servicio independiente gestionado por Microsoft y no fue el objetivo de esta cadena de explotación. Confundir ambas lleva a las organizaciones a reaccionar en exceso en una plataforma que no fue afectada o a subestimar el riesgo en una que sí lo fue. Aun así, las organizaciones deben evaluar SharePoint Online por separado por sus propias consideraciones de gobernanza de uso compartido externo, que es un tema distinto de la explotación de RCE en el lado del servidor.
El parche cierra la CVE-2026-55040 en sí, pero no revierte retroactivamente nada a lo que un atacante haya accedido antes de aplicarlo, ni resuelve la CVE-2026-63520, que es una vulnerabilidad distinta revelada posteriormente. La recomendación de Unit42 de Palo Alto sobre la ola de julio de 2026 fue explícita: parchear por sí solo no es suficiente para erradicar completamente una amenaza tras un acceso inicial; las organizaciones deben rotar las claves de máquina IIS y revisar los controles de acceso y los registros de autenticación que cubran la ventana previa a la aplicación del parche, no solo confirmar que el parche está instalado.
El intercambio seguro de datos de Kiteworks no utiliza la canalización de validación de tokens JWT explotada en la CVE-2026-55040, ni depende de una capa de integración tipo Business Connectivity Services para el acceso externo a datos. Cada solicitud se media a través del Control Plane de Kiteworks por solicitud. Esto es una comparación arquitectónica, no una afirmación de invulnerabilidad ante todas las posibles categorías de vulnerabilidades; ningún proveedor de software puede hacer esa afirmación con honestidad.
SharePoint Server en las instalaciones es un software gestionado por el cliente, lo que significa que no puede tener autorización FedRAMP por sí mismo; cada control debe ser implementado, instrumentado y evidenciado de forma independiente por la organización que lo despliega. Kiteworks cuenta con la designación FedRAMP High In-Process y ha mantenido la autorización FedRAMP Moderate de forma continua desde 2017. Esa distinción es relevante para organizaciones reguladas porque determina quién ya ha sido evaluado de forma independiente frente a una base de controles y quién debe demostrarlo por sí mismo tras un incidente como este.
Confirma si la CVE-2026-55040 y la CVE-2026-63520 están parcheadas y luego ve más allá del parche en sí. Revisa los registros de Business Connectivity Services y autenticación para la ventana de exposición, rota las claves de máquina IIS y cualquier credencial a la que el servidor pudiera acceder, y trata cualquier brecha de registro durante esa ventana como un hallazgo que requiere su propio plan de remediación. Las organizaciones que no tengan confianza en la integridad de su traza de auditoría para ese periodo deben asumir el peor escenario para fines de cumplimiento hasta que se demuestre lo contrario, ya que un regulador o auditor no aceptará «creemos que no pasó nada» como prueba.
Recursos adicionales
- Artículo del Blog Arquitectura Zero Trust: Nunca confíes, siempre verifica
- Video Microsoft GCC High: Desventajas que impulsan a los contratistas de defensa hacia ventajas más inteligentes
- Artículo del Blog Cómo proteger datos clasificados una vez que DSPM los identifica
- Artículo del Blog Generar confianza en IA generativa con un enfoque Zero Trust
- Video Guía definitiva para el almacenamiento seguro de datos sensibles para líderes de TI