惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
The GitHub Blog
The GitHub Blog
博客园 - 【当耐特】
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Recent Announcements
Recent Announcements
D
Docker
GbyAI
GbyAI
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
The Cloudflare Blog
雷峰网
雷峰网
A
About on SuperTechFans
小众软件
小众软件
博客园 - Franky
博客园 - 聂微东
F
Full Disclosure
大猫的无限游戏
大猫的无限游戏
C
Check Point Blog
MongoDB | Blog
MongoDB | Blog
G
Google Developers Blog
Microsoft Azure Blog
Microsoft Azure Blog
U
Unit 42
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V
V2EX
Engineering at Meta
Engineering at Meta
宝玉的分享
宝玉的分享
aimingoo的专栏
aimingoo的专栏
量子位
P
Proofpoint News Feed
Hugging Face - Blog
Hugging Face - Blog
博客园_首页
罗磊的独立博客
Martin Fowler
Martin Fowler
D
DataBreaches.Net
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
S
Secure Thoughts
Project Zero
Project Zero
L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志
C
Cybersecurity and Infrastructure Security Agency CISA
T
Tailwind CSS Blog
S
Schneier on Security
Blog — PlanetScale
Blog — PlanetScale
The Hacker News
The Hacker News
Spread Privacy
Spread Privacy
Security Latest
Security Latest
NISL@THU
NISL@THU
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
C
CXSECURITY Database RSS Feed - CXSecurity.com
J
Java Code Geeks

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant Common SOC 2 Failures (Real World) Stop Vibe-Checking Your AI App: A Practical Guide to Evals How to Use SonarQube and SonarScanner Locally to Level Up Your Code Quality Your Next To-Do App Is Dead — I Replaced Mine with an OpenClaw AI Sign a Nostr event in 60 lines of Python using coincurve — no nostr-sdk, no nbxplorer, no rust toolchain ITGC Audit Explained Like You’re in Big 4 Patch Tuesday abril 2026: Microsoft parcha 163 vulnerabilidades y un zero-day en SharePoint Stop scraping everything: a better way to track competitor price changes Listing on MCPize + the Official MCP Registry while routing payments OUTSIDE the marketplace — how I kept 100% of my x402 revenue Building an AI-Powered Risk Intelligence System Using Serverless Architecture Why We Ripped Function Overloading Out of Our AI Toolchain Testing AI-Generated Code: How to Actually Know If It Works SaaS Churn Is Killing Your Business. Here Is What to Do About It (Without a Support Team) The Speed of AI Is No Longer Linear - And Self-Improving Models Are Why How to Implement RBAC for MCP Tools: A Practical Guide for Engineering Teams From Standard Quote to Persuasive Proposal: AI Automation for Arborists I built a CLI that scaffolds complete multi-tenant SaaS apps Axios CVE-2025–62718: The Silent SSRF Bug That Could Be Hiding in Your Node.js App Right Now The dashboard that ended our friendship Data Pipelines Explained Simply (and How to Build Them with Python) The Hidden Cost of AI Systems Nobody Talks About. undefined vs undeclared, and how typeof behaves Switching from file-based jobs to NATS/Kafka in Rust without changing code io_uring Adventures: Rust Servers That Love Syscalls Why Agentic AI is Killing the Traditional Database The POUR principles of web accessibility for developers and designers Quantum Neural Network 3D — A Deep Dive into Interactive WebGL Visualization How To Install Caveman In Codex On macOS And Windows Automation Pipeline Reliability: Why Your Workflow Breaks When Nobody Is Watching I Built an 'Open World' AI Coding Agent — It Works From ANY Folder From Freelancing to Product: A Tech Service Company's SaaS Transformation China's AI Giants: Adding Tencent Hunyuan & ByteDance Doubao to AI University (74 Providers) On the Vibe Coders and Their Lies clerk: Auto-Summarize Your Claude Code Sessions AI Weekly — 2026/04/10–04/17 | The Model Lockdown Is Here, but the Toolchain Is the Real Battleground AI 週報 — 2026/04/10–2026/04/17 模型封鎖潮來了,但工具鏈才是真戰場 Maybe this is how Open-Source apps are born... 🚀 Fine-Tune LLMs with LoRA and QLoRA: 2026 Guide tRPC v11 + Next.js App Router: End-to-End Type Safety Without the Boilerplate ShadCN UI in 2026: Why I Stopped Installing Component Libraries and Started Owning My Components SaaS Billing in React Server Components: Stripe + Supabase Without a Single `useEffect` Join our DEV Weekend Challenge — $1,000 in Prizes Across TEN winners! Submissions Due April 20 at 6:59 AM UTC. Implementing FSRS Spaced Repetition in Flutter + Supabase — Adding Memory Science to an AI Learning App "I Texted My Localhost From the Train — Claude Code Fixed the Bug Before I Got Home" I Built a Sales Prep AI and It Went Deeper Than Expected Design to Code #2: One JSON, Eleven Outputs Solving the 100M-Row Problem: A Summary Table Pattern for High-Volume Push Notification Logs Flutter Web With Wasm: What Actually Changes For Developers I Built 50 Royalty-Free Soundtracks for My Side Project in a Weekend Using AI Music Generation The Vibe Coding Security Checklist: 7 Things to Check Before You Ship Stop Letting Googlebot Guess Fix Your React App's SEO Right Desconstruindo o Streaming do LinkedIn: Como Criar um Engine de Extração de Vídeo de Alta Performance com HLS e FFmpeg (EDA Part-1) EDA (Exploratory Data Analysis) Explained With Real Life — Why Looking at Your Data Is the Most Important Step in Machine Learning Brand Relationship Management at Scale: Our 4-Touch Outreach System for 200+ Brands Why String.fromEnvironment() Might Return an Empty String in Dart JGuardrails 1.0.0 — Hardening Java LLM Apps Against Jailbreaks, Toxicity, and Prompt Injection Plan and Schedule a Full Week of Threads Content From One Claude Conversation Coding Cat Oran Ep3, Five Tables Changed Everything Updated: BFF Pattern I'm done watching freelancers get buried by 200 proposals. So I'm building the alternative. This is my first post BFS Algorithm in Java Step by Step Tutorial with Examples Tracking LLM Pricing Monthly: An Open Dataset for 22 AI Models How We Measure Content ROI on a Comparison Site: Revenue Attribution Without Perfect Data Introducing Nova AI Ops: The AI-Native Operating System for SRE Teams I built a free desktop video downloader for Windows — Grabbit How Talkie OCR Helps Vision-Impaired & Dyslexic Users Read the World Around Them VRCFaceTracking安装和iPhone面捕配置教程,有bug Even CrowdStrike Can't See Your Agents The Automation Gold Rush: What n8n Workflows and Claude Are Opening Up for Developers Right Now
Linux kernel vulnerabilidades sin aviso a distros: lo que esto cambia en mi stack Ubuntu/Railway
Juan Torchia · 2026-05-02 · via DEV Community

