CVE-2026-56164: SharePoint on-premise bajo explotación activa

CVE-2026-56164 es una vulnerabilidad de autenticación ausente para una función crítica en Microsoft SharePoint Server on-premise que permite a un atacante no autenticado, por red y sin interacción del usuario, escalar privilegios. Los equipos de respuesta a incidentes de Mandiant y Google FLARE la descubrieron durante ataques reales, donde forma parte de una cadena que termina en ejecución remota de código. Con parche disponible desde el Patch Tuesday del 14 de julio de 2026 y presencia en el catálogo KEV de CISA, la explotación ya está confirmada y el plazo para actuar es corto.

Este aviso de Secra resume qué es CVE-2026-56164, cómo se encadena con otras dos vulnerabilidades para lograr acceso no autorizado y ejecución de código, qué versiones de SharePoint afecta, por qué el parcheo tiene una trampa específica en las granjas SharePoint, cómo detectar compromiso y qué medidas priorizar. No incluye código de explotación: el objetivo es defensivo.

Lo esencial sobre CVE-2026-56164

• Vulnerabilidad de autenticación ausente para una función crítica en SharePoint Server: permite escalar privilegios sin autenticación, por red y sin interacción del usuario.
• Descubierta por Mandiant y Google FLARE durante ataques reales, no en un laboratorio.
• Se explota encadenada con CVE-2026-32201 y CVE-2026-45659 para obtener RCE, desplegar web shells, robar las machine keys de IIS y desplegar malware.
• Afecta a SharePoint Server on-premise (2016, 2019 y Subscription Edition). SharePoint Online no se ve afectado.
• Microsoft publicó el parche en el Patch Tuesday del 14 de julio de 2026 y CISA lo añadió a su catálogo KEV con plazo federal corto.
• Parchear no basta: hay que confirmar la actualización específica de SharePoint en cada servidor y rotar las machine keys robadas para cortar la persistencia.

Qué es CVE-2026-56164

CVE-2026-56164 es una vulnerabilidad de autenticación ausente para una función crítica en Microsoft SharePoint Server. En términos llanos, existe una funcionalidad sensible del producto que debería exigir autenticación y no la exige. Un atacante remoto, sin credenciales y sin engañar a ningún usuario, puede invocar esa función y escalar privilegios dentro del sistema.

La vía de acceso es la red, el privilegio requerido es nulo y no hace falta interacción del usuario. Ese perfil (sin autenticación, sin interacción, explotable en remoto) es justo el que convierte una vulnerabilidad en candidata a explotación masiva y automatizada, porque elimina las barreras que normalmente ralentizan a un atacante. Si quieres repasar cómo se cataloga y prioriza un fallo así, lo explicamos en qué es un CVE.

Lo distintivo de este caso es su origen: no procede de un investigador que reporta un hallazgo teórico, sino de los equipos de respuesta a incidentes de Mandiant y Google FLARE, que la identificaron analizando ataques reales. Cuando una vulnerabilidad se descubre así, la conclusión operativa es inmediata: la explotación ya estaba en marcha antes de que existiera el aviso público.

La cadena de explotación

CVE-2026-56164 no se usa en solitario. Los atacantes la encadenan con CVE-2026-32201 y CVE-2026-45659 para construir un ataque completo de extremo a extremo. La lógica de encadenar vulnerabilidades es la misma que estudiamos en cualquier auditoría ofensiva: un fallo aislado suele tener un techo de impacto, pero varios combinados escalan hasta el control total del servidor.

De la autenticación ausente al acceso no autorizado

El punto de entrada es la ausencia de autenticación. Al no exigir credenciales para una función crítica, CVE-2026-56164 entrega a un atacante anónimo un acceso que en condiciones normales estaría reservado a usuarios autenticados. Esa escalada de privilegios es la palanca que abre la puerta al resto de la cadena.

De acceso no autorizado a ejecución remota de código

Combinando ese acceso con las otras dos vulnerabilidades, los atacantes logran ejecución remota de código (RCE) sobre el servidor SharePoint. La ejecución de código en el servidor web es el punto de inflexión de cualquier compromiso: a partir de ahí, el atacante deja de estar limitado a lo que la aplicación expone y empieza a operar con el contexto del propio servidor.

Persistencia: web shells y robo de machine keys

Una vez dentro, la actividad observada sigue un patrón conocido y especialmente peligroso:

