servidor
15 artículos con esta etiqueta
CVE-2026-98432 del kernel de Linux: un use-after-free de TCP activable por red (CVSS 9.8); instale el kernel corregido, reinicie y revise MPTCP
CVE-2026-98432 es un use-after-free en el código TCP IPv4 del kernel de Linux, publicado el 15 de octubre de 2026. La CNA del proyecto del kernel lo puntúa con CVSS v3.1 9.8 (red, sin privilegios, sin interacción del usuario). Según se informa, investigadores de una empresa de IA demostraron, en laboratorio y según su propio informe, la ejecución remota de código como root contra un servidor con un oyente Multipath TCP (MPTCP). BleepingComputer dice que no se ha demostrado públicamente la ejecución remota de código en servidores TCP normales y que no se ha confirmado ninguna explotación activa, y este sitio no encontró el CVE en el catálogo KEV de CISA el 1 de noviembre. Las correcciones upstream están en 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 y 7.2.10 y posteriores. A 1 de noviembre, Debian tiene kernels corregidos, SUSE tiene algunos, y Ubuntu y Red Hat indican las correcciones como en curso. Desactivar solo MPTCP no es una solución completa. Conclusión de este sitio: actualice los servidores Linux expuestos a internet a medida que lleguen las correcciones, reinicie y use una medida provisional del proveedor solo hasta entonces.
Qué comprobar tras una actualización urgente de PHP: PHP web frente a PHP de línea de comandos, set -e y códigos de salida de diff, y una revisión de intrusión
Durante la respuesta de octubre de 2026 a las vulnerabilidades críticas de PHP, un sitio que gestiona el operador de este sitio había actualizado el PHP web, pero el PHP de línea de comandos que usaba cron seguía apuntando a una versión antigua. Compruebe por separado el web y la CLI. Con set -e, diff y grep devuelven el estado de salida 1 para «diferencias encontradas» o «sin coincidencias», lo que detiene el script; gestione por separado los códigos 0, 1 y 2. Tras el parche, ejecute la misma lista de revisión de intrusión en todos los servidores, y resuelva una entrada de registro sospechosa comparando los archivos activos con la copia desplegada de referencia.
VMware ESX CVE-2026-41709 (CVSS 2.7): CISA incluye como explotado este fallo de registro de baja gravedad; aplique todo VMSA-2026-0006 y revise sus hosts
CVE-2026-41709 es un fallo de registro insuficiente en VMware ESX (CVSS 2.7, bajo): un atacante que ya tiene acceso de administrador puede realizar ciertas operaciones sin que queden registradas en los logs. Broadcom lo corrigió en el aviso VMSA-2026-0006 el 29 de julio de 2026, sin solución alternativa. El 28 de octubre de 2026 (hora de EE. UU.) CISA lo añadió a su catálogo de vulnerabilidades explotadas conocidas (KEV), con fecha límite del 11 de noviembre para las agencias federales de EE. UU. El informe de amenazas de una empresa de seguridad dice que un grupo vinculado a China lo usó como día cero en varias intrusiones en organizaciones de EE. UU., hasta principios de 2026, y SecurityWeek describe la finalidad como reducir la visibilidad del rastro de auditoría; este sitio no ha verificado ese informe de forma independiente. El fallo no da entrada por sí solo, pero significa que los registros de un host afectado pueden no mostrar lo que hizo un intruso. El mismo aviso incluye dos fallos de vCenter con 9,8, uno de los cuales (CVE-2026-59310) CISA incluyó como explotado el 18 de agosto, de modo que aplicar solo la corrección del fallo de ESX deja abiertas las vías de entrada. Conclusión de este sitio: actualice ESX y vCenter a las compilaciones corregidas de todo el aviso, envíe los registros de los hosts a un servidor aparte y busque señales de compromiso en lugar de fiarse solo de los registros.
Fragnesia del kernel de Linux (CVE-2026-46300): CISA la incluye como explotada con plazo al 31 de octubre; actualice PHP y el kernel, y reinicie
CVE-2026-46300, apodada Fragnesia, es una falla del kernel de Linux que permite a un usuario local con pocos privilegios obtener root (CVSS v3.1 7.8, vector de ataque local). Cuando el kernel mueve fragmentos de datos entre búferes de red, puede perder una marca que indica que los datos se comparten con un archivo en memoria, y el código IPsec ESP puede entonces descifrar sobre la copia en caché de un archivo de solo lectura. El proyecto del kernel publicó el CVE el 23 de mayo de 2026, y las correcciones están en los kernels 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 y 7.0.10 y posteriores. El 28 de octubre de 2026 (hora de EE. UU.), CISA la añadió a su catálogo de vulnerabilidades explotadas conocidas (KEV) por pruebas de explotación activa, con fecha límite del 31 de octubre para las agencias federales de EE. UU. La descripción de CISA dice que puede encadenarse con las fallas de PHP CVE-2026-109618 y CVE-2026-109619 para implantar webshells PHP y ejecutar comandos como root. Una empresa de seguridad informó de que esta cadena se usó contra 25 servidores (sobre todo cortafuegos), y SecurityWeek repitió el informe; este sitio no ha verificado las cifras de forma independiente. Ubuntu, Red Hat y Debian han publicado kernels corregidos, y una actualización del kernel solo surte efecto tras reiniciar. Conclusión de este sitio: si ejecuta sitios PHP en Linux, actualice PHP y el kernel, reinicie y busque webshells.
Vulnerabilidad CVE-2026-110447 en el servidor CODE integrado de Collabora en Nextcloud, explotada: quién está afectado y qué hacer
El 14 de octubre de 2026, los desarrolladores de Collabora Online revelaron el CVE-2026-110447, una vulnerabilidad de inyección de comandos del sistema operativo sin autenticación en la aplicación de Nextcloud Collabora Online - Built-in CODE Server (ID de aplicación richdocumentscode). A través de proxy.php de la aplicación, los comandos pueden ejecutarse como el usuario del servidor web. La condición es que el servidor CODE integrado no esté en ejecución, lo que puede ocurrir tras un reinicio del contenedor, una actualización o un fallo. Están afectadas las versiones anteriores a la 26.4.303; la 26.4.303 se publicó el 11 de septiembre. Los desarrolladores afirman que desactivar la aplicación no evita el problema y piden actualizarla o eliminarla. En Nextcloud 29 y versiones anteriores, que ya no tienen soporte, actualiza Nextcloud o elimina la aplicación. Según los desarrolladores, los servidores independientes de Collabora Online, las imágenes Docker, los paquetes RPM/DEB y Nextcloud All-in-One no están afectados. La puntuación CVSS v4.0 es 9,2. CISA añadió el fallo a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV) el 23 de octubre, con fecha límite el 26 de octubre. Los usuarios informaron de ataques desde alrededor del 10 de septiembre en el repositorio de los desarrolladores y, según informes de prensa, se instalaron web shells. Conclusión de este sitio: si la aplicación CODE integrada está instalada, aunque esté desactivada, comprueba su versión hoy, actualízala o elimínala y luego busca indicios desde el 10 de septiembre.
GitLab CVE-2026-110264 (CVSS 10.0) y la CVE-2026-97229 explotada: cómo comprobar y actualizar un GitLab autogestionado
El 21 de octubre de 2026, GitLab publicó las versiones de parche crítico 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13 para Community Edition (CE) y Enterprise Edition (EE). La falla más grave, CVE-2026-110264 (CVSS 10.0), es un desbordamiento de entero al compilar una expresión regular especialmente diseñada que, bajo ciertas condiciones, podría permitir a un usuario no autenticado ejecutar código arbitrario en el servidor de GitLab. Casi todas las versiones desde la 7.0 están afectadas. El 29 de octubre, CISA añadió una falla hermana, CVE-2026-97229 (CVSS 10.0, CWE-190), a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), con fecha límite del 1 de noviembre. Es el mismo tipo de fallo (un desbordamiento de entero en el compilador de expresiones regulares de CI/CD, alcanzable por un usuario no autenticado); GitLab la corrigió antes, el 12 de octubre, en 19.4.2, 19.3.5 y 19.2.8, y afecta solo a 19.2.0 a 19.2.7, 19.3.0 a 19.3.4 y 19.4.0 a 19.4.1. Quien siga por debajo de 19.4.2, 19.3.5 o 19.2.8 está expuesto a una falla explotada. Actualizar a las versiones recomendadas aquí (19.5.1, 19.4.3, 19.3.6, 19.2.9) también corrige CVE-2026-97229. GitLab.com ya está parcheado; las instalaciones autogestionadas deben actualizarse. La misma versión del 21 de octubre corrige dos fallas de gravedad alta (CVSS 8.2 y 7.5) y otras, pero esas correcciones solo llegan en las líneas 19.3.6, 19.4.3 y 19.5.1. La causa raíz está en el motor de expresiones regulares de Ruby (Onigmo), y Ruby publicó 4.0.9, 3.4.12 y 3.3.13 el 23 de octubre. Las aplicaciones que compilan una regexp a partir de cadenas controladas por un atacante están afectadas, y Regexp.timeout no protege contra estos fallos. Los avisos de GitLab no dicen que CVE-2026-110264 se haya explotado, y no figura en KEV a 30 de octubre. Alpine Linux informó de un intento de ataque contra su propio GitLab mediante CVE-2026-97229 el 20 y 21 de octubre, y de que actualizar solo GitLab (a la 19.3.6) no cerró la falla porque la corrección también necesitaba un Ruby parcheado; reconstruyó la instancia y no encontró pruebas de que se ejecutara código del atacante. Conclusión de este sitio: actualice hoy el GitLab autogestionado tras revisar las paradas obligatorias de actualización, termine en la 19.3.6 o posterior y, si compila GitLab usted mismo o usa su propio Ruby, compruebe que ese Ruby sea también 3.3.13, 3.4.12 o 4.0.9 o posterior. Las aplicaciones Ruby deben pasar a un Ruby corregido y dejar de construir regexps a partir de la entrada del usuario.
SiteGuard Server Edition CVE-2026-106931 explotada: quién está afectado y qué hacer
El 14 de octubre de 2026, EG Secure Solutions divulgó CVE-2026-106931, una vulnerabilidad de inyección de comandos del sistema operativo en la función de estadísticas de SiteGuard Server Edition, su firewall de aplicaciones web (WAF) basado en host, y dijo que ya se ha confirmado su explotación. La explotación puede permitir ejecutar comandos arbitrarios del sistema operativo con privilegios de root o SYSTEM en el servidor que ejecuta el producto. Están afectadas las versiones Ver2.20 y posteriores con la función de estadísticas activada (está activada por defecto): las ediciones Apache, Nginx e IIS anteriores a Ver8.00 Update5, y las ediciones Apache y Nginx para FreeBSD anteriores a Ver7.00 Update6. La edición IIS desde Ver3.10 hasta Ver4.00 Update4 no está afectada. Las correcciones son Ver8.00 Update5 y Ver7.00 Update6; para los sistemas que no se pueden actualizar hay un parche, incluso para versiones sin soporte. El fabricante califica la falla con vector de ataque local y privilegios bajos requeridos (CVSS v3.0 7.8, v4.0 8.5). JPCERT/CC emitió una alerta, indicando que ha confirmado que el producto se usa ampliamente en Japón y que desactivar la función de estadísticas evita el problema. CISA añadió la falla a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 20 de octubre con fecha límite el 23 de octubre. Conclusión de este sitio: si usa Server Edition, compruebe hoy la versión y la función de estadísticas, guarde los datos de diagnóstico antes de actualizar y luego aplique la versión corregida o el parche.
[Última hora] Los fallos de PHP CVE-2026-109618 y CVE-2026-109619 ya se están explotando y CISA los añade a su catálogo KEV: actualice ya a 8.5.12, 8.4.27, 8.3.36 u 8.2.35
El 21 de octubre de 2026, el equipo de seguridad de PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades críticas que pueden permitir la ejecución remota de código (RCE) sin autenticación, e instó a todos los usuarios a actualizar de inmediato. CVE-2026-109618 se relaciona con la gestión de memoria agotada y CVE-2026-109619 con un estado interno obsoleto que sobrevive entre peticiones; ambas tienen una puntuación de 9,2 según CVSS v4.0. Todas las instalaciones de PHP que atienden peticiones web están en riesgo (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). El equipo considera que mod_php es el de mayor riesgo, citando un exploit demostrado en el que una petición sin autenticar activa el ataque antes de que se ejecute cualquier código de la aplicación. PHP 8.1 y versiones anteriores no reciben actualización oficial; el equipo proporcionó backports mínimos del código fuente para 7.4, 8.0 y 8.1. Las distribuciones Linux recibieron los parches con antelación. No existe una mitigación completa; actualizar es la única opción segura. El 22 de octubre, IPA y JPCERT/CC de Japón emitieron alertas y JVN publicó JVNVU#99905564. CISA, que no había observado explotación cuando publicó por primera vez su alerta, añadió ambos fallos a su catálogo Known Exploited Vulnerabilities (KEV) el 26 de octubre, con un plazo hasta el 29 de octubre para las agencias civiles federales de EE. UU. Según informes de medios, los honeypots de un investigador de seguridad con PHP 8.4.26 sin parchear bajo mod_php registraron una ejecución remota de código exitosa el 24 de octubre. Los honeypots de un importante proveedor de nube ya habían registrado intentos de explotación desde el 17 de octubre, cuatro días antes de la divulgación. Hasta donde este sitio ha podido comprobar, a fecha del 27 de octubre no se había hecho pública ninguna intrusión fuera de honeypots. La mayoría de los principales proveedores japoneses de hosting compartido han anunciado que la corrección está aplicada, pero algunos, como KAGOYA, no. El 23 de octubre, el equipo de PHP divulgó una tercera incidencia (CVE-2026-115560) que las versiones del 21 de octubre no corrigen. Solo puede llevar a la ejecución de código con una combinación específica de configuración y código de aplicación; el equipo la considera improbable en la práctica, incluirá la corrección y un aviso completo en la próxima versión regular y recomienda establecer session.upload_progress.enabled=0 hasta entonces. No se han publicado las versiones afectadas ni una puntuación CVSS, y no se ha informado de explotación. A fecha del 29 de octubre (comprobado en php.net) no había ninguna versión que corrigiera esta incidencia. El 28 de octubre, CISA añadió también a KEV el fallo del kernel de Linux CVE-2026-46300 (plazo el 31 de octubre para las agencias federales de EE. UU.) y dijo que puede encadenarse con estos dos fallos para implantar webshells de PHP y ejecutar comandos como root. La postura de este sitio: la explotación ya está confirmada, así que confirme si usted o su proveedor actualizan PHP en cada sitio y pase a la versión corregida hoy. Revise también los registros desde el 17 de octubre en adelante en busca de señales de intrusión. En hosting compartido, consulte el aviso de finalización de su proveedor en su sitio web oficial.
¿La seguridad de un sitio web afecta al SEO? Vulnerabilidades, sitios hackeados, HTTPS y posicionamiento según la documentación oficial de Google
Google no incluye las vulnerabilidades entre los factores de posicionamiento. El daño llega cuando alguien las aprovecha. Las páginas de spam añadidas por un atacante hacen que los resultados muestren «Este sitio puede haber sido pirateado», el malware o el phishing activan el aviso «Sitio peligroso» en Chrome (otros navegadores muestran sus propios avisos de Safe Browsing) y los sitios que incumplen las políticas contra el spam pueden aparecer más abajo o no aparecer. En 2014 se anunció HTTPS como una señal «muy ligera», y la documentación actual de Google sobre la experiencia en la página dice que, aparte de las Core Web Vitals, los demás aspectos de la experiencia en la página no ayudan directamente a posicionar mejor un sitio. La opinión de este sitio: para el SEO, dedica el tiempo a que no te hackeen y a darte cuenta rápido si ocurre, no a subir una puntuación de seguridad.
Cómo saber si han hackeado tu sitio web o tu servidor: comprobaciones paso a paso para hosting compartido, WordPress y un VPS, y qué hacer primero si encuentras algo
Revisar un sitio en busca de intrusiones significa mirar tanto las señales visibles desde fuera como los rastros que quedan dentro. Señales: el informe de problemas de seguridad de Search Console, una etiqueta 'This site may be hacked' en los resultados de búsqueda, un aviso de tu hosting, administradores desconocidos, redirecciones que solo ocurren en el móvil o al llegar desde el buscador. Rastros: usuarios administradores, archivos del núcleo modificados (wp core verify-checksums), historial de inicios de sesión, authorized_keys, cron, puertos a la escucha, archivos cambiados recientemente. La opinión de este sitio: no encontrar nada no demuestra que estés limpio. Si encuentras algo, conserva las pruebas antes de limpiar, cambia todas las credenciales desde un dispositivo limpio, restaura una copia anterior a la intrusión o reconstruye, cierra la vía de entrada y solo entonces solicita una revisión.
¿Dejaste un archivo de secretos en un directorio público? Audita tu webroot
Cualquier cosa en tu webroot puede descargarse por URL por cualquiera. Un JSON de token/credenciales olvidado, un .env o una copia de seguridad significa exposición instantánea — y si vino de una plantilla compartida, todos los sitios tienen el mismo archivo. Solución: coloca en el directorio público solo cosas compartibles públicamente, mantén los secretos fuera del webroot con permisos 600, y una vez que encuentres uno, audita cada sitio y servidor.
Inventario de seguridad: 7 comprobaciones que pasan por alto quienes operan varios servidores
Para operadores solos/pequeños, los incidentes vienen menos de controles ausentes que de estado sin seguimiento. La frontera es el PC que guarda tus claves. Prioriza el 2FA según qué cuenta permite recuperar las demás (el correo primero), anota qué clave SSH abre qué servidor y borra las claves duplicadas, las que no se usan y los registros sobrantes, quita las contraseñas en texto plano de la nube, remedia de forma reversible una a una, y mantén los secretos fuera del registro. Inventario antes de añadir herramientas.
Git autoalojado vs GitHub: ¿cuál es realmente más seguro?
Autoalojar Git no te hace 'más seguro' — reubica el riesgo. La clase de exposición pública accidental desaparece, pero parchear el servidor, las copias de seguridad y la detección de secretos pre-commit pasan a ti. La decisión correcta si sigues haciendo ese trabajo; peor que GitHub si lo descuidas. La visión de este sitio: el autoalojamiento solo funciona acompañado de sus controles compensatorios.
Privilegio mínimo en claves SSH: mantén las claves de root de producción fuera de entornos efímeros que pueden ser comprometidos
Registrar una clave de root en producción desde un entorno efímero y comprometible (pod de GPU, runner de CI, VM desechable) significa que en el momento en que ese entorno se compromete, un atacante obtiene root en producción. Solución: sin claves de root en entornos efímeros; quita las claves cuando no se usen; si se necesita de nuevo, usa un usuario no-root más una clave restringida a un comando que limite la clave a una sola operación. Trata una clave reutilizada como tu activo más crítico y nunca construyas un montaje en el que una clave filtrada abra todos los servidores.
Mantener el .env fuera de la web pública en hosting compartido
La solución principal: el cuerpo de la app fuera del docroot, solo public/ expuesto. Bloquea primero el acceso con .htaccess, hazlo permanente reestructurando, luego autocomprueba. La visión de este sitio: esto no es el descuido de una persona sino un diseño peligroso que se volvió estándar en todo el sector — arréglalo con proceso, no con vigilancia. bootstrap-redirect vence al symlink.