La lista que todos quieren no existe. OpenAI publicó su informe, “A thousand fewer paths to root,” el 4 de noviembre de 2026, y el informe no nombra identificadores CVE, ni versiones de kernel afectadas, ni subsistemas. Nuestro reporte de noticias sobre los 948 exploits cubre los conteos, los costos y las afirmaciones. Este tutorial cubre la computadora frente a ti, y empieza desde una posición honesta: no puedes revisar un servidor contra una lista que nadie ha publicado.
Lo que sí puedes revisar es todo alrededor de esa lista faltante. Un exploit en esta clase empieza desde una cuenta local ordinaria y termina en root. Así que el estado de tus actualizaciones de kernel, tu cola de reinicio, tu cobertura de parche en vivo, tus cuentas locales y tus valores de endurecimiento del kernel decide cuánto espacio tendría tal exploit en tus computadoras hoy. Nada de eso necesita la lista de CVE. Todo es trabajo que querrías hecho incluso si la lista llegara mañana.
Lo que vas a construir o aprender
Terminarás con un registro escrito para un servidor, construido desde sus propias respuestas. El registro declara qué kernel se ejecuta, qué versión de distribución ejecuta la computadora, si una actualización de kernel espera ser instalada, si ya se debe un reinicio, si un servicio de parche en vivo está cubriendo el kernel en ejecución, qué cuentas locales existen y qué seis valores de endurecimiento se leen en esa computadora.
También terminarás con una lectura clara de los números de OpenAI. La tubería produjo 1,169 exploits de escalada de privilegios local funcionales, y el análisis de variantes agrupó esos exploits en 948 fallas distintas, cada una con un parche candidato. Candidato es la palabra que importa. Un parche candidato se convierte en una corrección real solo cuando los mantenedores del kernel lo aceptan y tu distribución lo entrega. Diez días después del escaneo de mediados de octubre, OpenAI dice que 61 de las fallas ya se habían parchado en el origen, 43 tenían parches en preparación y 299 se estaban informando y discutiendo en público. El resto aún se movía por la divulgación. Por eso la respuesta práctica hoy es cadencia de parcheo y exposición local, no una caza de 948 nombres.
Antes de empezar
Tres límites dan forma a toda esta auditoría, y cada uno te protege de una conclusión incorrecta.
Primero, la lista faltante es real. El informe de OpenAI da conteos, costos por etapa y estado de parcheo, y no da identificadores que una herramienta pudiera coincidir contra tu kernel. Cualquier escáner, publicación de blog o discurso de proveedor que afirme probar tus servidores para las 948 por nombre está inventando la lista contra la que prueba. Trata tal afirmación como mercadotecnia y pide sus datos de origen.
Segundo, una cadena de versión de kernel no es un veredicto. Las distribuciones llevan correcciones de seguridad a números de versión más antiguos, una práctica llamada backporting, así que un kernel que se ve antiguo junto a la versión más reciente del origen puede ya llevar una corrección dada. Lo contrario también se cumple. Un paquete de kernel nuevo puede estar instalado en disco mientras la computadora aún ejecuta el kernel antiguo con el que arrancó la semana pasada. Juzga por avisos de la distribución y por el estado de paquetes en la computadora, nunca comparando números de versión solo con el origen.
Tercero, la escalada de privilegios local necesita un inicio local. El atacante necesita código ejecutándose como algún usuario ordinario en la caja primero: una persona con una cuenta, una cuenta de servicio para una aplicación o una carga de trabajo dentro de un contenedor. Ese dato define el orden de este tutorial. Estado del kernel primero, luego las cuentas y cargas de trabajo que podrían entregarle a un atacante la posición de inicio.
Paso 1: Registra el kernel en ejecución y la distribución
Acción: en el servidor, ejecuta estos comandos y guarda la salida en un archivo de registro nombrado para el host:
uname -r
cat /etc/os-release
{ uname -a; cat /etc/os-release; } > kernel-audit-$(hostname).txt
El primer comando imprime la versión del kernel que se ejecuta ahora mismo, en una forma como 6.8.0-100-generic. El archivo /etc/os-release nombra la distribución y su versión, que es el par que decide qué avisos y qué nombres de paquete se aplican a ti. El tercer comando escribe ambas respuestas en un archivo pequeño que puedes conservar junto al resto de esta auditoría.
Resultado esperado: tienes tres datos por escrito, el nombre de host, la versión del kernel en ejecución y la versión de la distribución. Cada paso posterior se lee contra estos tres. Si la versión del kernel en ejecución te sorprende, esa sorpresa en sí es un hallazgo, y el Paso 2 explica la causa más común.
La auditoría empieza en papel: un registro por servidor, construido desde lo que la computadora informa sobre sí misma. Ilustración generada en el estilo de la casa Dirty Static.
Paso 2: Encuentra actualizaciones de kernel pendientes y estado de reinicio
Acción, en Debian y Ubuntu: actualiza las listas de paquetes, y luego pregunta qué paquetes de kernel esperan ser instalados. La actualización no cambia paquetes. Solo actualiza las listas contra las que tu computadora compara.
sudo apt update
apt list --upgradable 2>/dev/null | grep -E '^linux-(image|generic|headers)'
dpkg -l 'linux-image-*' | grep '^ii'
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
Los dos primeros comandos muestran si un paquete de kernel más reciente está en oferta. El tercero enumera los paquetes de kernel ya instalados en disco, y comparar su entrada más reciente con la salida de uname -r del Paso 1 te dice si un kernel instalado nunca ha sido arrancado. Los dos últimos comandos leen el marcador de reinicio. El archivo /var/run/reboot-required existe solo cuando una actualización instalada ha pedido un reinicio, y su archivo compañero nombra los paquetes que lo pidieron. Si el comando ls informa que el archivo no existe, ese error es la respuesta: no se marca ningún reinicio como debido.
Acción, en la familia RHEL:
dnf check-update
rpm -q kernel
sudo needs-restarting -r
El primer comando imprime las actualizaciones en oferta, y sale con código 100 cuando existen actualizaciones, que es información y no una falla. El segundo enumera paquetes de kernel instalados para la misma comparación con uname -r. El tercero informa si el sistema en ejecución necesita un reinicio para usar actualizaciones ya instaladas. La herramienta needs-restarting se incluye en el paquete dnf-utils, así que un comando faltante significa que ese paquete está ausente, y la comparación de uname arriba es tu evidencia hasta que lo instales.
Resultado esperado: una de tres lecturas por servidor. Una actualización de kernel espera, lo que te envía al Paso 6. O un kernel está instalado y se debe un reinicio, lo que también te envía al Paso 6 y explica cualquier resultado extraño del Paso 1. O nada espera y nada se debe, lo que significa que tu distribución no tiene un kernel más reciente para ti hoy, y los pasos restantes deciden tu postura.
Paso 3: Lee el estado de parche en vivo donde exista un servicio
Algunos servidores reciben correcciones para fallas graves del kernel aplicadas al kernel en ejecución, sin reinicio, mediante un servicio de parche en vivo. El servicio cubre solo las fallas que su creador juzga seguras para parchar así, y nunca mueve una computadora a un kernel más reciente. Es un puente entre reinicios, y este paso lee si el puente está realmente en su lugar.
Acción, en Ubuntu:
pro status
sudo canonical-livepatch status
El primer comando muestra si el servicio livepatch está activado. El segundo muestra el kernel en ejecución que protege y su estado de parche. Lee la línea de estado de parche al pie de la letra: te dice si los parches están aplicados, si aún no se necesita ninguno, o si el kernel en ejecución no es compatible con el servicio en absoluto. Un kernel no compatible no obtiene nada del servicio, diga lo que diga la suscripción, según la documentación de Ubuntu Pro.
Acción, en sistemas RHEL que usan kpatch:
sudo kpatch list
Resultado esperado: la herramienta enumera los parches en vivo cargados e instalados para el kernel en ejecución, o informa que la herramienta está ausente, en cuyo caso registra que ningún servicio de parche en vivo se ejecuta en este servidor. En cualquier sistema sin un servicio de parche en vivo, registra la misma respuesta simple y depende de los Pasos 2 y 6. Un espacio en blanco aquí no es una falla de la auditoría. Es el dato de que los reinicios son tu única ruta a correcciones del kernel en esa caja.
Paso 4: Cuenta las cuentas locales desde las que un exploit empezaría
Acción: enumera las cuentas ordinarias en el servidor. En la mayoría de los sistemas, las cuentas para personas empiezan en ID de usuario 1000, y la cuenta llamada nobody está muy por encima de ese rango, así que este filtro muestra las cuentas humanas y de servicio que importan:
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $6, $7}' /etc/passwd
getent group sudo
getent group wheel
who
Lee la salida como una lista de asistencia. El primer comando imprime cada nombre de cuenta, su carpeta personal y su shell de inicio de sesión. Los dos comandos siguientes nombran los miembros de los grupos que pueden ganar root por diseño, sudo en Debian y Ubuntu y wheel en la familia RHEL. Un exploit que llega a root desde una cuenta ordinaria hace esas listas de grupo más importantes, no menos, porque muestran quién ya tiene una ruta gestionada hacia arriba. El último comando muestra quién ha iniciado sesión ahora.
Cada cuenta local es una llave en la pared. La auditoría las cuenta y revisa cuáles reconoces. Ilustración generada en el estilo de la casa Dirty Static.
Acción: si el servidor ejecuta contenedores, enuméralos y revisa si alguno se ejecuta en modo privilegiado:
docker ps
docker ps -q | xargs -r docker inspect --format '{{.Name}} privileged={{.HostConfig.Privileged}}'
Usa los equivalentes de podman en sistemas que ejecutan Podman. Si ninguna herramienta existe, regístralo y sigue. Los contenedores comparten el kernel del host, así que parchar una imagen de contenedor no hace nada para una falla del kernel. El host es el objetivo, y un contenedor que se ejecuta con privileged definido en true tiene acceso amplio a ese host, así que cada contenedor así pertenece a tu lista de posiciones de inicio junto a las cuentas humanas.
Resultado esperado: una lista de cuentas y cargas de trabajo que reconoces, cada una propiedad de una persona o un servicio que puedes nombrar. Cualquier nombre que no puedas ubicar es el hallazgo más valioso en este paso. Elimina o desactiva una cuenta solo mediante tu proceso normal de cambio, con el dueño del servicio en el ciclo, porque una cuenta de servicio que parece inactiva puede aún ejecutar un trabajo nocturno.
Paso 5: Lee los valores de endurecimiento que dan forma al acceso al kernel
Los ajustes del kernel, leídos y cambiados con la herramienta sysctl, deciden cuánto del kernel puede tocar o ver un usuario ordinario. Este paso solo lee seis valores. No cambia ninguno de ellos, y las notas abajo explican lo que significa cada lectura para que puedas registrarla con entendimiento en lugar de como un número desnudo.
Acción: ejecuta:
sysctl kernel.kptr_restrict kernel.dmesg_restrict kernel.perf_event_paranoid kernel.unprivileged_bpf_disabled
sysctl user.max_user_namespaces
sysctl kernel.unprivileged_userns_clone
El tercer comando puede informar que la clave no existe. Esa clave se incluye solo en algunas distribuciones, principalmente la familia Debian, así que un error allí significa que el control está ausente en este kernel. Registra ausente como ausente. No lo registres como cero, porque las dos lecturas significan cosas diferentes.
Cómo leer los valores, contra la documentación del kernel:
kernel.kptr_restrictcontrola si las direcciones de memoria del kernel se ocultan cuando se imprimen. En 1, las direcciones se reemplazan con ceros para usuarios que carecen de la capacidad CAP_SYSLOG, con condiciones que la documentación detalla. En 2, se ponen en cero para todos. En 0, las direcciones se someten a hash antes de imprimir. Más alto es más ajustado, y este valor se relaciona con el lado de fuga de información de los resultados de OpenAI.kernel.dmesg_restricten 1 significa que solo usuarios con CAP_SYSLOG pueden leer el registro del kernel mediante la herramienta dmesg. En 0, cualquier usuario local puede leerlo.kernel.perf_event_paranoidcontrola la herramienta de medición perf. Los números más altos la restringen más, y las distribuciones incluyen valores predeterminados diferentes, incluido un valor de 4 en Ubuntu que el origen no define. Registra el número y compáralo con tu propia flota en lugar de con una tabla universal, porque no existe un predeterminado universal.kernel.unprivileged_bpf_disableden 1 o 2 significa que los usuarios ordinarios no pueden hacer llamadas sin privilegios a eBPF, la máquina virtual dentro del kernel que una larga línea de fallas pasadas de escalada ha abusado. La documentación del kernel agrega una advertencia que vale la pena conocer antes de que alguna vez definas este valor tú mismo: una vez definido en 1, el ajuste no puede borrarse hasta que la computadora reinicie.user.max_user_namespaceslimita cuántos espacios de nombres de usuario pueden crearse. Un valor de 0 cierra la creación por completo. Un valor grande deja la creación abierta, sujeta a otros controles.kernel.unprivileged_userns_clone, donde existe, en 0 significa que solo usuarios privilegiados pueden crear espacios de nombres de usuario. Los espacios de nombres de usuario son una herramienta de sandbox de la que dependen muchas configuraciones de contenedores y navegadores, y también son un punto de entrada común en exploits pasados de escalada, porque un espacio de nombres otorga a su creador privilegios elevados dentro de él sobre objetos del kernel que el host puede ver.
Resultado esperado: seis lecturas, o cinco lecturas más una ausencia registrada, por servidor. Este tutorial no te dice que cambies ninguno de ellos en una computadora de producción hoy. Cambiar ajustes de espacios de nombres o eBPF puede romper contenedores sin root, sandboxes y herramientas que dependen de ellos, así que cada cambio pertenece a una prueba en un host de repuesto primero, un cambio a la vez, con una forma de volver.
Paso 6: Instala el kernel que tu distribución ofrece, y luego reinicia
Acción, en Debian y Ubuntu:
sudo apt update
sudo apt full-upgrade
sudo reboot
Acción, en la familia RHEL:
sudo dnf update
sudo reboot
Donde tu política permite solo actualizaciones de seguridad, agrega la bandera de seguridad al comando dnf en lugar de una actualización completa, y acepta que otros paquetes entonces esperan su propia ventana. Después de que la computadora regrese, repite el Paso 1 y el Paso 2 en ella.
Resultado esperado: uname -r ahora imprime la versión de kernel más reciente que el Paso 2 mostró como instalada, la lista de paquetes de kernel actualizables está vacía, y el marcador de reinicio desapareció. Si uname -r aún imprime la versión antigua, la computadora arrancó su kernel anterior, y la tabla de Solución de problemas abajo cubre esa lectura.
Verificación
La auditoría funcionó cuando tu registro coloca cada servidor en exactamente una fila de esta tabla, con evidencia de la propia computadora.
| Evidencia de tu registro | Lectura |
|---|---|
| Actualización de kernel en espera en el Paso 2, o marcador de reinicio presente | Expuesto por retraso. La corrección existe y la computadora no la está ejecutando. El Paso 6 es todo el remedio, dentro de una ventana. |
| Kernel instalado más reciente que el kernel en ejecución | La misma lectura que arriba, con la causa nombrada. La actualización llegó y el reinicio nunca ocurrió. |
| Servicio de parche en vivo activado, kernel compatible, estado de parche aplicado o ninguno necesario | Cubierto entre reinicios para las fallas que el servicio selecciona. Las actualizaciones normales de kernel aún se aplican en su cadencia normal. |
| Respuesta de parche en vivo ausente o kernel no compatible, y ninguna actualización en espera | Actual solo mediante la ruta de paquetes. Tu postura es tu cadencia de reinicio, y nada más se interpone entre una falla y su corrección. |
| Una cuenta o un contenedor privilegiado que nadie puede nombrar | Una posición de inicio que no sabías que ofrecías. Resuélvela mediante tu proceso de cambio antes de preocuparte por valores del kernel. |
| Creación de espacios de nombres abierta y eBPF sin privilegios activado en un servidor que ejecuta cargas locales no confiables | Una superficie local más ancha de lo que la tarea necesita. Un candidato para un ajuste probado después, nunca una edición el mismo día en una caja de producción. |
| Ninguna actualización en espera, cuentas todas nombradas, estado de parche en vivo leído y registrado | Tan actual como hoy permite. Ninguna revisión puede decir más mientras las 948 no lleven identificadores, y cualquiera que afirme más está adivinando. |
Solución de problemas
| Problema | Causa probable | Solución |
|---|---|---|
uname -r aún muestra el kernel antiguo después del Paso 6 | La computadora reinició en su kernel anterior, o el paquete de kernel nuevo se instaló sin convertirse en el predeterminado de arranque | Compara la lista instalada del Paso 2 con la versión en ejecución, revisa la selección del menú del cargador de arranque, reinicia una vez más y lee uname -r de nuevo antes de juzgar. |
| El número de kernel en ejecución se ve más antiguo que el kernel más reciente del origen, pero la distribución enumera la clase de falla como corregida | Backporting. La distribución llevó la corrección a su propio número de versión | Confía en el aviso de la distribución y el registro de cambios del paquete para tu versión exacta sobre cualquier comparación de números del origen. |
needs-restarting no se encuentra | El paquete dnf-utils no está instalado en sistemas de la familia RHEL | Instala dnf-utils mediante tu proceso normal, o descansa el juicio de reinicio en la comparación instalado frente a en ejecución en el Paso 2. |
canonical-livepatch status dice que el kernel no es compatible | El kernel en ejecución está fuera de la lista que el servicio Livepatch cubre | El servicio no aplica nada a ese kernel. Mueve la computadora a un kernel compatible mediante el Paso 6 y lee el estado de nuevo. |
sysctl informa que kernel.unprivileged_userns_clone no existe | La clave se incluye solo en algunas distribuciones | Registra el control como ausente en este kernel. Juzga la exposición de espacios de nombres por la lectura de user.max_user_namespaces en cambio. |
dnf check-update termina con un mensaje en estilo de error y código 100 | El código 100 es la señal documentada de que existen actualizaciones | Lee la lista impresa. Es un hallazgo, no una falla. |
| Ninguna actualización de kernel está en oferta y las noticias suenan urgentes | Aún no se ha publicado un kernel más reciente para tu versión, que es el estado normal mientras las 948 se mueven por la divulgación | Mantén tu cadencia normal, conserva el registro de esta auditoría y vuelve a revisar después de que tu distribución publique su próximo kernel. No instales kernels desde fuera de los canales de tu distribución como atajo. |
| Un cambio de endurecimiento rompió un contenedor o un sandbox en pruebas | La carga de trabajo depende de espacios de nombres de usuario o de eBPF sin privilegios | Revierte ese único cambio en el host de prueba, registra la dependencia y limita cualquier cambio posterior a servidores que no ejecuten esa carga de trabajo. |
Próximos pasos
Convierte esta auditoría en un ritmo en lugar de un evento. Suscríbete a los avisos de seguridad de la distribución que cada servidor ejecuta, Ubuntu Security Notices, el rastreador de seguridad de Debian o los datos de seguridad de Red Hat, y deja que esos flujos impulsen tu cadencia de kernel en lugar de los titulares. Donde tu política lo permita, activa la instalación automática de actualizaciones de seguridad, mediante el paquete unattended-upgrades en la familia Debian o dnf-automatic en la familia RHEL, mientras mantienes los reinicios como eventos planificados que tú controlas.
Luego observa lo único que cambiaría este tutorial: identificadores. Cuando los informes de la ejecución de OpenAI lleguen a los mantenedores y al registro público, las asignaciones CVE y los avisos de distribución darán a los defensores una lista al fin. Vuelve a revisar tus registros del Paso 1 el día en que tu distribución publique correcciones de kernel vinculadas a esas asignaciones, y espera que ese día llegue por etapas durante semanas, no como una sola entrega. Hasta entonces, los servidores que salen de esta auditoría con kernels actuales, listas cortas de cuentas y registros honestos están tan defendidos como los datos públicos permiten.
Comandos y significados de valores verificados contra la documentación sysctl del kernel de Linux, la documentación de Ubuntu Pro Livepatch y la publicación de investigación de OpenAI, noviembre de 2026. Esta auditoría se verificó contra esos documentos y no se ejecutó contra un servidor de producción en esta ejecución, así que confirma cada lectura en tu propio hardware como dirige la tabla de Verificación.
Fuentes
- OpenAI, A thousand fewer paths to root, 4 de noviembre de 2026. Fuente principal para las 948 fallas distintas, los 1,169 exploits funcionales, el estado de parche candidato, los conteos de parcheo diez días después del escaneo y la ausencia de identificadores CVE, versiones afectadas y subsistemas del informe.
- Dirty Static, OpenAI Says Its Agents Built Working Exploits for 948 Distinct Linux Kernel Root Flaws, 5 de noviembre de 2026. El reporte de noticias que este tutorial sigue, para los conteos, costos y estado de divulgación en un lugar.
- La documentación del Kernel de Linux, Documentation for /proc/sys/kernel/. Fuente para los significados de kptr_restrict, dmesg_restrict y unprivileged_bpf_disabled, incluida la regla de que un valor de 1 para el control eBPF no puede borrarse hasta el reinicio.
- Documentación del Cliente Ubuntu Pro, How to manage Livepatch. Fuente para los comandos pro status y canonical-livepatch status y para la advertencia que produce un kernel no compatible.
- CSO Online, OpenAI built an AI pipeline to find, exploit and patch Linux flaws, noviembre de 2026. Cobertura independiente usada para verificar los conteos de la tubería y el estado de parcheo.
- Imágenes del héroe y el cuerpo: Dirty Static, generadas en estilo de la casa
FIN DE LA TRANSMISIÓN
Mantén la curiosidad. Cuestiónalo todo.
