6 min. de lectura<\/p>\n
Una vulnerabilidad cr\u00edtica en Splunk Enterprise permite a los atacantes crear y eliminar archivos en el servidor sin necesidad de autenticaci\u00f3n. La agencia estadounidense CISA la incluye en su lista de vulnerabilidades explotadas activamente desde el 18 de junio. M\u00e1s de 1.400 instancias est\u00e1n expuestas p\u00fablicamente en internet en todo el mundo, 223 de ellas en Europa.<\/strong><\/p>\n Lo m\u00e1s importante en resumen<\/p>\n Relacionado:<\/span>Priorizaci\u00f3n de parches: por qu\u00e9 CVSS por s\u00ed solo frena tu SOC<\/a> \/<\/span> Ingenier\u00eda de detecci\u00f3n sin bloqueo de proveedor<\/a><\/p>\n \u00bfQu\u00e9 es CVE-2026-20253?<\/strong> Una vulnerabilidad cr\u00edtica en el sidecar de PostgreSQL de Splunk Enterprise. Elude la autenticaci\u00f3n, lo que permite a los atacantes crear y eliminar archivos en el servidor sin necesidad de iniciar sesi\u00f3n. El valor CVSS es de 9,8 sobre 10.<\/p>\n Splunk Enterprise ha incluido un sidecar de PostgreSQL desde hace varias versiones. Este servicio se ejecuta junto al proceso principal de Splunk y proporciona una base de datos relacional, entre otros componentes, al Edge Processor, al protocolo de telemetr\u00eda OpAmp y a las pipelines de datos SPL2. Ah\u00ed es exactamente donde se encuentra el error.<\/p>\n CVE-2026-20253 consiste en la falta de una comprobaci\u00f3n de autenticaci\u00f3n. Un atacante no necesita iniciar sesi\u00f3n, no requiere tener una cuenta ni presentar una sesi\u00f3n v\u00e1lida. Puede crear y eliminar archivos en el sistema a trav\u00e9s del servicio expuesto.<\/p>\n Puede parecer menos grave que una ejecuci\u00f3n remota de c\u00f3digo cl\u00e1sica. Sin embargo, el potencial de da\u00f1o sigue siendo alto. Quien pueda crear y eliminar archivos sin autenticaci\u00f3n tiene la capacidad de inutilizar componentes o eliminar registros. Dependiendo del entorno, este tipo de acceso puede escalar hacia ataques m\u00e1s complejos. El valor CVSS de 9,8 sobre 10 clasifica la vulnerabilidad como cr\u00edtica, principalmente debido a la facilidad con la que puede explotarse sin necesidad de autenticaci\u00f3n.<\/p>\n La escalada tuvo lugar en pocos d\u00edas. El equipo de respuesta a incidentes de seguridad de Splunk (Splunk Product Security Incident Response Team) confirm\u00f3 los primeros ataques ya a principios de junio. El punto de inflexi\u00f3n lo marc\u00f3 la publicaci\u00f3n p\u00fablica de un concepto de prueba.<\/p>\n Ses d\u00edas entre el exploit p\u00fablico y el registro en KEV son una ventana muy estrecha. Tan pronto como circula un concepto de prueba, se reduce dr\u00e1sticamente el umbral para escaneos masivos contra sistemas expuestos. Quien espere al siguiente ciclo de mantenimiento regular, planea demasiado tarde.<\/p>\n Splunk recopila logs del conjunto completo de la red, por lo que suele estar ampliamente distribuido. Una parte de las instancias est\u00e1 directamente conectada a Internet, a menudo por comodidad en entornos distribuidos.<\/p>\n Cada una de estas instancias expuestas es un objetivo directo. Incluso los servidores accesibles internamente siguen siendo vulnerables tan pronto como alguien tenga acceso a la red, por ejemplo tras un ataque de phishing. La exposici\u00f3n a Internet debe cerrarse primero, seguida inmediatamente de las instancias internas.<\/p>\n La prioridad es clara. Splunk proporciona un parche. El informe de seguridad de Splunk sobre CVE-2026-20253 indica qu\u00e9 versiones afectadas hay y desde cu\u00e1l versi\u00f3n se cierra la brecha. Quien gestione Splunk Enterprise compara su estado de versiones con este informe y aplica la actualizaci\u00f3n. Esta es la \u00fanica medida que cierra realmente la brecha.<\/p>\n Si no es posible actualizar de inmediato, queda el recurso de emergencia: deshabilitar el PostgreSQL-Sidecar. Esto detiene el servicio vulnerable, pero tiene un costo. Edge Processor, OpAmp y las pipelines de datos SPL2 dejar\u00e1n de funcionar. Para muchas entornos, esto representa una p\u00e9rdida significativa de funcionalidad, apta solo como soluci\u00f3n temporal.<\/p>\n Independientemente del estado del parche, la exposici\u00f3n a Internet debe someterse a revisi\u00f3n. En la pr\u00e1ctica, rara vez hay raz\u00f3n para que un SIEM est\u00e9 expuesto directamente a Internet. Limitar el acceso a redes internas y a un VPN reduce inmediatamente la superficie de ataque.<\/p>\n Todo el conjunto de reglas de detecci\u00f3n se basa en los logs del SIEM. Este sistema recoge los registros de todo el red en un \u00fanico lugar. Si esta plataforma falla o es manipulada, el SOC pierde su fuente m\u00e1s importante de visi\u00f3n.<\/p>\n La posibilidad de borrar archivos agrava la situaci\u00f3n. Un atacante que elimine los registros borra sus huellas precisamente donde normalmente se detectar\u00edan. Una brecha en el sistema de detecci\u00f3n es por tanto m\u00e1s peligrosa que la misma brecha en un sistema perif\u00e9rico. Esta brecha afecta a la instancia que deber\u00eda alertar sobre el ataque.<\/p>\n Para la pr\u00e1ctica, esto significa: esta debilidad no es un parche com\u00fan entre muchos. Se refiere a la componente de la que depende la credibilidad de todas las dem\u00e1s alarmas.<\/p>\n La vulnerabilidad en el Sidecar de PostgreSQL de Splunk Enterprise evita la autenticaci\u00f3n. Un atacante puede crear y borrar archivos en el sistema sin datos de acceso v\u00e1lidos. Dependiendo del entorno, esto puede paralizar componentes o eliminar registros.<\/p>\n S\u00ed. La fecha l\u00edmite de CISA solo obliga a las autoridades federales estadounidenses, pero el riesgo t\u00e9cnico es id\u00e9ntico en cualquier lugar. Splunk est\u00e1 en uso en muchos SOC de DACH, y las 223 instancias expuestas en Europa muestran que tambi\u00e9n aqu\u00ed hay sistemas abiertos. Quien opera Splunk debe tratar el 21 de junio como una fecha l\u00edmite propia.<\/p>\n Splunk recomienda como medida intermedia desactivar el servicio del Sidecar de PostgreSQL. Con ello se detiene el servicio vulnerable, aunque caen fuera de funcionamiento los procesadores de borde, OpAmp y las pipelines de datos SPL2. Esta medida solo est\u00e1 pensada como soluci\u00f3n de emergencia hasta que se aplica el parche.<\/p>\n El indicador m\u00e1s r\u00e1pido es la accesibilidad desde el exterior: compruebe si el servicio del Sidecar de PostgreSQL responde desde Internet o desde segmentos no confiables. Dado que desde el 12 de junio existe un exploit p\u00fablico, toda instalaci\u00f3n expuesta corre un riesgo inminente. El Splunk Advisory menciona reglas concretas de detecci\u00f3n basadas en patrones de ataque confirmados; adem\u00e1s, conviene revisar los logs en busca de operaciones inesperadas con archivos.<\/p>\n El SIEM proporciona los registros para cada detecci\u00f3n. Si se manipula, al equipo de seguridad le falta visi\u00f3n sobre su propia red. Como la vulnerabilidad tambi\u00e9n permite borrar archivos, un atacante puede eliminar sus huellas precisamente donde deber\u00edan detectarse.<\/p>\n\n
Qu\u00e9 hace t\u00e9cnicamente posible la vulnerabilidad<\/h2>\n
De un concepto de prueba a su explotaci\u00f3n activa<\/h2>\n
\u00bfCu\u00e1ntos sistemas est\u00e1n ahora expuestos?<\/h2>\n
Parchear, apagar o aislar<\/h2>\n
\n
Por qu\u00e9 el SIEM es un objetivo especialmente delicado<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfQu\u00e9 permite exactamente la CVE-2026-20253?<\/h3>\n
\u00bfEst\u00e1n afectadas las empresas DACH, aunque la fecha l\u00edmite de CISA solo aplica para organismos estadounidenses?<\/h3>\n
\u00bfQu\u00e9 hacer si no es posible aplicar el parche inmediatamente?<\/h3>\n
\u00bfC\u00f3mo puedo saber si mi instalaci\u00f3n de Splunk est\u00e1 expuesta?<\/h3>\n
\u00bfPor qu\u00e9 una vulnerabilidad en el SIEM es especialmente cr\u00edtica?<\/h3>\n
Recomendaciones de lectura de la redacci\u00f3n<\/h3>\n