Ir al contenido
EuroVPSEuroVPS

CVE-2026-46333 (ssh-keysign-pwn): carrera en ptrace

FAQ de EuroVPS

Actualizado el 4 min de lectura

Shared FAQ page chrome (breadcrumb, dates, read time, «Siga leyendo», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Se ha divulgado una nueva vulnerabilidad del kernel Linux, registrada como CVE-2026-46333 y conocida públicamente como ssh-keysign-pwn. El problema afecta a la lógica de chequeo de acceso de ptrace del kernel Linux durante la salida de un proceso y puede permitir que un usuario local sin privilegios lea ficheros sensibles propiedad de root en determinadas condiciones. Ya hay exploits públicos de prueba de concepto disponibles.

Esta vulnerabilidad es especialmente importante para sistemas Linux multiusuario, servidores multiinquilino y entornos donde usuarios locales no confiables o semiconfiables tienen acceso a shell.


Qué es CVE-2026-46333

CVE-2026-46333 es una condición de carrera del kernel Linux en la ruta de chequeo de acceso de ptrace. Durante el proceso de salida de un programa privilegiado hay una breve ventana en la que el proceso ya ha liberado su descriptor de memoria pero todavía tiene descriptores de fichero abiertos. Un proceso local sin privilegios puede abusar de esta carrera para duplicar descriptores de fichero del proceso privilegiado que está saliendo.

Los exploits públicos demuestran actualmente el acceso a ficheros sensibles a través de programas SUID privilegiados como:

  • ssh-keysign, que puede acceder a las claves privadas de host de SSH
  • chage, que puede acceder a /etc/shadow

Sistemas afectados

Según los avisos de los fabricantes disponibles a 15 de mayo de 2026:

AlmaLinux

AlmaLinux ha confirmado que AlmaLinux 9 y AlmaLinux 10 son vulnerables, y los exploits públicos funcionan de forma fiable en ambos. AlmaLinux 8 no es explotable con la prueba de concepto pública actual, pero el fallo de lógica subyacente del kernel está presente y AlmaLinux también prepara parches para él.

Los kernels corregidos de AlmaLinux están disponibles actualmente en el repositorio de testing:

SistemaVersión de kernel corregida
AlmaLinux 8kernel-4.18.0-553.124.4.el8_10
AlmaLinux 9kernel-5.14.0-611.54.6.el9_7
AlmaLinux 10kernel-6.12.0-124.56.5.el10_1

CloudLinux

CloudLinux ha confirmado que CloudLinux 8 LTS, CloudLinux 9 y CloudLinux 10 están afectados por la prueba de concepto pública actual. CloudLinux 7 no está afectado. CloudLinux 7h y CloudLinux 8 mainstream contienen la carrera subyacente del kernel, aunque la prueba de concepto pública actual no los explota directamente.

CloudLinux ha recomendado una mitigación inmediata para todo el host mediante el sysctl específico de CloudLinux kernel.user_ptrace=0.


Mitigación inmediata

La corrección permanente es instalar un kernel corregido de su proveedor de sistema operativo y reiniciar con ese kernel. Hasta que el kernel corregido esté instalado, las siguientes mitigaciones pueden reducir la exposición.


Mitigación para servidores CloudLinux

En sistemas CloudLinux, aplique la siguiente mitigación:

sysctl -w kernel.user_ptrace=0
echo 'kernel.user_ptrace = 0' | sudo tee /etc/sysctl.d/99-ptracenull.conf
sudo sysctl --system

Verifique:

sysctl kernel.user_ptrace

Salida esperada:

kernel.user_ptrace = 0

Este ajuste desactiva el uso de ptrace sin privilegios en sistemas CloudLinux y bloquea a nivel de kernel la prueba de concepto pública conocida actualmente. CloudLinux señala que puede afectar a herramientas como gdb -p, strace -p y otras herramientas de depuración o monitorización que dependen de adjuntarse a procesos sin privilegios.


Mitigación para servidores AlmaLinux

En sistemas AlmaLinux, AlmaLinux recomienda endurecer ptrace_scope de Yama:

sysctl -w kernel.yama.ptrace_scope=3
echo 'kernel.yama.ptrace_scope = 3' > /etc/sysctl.d/99-ssh-keysign-pwn.conf
sysctl --system

Verifique:

sysctl kernel.yama.ptrace_scope

Salida esperada:

kernel.yama.ptrace_scope = 3

AlmaLinux indica que fijar kernel.yama.ptrace_scope en 2 o 3 bloquea los exploits públicos conocidos. Fijarlo en 3 desactiva por completo el attach de ptrace, lo que puede afectar a herramientas de depuración como gdb o strace -p.


Bastionado adicional opcional

Donde proceda, los administradores también pueden quitar el bit SUID de los binarios objetivo conocidos actualmente:

chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null
chmod u-s /usr/bin/chage

Verifique:

ls -l /usr/libexec/openssh/ssh-keysign /usr/bin/chage

Los permisos ya no deberían mostrar una s en el campo de ejecución del propietario.

Esta es solo una mitigación parcial. Cubre los objetivos de exploit públicos conocidos actualmente, pero no corrige el problema subyacente del kernel. También puede afectar a la autenticación SSH basada en host o al uso de chage por usuarios distintos de root.


Corrección permanente: actualice el kernel

Cuando los paquetes corregidos estén disponibles en los repositorios de producción de su proveedor, actualice el kernel y reinicie:

dnf clean all
dnf update -y 'kernel*'
reboot

Tras el reinicio, verifique el kernel en ejecución:

uname -r
rpm -q kernel | sort -V

Para AlmaLinux 8, 9 y 10, los kernels corregidos se publicaron por primera vez en el repositorio de testing el 15 de mayo de 2026. La disponibilidad en producción debe confirmarse en el repositorio del proveedor antes de aplicar actualizaciones en sistemas de producción críticos.


KernelCare / live patching

CloudLinux ha indicado que se están preparando live patches de KernelCare para los sistemas afectados. Cuando estén disponibles, los servidores con KernelCare deberían poder recibir la corrección sin reinicio mediante el proceso estándar de live patching de KernelCare.

Para actualizar KernelCare manualmente:

kcarectl --update

Para comprobar los parches aplicados:

kcarectl --patch-info | grep CVE-2026-46333

Recomendación de EuroVPS

Mitigue ahora, parchee cuando el kernel del proveedor llegue al repositorio de producción y, mientras tanto, revise qué usuarios locales tienen acceso a shell.


¿Necesita ayuda?

Abra un ticket de soporte desde el área de cliente y nuestros ingenieros mitigarán, parchearán y programarán el reinicio por usted.

De las FAQ de EuroVPS, publicado por primera vez el 15 de mayo de 2026.

Más en la categoría «Anuncios»

Su próximo socio de infraestructura

¿Todavía tiene
una pregunta?

Díganos qué intenta hacer. Un ingeniero lo leerá y le responderá.

+357 222 32280
Un ingeniero de EuroVPS transporta un nodo de servidor en la sala del datacenter
Una conversación con las personas que cuidarán de su infraestructura.

Empecemos por su infraestructura.

Un poco de contexto nos ayuda a empezar la conversación adecuada.

Usaremos sus datos para responder a su consulta. Política de privacidad