preparación para la era de la IA
13 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.
Seguridad para la era de la IA: los fundamentos que blindar ya (lista de prioridades)
La IA sobre todo amplifica los ataques sobre debilidades EXISTENTES (CVE sin parchear, contraseñas reutilizadas, secretos expuestos) más que inventar nuevas, y las encuentra de forma automática, rápida y a escala. Así que la mejor preparación es blindar los fundamentos en el orden correcto: parcheo de CVE + monitoreo de dependencias, dejar de reutilizar contraseñas + MFA, quitar secretos expuestos, mínimo privilegio, reducir la superficie pública, registros/IOC, copias de seguridad.
Medidas de seguridad para la era de la IA que funcionan y que no: por qué también atacan a los sitios pequeños
Cuatro ideas equivocadas de la era de la IA corregidas: (1) demasiado pequeño para ser objetivo → los ataques automatizados no necesitan que un humano elija el objetivo; (2) necesita un control nuevo especial → los fundamentos siguen funcionando mejor; (3) un producto te hace seguro → diseño de prevención antes que detección; (4) el código de IA es rápido, así que es seguro → puede desplegarse con vulnerabilidades, así que revisa antes de publicar. Lo que funciona son los aburridos fundamentos en el orden correcto.
Suplantación de correo con tu propio dominio: cómo distinguirla de una intrusión y cómo la detienen SPF, DKIM y DMARC
Un correo sospechoso que parece venir de tu propio dominio normalmente no es una intrusión — es un From falsificado, porque SMTP permite a cualquiera escribir la línea From. Leer las cabeceras (Authentication-Results, Received, Reply-To) distingue una intrusión de una falsificación. La razón principal de que llegue a tu bandeja de entrada es la falta de una política DMARC. Corrígelo con SPF → DKIM → DMARC (p=none → reject).
Fundamentos de copias de seguridad: la regla 3-2-1 y un plan de recuperación que sobrevive al ransomware
«Tengo una copia de seguridad» no basta; solo es útil una copia que has verificado que puedes restaurar. Los fundamentos: la regla 3-2-1 (tres copias, dos tipos de medio, una fuera del sitio). Para el ransomware además necesitas al menos una copia «offline o inmutable» — una copia siempre conectada se cifra junto con el original. La sincronización en la nube no es una copia de seguridad (también replica borrados y cifrado). El versionado y una prueba de restauración periódica completan la práctica.
Elegir bien la MFA: qué significa «resistente al phishing» y por qué el SMS es débil
La MFA combina categorías distintas de factores. Los códigos introducidos a mano pueden retransmitirse mediante phishing; el SMS depende además del control del número. Para cuentas importantes, prioriza métodos resistentes al phishing, como passkeys o llaves FIDO2, y revisa la verificación del usuario y la recuperación.
Corregir CVE de dependencias de verdad: escanear, corregir, aislar y seguir vigilando
El trabajo de vulnerabilidades no termina cuando «lo corriges». Hecho = 1) escanear, 2) corregir, 3) aislar/delegar, 4) monitorear. Hasta que el monitoreo (detección diaria de cambios) esté en marcha, está incompleto — las dependencias vuelven a ser vulnerables mañana. Una corrección perfecta que el siguiente despliegue sobrescribe vale cero. Los equipos pequeños se mantienen seguros con dos disciplinas: detección automatizada de cambios y «local→push→deploy».
Instalar y usar osv-scanner: encuentra automáticamente CVE en tus dependencias
osv-scanner escanea lockfiles y contenedores para sacar a la luz CVE en tus dependencias, gratis. Esto recorre la instalación, la ejecución y la integración en CI, además de cuándo usarlo frente a npm/pnpm audit y Dependabot. La visión de este sitio: qué herramienta encaja depende de tu configuración. Usa osv-scanner en proyectos multiecosistema o sin GitHub, y al pnpm audit incluido para un único árbol npm.
¿Son seguros los gestores de contraseñas? Cómo funcionan, nube vs local y cómo elegir
Un gestor de contraseñas ayuda a usar una contraseña robusta y distinta para cada servicio. El cifrado de conocimiento cero está diseñado para proteger el contenido incluso si se filtran datos cifrados del proveedor, pero la seguridad también depende de la fortaleza de la contraseña maestra, la configuración de cifrado y la seguridad del dispositivo. Usa MFA para evitar accesos no autorizados y elige nube o local según el uso.
¿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.
La base de seguridad para desarrolladores independientes y pequeños operadores: controles estándar en orden de prioridad
La base no es 'todo igual de importante'. El orden de prioridad de este sitio: 1) cuentas de administración, dominio y correo (MFA), 2) secretos y código, 3) la propia app, 4) parchear, detectar, recuperar. Con tiempo finito, complétala de arriba abajo. La mayoría de las brechas graves no vienen de ataques novedosos sino de que falta un control básico.
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.
Una clave de API se filtró desde código escrito por IA y se usó para cargos fraudulentos: la causa era una vulnerabilidad CVSS 10.0 sin parchear
El pico en la factura fue un síntoma. La causa era un RCE CVSS 10.0 publicado y sin parchear. Un caso anonimizado, destilado en lecciones defensivas.