Linux kernel vulnerabilidades sin aviso a distros: lo que esto cambia en mi stack Ubuntu/Railway

Cometí un error que me costó tres horas de debugging en producción y una noche de paranoia: asumí que Ubuntu sabía antes que yo de las vulnerabilidades del kernel que afectaban mis containers. Spoiler: no sabe. Nadie le avisa. Se enteran cuando vos te enterás.

No lo cuento para quejarme de los maintainers del kernel — entiendo la complejidad del ecosistema. Lo cuento porque si vos deployás en Railway, Fly, Render o cualquier plataforma que corra sobre Linux (o sea, básicamente todos), estás operando bajo el mismo supuesto roto que operaba yo.

Linux kernel vulnerabilidades distribuciones producción: el modelo de disclosure está quebrado

Mi tesis, directa: el proceso actual de disclosure del kernel Linux es funcionalmente equivalente a un zero-day para cualquier distro que no sea mainline. Canonical, Red Hat, Debian — todos se enteran del CVE cuando sale el advisory público. No hay embargo coordinado como existe en otros ecosistemas de seguridad. No hay 90 días de Google Project Zero para que el downstream parchee antes de que el detalle quede expuesto.

Un HN score de 501 sobre este tema no es ruido. Es señal de que la comunidad técnica está procesando algo que venía ignorando.