• Despliegue de web shells: ficheros .aspx maliciosos que dan al atacante una consola remota persistente sobre el servidor. Es el mismo desenlace que analizamos en subida de archivos insegura: de web shell a RCE; una web shell instalada por esta vía se comporta después como cualquier backdoor.
• Robo de las machine keys de IIS: las claves de máquina de ASP.NET (ValidationKey y DecryptionKey) que SharePoint usa para firmar y cifrar el ViewState. Robarlas es lo que hace este ataque distinto de un compromiso corriente.
• Despliegue de malware adicional para afianzar el acceso.

El robo de las machine keys merece una explicación propia porque es la raíz de la persistencia a largo plazo. Con las claves ValidationKey y DecryptionKey en su poder, un atacante puede falsificar objetos ViewState válidos y firmarlos como si procedieran del propio servidor. SharePoint los deserializa confiando en ellos, y esa deserialización se convierte en un canal de ejecución de código que funciona incluso después de aplicar el parche. Dicho de otro modo: parchear la vulnerabilidad de acceso cierra la puerta de entrada, pero no invalida una llave que el atacante ya copió.

Esta dinámica recuerda de forma directa a la oleada "ToolShell" que golpeó a SharePoint en 2025, donde el robo de claves criptográficas fue precisamente el mecanismo que permitió a los atacantes mantenerse dentro de las granjas comprometidas pese a los parches. La lección de aquel episodio, que rotar las claves es tan obligatorio como parchear, vuelve a aplicarse aquí.

Versiones afectadas

CVE-2026-56164 afecta a SharePoint Server en su modalidad on-premise:

El matiz es importante para acotar el alcance en tu organización: las cargas de SharePoint que viven en Microsoft 365 (SharePoint Online) quedan fuera del problema. El riesgo se concentra en las granjas SharePoint que la organización opera sobre su propia infraestructura, que suelen ser sistemas internos con alto valor (documentación corporativa, intranets, flujos de negocio) y, con frecuencia, con ciclos de parcheo más lentos que los servicios en la nube.

Severidad y estado de explotación

Sobre la severidad conviene ser preciso. Microsoft y CISA tratan esta vulnerabilidad como crítica y explotada activamente. En lugar de fijarnos en una puntuación numérica exacta, lo relevante para priorizar es el conjunto de hechos verificados: se descubrió analizando ataques reales, se encadena para lograr RCE sin autenticación y CISA la incorporó a su catálogo KEV (Known Exploited Vulnerabilities), reservado a vulnerabilidades con explotación confirmada.

La inclusión en el KEV no es un detalle burocrático. Conlleva un plazo federal corto de remediación para las agencias estadounidenses y funciona, para cualquier organización, como una señal inequívoca de máxima prioridad: si algo está en el KEV, tiene explotación confirmada en el mundo real. Es la diferencia entre severidad teórica y explotabilidad real que marca la priorización de cualquier programa de parcheo serio.

El parcheo tiene una trampa: cómo se remedia una granja SharePoint

Aquí está el punto donde muchas organizaciones se equivocan y quedan expuestas creyéndose seguras. Microsoft publicó la corrección en el Patch Tuesday del 14 de julio de 2026, pero aplicar el parche en una granja SharePoint no funciona como una actualización de Windows corriente.

Desplegar la actualización de Windows no remedia SharePoint

SharePoint tiene su propio proceso de servicing. Desplegar únicamente la actualización acumulativa de Windows a través de los mecanismos habituales de parcheo no remedia una granja SharePoint. La actualización específica de SharePoint debe instalarse y, después, completarse el proceso de servicing que aplica los cambios a la configuración de la granja. Si te quedas en el paso de Windows, el binario puede parecer actualizado mientras la vulnerabilidad sigue viva.

Confirmar y validar en cada servidor

Por eso hay que confirmar y validar la actualización específica de SharePoint en cada servidor de la granja, no dar por hecho que un despliegue centralizado la aplicó. En una granja con varios servidores frontend y de aplicaciones, basta con que uno quede sin actualizar para que la superficie siga abierta. La verificación servidor a servidor es tediosa, pero es exactamente lo que separa una granja realmente parcheada de una que solo lo parece.

Rotar las machine keys de IIS y ASP.NET

