RCE en WordPress vía libheif: exploit chain público para HEIC

Si tu WordPress está en producción y acepta imágenes HEIC/HEIF, prestá atención: desde el 5 de octubre de 2026 hay una cadena de explotación pública que convierte una subida en la biblioteca de medios en ejecución remota de código. No es un plugin: es una falla en libheif, la librería del sistema que decodifica ese formato.

Qué pasó

Hay dos piezas acá y conviene no mezclarlas, porque cada una tiene su propia fecha.

La vulnerabilidad la encontró Alex Thomas (Wordfence) el 1 de septiembre de 2026 con su framework de testing agéntico Argus, durante una auditoría de WordPress 7.1. Es un heap overflow en el decodificador unci de imágenes sin comprimir de libheif (tracking GHSA-x8r2-mggj-j6wr, severidad crítica). Afecta a libheif 1.18.0 hasta 1.23.2 y está corregida desde 1.23.3. Todavía no tiene CVE asignado.

Lo nuevo del 5 de octubre es otra cosa: Fortbridge publicó el exploit completo. El advisory original dejaba los payloads finales sin publicar; Fortbridge construyó su propia cadena, la liberó con código, perfiles de build y contenedores reproducibles.

Cómo funciona, en corto: una imagen HEIC maliciosa declara sus dos canales de croma con profundidades distintas (Cb de 16 bits, Cr de 8 bits). libheif reserva un byte por muestra para el plano Cr pero escribe usando el ancho de dos bytes de Cb, así que cada escritura en Cr se pasa del final de la asignación. Los bytes escritos salen del archivo, o sea que el atacante los controla. Eso permite pisar el puntero de tabla virtual (vptr) de un objeto C++ del decodificador, y en el destructor se dispara una llamada virtual hacia la dirección elegida.

El paso que convierte esto en RCE y no en un crash es el ASLR. El exploit no recibe un mapeo del proceso: sube imágenes de disclosure por la misma biblioteca de medios y lee las direcciones de memoria de los JPEG derivados que genera WordPress. Cada byte filtrado viaja dentro de un bloque de 8×8 en el canal luma, y el exploit toma la mediana de cada bloque para sobrevivir a la compresión JPEG. Con eso resuelve las bases de libc y de MagickCore, identifica cuál de sus dos stacks exactos está corriendo, recién entonces construye el disparador. Además ocupa 7 de los 8 workers de PHP-FPM con subidas lentas para reservarse el octavo.

Resultados medidos, y ojo con esto: 6 de 8 procesos padre nuevos de PHP-FPM en Ubuntu 26.04 (75%) y 22 de 24 en Debian 13 (91.7%). No son tasas universales para WordPress: dependen del stack exacto, del tamaño del pool y de cualquier actualización de paquete. El criterio fue estricto: un worker que muere con HTTP 503 es telemetría de crash, nunca prueba de RCE. Solo contou cuando un GET posterior a una ruta que antes devolvía 404 respondió 200 con uid=33(www-data).

Impacto

• Necesita una cuenta con upload_files: Autor o superior. No es un visitante anónimo. Pero en sitios con varios autores o con registro abierto, un usuario blog de tu propio equipo alcanza.
• El decodificador corre antes de que cualquier regla lo mire: WordPress pasa el archivo a Imagick → ImageMagick → libheif dentro del worker de PHP-FPM, antes de que un plugin de seguridad o una regla de hardening intervengan.
• El código corre como el usuario de PHP-FPM (www-data en el laboratorio), es decir con permisos de lectura sobre tu código y tus secretos de aplicación.
• Requiere build con WITH_UNCOMPRESSED_CODEC=ON. Si tu libheif no compiló ese códec, esta vía no te aplica.
• Stacks vulnerables reportados: imagen oficial de Docker de WordPress (1.19.8), Debian 13 trixie (1.19.8), Ubuntu 26.04 (1.21.2), Fedora 44 (1.21.2).
• Stacks NO vulnerables: Ubuntu 24.04 LTS (1.17.6), Debian 12 bookworm (1.15.1), AlmaLinux 10 (1.17.6), Alpine 3.22/3.23 (el códec sin comprimir no viene compilado).
• No hay explotación en the wild reportada. Hay PoC público. No hay actor de amenaza ni malware documentado.

Qué hacer ahora

1. Actualizá libheif a 1.23.3 o superior. En Debian/Ubuntu: apt update && apt install --only-upgrade libheif1. Debian 13 ya tiene el fix en su rama de seguridad como 1.23.4-1~deb13u1, así que si tenés trixie con las actualizaciones de seguridad aplicadas, ya lo tenés.
2. Reiniciá PHP-FPM después del parche. Si no, los workers siguen con la librería vieja mapeada en memoria.
3. Revisá qué build tenés. Herramientas → Salud del sitio → Información → Manejo de medios: si ahí no aparece el soporte HEIC, tu build no tiene el códec.
4. Buscá evidencia de compromiso, no solo el parche. Dos indicadores concretos:
   • El perfil Debian del exploit deja el resultado de id en /rce-proof.txt. Si ese archivo existe en tu servidor, asumí compromiso total y arrancá la recuperación desde cero.
   • En los logs, crashes repetidos de hijos de PHP-FPM con HTTP 503 alrededor de subidas HEIC/AVIF, sobre todo archivos con relaciones unci, iden, crop, overlay o grid. Un 503 repetido en ese contexto es evento de seguridad, no ruido.
5. Hasta que parchees, rechazá HEIC/AVIF antes del decode nativo: .heic, .heif, .heics, .heifs y .avif. Bloquear la extensión en el cliente no alcanza si otro flujo los procesa igual.
6. Activá la protección contra ejecución de PHP en wp-content/uploads/ (en Wordfence: “Disable Code Execution for Uploads directory”). No arregla la corrupción de memoria, pero limita a dónde puede llegar el exploit.
7. Si procesás media no confiable, aislá el servicio: un worker desechable, con privilegios mínimos, sin acceso a red y sin secretos de la aplicación.

TL;DR: heap overflow en el decodificador unci de libheif (1.18.0–1.23.2, corregido en 1.23.3) permite RCE en WordPress subiendo un HEIC malicioso, y desde el 5 de octubre hay exploit público con PoC. Necesita Autor o superior, corre como www-data y exige build con códec sin comprimir. Parcheá, reiniciá PHP-FPM, y buscá /rce-proof.txt más los 503 alrededor de subidas HEIC.

Fuentes

• Fortbridge — WordPress libheif RCE: Exploit Chain (05/10/2026, Adrian Tiron)
• strukturag/libheif — Advisory GHSA-x8r2-mggj-j6wr (heap overflow en unci)
• Debian Security Tracker — libheif (versiones por rama y estado del fix)