Saltar al contenido
ITLAB
ESEN

30 / 10 / 2026 · Seguridad

Lo que no se arregla con un parche: vulnerabilidades de hardware

Algunas fallas vienen en el procesador o la memoria y no se corrigen del todo con una actualización. Casos conocidos y cómo compensar el riesgo en su empresa.

Tercera entrega de nuestra serie sobre seguridad de servidores en la era de la IA. La primera parte trató del software, que se corrige instalando una versión nueva. Con el hardware no siempre es así.

La mayoría de las fallas de seguridad son de software, que se corrige instalando una versión nueva. Pero también hay fallas en el propio hardware: en el diseño del procesador, de la memoria o de su firmware. Vienen de fábrica, y algunas no se pueden corregir del todo con una actualización. Con la IA acelerando la búsqueda de fallas, es razonable esperar que aparezcan más.

Algunos casos conocidos muestran el rango:

  • Spectre y Meltdown (2018). Fallas en la forma en que los procesadores adelantan trabajo. Se mitigaron con cambios en el sistema operativo y el firmware, con pérdidas de rendimiento de entre 5 % y 30 % en algunas cargas especializadas, según Wikipedia), y los fabricantes debieron rediseñar procesadores nuevos.
  • Rowhammer. Leer repetidamente ciertas zonas de la memoria puede alterar datos vecinos. Las defensas incorporadas en la memoria han sido evadidas una y otra vez, también en memorias DDR5, según el resumen de Wikipedia.
  • Hertzbleed (2022). Permite deducir secretos a partir de los cambios de frecuencia del procesador. Según Wikipedia, ni Intel ni AMD planearon parches de microcódigo; la recomendación fue reforzar las bibliotecas criptográficas.
  • TEE.fail (2025). Un ataque físico al bus de memoria DDR5 que rompe las zonas protegidas de procesadores Intel y AMD. Requiere acceso físico al equipo, y AMD declaró que no planea mitigaciones porque ese tipo de ataque queda fuera de su modelo de amenaza, según BleepingComputer.
  • Degradación de procesadores Intel de 13.ª y 14.ª generación. Según TechTimes, las actualizaciones de firmware frenan el daño, pero no revierten el silicio ya degradado: la única solución es reemplazar el chip.
  • Microcódigo de AMD. Una falla en la verificación de firmas permitía cargar microcódigo malicioso con privilegios de administrador; se corrigió con actualizaciones de BIOS que debe publicar cada fabricante de equipos, según SecurityWeek.

Cuando no hay parche, o el parche depende de una cadena de fabricantes, la respuesta es de compensación:

  1. Inventario de hardware y firmware, no solo de software: qué procesadores, placas y versiones de BIOS hay, y qué avisos les aplican.
  2. Aplicar las actualizaciones de microcódigo y BIOS que publiquen los fabricantes, sabiendo que suelen llegar más tarde que las de software.
  3. Reducir quién puede llegar al equipo. Muchas de estas fallas exigen acceso físico, privilegios de administrador o ejecutar código en la máquina: restringir privilegios, proteger el acceso físico y no exponer interfaces de administración reduce mucho el riesgo.
  4. Aislar y segmentar. Separar los sistemas sensibles en redes y equipos distintos limita lo que un atacante puede alcanzar.
  5. Reforzar el software encima del hardware, como en el caso de las bibliotecas criptográficas.
  6. Planificar el ciclo de vida. Un equipo sin soporte del fabricante, o con una falla física conocida, debe tener fecha de reemplazo.

Qué preguntarle a su proveedor de TI

  • ¿Llevan inventario del hardware y del firmware, y aplican las actualizaciones de BIOS y microcódigo?
  • ¿Qué equipos están fuera de soporte del fabricante y cuándo se reemplazan?
  • ¿Las interfaces de administración de servidores y equipos de red están fuera del alcance de internet?

Preguntas frecuentes

¿Hay fallas que no se pueden parchar? Sí, algunas fallas de hardware no se corrigen del todo con actualizaciones. Ahí la respuesta es compensar: restringir el acceso, aislar sistemas, reforzar el software y planificar el reemplazo del equipo.

¿Debo cambiar mis equipos? No necesariamente. Muchas de estas fallas exigen acceso físico o privilegios de administrador. Pero un equipo sin soporte del fabricante, o con una falla física conocida, debería tener fecha de reemplazo.

Fuentes

Sigue la serie

Contacto

Si quiere revisar el inventario y el ciclo de vida de los equipos de su organización, ITLab puede ayudarle. Contáctenos.

¿Necesitas a alguien que se haga cargo de tu tecnología?

Cuéntanos qué necesitas ordenar, proteger o resolver. La primera conversación no tiene costo: evaluamos si nuestro modelo te sirve y cuáles serían los siguientes pasos.

Conversemos sobre tu empresa