Y hay un paso que no puede omitirse aunque el parche esté correctamente aplicado: rotar las machine keys de IIS y ASP.NET después de parchear. Como explicamos antes, unas claves robadas permiten falsificar ViewState y mantener la persistencia incluso en un servidor ya parcheado. Rotar las claves invalida las que el atacante pudiera haber copiado y cierra ese canal de persistencia. Si tu granja estuvo expuesta sin parchear durante la ventana de explotación, la rotación de claves no es opcional: es parte del remediado.

Cómo detectar exposición y compromiso

La detección tiene dos planos: saber si eres vulnerable y saber si ya te han comprometido.

Identificar exposición:

• Inventaría todas las granjas y servidores SharePoint on-premise de la organización, incluidas instancias departamentales o heredadas que ningún equipo reclama. El descubrimiento continuo con un programa de gestión de la superficie de ataque (ASM y EASM) es lo que evita que una granja olvidada quede sin parchear.
• Confirma, servidor a servidor, que la actualización específica de SharePoint del 14 de julio de 2026 está instalada y que el proceso de servicing se completó.
• Comprueba si alguna granja estuvo expuesta a internet sin el parche durante la ventana de explotación.

Buscar indicios de compromiso (threat hunting):

• Web shells: ficheros .aspx sospechosos, especialmente en los directorios LAYOUTS de SharePoint. Cualquier .aspx que no forme parte de la distribución oficial o que aparezca con fechas de modificación recientes merece investigación inmediata.
• Robo de machine keys: accesos o lecturas anómalas de la configuración donde residen las claves de ASP.NET, y cualquier señal de que las claves hayan podido exfiltrarse.
• Peticiones anómalas a la función crítica afectada y patrones de acceso inusuales en los logs de IIS y de SharePoint.
• Cuentas, tareas programadas o servicios nuevos e inesperados, y conexiones salientes anómalas desde los servidores de la granja.

Un punto crítico: parchear no expulsa a un atacante que ya entró. Si una granja estuvo expuesta y sin parchear durante la ventana de explotación, hay que asumir compromiso e investigar en consecuencia, en lugar de limitarse a actualizar. Con las machine keys potencialmente robadas, esa suposición de compromiso es especialmente prudente.

Mitigaciones prioritarias

Acción uno: instalar la actualización específica de SharePoint

Aplica la actualización de SharePoint del Patch Tuesday del 14 de julio de 2026 y completa el proceso de servicing. Recuerda que desplegar solo la actualización acumulativa de Windows no remedia la granja. Es la medida prioritaria y no admite demora dado que la explotación está confirmada.

Acción dos: confirmar servidor a servidor

Valida en cada servidor de cada granja que la actualización de SharePoint quedó instalada y aplicada. No des por hecho que un despliegue centralizado lo hizo por ti; una única máquina sin parchear reabre toda la superficie.

Acción tres: rotar las machine keys

Tras parchear, rota las machine keys de IIS y ASP.NET. Es lo único que invalida unas claves potencialmente robadas y corta la persistencia vía ViewState falsificado. Este paso es obligatorio si hubo exposición, no una precaución opcional.

Acción cuatro: reducir la exposición y filtrar en el borde

Mientras completas el remediado, limita la exposición a internet de las granjas SharePoint on-premise que no la necesiten y usa el filtrado en el borde para reducir la superficie accesible. Un WAF bien configurado ayuda a mitigar temporalmente ciertos vectores, aunque nunca sustituye a parchear y rotar claves.

Acción cinco: investigar si hubo exposición

Si alguna granja estuvo accesible sin parchear, activa el procedimiento de respuesta: threat hunting retrospectivo en busca de web shells y accesos a las claves, revisión de integridad de los servidores, rotación de credenciales y contención de cualquier artefacto encontrado. Un simple parche no elimina una web shell ya instalada.

Encaje con la gestión de vulnerabilidades

CVE-2026-56164 es un caso de manual sobre por qué un programa de gestión de vulnerabilidades con SLA de parcheo y verificación real importa. La vulnerabilidad ilustra varios principios que resumimos cada mes en nuestro repaso de vulnerabilidades críticas del Patch Tuesday:

