Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Las dependencias amplían el periodo de exposición, ya que las versiones de Celery en fase de fin de vida útil (EOL) te mantienen vinculado a ramas antiguas de kombu, billiard y vine que ya no reciben actualizaciones de seguridad retroactivas.
- Las actualizaciones precipitadas son costosas y arriesgadas, ya que pasar de Celery 4.x a 5.x puede provocar cambios en el tiempo de ejecución, la interfaz de línea de comandos, el backend y las dependencias que interrumpan los flujos de trabajo en producción.
- El fin de la vida útil (EOL) de Celery no supone el fin de la seguridad, ya que TuxCare ELS sigue ofreciendo cobertura para las versiones de Celery que han llegado al fin de su vida útil mientras realizas la actualización según tu propio calendario.
Si estás ejecutando cualquier tipo de tarea de procesamiento en segundo plano en Python, es muy probable que Celery esté involucrado en ella. Envío de correos electrónicos, generación de informes, procesamiento de pagos, flujos de inferencia de aprendizaje automático, exportaciones de datos programadas… Celery se encarga del trabajo asíncrono que mantiene en funcionamiento las aplicaciones de producción. Lleva haciéndolo desde hace casi 17 años, se descarga casi 50 millones de veces al mes en PyPI y es el tipo de infraestructura que desaparece discretamente en segundo plano en cada pila en la que se integra.
Y precisamente por eso las situaciones de fin de vida útil (EOL) de Celery suelen pillar a los equipos desprevenidos.
Celery no cuenta con una política formal de soporte a largo plazo. El proyecto establece explícitamente que ofrece soporte para la serie 5.x actual hasta que se lance Celery 6.x, y Celery 4.x dejó de recibir soporte una vez que la versión 5.x alcanzó la estabilidad. No hay un periodo de mantenimiento, ni un calendario de retroportes, ni un compromiso de parches de seguridad para las versiones anteriores. Cuando una versión queda obsoleta, se da por terminada.
Así pues, si estás utilizando una versión de Celery que ha llegado al final de su ciclo de vida (EOL), ya sea una 4.x o una versión 5.x fijada más antigua que va unas cuantas versiones menores por detrás, en la práctica ya te encuentras en una situación de fin de vida útil. Hablemos de lo que eso significa realmente para tus colas de tareas en producción.
Cómo funcionan realmente las publicaciones de Celery
Antes de profundizar en lo que significa «EOL» desde el punto de vista operativo, conviene entender cómo gestiona Celery su propio ciclo de vida de versiones, ya que el proyecto es inusualmente transparente al respecto.
Celery fue creado por Ask Solem y se lanzó por primera vez en 2009. La serie 4.x se mantuvo activa desde 2016 hasta aproximadamente 2021, cuando se lanzó Celery 5.2. En ese momento, el equipo del proyecto anunció explícitamente que ya no disponía de los recursos necesarios para mantener Celery 4.x. Desde entonces, esta línea ha dejado de recibir soporte técnico y no se han publicado parches de seguridad para ninguna versión de la serie 4.x.
La actual serie 5.x seguirá el mismo patrón en el futuro: Celery 5.x seguirá recibiendo soporte hasta que se lance Celery 6.x. No existe una designación LTS ni un anuncio oficial sobre cuándo una versión menor de la serie 5.x dejará de recibir correcciones. El proyecto simplemente sigue avanzando, y las versiones fijadas que se quedan atrás acumulan vulnerabilidades sin parchear.
La política de compatibilidad con las versiones de Python lo deja claro. Celery 5.0 requería Python 3.6 o superior. Celery 5.2 dejó de ser compatible con Python 3.6. Celery 5.4 dejó de ser compatible con Python 3.7. Celery 5.6 dejó de ser compatible con Python 3.8, pasando a requerir como mínimo Python 3.9. La versión estable actual es la 5.6.x. Si estás utilizando cualquier versión anterior, estás ejecutando un software para el que el proyecto ya no ofrece parches de forma activa.
Aquí no hay seguridad parcial. Un equipo que utilice Celery 4.4.7 con un archivo de requisitos bloqueado no se encuentra en una «ventana de mantenimiento»; está por su cuenta.
Qué significa realmente el fin de vida útil (EOL) de Celery para tu entorno de producción
Tus procesos están en marcha, tus tareas se están ejecutando y tus colas parecen estar en buen estado. No hay ningún problema grave. Entonces, ¿por qué es importante el fin de la vida útil de algo tan invisible desde el punto de vista operativo?
Los investigadores de seguridad no esperan a que actualices el software para detectar vulnerabilidades. Los atacantes se centran específicamente en el software de infraestructura ampliamente implantado que se ejecuta en versiones al final de su ciclo de vida (EOL), precisamente porque saben que no se van a publicar parches. Y Celery es uno de los programas de infraestructura de Python más utilizados que existen.
Las versiones de Celery que han llegado al final de su ciclo de vida (EOL) entrañan riesgos de seguridad documentados, y la naturaleza de las vulnerabilidades resulta especialmente preocupante para la infraestructura de colas de tareas.
CVE-2021-23727 (CVSS 7.5, High): A stored command injection vulnerability affecting all Celery versions before 5.2.2. By default, Celery trusts the messages and metadata stored in result backends without validation. When reading task metadata from the backend, the data is deserialized using a function that performs recursive attribute lookups based on a Python dotted path, loading whatever module and class the stored metadata specifies. An attacker who can access or manipulate metadata in the Celery result store can inject a payload like {‘exc_module’: ‘os’, ‘exc_type’: ‘system’, ‘exc_message’: ‘your_command’} and have it executed as an OS command when the worker processes that task result. The result: arbitrary command execution on the worker host, with potential for full system takeover or lateral movement into the broader infrastructure. IBM flagged this CVE in security advisories for multiple enterprise products, including IBM Spectrum Protect Plus and IBM QRadar. It affects every Celery deployment on a version before 5.2.2 that uses a result backend, which is the overwhelming majority of production Celery setups.
Si utilizas Celery 4.x, estás expuesto a esta vulnerabilidad y no hay ningún parche oficial disponible para tu versión. Si utilizas una versión 5.x anterior a la 5.2.2, la situación es la misma.
Más allá de las vulnerabilidades directas del propio Celery, los marcos de cumplimiento no son indulgentes con el software de infraestructura que ya no recibe soporte. La norma PCI DSS exige que las vulnerabilidades de alta gravedad se corrijan en un plazo de 30 días. Los auditores de SOC 2 preguntan específicamente por el software sin soporte en los entornos de producción. El uso de versiones de Celery que han llegado al final de su vida útil (EOL) se considera una carencia en la documentación en todas las auditorías de seguridad a las que se somete tu organización.
El riesgo oculto: tu cadena de dependencias
Cuando los equipos evalúan la seguridad de Celery, suelen centrarse en la propia cola de tareas, los grupos de trabajadores, el enrutamiento de tareas y la limitación de tasa. Es un punto de partida razonable, pero no tiene en cuenta hasta dónde se extiende realmente la ventana de exposición.
Todas las dependencias principales de Celery se mantienen bajo el mismo paraguas del proyecto Celery: kombu (la biblioteca de mensajería que abstrae RabbitMQ, Redis y otros brokers), billiard (la rama de multiprocesamiento que alimenta el grupo de trabajadores prefork) y vine (la biblioteca de promesas/callbacks para la composición de tareas asíncronas). Celery 5.x requiere además click y sus componentes complementarios para la CLI. No se trata de complementos opcionales, sino que son imprescindibles para que cualquier instalación de Celery funcione.
The version pinning relationship matters here. Celery 4.4.7 requires kombu <4.7,>=4.6.10 and billiard <4.0,>=3.6.3.0. Celery 5.3.x requires kombu <6.0,>=5.3.4. These are hard constraints. When you’re pinned to a Celery EOL version, you’re also pinned to old ranges of all the core dependencies, and the Celery project does not backport security patches to those older kombu, billiard, or vine branches.
Kombu se encarga de toda la serialización y deserialización de mensajes para la comunicación con el broker de Celery. Billiard gestiona el grupo de trabajadores. Si se detecta una vulnerabilidad CVE en la versión fijada de cualquiera de ellos, esta permanecerá sin parchear, al igual que la propia versión de Celery que ha llegado al final de su vida útil (EOL).
El resultado es una ventana de exposición cada vez mayor. pip audit puede señalar las CVE en tus paquetes instalados una vez que se han hecho públicas, pero no puede aplicar correcciones retroactivamente a versiones de paquetes que han llegado al final de su vida útil (EOL). La superficie de vulnerabilidad abarca todo el árbol de dependencias, no solo la capa de la cola de tareas en la parte superior.
Tus opciones cuando el apio llega al final de su vida útil
Así que tu versión de Celery ha llegado al final de su ciclo de vida (EOL), o va por ese camino. ¿Cuáles son tus opciones realistas de ahora en adelante?
Dos de ellas conllevan un elevado coste, una gran planificación y riesgos operativos. La tercera —la ampliación del soporte técnico— es la opción que realmente resuelve el problema de seguridad sin obligarte a realizar una migración para la que aún no estás preparado, y es la que la mayoría de los equipos desearían haber descubierto antes.
Opción 1: Actualizar a una versión reciente de Celery
La respuesta oficial: actualízate a la última versión de Celery 5.6.x, disfruta de una cobertura de seguridad activa y aprovecha las mejoras de estabilidad que el proyecto ha ido incorporando a lo largo de varias versiones menores.
Y la versión actual de Celery es, sin duda, mejor. Se han solucionado las fugas de memoria en la gestión de excepciones. Se han resuelto los problemas de estabilidad del broker de Redis que afectaban a las versiones anteriores de la serie 5.x. Se ha añadido compatibilidad con Python 3.13 y 3.14. Para los equipos que trabajan con códigos en constante mantenimiento, actualizar es la decisión más acertada a largo plazo.
Pero actualizar un sistema de producción en una versión de Celery que ha llegado al final de su ciclo de vida (EOL) se hace así:
La compatibilidad con Python 2 ha desaparecido por completo: Celery 5.x ha dejado de ser compatible con Python 2 por completo. Si alguna parte del código de tus tareas o de tus backends personalizados se basaba en patrones de Python 2, es necesario solucionarlo antes de que la actualización sea siquiera posible. Para las organizaciones con aplicaciones Django heredadas que aún ejecutan flujos de trabajo en Python 2.7 a través de Celery 4.x, este no es un cambio menor; se trata de una migración en tiempo de ejecución que afecta a toda la pila de la aplicación.
Cambios importantes en la CLI: La CLI de Celery 5.0 se ha reescrito utilizando Click. Las opciones globales que antes iban a continuación del subcomando ahora deben ir antes de este. Comandos como celery worker –app path.to.app se han convertido en celery –app path.to.app worker. Es necesario revisar y actualizar cualquier script de implementación, comando de inicio de contenedores, especificaciones de pods de Kubernetes o archivos de unidad de systemd que invoquen a los trabajadores de Celery.
Backends y módulos eliminados: El backend de resultados AMQP se ha eliminado por completo en Celery 5.0. El celery.utils.encoding y celery.task se han eliminado. Las importaciones que funcionaban en Celery 4.x ahora generan un error ImportError. Cualquier tarea personalizada que utilice from celery.task import Task deben actualizarse a from celery import Task. Cualquier código que utilice Celery.shared_task a través de la ruta antigua debe actualizarse de forma equivalente.
Kombu version incompatibility: Celery 4.x requires kombu <4.7. Celery 5.6.x requires kombu >=5.6. There’s no incremental path here; this is a hard dependency jump that affects how your Celery application connects to RabbitMQ, Redis, and any other broker you’re using. Broker connection behavior, serialization defaults, and connection pooling all changed between kombu 4.x and 5.x.
Migración de pytz a zoneinfo: Celery 5.3 ha sustituido pytz por el módulo zoneinfo integrado en Python para la gestión de zonas horarias, pasando a utilizar tzdata como dependencia de la base de datos de zonas horarias. Es necesario revisar todas las tareas que dependan de objetos de zona horaria específicos de pytz en su lógica de programación.
¿Se trata de un código fuente pequeño con unas pocas tareas? Esta actualización es un sprint específico. ¿Se trata de un sistema de producción maduro con docenas de definiciones de tareas, backends personalizados, automatización de la implementación y años de patrones acumulados en torno a la antigua CLI? En ese caso, te espera una planificación minuciosa, pruebas exhaustivas y un riesgo real de que las cadenas de tareas se interrumpan bajo la carga de producción.
Opción 2: Migración a marcos alternativos
Algunos equipos, ante la situación del fin de vida útil (EOL) de Celery, consideran que es el momento de replantearse todo el enfoque.
Dramatiq, RQ (Redis Queue), Huey u opciones nativas de la nube como AWS SQS con Lambda son todas alternativas válidas, cada una con sus ventajas e inconvenientes específicos que podrían adaptarse mejor a tu situación.
Pero seamos sinceros sobre lo que implica la migración de un marco de trabajo. No se trata simplemente de cambiar una biblioteca. Se trata de reescribir cada definición de tarea utilizando los patrones de decorador y de clase del nuevo marco de trabajo. Se trata de sustituir las primitivas de «canvas» de Celery (cadenas, acordes, grupos) por lo que utilice el nuevo marco de trabajo para la composición de tareas, si es que lo admite. Estás reconstruyendo tu configuración de monitorización, la configuración de despliegue de los trabajadores, tu lógica de reintentos y retrasos, y la integración con el backend de resultados. Y estás haciendo todo esto mientras mantienes el sistema existente en funcionamiento en producción.
Las ventajas arquitectónicas a largo plazo pueden justificar sin duda alguna esta labor en el contexto adecuado. El plazo y el coste reales casi siempre superan con creces las estimaciones iniciales. Y el periodo durante el cual los trabajadores de producción utilizan una versión de Celery al final de su ciclo de vida (EOL) mientras se lleva a cabo la migración es precisamente el periodo de riesgo que se intentaba eliminar.
Opción 3: Asistencia técnica ampliada de terceros
Existe una tercera vía a la que no se le presta la atención que merece: el soporte de seguridad ampliado que ofrecen empresas especializadas precisamente en este problema.
TuxCare ofrece soporte técnico de ciclo de vida ilimitado para las versiones de Celery que han llegado al final de su vida útil (EOL). En lugar de verte obligado a realizar una migración para la que aún no estás preparado, o de dejar tus colas de tareas expuestas mientras la planificas, puedes seguir utilizando tu versión actual de Celery, pero con cobertura continua de parches de seguridad.
La lógica es sencilla: ganas tiempo y control. Tiempo para planificar una actualización adecuada cuando realmente encaje en tu hoja de ruta de ingeniería. Control sobre tu calendario de migración, en lugar de verte obligado a actuar por la publicación de un CVE que te obliga a tomar medidas en el peor momento posible, de esos que se producen un viernes por la tarde.
El verdadero coste de precipitarse al actualizar Celery EOL
Hablemos de lo que ocurre realmente cuando los equipos se ven obligados a acelerar una migración de Celery al final de su ciclo de vida (EOL) en un plazo poco realista porque una auditoría de seguridad acaba de señalar que se está utilizando una versión que ya no recibe soporte.
Aumento de la carga de soporte: Las diferencias de comportamiento entre Celery 4.x y 5.x que no se habían detectado en el entorno de pruebas empiezan a aparecer en producción. Tareas que se completaban sin problemas en Celery 4.x ahora muestran errores que antes se ocultaban. Fallos en la invocación de la CLI en los scripts de implementación que parecían funcionar bien en las pruebas. El comportamiento del grupo de conexiones de Kombu es ligeramente diferente bajo un alto rendimiento. La cola de guardia se llena de incidencias que se remontan todas a la migración.
Inestabilidad del sistema: Las implementaciones de Celery EOL se ejecutan en entornos distribuidos con múltiples nodos de trabajo, brokers compartidos y backends de resultados compartidos. Las sutiles incompatibilidades en la forma en que las diferentes versiones de Celery gestionan la serialización de tareas o el almacenamiento de resultados pueden provocar fallos que son extremadamente difíciles de reproducir fuera de la carga de producción. Estos son los problemas que generan alertas a las 3 de la madrugada y dejan a los ingenieros realmente descontentos.
Acumulación de deuda técnica: En el afán por cumplir con los requisitos, se añaden soluciones de compatibilidad. Los módulos de tareas se envuelven con bloques «try/except ImportError» . A las antiguas opciones de la CLI se les asignan alias mediante scripts envolventes con comentarios del tipo «arreglar esto como es debido más adelante». Seis meses después de la migración, técnicamente estás en la versión actual de Celery, pero ejecutando una infraestructura llena de soluciones provisionales que hacen que la próxima actualización sea aún más difícil.
Excesos presupuestarios: La estimación inicial era de cuatro semanas. Diez semanas después, sigues depurando el comportamiento de la conexión con el broker y persiguiendo fallos intermitentes en las tareas que solo aparecen bajo carga de producción. El contratista al que se ha recurrido para ayudar sigue facturando. El trabajo previsto para nuevas funcionalidades se ha retrasado dos trimestres. El coste de oportunidad de que tus ingenieros sénior de backend se dediquen a depurar casos extremos de serialización de Celery en lugar de desarrollar un producto es muy real.
La actualización es la solución adecuada a largo plazo. Una migración apresurada de Celery al final de su ciclo de vida (EOL), impulsada por la presión del cumplimiento normativo, es un modo de fallo concreto y totalmente predecible. No son lo mismo.
La solución sencilla: TuxCare ELS para las versiones de Celery que han llegado al final de su vida útil
Aquí es donde el servicio de soporte de ciclo de vida ilimitado de TuxCare para Celery cambia realmente las reglas del juego.
TuxCare lleva más de una década dedicándose a esto, proporcionando parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y marcos de aplicaciones que han llegado al final de su ciclo de vida. Han distribuido más de 220 000 parches de seguridad en todo el ecosistema de código abierto. Cuando afirman que saben cómo mantener seguro el software que ha llegado al final de su ciclo de vida a escala empresarial, lo han demostrado realmente a gran escala, en repetidas ocasiones, para algunas de las organizaciones más grandes del mundo.
¿Qué diferencia al enfoque de TuxCare?
Cobertura completa de la cadena de dependencias: Esto es especialmente importante para Celery, dada la estrecha dependencia de la funcionalidad del marco de trabajo respecto a kombu, billiard y vine. TuxCare no se limita a aplicar parches al propio Celery, sino que cubre tus dependencias directas y las dependencias transitivas subyacentes, todo ello sin coste adicional. Los problemas de seguridad de kombu, las vulnerabilidades de billiard, la exposición de vine… TuxCare lo tiene todo cubierto. No solo estás protegiendo la cola de tareas; estás protegiendo toda la pila de dependencias de Celery.
Proceso de aplicación de parches automatizado y optimizado: El proceso de TuxCare combina una automatización avanzada con la validación de expertos. Supervisan el NVD, los avisos de seguridad de los proveedores, los feeds de seguridad de GitHub y todos los lugares donde se dan a conocer las vulnerabilidades de Celery EOL. Cuando se publica un CVE, utilizan herramientas algorítmicas y automatización asistida por IA para aplicar retroactivamente las correcciones de seguridad a las versiones fuera de ciclo de vida; a continuación, los expertos en seguridad validan cada parche antes de su distribución. Cada actualización se somete a pruebas de integridad, funcionalidad y regresión antes de llegar a tus repositorios. ¿Quieres ver exactamente cómo funciona esto? Echa un vistazo al el informe técnico de TuxCare sobre su proceso de aplicación de parches de código abierto.
Integración perfecta: Los parches de TuxCare se integran directamente en tu flujo de trabajo actual con pip. Tanto si utilizas pip, Poetry o cualquier gestor de paquetes estándar de Python, los paquetes ELS funcionan a la perfección. No tendrás que reformar tus procesos de implementación ni volver a formar a tu equipo. Seguirás utilizando exactamente lo que ya tienes configurado.
Respuesta rápida respaldada por un acuerdo de nivel de servicio (SLA): Cuando se dan a conocer nuevas vulnerabilidades de Celery EOL, TuxCare proporciona parches respaldados por acuerdos de nivel de servicio reales. No tendrás que cruzar los dedos esperando a que alguien acabe adaptando una solución. Recibirás actualizaciones de seguridad listas para su implementación en producción en un plazo garantizado, con asistencia real si algo sale mal.
Relación coste-eficacia: Esto es lo que más sorprende a la mayoría de los equipos sobre el soporte ampliado: suele ser considerablemente más económico que las alternativas. Si se suma el tiempo de ingeniería a las tarifas horarias reales, los ciclos de pruebas, los honorarios de los contratistas, el posible tiempo de inactividad, los retrasos en las funcionalidades y el coste de oportunidad, el soporte ampliado (ELS) suele suponer solo una fracción de ese total. Además, se evita que el equipo se agote en una migración de alta presión bajo la presión del cumplimiento normativo.
Cumplimiento normativo y transparencia: Cada versión de TuxCare ofrece una visibilidad completa de los parches aplicados: qué CVE se han solucionado, qué componentes se han modificado y cómo verificarlo todo en la lista de materiales de software (SBOM). Eso es exactamente lo que necesitas para las auditorías de PCI DSS, las revisiones de SOC 2 y cualquier otro marco de cumplimiento normativo que plantee preguntas concretas sobre el software en fin de vida útil que se utiliza en producción.
Cómo empezar
Si estás utilizando versiones de Celery que han llegado al final de su vida útil (EOL) y quieres saber qué cobertura hay realmente disponible, TuxCare mantiene un rastreador de CVE en tiempo real donde puedes consultar las vulnerabilidades y las correcciones disponibles para Celery.
¿Quieres conocer todos los detalles sobre las versiones compatibles, los precios y la implementación? Visita el servicio de soporte de ciclo de vida ilimitado de TuxCare para Celery para obtener más información.
No dejes que el fin de la vida útil de Celery ponga en riesgo tus colas de tareas
Celery ha tenido una trayectoria notable. Lleva más de 15 años siendo la columna vertebral del procesamiento de tareas en segundo plano en Python. Se encarga del trabajo asíncrono que hay detrás de algunos de los sistemas de producción más complejos del mundo, y lo hace de forma tan discreta que la mayoría de los ingenieros se olvidan de que existe hasta que surge algún problema.
Pero si estás utilizando versiones de Celery que han llegado al final de su ciclo de vida (EOL) en entorno de producción, ya sea una instalación fijada en la versión 4.4.x o una versión anterior de la serie 5.x, que «siga procesando tareas» no equivale a que «siga siendo seguro».
El fin de la vida útil (EOL) de Celery no tiene por qué suponer un problema. Tienes opciones reales. Puedes planificar una actualización bien meditada a una versión actual de Celery cuando realmente se ajuste a la hoja de ruta de tu equipo. Puedes evaluar si otro marco de trabajo tiene sentido desde el punto de vista arquitectónico para tu situación. O puedes recurrir al soporte ampliado para mantener la seguridad y el cumplimiento normativo mientras tomas esas decisiones según tu propio calendario, en lugar de según el de un escáner de seguridad.
Los equipos que gestionan adecuadamente las situaciones de fin de vida útil (EOL) de Celery identifican los riesgos con antelación, comprenden qué opciones hay realmente disponibles y toman decisiones deliberadas en lugar de reactivas, independientemente del presupuesto o del grado de modernidad del código.
Si el fin de vida útil (EOL) de Celery te preocupa en este momento, merece la pena que te informes sobre lo que ofrece TuxCare. Quizá descubras que proteger lo que ya has desarrollado, mientras planificas la actualización que realmente deseas, es un mejor paso a seguir que precipitarte a realizar una migración para la que aún no estás preparado.
Visita el soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para descubrir cómo el soporte ampliado puede proteger toda su pila de código abierto durante todo el tiempo que lo necesite.
