FFmpeg tiene 100+ CVEs. ¿Seguís corriendo uno propio?
Si estás procesando video en un servidor que vos administrás con FFmpeg, tenés más de 100 CVEs conocidas que son tu problema. Una API de transcodificación de video segura cambia ese modelo por completo: mandás un HTTP request, la infraestructura aislada procesa el video, y recibís el resultado. Tu superficie de ataque pasa de “un servidor FFmpeg entero” a “una API key”.
En 30 segundos
- FFmpeg tiene más de 100 CVEs documentadas; cada una es responsabilidad del equipo que lo administra.
- El modelo managed (API) reduce la superficie de ataque a una sola credencial de autenticación.
- Transcodificación segura implica tres cosas: HTTPS en tránsito, autenticación por Bearer token, y archivos que no persisten tras el procesamiento.
- JWT + reverse proxy delante de FFmpeg self-hosted no resuelve el problema de fondo.
- Alternativas managed en 2026: Google Transcoder API, AWS MediaConvert, Shotstack, Mux, Cloudinary.
El problema: más de cien vulnerabilidades en FFmpeg
FFmpeg es una maravilla de ingeniería. También es un software con más de 100 CVEs conocidas. Heap-use-after-free, buffer overflows, memory leaks. La CVE-2025-25469, por ejemplo, es un memory leak que permite DoS contra servidores de medios: mandás ciertos streams malformados y el proceso empieza a consumir RAM hasta que cae.
El problema no es FFmpeg en sí. El problema es lo que implica correrlo en infraestructura propia.
Cada CVE que aparece es tu problema. Parchar, verificar que el parche no rompa nada, volver a desplegar. Si tenés múltiples entornos, multiplicá ese trabajo. Y si el sistema de CI/CD de turno tarda en aprobar cambios de infraestructura (que sí, pasa todo el tiempo), estás corriendo con una versión vulnerable mientras tanto.
Lo que nadie te cuenta es que muchos equipos de producto que usan FFmpeg auto-hosteado nunca actualizan versiones. Subieron FFmpeg 4.x hace tres años, funciona, y nadie lo toca porque “si funciona, no lo toques”. Eso en un servidor que procesa videos de usuarios externos es una invitación abierta.
Costo oculto del self-hosted: no es solo parchear
Ponele que decidís mantener FFmpeg en tu propio servidor. La cadena de seguridad que tenés que sostener va mucho más allá del parche ocasional:
- Patching continuo: monitorear CVEs, evaluar impacto, testear en staging, desplegar. Ciclo que no termina.
- Aislamiento de red: el proceso de FFmpeg no debería tener acceso libre a la red interna. Requiere reglas de firewall, namespaces o contenedores bien configurados.
- Control de acceso: ¿quién puede disparar trabajos de transcodificación? ¿Hay autenticación antes de llegar al binario?
- Permisos de almacenamiento: los archivos temporales tienen que ir a algún lado. Un bucket S3 mal configurado con permisos abiertos y archivos de video de usuarios es un escenario que le pasó a más de un equipo.
- Sanitización de logs: FFmpeg loguea paths de archivos. Si esos paths tienen información sensible (nombres de usuario, IDs internos), tenés que asegurarte de que los logs no sean accesibles.
Todo eso antes de escribir una sola línea del código que realmente querés escribir: el procesamiento de video. Más contexto en integrar APIs en tus proyectos.
Qué significa realmente “transcodificación segura”
La mayoría de las guías sobre transcodificación segura arrancan desde el lugar equivocado. Te explican cómo poner JWT y un reverse proxy delante de tu servidor FFmpeg. Eso es poner una cerradura en una puerta que no necesitás abrir.
Según el análisis publicado en dev.to, transcodificación segura implica tres cosas concretas:
- Seguridad en tránsito: cada byte viaja por HTTPS. Sin video en texto plano en el cable.
- Autenticación: solo tu código puede disparar trabajos. Sin acceso anónimo ni credenciales compartidas.
- Ciclo de vida de datos: los archivos de video no persisten después del procesamiento salvo que vos explícitamente los guardes.
¿Y qué pasó cuando los equipos intentaron resolver esto con JWT + nginx frente a FFmpeg? Exacto: resolvieron el punto de entrada pero dejaron expuesto todo lo de atrás. El proceso de FFmpeg sigue corriendo con las mismas vulnerabilidades, los archivos temporales siguen existiendo, y el aislamiento de red sigue siendo responsabilidad tuya.
API managed vs. servidor propio: la diferencia de modelo
Una API de transcodificación managed da vuelta la ecuación de seguridad. Vos mandás un HTTP request con el video. La API lo procesa en infraestructura aislada que vos no administrás. Recibís el resultado.
Tu superficie de ataque en ese modelo es una API key. No un servidor con FFmpeg, no un sistema de archivos con permisos complejos, no logs que hay que sanitizar. Una credencial.
El proveedor se hace cargo de mantener el software actualizado, del aislamiento entre trabajos de distintos clientes, del ciclo de vida de los archivos temporales. Es responsabilidad compartida, y la parte más pesada la tiene quien diseñó el sistema para eso.
Autenticación: por qué Bearer token en header y no API key en query string
Hay una diferencia que importa entre estas dos formas de autenticar:
POST /transcodes?api_key=abc123POST /transcodesconAuthorization: Bearer abc123en el header
La primera opción mete la credencial en la URL. Las URLs aparecen en logs de servidores, en el historial del navegador, en los referer headers cuando hay redirects. Una API key en query string es una credencial que ya estuvo expuesta antes de que te des cuenta. Sobre eso hablamos en almacenamiento escalable de metadatos.
El Bearer token en header Authorization no viaja en la URL. Si alguien captura el log del servidor, no ve la credencial. Si hay un redirect, no se filtra en el Referer.
El ejemplo concreto que muestra FFmpeg Micro (una de las APIs del mercado) es directo:
POST https://api.ffmpeg-micro.com/v1/transcodes- Header:
Authorization: Bearer YOUR_API_KEY - Header:
Content-Type: application/json
Sin parámetros en la URL. Sin credenciales expuestas en logs. Es la forma correcta, y cualquier API que todavía te pida la key en query string (en 2026) viene flojo.
Ciclo de vida de datos: el problema del bucket con archivos huérfanos
Cuando procesás video con FFmpeg self-hosted, el archivo tiene que estar en algún lado durante el procesamiento. Creás un archivo temporal, FFmpeg lo lee, genera el output, y después… ¿qué? Si el job termina bien, podés limpiar. Si el job falla a mitad de camino (lo que pasa seguido con archivos corruptos o streams inesperados), el archivo temporal queda ahí.
Multiplicá eso por miles de jobs y tenés un directorio o bucket S3 lleno de archivos de video de usuarios que nadie borró (si es que el bucket tiene permisos abiertos, son accesibles para cualquiera que adivine el path).
En el modelo managed, los archivos no persisten después del procesamiento salvo que vos explícitamente los guardes. El proveedor maneja el ciclo de vida. No hay archivos huérfanos porque la plataforma fue diseñada para limpiarlos. Lo explicamos a fondo en automatización de pipelines de video.
Esto parece obvio hasta que te pasa. Y le pasó a equipos con recursos.
Alternativas a FFmpeg self-hosted en 2026
Si estás evaluando migrar, estas son las opciones principales con criterio de seguridad como variable central, no solo features o precio:
| Servicio | Proveedor | Modelo de seguridad | Costo base | Foco |
|---|---|---|---|---|
| Transcoder API | Google Cloud | IAM + infraestructura aislada por job | USD 0.015/min SD | Escala enterprise, integración GCP |
| MediaConvert | AWS | IAM Roles + VPC, sin servidor compartido | USD 0.0075/min SD | Workflows complejos, alto volumen |
| Shotstack | Independiente | API key + jobs aislados | Plan dev gratuito, USD 49/mes base | Video programático, renders rápidos |
| Mux | Independiente | Bearer token + signed URLs | USD 0.0115/min almacenado | Streaming, player integrado |
| Cloudinary | Independiente | API key + transformaciones on-the-fly | Plan gratuito, USD 89/mes base | Imágenes y video, transformaciones rápidas |
Ojo con el criterio de comparación: si tu prioridad es seguridad, la pregunta no es “¿cuántos formatos soporta?” sino “¿cómo maneja el aislamiento entre jobs?”, “¿los archivos persisten sin que yo lo pida?”, y “¿cómo manejo credenciales?”.
La Transcoder API de Google Cloud tiene la ventaja de que si ya usás GCP, el modelo de IAM es el mismo de toda la plataforma. No es una credencial separada que gestionar. Si en cambio estás en AWS, MediaConvert con IAM Roles es la opción natural por la misma razón.
Para proyectos más chicos o equipos que no quieren quedar atados a un cloud provider, Shotstack y Mux son opciones razonables. Shotstack en particular tiene documentación específica para equipos migrando desde FFmpeg self-hosted.
Si tu infraestructura está en la nube y necesitás hosting confiable para los servicios que rodean la pipeline de video, donweb.com tiene opciones de cloud y VPS para alojar los componentes de tu stack que sí necesitan servidor propio.
Errores comunes al migrar de FFmpeg self-hosted
Pensar que el problema es solo el binario
Muchos equipos migran la ejecución de FFmpeg a un contenedor y creen que resolvieron el problema de seguridad. El contenedor corre el mismo FFmpeg con las mismas vulnerabilidades, en infraestructura que vos seguís administrando. Cambiaste la forma de desplegarlo, no el modelo de seguridad.
Meter la API key en variables de entorno sin más
Una API key en una variable de entorno es mejor que hardcodeada, pero si ese entorno es un servidor compartido o un repositorio donde alguien metió un .env sin querer, el resultado es el mismo. Las credenciales de APIs de transcodificación tienen que pasar por un sistema de secrets management (AWS Secrets Manager, Google Secret Manager, HashiCorp Vault), no vivir en archivos de configuración.
No revisar el ciclo de vida de archivos del proveedor
Asumir que el proveedor borra todo automáticamente sin leer la documentación es una apuesta arriesgada. Algunos servicios tienen períodos de retención por defecto (24h, 7 días, indefinido con costo adicional de storage). Verificá explícitamente qué pasa con los archivos después de que el job termina. Si el proveedor los retiene por defecto y vos no lo sabías, tus videos de usuarios están guardados en algún servidor que no controlás.
Preguntas Frecuentes
¿Cuántas vulnerabilidades tiene FFmpeg?
Más de 100 CVEs documentadas según el registro público en CVE Details. Incluyen heap-use-after-free, buffer overflows, y memory leaks como CVE-2025-25469 que permite ataques de denegación de servicio contra servidores de medios. Cada una es responsabilidad del equipo que administra la instalación. Ya lo cubrimos antes en opciones de procesamiento en nube.
¿Cómo transcodificar videos de forma segura sin servidor propio?
Usando una API managed de transcodificación como Google Transcoder API, AWS MediaConvert, o Shotstack. Mandás el video vía HTTP con Bearer token en el header Authorization, la plataforma lo procesa en infraestructura aislada, y devuelve el resultado. No hay servidor que mantener, no hay FFmpeg que parchear.
¿Por qué es inseguro mantener un servidor FFmpeg propio?
Porque cada vulnerabilidad nueva en FFmpeg es tu problema operativo: parchear, verificar que no rompa nada, volver a desplegar. A eso sumale aislamiento de red, control de acceso, permisos de archivos temporales y logs. Si el equipo no tiene procesos activos de patch management, lo más probable es que el servidor esté corriendo una versión vulnerable durante semanas o meses.
¿Cuál es la mejor API para transcodificación de video en 2026?
Depende del contexto. Si ya usás GCP, la Transcoder API de Google Cloud a USD 0.015/min SD tiene la ventaja de integrarse al IAM que ya administrás. Si estás en AWS, MediaConvert a USD 0.0075/min SD es la opción natural. Para proyectos más chicos sin dependencia de cloud provider, Mux o Shotstack son opciones razonables con buen modelo de seguridad por defecto.
¿JWT y un reverse proxy delante de FFmpeg es suficiente?
No. JWT y un reverse proxy resuelven el punto de entrada pero no el problema de fondo: FFmpeg sigue corriendo con sus vulnerabilidades, los archivos temporales siguen existiendo en infraestructura que vos administrás, y el aislamiento entre trabajos sigue siendo responsabilidad tuya. Es una capa adicional, no una solución al modelo de seguridad.
Conclusión
El cambio de modelo no es menor. Si pasás de FFmpeg self-hosted a una API managed, no estás “tercerizando el problema”: estás cambiando quién es responsable de qué. Vos dejás de administrar un servidor con 100+ CVEs potenciales y pasás a gestionar una credencial.
Para la mayoría de los equipos que procesan video como parte de una aplicación (sin que sea su negocio principal), ese intercambio tiene sentido. El tiempo que ahorran en patch management y hardening de infraestructura lo pueden invertir en lo que realmente les importa.
Si tu caso es diferente (regulaciones que requieren control total de la infraestructura, volúmenes donde los costos de API se vuelven prohibitivos, o requirements de latencia muy estrictos), la ecuación cambia. Pero para el 80% de los casos, la API managed gana por simplicidad y por carga operativa.
La pregunta no es “¿es FFmpeg seguro?”. FFmpeg como proyecto tiene sus procesos de seguridad. La pregunta es “¿tengo los procesos operativos para mantenerlo seguro en mi infraestructura?”. Y la respuesta honesta, en la mayoría de los equipos, es que no.
