Mi homelab se fue a la chucha y aprendí algo que no olvido: el enemigo no es el atacante, soy yo

Hace un par de días un chico que publica en un blog básico como el mío despertó con su servidor al 95% de CPU. No estaba compilando el kernel, no estaba entrenando un modelo de IA, no tenía un script de backup corriendo a las 3 de la mañana. Estaba siendo minado por un atacante que entró por su instancia de Forgejo, el fork open source de Gitea.

El ataque fue trivial. El error, mío.

El vector fue el CVE-2026-60004, una ejecución remota de código que aprovecha el endpoint diffpatch. El atacante creó una cuenta, subió un repo con un hook post-index-change malicioso y ejecutó lo que quiso. En menos de lo que canta un gallo tenía un minero de cripto corriendo en el contenedor Docker.

Pero aquí viene lo que me dolió: el ataque no fue posible por una zero-day secreta ni por ingeniería social. Fue posible por dos errores humanos que cualquiera de nosotros comete.

Primero: el sign-up estaba abierto. El dueño pensaba que lo había cerrado. Una mala configuración, un checkbox sin revisar, y el atacante creó su cuenta sin fricción.

Segundo: la imagen Docker estaba fijada en la versión v13, que llegó a end-of-life hace seis meses. Sin tag latest, sin actualización automática, sin nadie mirando los release notes. El parche ya existía en las versiones v15 LTS y v16, pero nadie le había dado click al botón de update.

Esto no es un post de un whitepaper, es una confesión.

Si eres como yo, que tienes varios VPS corriendo cosas en Docker para la pega o para changas, sabes que mantener todo al día es un dolor de cabeza. Pero este caso me deja una caleta que es obvia pero que no quería ver: el enemigo no es el hacker, soy yo.

El atacante solo buscó una IP con Forgejo, verificó si el endpoint /api/v1/repos/{user}/{repo}/diffpatch respondía, creó un usuario y listo. No hubo exploit zero-day. No hubo magia. Fue un escaneo automatizado contra instancias desactualizadas, exactamente como los que yo hago en mis pentests de la universidad.

Lo que me molesta poquito es que el postmortem original del chico es honesto y bien documentado. Muestra logs de Pangolin, el timeline del ataque, los hashes SHA-256 de los binarios maliciosos, y hasta tiene la decencia de decir que usó un LLM para entender el shell script ofuscado. Eso es más forense del que veo en muchos clientes que pagan por «ciberseguridad».

La lección que guardo en mi .bashrc

Si no puedes parchear rápido, no expongas. Punto. No importa si es un GitLab, un Forgejo, un Nextcloud o un WordPress viejo. Si tu contenedor tiene una versión fija y nadie se acuerda de actualizarla, eventualmente alguien va a encontrar el CVE y va a entrar.

También me deja pensando en la forma en que administramos nuestra propia infraestructura. En mi caso, Tokio tiene scripts de update automático para algunos servicios, pero otros los tengo con versiones fijadas porque «así funciona». Después de leer esto, hoy mismo revisé mis contenedores. Si encontré algo con EOL, lo actualicé. Si no podía actualizar, lo bajé del firewall.

Y tú, ¿cuándo fue la última vez que revisaste los tags de tus imágenes Docker? ¿Sabes si tus sign-ups están realmente cerrados? No esperes a que Komodo te avise con una alerta de CPU al 95% para darte cuenta de que ya es tarde.

Fuente de inspiración: My Homelab Got Hacked – A Postmortem