Pi-hole 6.5: ¿actualizar? Seguridad, gravity.db y qué revisar antes

#homelab #selfhosted #pihole #seguridad

Resumen

Sí, conviene actualizar a Pi-hole 6.5, pero tras unas comprobaciones concretas. A fecha de 2026-10-28, según la página de la release consultada, Pi-hole Core v6.5 es sobre todo un endurecimiento de seguridad: corrige cuatro avisos de severidad alta (CVSS 7.8, 7.8, 7.8 y 7.3) y uno de severidad baja (CVSS 2.2). Además migra tu gravity.db automáticamente y retira un comando.

Criterio de decisión, razonado a partir de lo anterior:

Si tu Pi-hole es accesible para otros usuarios o servicios de la máquina, o ejecuta FTL con configuración editable, los avisos de root y ejecución de comandos justifican actualizar pronto.
Si usas arpflush en scripts o cron, o adlists file://, o gravity.db en una ruta personalizada, revisa esos puntos antes; si no, el riesgo de la actualización es bajo.

Qué ha cambiado

Vulnerabilidades corregidas

Los cuatro avisos de severidad alta son:

Ejecución de comandos mediante un PID manipulado (GHSA-cf36-4hhc-8398), CVSS 7.8.
Root siguiendo un symlink al escribir el archivo de versión (GHSA-xch2-4qxw-g5vj), CVSS 7.8.
/opt/pihole pasa a ser de solo lectura para el servicio FTL (GHSA-j8vh-6fp9-cjcx), CVSS 7.8.
Root escribiendo en rutas proporcionadas por la configuración (GHSA-mff6-cjc4-5wq9), CVSS 7.3.

El de severidad baja (GHSA-g63w-24cr-p3w6, CVSS 2.2) afecta a adlists file://: la comprobación de lectura y curl podían resolver archivos distintos; ahora las listas locales se leen como el usuario cuyo acceso se comprobó.

A ello se suma más endurecimiento de privilegios: el comprobador de actualizaciones y los ajustes previos al arranque de FTL se ejecutan como usuario pihole, solo se confía en repositorios git que pihole no pueda modificar, y se deja de conceder CAP_CHOWN a todo lo que ejecuta pihole-FTL (se mantiene en el conjunto ambient del servicio FTL).

Qué se elimina o cambia de comportamiento

arpflush se elimina en favor de networkflush. Si algún script o cron aún llama a arpflush, fallará; sustitúyelo por networkflush.
Adlists file://: se leen sin curl y su URI se interpreta con expansión de parámetros y canonicalización de ruta (RFC 8089). Si tus rutas locales usan formas poco habituales, comprueba que siguen resolviéndose.
listsCache se guarda junto a gravity.db en lugar de siempre en /etc/pihole. Es relevante si gravity.db está en una ruta personalizada o en volúmenes Docker: el directorio puede aparecer en otro sitio.
Otros cambios menores: se evita la doble rotación de logs ahora que pihole está en /etc/logrotate.d (con USR2 tras logrotate), /etc/pihole/versions es legible por todos, mejora el manejo de errores de gravity y el volcado de consultas de 24 h se hace vía API de FTL.

gravity.db

El esquema se mejora para rendimiento (tablas de unión WITHOUT ROWID, nuevos índices para búsquedas de grupos, triggers más baratos) y las bases existentes se migran automáticamente a la versión de esquema 21 al actualizar. Implicación práctica: la migración es automática, pero no está documentado cuánto tarda en bases grandes, y una vez migrada tu base ya no tendrá el esquema anterior; de ahí que una copia previa sea aquí especialmente útil.

Relación con FTL v6.8

La URL de origen del adlist se pasa a parseList de FTL, algo necesario para la corrección de adlists file:// de FTL v6.8. Si dependes de listas locales, el arreglo completo requiere esa versión de FTL; el pack no indica qué versión de FTL acompaña a Core 6.5.

¿Afecta a Debian 11?

Debian 11 se elimina de la matriz de distribuciones del CI de Pi-hole, lo que sugiere que deja de probarse en esta versión. No hay información de que deje de funcionar, pero si ejecutas Debian 11 asumes una combinación sin pruebas automáticas; plantéate migrar de sistema.

Qué comprobar en tu homelab

Copia con Teleporter. Pi-hole incluye Teleporter para copias de configuración. Expórtala antes de actualizar, porque gravity.db se migra de forma automática al esquema 21.
Scripts y cron. Busca usos de arpflush y cámbialos por networkflush.
Adlists locales. Si tienes entradas file://, verifica que el archivo es legible por el usuario correcto y que la ruta se interpreta como esperas. Comprueba también la versión de FTL (v6.8 para la corrección completa).
Rutas personalizadas y Docker. Si gravity.db no está en el sitio por defecto o usas volúmenes, localiza dónde queda listsCache tras actualizar. En Docker, el pack no detalla el impacto exacto ni cómo se versiona la imagen.
Permisos y automatizaciones propias. Si algo tuyo escribía en /opt/pihole desde FTL, o dependía de que pihole-FTL tuviera CAP_CHOWN, puede dejar de funcionar.
Sistema operativo. Si estás en Debian 11, tenlo presente.

Límites: no hay datos sobre problemas conocidos tras actualizar ni sobre la duración de la migración en bases grandes.

¿Lo usas en tu homelab? Cuéntalo en los comentarios.

Fuentes

Este artículo se ha elaborado con asistencia automatizada

DEV Community