• Explotación antes del aviso: descubierta analizando ataques reales, la ventana de exposición empezó antes de que el parche existiera. Eso obliga a tratar toda granja SharePoint expuesta como potencialmente comprometida.
• Parchear no es un solo paso: la trampa del servicing de SharePoint demuestra que "aplicamos los parches" no equivale a "estamos parcheados". La verificación servidor a servidor es el control que cierra esa brecha.
• La persistencia sobrevive al parche: el robo de machine keys, igual que en la cadena wp2shell y otras oleadas de RCE que analizamos en wp2shell (CVE-2026-63030), muestra que remediar incluye erradicar la persistencia, no solo cerrar el fallo.
• Inventario y KEV: la inclusión en el catálogo KEV de CISA convierte esto en prioridad máxima. Un inventario completo de la superficie es lo que permite actuar dentro del plazo.

Preguntas frecuentes

¿Estoy afectado si uso SharePoint Online en Microsoft 365?

No. CVE-2026-56164 afecta a SharePoint Server on-premise (2016, 2019 y Subscription Edition). SharePoint Online no se ve afectado. El riesgo se concentra en las granjas que tu organización opera sobre su propia infraestructura.

¿Basta con desplegar el Patch Tuesday de Windows para quedar protegido?

No. SharePoint tiene su propio proceso de servicing y desplegar únicamente la actualización acumulativa de Windows no remedia una granja SharePoint. Hay que instalar la actualización específica de SharePoint, completar el servicing y confirmarlo en cada servidor.

¿Por qué debo rotar las machine keys si ya he parcheado?

Porque unas machine keys robadas permiten falsificar objetos ViewState y mantener la persistencia mediante deserialización incluso después de aplicar el parche. Parchear cierra la vía de entrada, pero no invalida una clave que el atacante ya copió. Rotarlas corta esa persistencia.

¿Cómo sé si mi granja SharePoint ya ha sido comprometida?

Busca web shells (ficheros .aspx sospechosos, especialmente en los directorios LAYOUTS), señales de robo de las machine keys de ASP.NET, peticiones anómalas a la función afectada y cuentas o servicios inesperados. Si la granja estuvo expuesta sin parchear durante la ventana de explotación, asume compromiso e investiga.

¿Qué significa que CISA lo haya añadido al catálogo KEV?

El catálogo KEV recoge vulnerabilidades con explotación confirmada en el mundo real. La inclusión conlleva un plazo federal corto de remediación para las agencias estadounidenses y, para cualquier organización, es una señal de máxima prioridad: si está en el KEV, tiene explotación confirmada en el mundo real.

¿Tiene relación con la oleada "ToolShell" de 2025?

CVE-2026-56164 recuerda a la oleada "ToolShell" que golpeó a SharePoint en 2025, sobre todo por el robo de material criptográfico (las machine keys) para mantener persistencia pese a los parches. El patrón de encadenar acceso, RCE y robo de claves es el mismo, y la lección también: rotar las claves es tan obligatorio como parchear.

Recursos relacionados

• Qué es un CVE: cómo se referencia y prioriza una vulnerabilidad como CVE-2026-56164.
• wp2shell: RCE sin autenticación en WordPress: otra cadena de RCE reciente donde el encadenamiento y la persistencia marcan el impacto.
• Subida de archivos insegura: de web shell a RCE: el desenlace típico de una ejecución de código en un servidor web.
• Qué es un backdoor: tipos y detección: cómo se comportan las web shells persistentes desplegadas en la cadena.
• Qué es un WAF: filtrado en el borde como mitigación temporal mientras se parchea.
• Gestión de la superficie de ataque (ASM y EASM): descubrir granjas SharePoint expuestas antes que el atacante.
• Patch Tuesday: repaso de vulnerabilidades críticas: cómo priorizar el parcheo mes a mes.

Evaluación de exposición a CVE-2026-56164 con Secra

Secra es una empresa de ciberseguridad ofensiva con un programa interno de investigación de vulnerabilidades y advisories propios publicados en NVD e INCIBE-CERT (CVE-2025-40652 en CoverManager y CVE-2023-3512 en Setelsa ConacWin CB, entre otros). Esa disciplina de descubrimiento aplicada a tu superficie expuesta es lo que separa detectar una exposición a CVE-2026-56164 antes o después del incidente.

Ayudamos a organizaciones a evaluar su exposición real: inventario y descubrimiento continuo de granjas SharePoint on-premise, verificación servidor a servidor del parcheo y del servicing, revisión de la rotación de machine keys, threat hunting retrospectivo de web shells y robo de claves y, cuando procede, intervención de respuesta a incidentes. Escríbenos a través de contacto.