Uso después de liberar.

Un "use-after-free" (UAF) ocurre cuando un puntero sigue refiriendo a un objeto después de que free()/delete lo haya liberado. Si el atacante consigue que esa misma región de memoria se reasigne como un objeto distinto —una técnica llamada heap grooming o "heap feng shui"—, el puntero colgante le proporciona en la práctica una confusión de tipos, perfecta para sobrescribir punteros de funciones virtuales, direcciones de callback o estado sensible. Los UAF dominan la explotación de navegadores y kernels y están catalogados como CWE-416.

Algunos casos con nombre ilustran el impacto. CVE-2018-8174, un UAF en el motor VBScript alcanzable a través de Internet Explorer, se convirtió en arma en el día cero "Double Kill" y se incorporó a kits de explotación. CVE-2022-0609, un UAF en el componente Animation de Chrome, fue explotado de forma activa como día cero; el Threat Analysis Group de Google atribuyó las campañas a actores estatales norcoreanos que tenían como objetivo a empresas de medios y fintech. La prevalencia de estos fallos es la razón por la que tanto Microsoft como Google informan de que alrededor del 70% de sus CVE históricos provienen de errores de seguridad de memoria, lo que impulsa al sector hacia Rust.

flowchart TD
  A[Objeto asignado, el puntero P lo referencia] --> B["free() / delete invocado"]
  B --> C[P queda colgante, la memoria vuelve al asignador]
  C --> D[El atacante rocia el heap para reclamar el hueco]
  D --> E[La misma memoria se reasigna como objeto controlado por el atacante]
  E --> F[El programa desreferencia P]
  F --> G[Confusion de tipos -> secuestro de vtable / flujo de control]

Las defensas incluyen modelos disciplinados de propiedad (RAII, smart pointers), lenguajes con recolección de basura o seguros en memoria como Rust, asignadores endurecidos (cuarentena, pools de aislamiento, GWP-ASan) y pruebas con KASAN/Valgrind. Los navegadores despliegan además guardas del estilo de MiraclePtr y PartitionAlloc.