Velocity packet decoding memory leak cómo corregirlo con Build 563
Si usas Velocity como proxy (lobby / network / multiserver) y de repente ves RAM subiendo sin razón, GC pegándose tiros y el proceso muriendo por OOM… hay un motivo muy probable: un memory leak en el “packet decoding” que se estuvo moviendo en la comunidad como exploit.
La buena noticia: PaperMC ya lo parcheó. La mala: si estás en versiones anteriores a Build 563, sigues expuesto.
Qué es el “packet decoding memory leak” en Velocity
Velocity procesa tráfico de red constantemente. Cuando un cliente manda datos, pasan por decodificadores (Netty) que convierten bytes en “paquetes” entendibles.
El problema aquí fue un leak de ByteBuf (buffers de Netty). En términos humanos: memoria que debería liberarse, no se libera, y con suficiente ruido termina en consumo de RAM brutal, GC agresivo y posible crash.
No hace falta que tu proxy “tenga mucha gente”: si alguien abusa del vector, el proxy se puede ir al suelo con pocos jugadores reales.
Versiones afectadas
Afectadas: Velocity Build < 563
Corregido: Velocity 3.4.0-SNAPSHOT Build #563
Qué arregla exactamente Build 563
En el changelog oficial del build, PaperMC lista el fix como:
“Fix ByteBuf memory leak in MinecraftVarintFrameDecoder” (PR #1715)
Esto es clave porque MinecraftVarintFrameDecoder está literalmente en la ruta caliente del tráfico: si eso gotea memoria, se siente rapidísimo.
Extra: en builds previos también aparece un endurecimiento útil:
“Restrict empty packet frames from clients” (Build #561)
Aunque eso no reemplaza el parche del leak, sí suena a “vamos a cerrar puertas raras”.
Cómo verificar qué build estás corriendo
Opciones rápidas (elige tu veneno):
Por el nombre del .jar
Si tu archivo se llama algo como:
velocity-3.4.0-SNAPSHOT-562.jar→ estás vulnerablevelocity-3.4.0-SNAPSHOT-563.jar→ ya traes el fix
Por el log de arranque
Velocity normalmente imprime versión/build al iniciar. Si ves algo menor a 563, toca update.
Cómo actualizar Velocity y evitar el drama
La forma segura y estándar:
Descarga el último build desde PaperMC (Build #563 o superior).
Detén el servicio de Velocity.
Reemplaza el .jar por el nuevo (ideal: conserva el nombre o ajusta tu systemd).
Inicia y revisa logs para confirmar build.
PaperMC también lo deja claro en su doc de “getting started”: descargar desde su página oficial y correrlo desde una carpeta dedicada.
Actualizar en TCP
Dirígete al apartado de versiones y usa el botón de actualizar a Build 563.
Mitigaciones recomendadas si no puedes actualizar hoy
Actualizar es el fix real. Pero si andas en modo “producción ardiendo”:
Rate limiting de conexiones nuevas al puerto del proxy (firewall / proxy TCP / proveedor) para bajar spam.
Si puedes, protección L4 delante (reverse proxy TCP / anti-DDoS) para filtrar basura antes de que toque Netty.
Monitorea: RAM, GC, conexiones nuevas por minuto, y reinicios inesperados.
Ojo: esto no “cura” el leak, solo baja la probabilidad de que te lo exploten.
Links oficiales que sí importan
Velocity Downloads (Build 563): https://papermc.io/downloads/velocity
Commit (Build 563 fix): https://github.com/PaperMC/Velocity/commit/3022793418739656aa35584eadce104897b82f8c
PR/Issue #1715: https://github.com/PaperMC/Velocity/issues/1715
Build 561 hardening commit: https://github.com/PaperMC/Velocity/commit/a03bd884aa7a53744b4e85b44cdf124ddb744526