El kernel mantiene una lista de "distros" en linux-distros@vs.openwall.org, pero la coordinación real es laxa. El LTS security team opera con embargo de máximo 7 días para issues embargados — y eso aplica solo para una fracción de las vulnerabilidades. Para el resto, el flujo es: patch mergeado a mainline → CVE asignado → todas las distros corriendo.

Desde Asahi Linux, donde exploré qué implica correr un kernel ARM no-mainline, el problema me quedó más claro: cuanto más alejado estás del upstream, mayor es el delay entre que sale el fix y que lo tenés disponible. Ubuntu LTS con HWE kernel es mejor que muchas alternativas, pero igual llega después.

Lo que encontré cuando audité mi stack real

Corro una app Next.js en Railway. Los containers se buildean sobre una imagen base Ubuntu 22.04 LTS. Me senté a hacer un ejercicio concreto: ¿cuánto tiempo tardó Ubuntu en publicar el patch para los últimos CVEs críticos del kernel versus la fecha de merge a mainline?

# Chequeá la versión de kernel que corre Railway en tus containers
# (ejecutalo desde tu app o en un RUN durante el build)
uname -r
# Output típico: 5.15.0-1xxx-aws o similar — no es el kernel de Ubuntu directamente

# Para ver el estado de patches de seguridad en Ubuntu:
ubuntu-security-status --thirdparty
# También útil:
pro security-status

Enter fullscreen mode Exit fullscreen mode

Lo que encontré: Railway corre sobre infraestructura de AWS. El kernel que ven mis containers no es el kernel Ubuntu — es el kernel de Amazon Linux modificado por AWS. Eso cambia el análisis completamente, y en mi caso lo hace más opaco, no más seguro.

# Esto lo corrí desde un container de Railway con acceso a shell:
cat /proc/version
# Linux version 5.15.0-1057-aws (buildd@lcy02-amd64-059)
# (Ubuntu 5.15.0-1057.61-aws 5.15.163)

# Para ver CVEs pendientes en el kernel de tu container:
# (necesitás instalar ubuntu-advantage-tools)
apt-get install -y ubuntu-advantage-tools
ua security-status

Enter fullscreen mode Exit fullscreen mode

El gap que me preocupa no es teórico. En febrero 2025, CVE-2024-53104 (uso-después-de-libre en el driver USB UVC del kernel) tuvo el fix mergeado a mainline el 18 de enero. Ubuntu publicó el USN (Ubuntu Security Notice) el 5 de febrero — dieciocho días después. Durante esos dieciocho días, cualquiera que supiera del issue tenía ventaja sobre cualquier sysadmin corriendo Ubuntu.

Dieciocho días no es catastrófico si el vector de ataque requiere acceso físico al hardware. Pero si el vector es red + container escape, esos días importan.

Mi stack de producción también toca decisiones de costos en AWS y Railway donde la superficie de exposición creció cuando empecé a escalar. Más containers, más kernel calls, más attack surface.

Los gotchas reales que un dev individual no ve venir

Gotcha 1: confundís "imagen actualizada" con "kernel actualizado"

# Esto NO actualiza el kernel del host:
FROM ubuntu:22.04
RUN apt-get update && apt-get upgrade -y

# Actualizás los paquetes del userspace del container.
# El kernel lo provee el host (Railway/AWS/GCP).
# Vos no controlás cuándo ese kernel se actualiza.

Enter fullscreen mode Exit fullscreen mode

Este es el error conceptual más común. Corrés apt upgrade en el Dockerfile, ves que todo está verde, y asumís que el kernel está parchado. No. El kernel lo gestiona Railway/AWS por vos, en sus tiempos, con sus prioridades.

Gotcha 2: la superficie real es más grande cuando usás PostgreSQL

Corro PostgreSQL en Railway. Cada query pasa por system calls — read(), write(), mmap(). Vulnerabilidades en el subsistema de memoria del kernel (tipo CVE-2024-26581, heap overflow en netfilter que estuvo varios días sin patch en distros estables) afectan directamente a workloads de base de datos. No es teórico.

Cuando revisé pgbackrest y el estado de mis backups de Postgres, el kernel era el supuesto implícito de integridad debajo de todo. Si el kernel tiene un exploit activo, los checksums de pgbackrest no te salvan de nada.

