Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- As dependências ampliam a janela de exposição, pois as versões do Celery em fim de vida útil (EOL) mantêm você vinculado a ramificações mais antigas do kombu, billiard e vine, que não recebem mais atualizações de segurança retroativas.
- Atualizações apressadas são caras e arriscadas, pois a migração do Celery 4.x para o 5.x pode acarretar alterações no ambiente de execução, na interface de linha de comando (CLI), no back-end e nas dependências, o que pode interromper os fluxos de trabalho de produção.
- O fim do ciclo de vida (EOL) do Celery não significa o fim da segurança, pois o TuxCare ELS continua oferecendo suporte às versões do Celery que chegaram ao fim do ciclo de vida enquanto você realiza a atualização de acordo com seu próprio cronograma.
Se você estiver executando qualquer tipo de processamento de tarefas em segundo plano em Python, é muito provável que o Celery esteja envolvido nisso. Entrega de e-mails, geração de relatórios, processamento de pagamentos, pipelines de inferência de ML, exportações programadas de dados — o Celery lida com o trabalho assíncrono que mantém as aplicações de produção em funcionamento. Ele vem fazendo isso há quase 17 anos, é baixado quase 50 milhões de vezes por mês no PyPI e é o tipo de infraestrutura que desaparece discretamente em segundo plano em todas as pilhas de tecnologia com as quais entra em contato.
É exatamente por isso que as situações de fim de vida útil (EOL) do Celery tendem a pegar as equipes de surpresa.
O Celery não possui uma política formal de suporte de longo prazo. O projeto afirma explicitamente que oferece suporte à série 5.x atual até o lançamento do Celery 6.x, e o Celery 4.x deixou de receber suporte assim que a versão 5.x se tornou estável. Não há janela de manutenção, nem cronograma de backport, nem compromisso com patches de segurança para versões mais antigas. Quando uma versão é substituída, o suporte é encerrado.
Portanto, se você estiver usando uma versão do Celery em fim de vida útil (EOL), seja a 4.x ou uma versão 5.x fixada mais antiga que esteja algumas versões menores atrasada, você já está, em todos os sentidos práticos, na fase de fim de vida útil. Vamos falar sobre o que isso realmente significa para suas filas de tarefas em produção.
Como funcionam, na verdade, as versões do Celery
Antes de nos aprofundarmos no que o EOL significa na prática, é importante entender como o Celery gerencia seu próprio ciclo de vida de versões, já que o projeto é excepcionalmente transparente a respeito disso.
O Celery foi criado por Ask Solem e lançado pela primeira vez em 2009. A série 4.x esteve em vigor de 2016 até aproximadamente 2021, quando o Celery 5.2 foi lançado. Nessa ocasião, a equipe do projeto anunciou explicitamente que não dispunha mais de recursos para manter o Celery 4.x. Desde então, essa linha não recebe mais suporte, e não há mais lançamento de patches de segurança para nenhuma versão da série 4.x.
A atual série 5.x seguirá o mesmo padrão daqui para frente: o Celery 5.x terá suporte até o lançamento do Celery 6.x. Não há designação LTS, nem anúncio formal sobre quando uma versão secundária da série 5.x deixará de receber correções. O projeto simplesmente segue em frente, e as versões fixadas que ficam para trás acumulam vulnerabilidades sem correção.
A política de suporte às versões do Python deixa isso bem claro. O Celery 5.0 exigia o Python 3.6 ou superior. O Celery 5.2 deixou de oferecer suporte ao Python 3.6. O Celery 5.4 deixou de oferecer suporte ao Python 3.7. O Celery 5.6 deixou de oferecer suporte ao Python 3.8, exigindo, no mínimo, o Python 3.9. A versão estável atual é a 5.6.x. Se você estiver usando qualquer versão anterior, estará executando um software para o qual o projeto não oferece mais atualizações ativas.
Não há segurança parcial nesse caso. Uma equipe que esteja executando o Celery 4.4.7 com um arquivo de requisitos bloqueado não está em uma “janela de manutenção”; ela está por conta própria.
O que o fim do suporte (EOL) do Celery realmente significa para o seu ambiente de produção
Seus processos estão em execução, suas tarefas estão sendo processadas e suas filas parecem estar em boas condições. Não há nenhum problema urgente. Então, por que o fim da vida útil é importante para algo tão invisível do ponto de vista operacional?
Os pesquisadores de segurança não esperam que você faça a atualização para identificar vulnerabilidades. Os invasores têm como alvo específico softwares de infraestrutura amplamente utilizados que rodam em versões em fim de vida (EOL), justamente porque sabem que não haverá mais correções. E o Celery é um dos softwares de infraestrutura em Python mais amplamente utilizados que existem.
As versões do Celery que chegaram ao fim da vida útil (EOL) apresentam riscos de segurança documentados, e a natureza dessas vulnerabilidades é particularmente preocupante para a infraestrutura de filas de tarefas.
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.
Se você estiver usando o Celery 4.x, está exposto a essa vulnerabilidade, sem que haja uma correção oficial disponível para a sua versão. Se estiver usando uma versão 5.x anterior à 5.2.2, a situação é a mesma.
Além das vulnerabilidades diretas no próprio Celery, as estruturas de conformidade não são tolerantes com softwares de infraestrutura sem suporte. O PCI DSS exige que vulnerabilidades de alta gravidade sejam corrigidas em até 30 dias. Os auditores do SOC 2 perguntam especificamente sobre softwares sem suporte em ambientes de produção. A execução de versões do Celery que chegaram ao fim da vida útil (EOL) é considerada uma lacuna na documentação em todas as auditorias de segurança pelas quais sua organização passa.
O risco oculto: sua cadeia de dependências
Quando as equipes avaliam a segurança do Celery, tendem a se concentrar na própria fila de tarefas, nos conjuntos de trabalhadores, no roteamento de tarefas e na limitação de taxa. Esse é um ponto de partida razoável, mas não leva em conta até onde se estende a verdadeira janela de exposição.
As principais dependências do Celery são todas mantidas sob o mesmo guarda-chuva do projeto Celery: kombu (a biblioteca de mensagens que abstrai o RabbitMQ, o Redis e outros brokers), billiard (o fork de multiprocessamento que alimenta o pool de trabalhadores prefork) e vine (a biblioteca de promessas/callbacks para composição de tarefas assíncronas). O Celery 5.x também requer o click e seus componentes associados para a CLI. Essas não são adições opcionais; elas são necessárias para que qualquer instalação do 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.
O Kombu é responsável por toda a serialização e desserialização de mensagens para a comunicação do Celery com o broker. O Billiard é o motor do pool de workers. Se for identificada uma vulnerabilidade (CVE) na versão fixada de qualquer um deles, ela permanecerá sem correção, assim como a própria versão do Celery que chegou ao fim da vida útil (EOL).
O resultado é uma janela de exposição cada vez maior. O pip audit pode sinalizar CVEs nos pacotes instalados assim que forem divulgados, mas não consegue aplicar correções retroativamente a versões de pacotes em fim de vida (EOL). A superfície de vulnerabilidade abrange toda a árvore de dependências, não apenas a camada da fila de tarefas no topo.
Suas opções quando o aipo chega ao fim da vida útil
Então, sua versão do Celery está no fim do ciclo de vida (EOL) ou está caminhando nessa direção. Quais são as opções realistas que você tem daqui para frente?
Duas delas envolvem alto custo, planejamento e risco operacional. A terceira — suporte estendido — é a opção que realmente resolve o problema de segurança sem forçar uma migração para a qual você ainda não está preparado, e é aquela que a maioria das equipes gostaria de ter descoberto mais cedo.
Opção 1: Atualizar para uma versão recente do Celery
A resposta oficial: atualize para a versão mais recente do Celery 5.6.x, obtenha cobertura de segurança ativa e aproveite as melhorias de estabilidade que o projeto vem oferecendo ao longo de várias versões secundárias.
E a versão atual do Celery é realmente melhor. Os vazamentos de memória no tratamento de exceções foram corrigidos. Os problemas de estabilidade do broker Redis que afetavam as versões anteriores da série 5.x foram resolvidos. Foi adicionado suporte ao Python 3.13 e 3.14. Para equipes que trabalham com bases de código mantidas ativamente, a atualização é a decisão certa a longo prazo.
Mas a atualização de um sistema de produção em uma versão do Celery que chegou ao fim da vida útil (EOL) é feita da seguinte maneira:
A compatibilidade com o Python 2 foi totalmente removida: O Celery 5.x deixou de oferecer suporte ao Python 2 por completo. Se alguma parte do código de suas tarefas ou back-ends personalizados dependia de padrões do Python 2, isso precisa ser resolvido antes mesmo que uma atualização seja possível. Para organizações com aplicativos Django legados que ainda executam fluxos de trabalho em Python 2.7 por meio do Celery 4.x, essa não é uma mudança menor; trata-se de uma migração em tempo de execução que afeta toda a pilha de aplicativos.
Alterações que quebram a compatibilidade na CLI: A CLI do Celery 5.0 foi reescrita usando o Click. As opções globais que antes vinham após o subcomando agora devem vir antes dele. Comandos como celery worker –app path.to.app passaram a ser celery –app path.to.app worker. Quaisquer scripts de implantação, comandos de inicialização de contêineres, especificações de pods do Kubernetes ou arquivos de unidade do systemd que invoquem workers do Celery precisam ser revisados e atualizados.
Backends e módulos removidos: O backend de resultados AMQP foi totalmente removido no Celery 5.0. O celery.utils.encoding e celery.task foram removidos. As importações que funcionavam no Celery 4.x agora geram um erro ImportError. Quaisquer tarefas personalizadas que utilizem from celery.task import Task precisam ser atualizadas para from celery import Task. Qualquer código que utilize Celery.shared_task pela forma antiga precisa de atualizações equivalentes.
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.
Migração do pytz para o zoneinfo: O Celery 5.3 substituiu o pytz pelo módulo zoneinfo, integrado ao Python, para o gerenciamento de fusos horários, passando a utilizar o tzdata como dependência de banco de dados de fusos horários. Quaisquer tarefas que dependam de objetos de fuso horário específicos do pytz em sua lógica de agendamento precisam ser revisadas.
Para uma base de código pequena, com poucas tarefas? Essa atualização é um sprint bem focado. Para um sistema de produção maduro, com dezenas de definições de tarefas, back-ends personalizados, automação de implantação e anos de padrões acumulados em torno da antiga CLI? Você terá que contar com um planejamento cuidadoso, testes minuciosos e o risco real de que os pipelines de tarefas deixem de funcionar sob a carga de produção.
Opção 2: Migração para estruturas alternativas
Algumas equipes, ao se depararem com a situação do fim da vida útil (EOL) do Celery, consideram que é o momento de repensar toda a abordagem.
Dramatiq, RQ (Redis Queue), Huey ou opções nativas da nuvem, como o AWS SQS com Lambda, são todas alternativas viáveis, cada uma com vantagens e desvantagens específicas que podem, na verdade, se adequar melhor à sua situação.
Mas sejamos honestos sobre o que envolve a migração de um framework. Você não está simplesmente trocando uma biblioteca. Você está reescrevendo todas as definições de tarefas usando os padrões de decorador e de classe do novo framework. Você está substituindo as primitivas de tela do Celery (cadeias, acordes, grupos) pelo que quer que o novo framework utilize para a composição de tarefas — se é que ele oferece suporte a isso. Você está reconstruindo sua configuração de monitoramento, sua configuração de implantação de workers, sua lógica de repetição de tentativas e recuo, e sua integração com o backend de resultados. E está fazendo tudo isso enquanto mantém o sistema existente em funcionamento na produção.
Os benefícios arquitetônicos de longo prazo podem, sem dúvida, justificar esse trabalho na situação certa. O prazo e o custo reais quase sempre acabam ficando bem acima das estimativas iniciais. E o período em que seus funcionários da produção ficam trabalhando com uma versão do Celery em fim de vida (EOL) enquanto a migração está em andamento é exatamente a janela de vulnerabilidade que você estava tentando eliminar.
Opção 3: Suporte estendido de terceiros
Existe uma terceira opção que não recebe a atenção que merece: o suporte estendido de segurança oferecido por empresas especializadas exatamente nesse problema.
A TuxCare oferece suporte contínuo ao ciclo de vida para versões do Celery que chegaram ao fim da vida útil (EOL). Em vez de ser forçado a realizar uma migração para a qual ainda não está preparado, ou de deixar suas filas de tarefas desprotegidas enquanto planeja essa migração, você continua utilizando sua versão atual do Celery, mas com cobertura contínua de patches de segurança.
A lógica é simples: você ganha tempo e controle. Tempo para planejar uma atualização adequada quando ela realmente se encaixar no seu plano de desenvolvimento. Controle sobre o cronograma de migração, em vez de ficar à mercê de uma divulgação de CVE que o obriga a agir no pior momento possível — daqueles que acontecem numa sexta-feira à tarde.
O verdadeiro custo de apressar uma atualização do Celery EOL
Vamos falar sobre o que realmente acontece quando as equipes tentam encaixar uma migração do Celery em fim de vida útil (EOL) em um prazo irrealista, porque uma auditoria de segurança acabou de sinalizar a versão sem suporte.
Aumento da carga de suporte: As diferenças de comportamento entre o Celery 4.x e o 5.x que não apareceram no ambiente de teste começam a surgir na produção. Tarefas que eram concluídas silenciosamente no Celery 4.x agora apresentam erros que antes eram ignorados. Falhas na invocação da CLI em scripts de implantação que pareciam estar corretas nos testes. Comportamento do pool de conexões do Kombu que é sutilmente diferente sob alta taxa de transferência. Sua fila de plantão fica lotada de incidentes que, todos, podem ser atribuídos à migração.
Instabilidade do sistema: As implantações do Celery EOL são executadas em ambientes distribuídos com vários nós de trabalho, brokers compartilhados e back-ends de resultados compartilhados. Pequenas incompatibilidades na forma como diferentes versões do Celery lidam com a serialização de tarefas ou o armazenamento de resultados podem causar falhas que são extremamente difíceis de reproduzir fora da carga de produção. Esses são os problemas que geram alertas às 3 da manhã e engenheiros genuinamente insatisfeitos.
Acúmulo de dívida técnica: Na pressa para garantir a conformidade, são adicionados shims de compatibilidade. Os módulos de tarefa são envolvidos por blocos try/except ImportError . As opções antigas da CLI recebem aliases por meio de scripts de envoltório com comentários do tipo “corrija isso direito mais tarde”. Seis meses após a migração, você está tecnicamente na versão atual do Celery, mas executando uma infraestrutura cheia de soluções provisórias que tornam a próxima atualização ainda mais difícil.
Excedentes orçamentários: A estimativa original era de quatro semanas. Dez semanas depois, você ainda está depurando o comportamento da conexão com o broker e investigando falhas intermitentes nas tarefas que só ocorrem sob carga de produção. O prestador de serviços contratado para ajudar continua cobrando. O trabalho programado para o desenvolvimento de novos recursos foi adiado por dois trimestres. O custo de oportunidade de ter seus engenheiros sênior de back-end depurando casos extremos de serialização do Celery, em vez de desenvolver um produto, é muito real.
A atualização é a solução correta a longo prazo. Uma migração apressada do Celery devido ao fim do ciclo de vida (EOL), sob pressão de conformidade, é um tipo específico e totalmente previsível de falha. Não são a mesma coisa.
A solução fácil: TuxCare ELS para versões do Celery em fim de vida útil
É aqui que o Suporte de Ciclo de Vida Ilimitado da TuxCare para o Celery realmente muda o jogo.
A TuxCare vem fazendo isso há mais de uma década, fornecendo patches de segurança para sistemas operacionais, ambientes de execução, bibliotecas e estruturas de aplicativos que chegaram ao fim de vida útil. A empresa já distribuiu mais de 220.000 patches de segurança em todo o ecossistema de código aberto. Quando afirmam que sabem como manter a segurança de softwares que chegaram ao fim de vida útil em escala empresarial, eles realmente já fizeram isso em grande escala, repetidamente, para algumas das maiores organizações do mundo.
O que diferencia a abordagem da TuxCare
Cobertura completa da cadeia de dependências: Isso é extremamente importante especificamente para o Celery, considerando o quanto a funcionalidade da estrutura depende do kombu, do billiard e do vine. A TuxCare não se limita a aplicar patches apenas no próprio Celery; ela cobre suas dependências diretas e as dependências transitivas subjacentes a elas, tudo sem custo adicional. Os problemas de segurança do kombu, as vulnerabilidades do billiard, a exposição do vine – a TuxCare cobre toda a superfície. Você não está apenas protegendo a fila de tarefas; está protegendo toda a pilha de dependências do Celery.
Processo refinado e automatizado de aplicação de patches: O processo da TuxCare combina automação avançada com validação especializada. Eles monitoram o NVD, os alertas de segurança dos fornecedores, os feeds de segurança do GitHub e todos os locais onde vulnerabilidades do Celery em fim de vida (EOL) são divulgadas. Quando um CVE é publicado, eles utilizam ferramentas algorítmicas e automação assistida por IA para aplicar correções de segurança retroativamente às versões em fim de vida; em seguida, especialistas em segurança validam cada patch antes de sua distribuição. Cada atualização passa por testes de integridade, funcionalidade e regressão antes mesmo de chegar aos seus repositórios. Quer ver exatamente como isso funciona? Confira o white paper técnico da TuxCare sobre seu processo de aplicação de patches em código aberto.
Integração perfeita: Os patches da TuxCare se integram diretamente ao seu fluxo de trabalho do pip já existente. Não importa se você usa o pip, o Poetry ou qualquer gerenciador de pacotes Python padrão: os pacotes ELS simplesmente funcionam. Você não precisa reformular seus pipelines de implantação nem treinar novamente sua equipe. Você continua usando exatamente o que já tem configurado.
Resposta rápida respaldada por SLA: Quando novas vulnerabilidades do Celery EOL são divulgadas, a TuxCare fornece patches respaldados por acordos de nível de serviço efetivos. Você não precisa ficar torcendo para que alguém, eventualmente, faça o backport de uma correção. Você recebe atualizações de segurança prontas para produção em um prazo garantido, com suporte real caso algo dê errado.
Custo-benefício: Eis o que mais surpreende a maioria das equipes em relação ao suporte estendido: ele costuma ser significativamente mais barato do que as alternativas. Quando se somam o tempo de engenharia com base nas taxas horárias reais, os ciclos de teste, os honorários de prestadores de serviços, o possível tempo de inatividade, o atraso no lançamento de recursos e o custo de oportunidade, o ELS normalmente custa apenas uma fração desse total. Além disso, você não está sobrecarregando sua equipe com uma migração sob alta pressão para cumprir normas de conformidade.
Conformidade e transparência: Cada versão do TuxCare oferece visibilidade completa sobre o que foi corrigido – quais CVEs foram resolvidos, quais componentes foram modificados e como verificar tudo na sua lista de materiais de software (SBOM). É exatamente isso que você precisa para auditorias PCI DSS, revisões SOC 2 e qualquer outra estrutura de conformidade que faça perguntas específicas sobre softwares em fim de vida útil em produção.
Como começar
Se você estiver utilizando versões do Celery que chegaram ao fim da vida útil (EOL) e quiser saber qual é a cobertura realmente disponível, a TuxCare mantém um rastreador de CVEs em tempo real, onde você pode verificar vulnerabilidades e correções atualizadas para o Celery.
Quer saber tudo sobre as versões compatíveis, preços e implementação? Acesse Suporte de Ciclo de Vida Ilimitado da TuxCare para o Celery para obter mais detalhes.
Não deixe que o fim da vida útil do Celery coloque suas filas de tarefas em risco
O Celery tem tido uma trajetória notável. Há mais de 15 anos, ele é a espinha dorsal do processamento de tarefas em segundo plano no Python. Ele lida com o trabalho assíncrono por trás de alguns dos sistemas de produção mais complexos do mundo, e o faz de forma tão discreta que a maioria dos engenheiros se esquece de que ele existe até que algo dê errado.
Mas se você estiver executando versões do Celery cujo ciclo de vida já chegou ao fim (EOL) em ambiente de produção — seja uma instalação fixada na versão 4.4.x ou uma versão mais antiga da série 5.x —, “ele ainda está processando tarefas” não significa o mesmo que “ele ainda é seguro”.
O fim do ciclo de vida (EOL) do Celery não precisa significar uma correria. Você tem opções reais. É possível planejar uma atualização bem pensada para uma versão atual do Celery quando ela realmente se encaixar no roteiro da sua equipe. Você pode avaliar se uma estrutura diferente faz sentido do ponto de vista arquitetônico para a sua situação. Ou pode utilizar o suporte estendido para manter a segurança e a conformidade enquanto toma essas decisões de acordo com o seu próprio cronograma, em vez de seguir o de um verificador de segurança.
As equipes que lidam bem com situações de fim de vida útil (EOL) do Celery reconhecem os riscos antecipadamente, entendem o que realmente está disponível e tomam decisões deliberadas, em vez de reativas, independentemente do orçamento ou da modernidade da base de código.
Se o fim do suporte (EOL) do Celery está em sua agenda no momento, vale a pena conhecer o que a TuxCare oferece. Você pode descobrir que proteger o que já desenvolveu, enquanto planeja a atualização que realmente deseja, é um próximo passo mais adequado do que apressar uma migração para a qual ainda não está preparado.
Visite o Suporte de Ciclo de Vida Ilimitado da TuxCare para Software de Código Aberto para ver como o suporte estendido pode proteger toda a sua pilha de código aberto pelo tempo que você precisar.