Gotcha 3: los lenguajes de sistema no te protegen de vulnerabilidades del kernel

Escribí sobre los bugs que Rust no previene. Este es el corolario: el tipo safety de Rust no te protege si el kernel que corre debajo tiene un use-after-free en su propio subsistema de memoria. El aislamiento del proceso asume que el kernel es confiable. Cuando esa asunción falla, fallás vos también.

Gotcha 4: el exploit timing es asimétricamente malo para vos

El actor malicioso tiene el CVE detail al mismo tiempo que los maintainers de la distro. Pero el actor malicioso puede desarrollar el exploit inmediatamente. La distro necesita: entender el issue, backportear el fix a su versión del kernel (no siempre trivial), QA, publicar el USN, y esperar que los sysadmins apliquen el update. El gap entre "CVE público" y "kernel parchado en producción real" puede ser semanas.

Gotcha 5: los clipboard bugs también viajan por el kernel

Esto puede sonar raro, pero cuando exploré el bug de clipboard que reproducí en mi propia app Next.js, el camino de datos pasa por el kernel también — especialmente en entornos headless donde Xvfb o similares interactúan con el scheduler. No es el mismo vector, pero el principio es el mismo: las capas de abstracción que considerás "tuyas" tienen dependencias del kernel que no ves.

Lo que puedo hacer yo como dev individual (sin ser distro maintainer)

Acá está la postura honesta: no puedo parchear el kernel de Railway. Ese control no existe para mí. Pero sí puedo reducir la superficie y el tiempo de exposición.

# 1. Monitoreo de USNs de Ubuntu — automatizá esto en tu CI/CD
# Suscribite al feed de Ubuntu Security Notices:
# https://ubuntu.com/security/notices/rss.xml

# 2. En tu Dockerfile, fijá la imagen base con digest para poder
#    trackear cuándo Railway actualiza el host:
FROM ubuntu:22.04@sha256:HASH_ESPECIFICO

# 3. Chequeá el kernel version al inicio de tu app (Node.js):
const os = require('os');
// Logueá esto en tu startup para Railway:
console.log(`Kernel: ${os.release()} | Platform: ${os.platform()}`);
// Si cambia entre deploys, Railway actualizó el host kernel.

Enter fullscreen mode Exit fullscreen mode

// src/lib/startup-audit.ts
// Logueo de info de entorno al arrancar — Railway lo captura en los logs
import os from 'os';

export function logSecurityBaseline(): void {
  const info = {
    kernel: os.release(),      // versión del kernel del host
    platform: os.platform(),   // linux
    arch: os.arch(),           // x64, arm64
    nodeVersion: process.version,
    timestamp: new Date().toISOString(),
  };

  // Guardalo en Railway: lo vas a ver si el kernel cambia entre deploys
  console.log('[SECURITY_BASELINE]', JSON.stringify(info));
}

Enter fullscreen mode Exit fullscreen mode

# 4. Activá las notificaciones de seguridad de Railway
# No tienen un feed de CVEs propio publicado, pero sí un status page.
# Suscribite a: https://status.railway.app/

# 5. Para reducir surface dentro de tu control: seccomp profiles en Docker
# Esto no parchea el kernel pero reduce las syscalls que tu container puede hacer:
docker run --security-opt seccomp=./seccomp-profile.json tu-imagen

Enter fullscreen mode Exit fullscreen mode

El punto más importante que cambié en mi workflow: traté Railway como un provider de infraestructura opaco en términos de kernel, no como algo que controlo. Eso me movió a defender en las capas que sí controlo — autenticación, validación de input, network policies dentro del container.

También cambié mi perspectiva sobre las herramientas de monitoreo de seguridad. Cuando analicé cómo las plataformas de Microsoft crean dependencia real, la misma lógica aplica acá: dependés de Railway para el kernel security, y esa dependencia es invisible hasta que importa.

FAQ — Preguntas reales sobre kernel vulnerabilidades en producción

¿Por qué las distros no reciben aviso previo de las vulnerabilidades del kernel?

El kernel Linux no tiene un proceso de embargo coordinado obligatorio para el downstream. Existe la lista linux-distros donde los maintainers pueden reportar issues sensibles, pero la participación es voluntaria y el embargo máximo es de 7 días para issues críticos. Para la mayoría de los CVEs, el flujo es público desde el primer momento: patch mergeado a mainline, CVE asignado, todos se enteran al mismo tiempo. Es un trade-off deliberado entre velocidad de fix y coordinación — el kernel privilegia la velocidad de patch sobre el delay coordinado.

Si corro en Railway (o Fly o Render), ¿quién es responsable de parchear el kernel?

La plataforma. Vos no tenés acceso al host kernel — ese nivel de aislamiento es la base del modelo PaaS. Railway/Fly parchean el kernel en sus hosts; vos no tenés visibilidad de cuándo lo hacen ni cómo. Podés monitorear el os.release() de tu runtime para detectar cambios entre deploys, pero el control real no está en tus manos.

¿Actualizar la imagen base Docker me protege de vulnerabilidades del kernel?

No. Las imágenes Docker actualizan el userspace (libc, binutils, las herramientas del sistema de archivos). El kernel es provisto por el host donde corre el container. apt upgrade dentro del Dockerfile no toca el kernel. La única forma de parchear el kernel es actualizar el host — que en PaaS lo hace el proveedor.

¿Qué tan rápido parchan Railway/AWS los kernels cuando sale un CVE crítico?

No publican SLAs de esto con esa granularidad. AWS tiene el Amazon Linux Security Center con tiempos de respuesta documentados para sus propias AMIs, pero Railway corre sobre su propia abstracción encima de AWS. En la práctica, para CVEs críticos con exploit activo, los proveedores grandes parchean en horas a días. Para CVEs importantes sin exploit público activo, puede ser semanas. La opacidad es real.

¿TypeScript o Rust me protegen de vulnerabilidades del kernel?

No en el vector relevante. El type safety opera en el espacio del proceso — previene errores en la lógica de la aplicación. Una vulnerabilidad de kernel que permite container escape o privilege escalation opera debajo del proceso. El aislamiento de lenguaje asume que el kernel es confiable. Cuando esa asunción falla, el lenguaje no puede salvarte. TypeScript 7 con su nueva arquitectura sigue teniendo ese límite.

¿Qué puedo hacer concretamente para reducir mi exposición hoy?

Tres cosas concretas: primero, suscribite al feed de Ubuntu Security Notices para CVEs de kernel y tratalo como información operacional, no académica. Segundo, activá seccomp profiles en tus containers Docker para reducir la superficie de syscalls disponibles para un posible exploit. Tercero, revisá si tu proveedor PaaS tiene un status page de seguridad o un programa de divulgación — si no lo tiene, eso ya es información sobre la madurez de seguridad del proveedor. El control que tenés es en las capas de encima del kernel; priorizalas.

Lo que esto cambia realmente en cómo opero

El modelo mental que tenía era: "corro en Ubuntu, Ubuntu tiene un equipo de seguridad, estoy cubierto". Ese modelo era cómodo y falso.

El modelo correcto es: corro sobre un kernel que no controlo, parchado en tiempos que no conozco, por una cadena de proveedores (Railway → AWS → kernel upstream) donde cada eslabón agrega delay. Eso no me paralizó — me hizo más preciso sobre dónde poner energía.

La energía útil está en: autenticación robusta, network policies dentro del container, monitoreo de runtime para comportamiento anómalo, y reducción de privilegios (no correr como root dentro del container, que sigue siendo demasiado común). Esas son capas que controlo.

Lo que no compro es la narrativa de que esto es un problema que "las distros van a resolver". El kernel es un proyecto descentralizado con millones de líneas de código y miles de contributors. El proceso de disclosure va a seguir siendo así porque coordinar upstream disclosure con downstream timing a escala global es un problema sin solución limpia.

Mi decisión: tratar la seguridad del kernel como un riesgo de infraestructura que mitigo en las capas que tengo, no como un problema que alguien más va a resolver para mí antes de que importe.


¿Cómo manejás vos el gap de kernel security en producción? ¿Tenés un proceso de monitoreo de USNs o confiás en el proveedor? Dejá el comentario abajo — me interesa ver cómo lo resuelven otros devs que corren stacks similares.


Este artículo fue publicado originalmente en juanchi.dev