PHP2Shell no Synology: Como corrigimos seis sites em um único dia

PHP2Shell PHP2Shell é o nome que a indústria adotou para CVE-2026-109618 e CVE-2026-109619, um par de falhas críticas no próprio mecanismo PHP que permitem a execução remota de código sem autenticação. Detalhes vazaram em 20 de outubro de 2026, um dia antes da divulgação coordenada, e o projeto PHP lançou versões de emergência em 21 de outubro. Como o bug reside no interpretador e não em qualquer aplicativo, aplicar patches no WordPress, Joomla ou MediaWiki não resolve o problema. A única solução real é uma nova compilação do PHP. Mantemos seis sites WordPress públicos em hardware Synology, e o PHP2Shell fez com que todos eles tivessem que ser reconstruídos na mesma semana. Este guia aborda o que o bug realmente é, como corrigi-lo no DSM por meio do Package Center, como lidar com ele quando seu site é executado em um contêiner e a comparação desconfortável entre o que o Synology lançou e o que outros fornecedores de NAS conseguiram até agora.

Ponto SynoPower Club:Nossos seis sites foram corrigidos em um único dia útil após a publicação do aviso do PHP2Shell, e o que tornou isso possível não foi heroísmo, mas sim a publicação dos pacotes corrigidos pela ASUSTOR (Synology) na mesma data do aviso. O aviso Synology-SA-26:14 foi publicado em 22 de outubro com o status "Resolvido" e uma tabela completa de versões corrigidas até o PHP 7.4. No mesmo dia, a QNAP publicou o aviso QSA-26-18 com o status "Em correção" e a mensagem "A ser anunciado" em cada célula de versão corrigida, e a ASUSTOR respondeu excluindo o PHP legado do App Central em vez de corrigi-lo. Se você hospeda um site público em um NAS, essa diferença não é um detalhe de marketing. É a diferença entre atualizar um pacote e tirar seu site da internet enquanto você espera.

O que é PHP2Shell e por que ele é diferente?

O PHP2Shell não é um bug isolado, mas sim um conjunto de falhas relacionadas à segurança de memória no PHP, que ocorre na forma como o sistema limpa os recursos após uma requisição que esgotou a memória disponível. O PHP utiliza longjmp() Para evitar erros fatais, incluindo falta de memória, esse salto ignora o código de limpeza que normalmente colocaria o mecanismo de volta em um estado conhecido. Parte desse estado é global e persiste na próxima solicitação processada pelo mesmo processo de trabalho.

A vulnerabilidade CVE-2026-109618 está relacionada à falta de memória. Uma requisição HTTP maliciosa esgota o limite de memória enquanto os dados da requisição estão apenas parcialmente inicializados, fazendo com que a rotina de limpeza percorra estruturas que nunca foram concluídas. Já a vulnerabilidade CVE-2026-109619 está relacionada ao uso após liberação de memória: o estado global que aponta para a memória liberada pela requisição pode ser lido por uma requisição posterior no mesmo worker, permitindo a execução de código ou a divulgação de memória.

Duas características tornam o PHP2Shell pior do que os avisos usuais sobre PHP. Primeiro, ele é pré-autenticação. Ambas as falhas são acionadas antes que qualquer autenticação em nível de aplicação seja executada, portanto, uma tela de login, um plugin de membros ou uma senha de administrador não protegem nada. Segundo, a variante de divulgação de memória vaza a memória do processo worker, e um worker PHP em um site WordPress armazena credenciais de banco de dados, tokens de API e chaves de pagamento. Uma leitura bem-sucedida não precisa chegar à execução do código para arruinar sua semana.

As duas vulnerabilidades CVE do PHP2Shell receberam uma pontuação de 9,2 no CVSS v4.0 pela equipe de segurança do PHP. A Synology, por sua vez, atribuiu-lhes uma pontuação de 9,8 no CVSS v3.1 em seu próprio comunicado. Escalas diferentes, mesma conclusão. Os relatos de exploração são contraditórios: a watchTowr afirma ter detectado tentativas contra sua rede honeypot, enquanto a Bitdefender não relatou nada em sua telemetria até o momento da redação deste texto, e a QNAP declara não ter recebido relatos de exploração direcionada especificamente a produtos da QNAP.

PHP2Shell versus um exploit normal do WordPress

A maior parte dos ataques a sites WordPress públicos são vulnerabilidades de plugins. O padrão é conhecido: um plugin inclui um endpoint REST quebrado, um scanner o encontra, você atualiza o plugin e a vulnerabilidade é corrigida. O PHP2Shell quebra completamente esse padrão, e a prática de auditar plugins automaticamente se torna um esforço desperdiçado nesse caso.

Aspecto	CVE típico de plugin	PHP2Shell
Onde vive o inseto	Código da aplicação (plugin ou tema)	O próprio interpretador PHP
Quem pode desencadear isso?	Geralmente requer uma função de assinante ou administrador.	Ninguém. Pré-autenticação, antes da execução da lógica do aplicativo.
Atualizar o WordPress ajuda?	Geralmente sim	Não. Atualizações do núcleo e de plugins são irrelevantes.
Um WAF (filtro de imagem da esposa) impede isso?	Normalmente, uma vez que uma regra existe,	Em parte. As regras de formato de requisição não consideram o caminho OOM.
O que realmente resolve o problema?	Atualização do plugin	Uma nova compilação do PHP, nada mais.
raio de explosão	Um site, uma funcionalidade	Todos os sites PHP no servidor, todos de uma vez.

Essa última linha explica por que o PHP2Shell se transformou em um dia inteiro de trabalho em vez de uma tarde. Um único pacote PHP compartilhado em um NAS pode estar por trás de uma dúzia de hosts virtuais do Web Station, e uma única imagem de contêiner pode ser a base para vários sites. A aplicação de patches não é por site, mas sim por ambiente de execução, e você precisa enumerar os ambientes de execução antes de poder afirmar que algo foi feito.

Como saber se seu NAS está exposto

A avaliação da sua exposição ao PHP2Shell começa por separar duas questões distintas. O sistema contém uma versão vulnerável do PHP e essa versão é acessível pela internet? A Synology faz essa distinção explicitamente: o DSM inclui um componente PHP interno usado pelo sistema operacional, e a Synology afirma que ele não possui módulos acessíveis externamente e, portanto, nenhuma superfície de ataque exposta. O risco atribuído a esse componente é mínimo, e a correção está prevista para uma versão posterior do DSM, para que as verificações de vulnerabilidades parem de sinalizá-lo.

Os pacotes relevantes para o PHP2Shell são aqueles que fornecem PHP para a web. A lista Synology inclui Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station e WordPress. Se você tiver algum desses instalados e acessíveis, você está dentro do escopo.

Verifique as versões diretamente em vez de confiar em um painel de controle. No Centro de Pacotes, os pacotes PHP instalados mostram suas versões no bloco e o aviso de atualização indica a versão de destino. A partir de um terminal, consulte o próprio ambiente de execução:

Pacote PHP # Synology (ajuste o caminho para a versão que você está executando) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Um site em contêiner docker exec php -v

O motivo para insistir em php -v Ao auditar o PHP2Shell, percebe-se que todos os outros sinais são enganosos. A saída da compilação pode reportar sucesso enquanto reutiliza uma camada em cache, um painel de controle pode mostrar um pacote como atualizado quando o worker em execução não está, e um cabeçalho de resposta HTTP pode ser removido por uma CDN antes mesmo de você vê-lo. Dois dos nossos seis sites foram reportados como íntegros em suas telas de administração, mesmo executando um interpretador sem patches.

Aplicando patches no PHP2Shell no Synology em 4 etapas

Para um site Web Station no DSM, a correção completa do PHP2Shell consiste em uma atualização do Centro de Pacotes. O pacote Synology publica atualizações de segurança do PHP para o DSM 7.4, 7.3 e 7.2, e após a atualização dos pacotes PHP, os pacotes dependentes são reinicializados, o que resolve o problema. O Mail Station é a exceção documentada e requer uma atualização manual própria.

A captura de tela acima foi feita em uma de nossas máquinas na manhã seguinte ao aviso do PHP2Shell. Observe que o painel "Novidades" indica a versão upstream diretamente, permitindo que você compare o sufixo de compilação Synology com a versão do PHP sem precisar adivinhar. O Calendar Synology aparece na mesma lista de atualizações na versão 3.0.4-21435, que é exatamente a versão recomendada no aviso.

Uma armadilha do PHP2Shell que vale a pena mencionar para usuários do Web Station: uma máquina DSM pode ter várias versões do PHP instaladas simultaneamente, e cada host virtual está vinculado a um perfil. Atualizar o perfil padrão não resolve o problema de um site vinculado a uma versão diferente. Primeiro, liste os perfis, atualize todos eles e, em seguida, verifique a vinculação de cada site em Serviços Web.

Quais pacotes DSM são afetados?

A declaração Synology no PHP2Shell é mais restrita do que o pânico sugeria. Apenas sistemas que executam determinados pacotes dependentes do PHP são afetados, e o Synology Drive explicitamente não está entre eles. O IDrive está na lista, mas é um software de terceiros.

• Acesso via web e prioridade máxima. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer e phpMyAdmin. Estes disponibilizam PHP para qualquer pessoa que consiga acessá-los.
• Correio e calendário. O Mail Station precisa de uma atualização manual após o pacote PHP. O calendário Synology possui sua própria versão corrigida, a 3.0.4-21435.
• O componente interno do DSM. Presente, mas não acessível externamente; a correção foi adiada para uma versão posterior do DSM; risco classificado como mínimo pela Synology.
• Os recipientes não estão cobertos. O ambiente de execução PHP dentro do Container Manager é de sua responsabilidade e pode ser modificado por você. Nenhuma atualização de pacote o afetará, e esse é o motivo mais comum pelo qual o proprietário de um NAS pensa que terminou quando, na verdade, não terminou.

Se você ainda estiver usando uma versão do DSM anterior à 7.2, a Synology recomenda desativar temporariamente os pacotes afetados até que uma versão corrigida esteja disponível. O próprio DSM 7.2 é sinalizado como descontinuado na declaração, mesmo tendo recebido essas atualizações do PHP.

O caso mais crítico do PHP2Shell é o PHP 7.3 e versões anteriores. O pacote Synology não corrigirá o problema com a versão 7.3, pois essa versão está em fim de vida útil e o projeto original não publicou nada para versões anteriores à 7.3. Distribuições Linux disponibilizaram correções para algumas versões antigas, mas um pacote PHP Synology não é um pacote de distribuição. Se um site precisa do PHP 7.3 ou 5.6 para funcionar, não haverá nenhuma correção e as opções mais sensatas são migrar o site para uma versão com suporte, protegê-lo com um WAF (Web Application Firewall) ou retirá-lo da internet pública.

Como os proprietários de sites de contêineres lidam com o PHP2Shell

Cinco dos nossos seis sites executam o WordPress em Docker em vez do Web Station, e é aí que o PHP2Shell se torna interessante, porque o Centro de Pacotes não pode ajudar. O ambiente de execução é o que a imagem contém, e reconstruir uma imagem não é o mesmo que atualizá-la.

A primeira falha do PHP2Shell que encontramos, e a que tem maior probabilidade de afetar outras pessoas, é que a reconstrução de uma imagem personalizada reutiliza a camada base em cache. Uma imagem não fixada DE A tag não significa "atualizado". Uma de nossas imagens havia sido reconstruída quatro dias antes e ainda continha uma versão do PHP de julho de 2025, com mais de um ano de atraso em relação às correções de segurança, porque nada havia forçado o Docker a baixar novamente a base.

# Errado: reutiliza silenciosamente qualquer camada base que esteja em cache localmente. `docker build -t mysite .` # Certo: sempre baixa novamente a imagem base. `docker build --pull -t mysite .` # Em seguida, inicie apenas o serviço desejado, sem iniciar os serviços irmãos inativos. `docker compose up -d --no-deps wordpress` # E verifique o que realmente importa. `docker exec wordpress php -v`

A segunda falha do PHP2Shell é mais grave porque reporta sucesso. O redirecionamento da saída da compilação ocorre através de cauda oculta uma falha de compilação, já que o código de saída de um pipeline pertence ao último comando nele e conjunto -e nunca é acionado. A etapa de composição recria o contêiner a partir da imagem antiga, imprime "Iniciado" e você se depara com um site sem patches que parece recém-implantado. Verifique o resultado da compilação separadamente e confirme com php -v após.

Duas observações importantes. Marque a imagem antiga antes de recriá-la, pois uma imagem mantém sua tag e oferece um ponto de reversão gratuito, muito mais econômico do que um snapshot. Além disso, não espere que uma atualização de imagem atualize o aplicativo: o ponto de entrada oficial da imagem do WordPress copia os arquivos principais somente quando o diretório raiz do documento está vazio. Portanto, recriar um contêiner em uma imagem mais recente deixa a instalação existente exatamente como estava. Confirmamos isso em um ambiente de teste antes de mexer na produção, e a versão do WordPress não foi alterada.

Por que desabilitar session.upload_progress resolve apenas metade do problema?

A solução paliativa do PHP2Shell que está sendo utilizada em máquinas que não podem ser corrigidas consiste em definir session.upload_progress.enabled = 0, E no DSM, que fica no Web Station em Configurações de Linguagem de Script, na aba Núcleo do perfil PHP. Vale a pena fazer isso. Não é uma solução definitiva, e a lacuna é importante.

O caminho de progresso de upload da sessão é apenas uma das formas de acesso. A variante de divulgação de memória é alcançada por meio do tratamento comum de requisições multipart e não requer o recurso de sessão, portanto, desativar esse recurso deixa esse caminho aberto. O projeto PHP afirmou diretamente que não existem mitigações completas e que a atualização é a única solução segura. O Imunify360 relata que nenhuma regra bloqueia atualmente o caminho de falta de memória do CVE-2026-109618, e a Elastic observa que a configuração de progresso de upload fecha os caminhos de sessão confirmados, mas não todas as variantes.

Você também verá limite_de_memória = -1 Sugeriu-se, com base na lógica de que o bug é alcançado por meio de uma condição de falta de memória. Considere isso uma troca, não uma vantagem. Remover o limite em um servidor web público troca um modo de falha por outro, e em um NAS com orçamento de memória compartilhado, isso leva o pool de processos a esgotar toda a máquina.

O filtro de borda é a camada do PHP2Shell que realmente agrega valor, pois detecta o tráfego descriptografado, enquanto seu roteador não. A Cloudflare implementou proteção por meio de regras gerenciadas para o PHP2Shell, a AWS adicionou cobertura para a vulnerabilidade CVE-2026-109619 na versão 2.3 do seu grupo de regras gerenciadas para PHP, e o Azure Front Door lançou a regra 99006001, que está desativada por padrão. Existem regras da comunidade para Snort e Suricata no GitHub, mas os conjuntos de regras oficiais do Snort e de Ameaças Emergentes não haviam publicado nada até o momento da redação deste texto, portanto, um recurso de prevenção de intrusões em um NAS não será suficiente neste caso. De qualquer forma, ele não consegue ler o conteúdo de um TLS.

Qual fornecedor de NAS realmente lançou uma correção?

Esta é a parte da história do PHP2Shell que deve influenciar sua decisão de compra. O PHP upstream foi lançado em 21 de outubro. Veja a seguir a situação dos quatro principais fornecedores de NAS para consumidores e profissionais no dia seguinte, com base em seus próprios avisos e não em análises da mídia.

Fornecedor	Consultivo	Status	Versões corrigidas publicadas
Synology	Synology-SA-26:14, 22 de outubro de 2026	Resolvido	Sim. Todas as versões do PHP, do 7.4 ao 8.4, além do Calendar e do Mail Station.
QNAP	QSA-26-18, 22 de outubro de 2026	Consertando	Não. Em todas as linhas está escrito "A ser anunciado".
ASUSTOR	Descontinuação do PHP legado, 22 de outubro de 2026	Aposentadoria, não uma solução paliativa	Não. As versões PHP 7, 7.3, 7.4 e 8.1 foram removidas da Central de Aplicativos.
UGREEN	Nenhum encontrado	Desconhecido	Não foram encontradas recomendações para o UGOS Pro.

A equipe Synology publicou uma tabela completa de versões do PHP2Shell no mesmo dia do aviso e marcou o aviso como Resolvido. Um usuário do DSM que o lesse tinha uma ação a tomar naquela mesma tarde: abrir a Central de Pacotes, clicar em Atualizar e verificar. Esse é todo o processo de correção, e é por isso que nossas máquinas Web Station foram concluídas em minutos, em vez de dias.

A QNAP publicou na mesma data uma lista extensa de produtos afetados, incluindo QTS 6.1.0, QTS 5.2.11 e versões anteriores, QuTS hero h6.1.0, h6.0.x e h5.2.11 e versões anteriores, QuTScloud c5.2.9 e versões anteriores, Note Station 3, QNE ADRA, QVR Surveillance em modelos ARM32 e TVR OS. Todos eles apresentam o status "Em correção", sem uma versão corrigida definida. Como o ambiente de execução PHP faz parte dos componentes web do QTS, não há um pacote para atualizar, portanto, a correção precisa ser feita por meio de firmware.

Enquanto isso, a QNAP oferece às vítimas do PHP2Shell uma lista de medidas de mitigação, e vale a pena lê-la atentamente devido às recomendações: desativar o encaminhamento de portas e o UPnP no roteador, cancelar a publicação dos serviços myQNAPcloud, usar uma VPN para o acesso remoto, restringir as portas de gerenciamento a sub-redes confiáveis, interromper aplicativos baseados em PHP que não sejam necessários, desativar o servidor web integrado se não estiver em uso e verificar o QuLog Center em busca de sinais de comprometimento. Essas são recomendações sensatas para um dispositivo sem as atualizações de segurança. Para quem hospeda um site público, também é uma recomendação para que o site seja desativado.

A ASUSTOR adotou uma terceira estratégia. Seu comunicado, datado de 22 de outubro e intitulado "Anúncio de Descontinuação do PHP Legado", remove o PHP 7, PHP 7.3, PHP 7.4 e PHP 8.1 da App Central com efeito imediato, recomenda o backup de dados importantes e orienta os usuários a utilizarem somente o PHP 8.3 ou 8.4 daqui em diante. A justificativa é defensável, visto que o projeto upstream só corrige as versões 8.2 e posteriores. O efeito para o usuário que executa um aplicativo PHP antigo é que o ambiente de execução desaparece da loja em vez de ser corrigido, e a ASUSTOR não informa que uma versão corrigida do PHP 8.3 ou 8.4 foi disponibilizada. Observe o contraste com o comunicado Synology, que publicou uma versão corrigida do PHP 7.4 (7.4.33-0131) exatamente para os usuários que a ASUSTOR está solicitando a migração.

Para a UGREEN, não encontramos nenhum aviso sobre a vulnerabilidade PHP2Shell no UGOS Pro. A ausência de uma declaração pública não comprova que um produto seja vulnerável, e o UGOS Pro pode simplesmente não incluir um ambiente de execução PHP voltado para a web. Mas, se você é o proprietário, o silêncio não é uma resposta que possa ser levada em consideração, e isso por si só já representa uma forma de exposição.

Nada disso torna o Synology perfeito. Ele não corrige o PHP 7.3, sinaliza o DSM 7.2 como obsoleto e seu próprio componente PHP interno ainda é programado em vez de receber patches. A questão é mais específica e útil do que um argumento de marca: no dia em que uma falha de execução remota de código pré-autenticação foi descoberta no mecanismo do PHP, um fornecedor transformou a correção em um botão na Central de Pacotes, enquanto os outros a transformaram em um jogo de espera.

Onde encontrar mais recursos oficiais

No momento em que este texto foi escrito, o PHP2Shell tinha apenas dois dias de existência e a situação ainda está em desenvolvimento, portanto, consulte as fontes primárias em vez de resumos. Ainda não há cobertura em vídeo oficial de nenhum dos fornecedores, então a lista abaixo é documentação e não tutoriais passo a passo.

• Synology-SA-26:14 Esta é a tabela de versões oficial. Verifique-a novamente antes de aplicar o patch, pois os avisos são revisados.
• A declaração Synology PSIRT A lista inclui os pacotes afetados e explica o componente interno do DSM e a exceção do Mail Station.
• Os avisos upstream do GitHub GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp estão vinculados ao aviso Synology e descrevem o comportamento do mecanismo, em vez do pacote do fornecedor.
• QNAP QSA-26-18 É onde uma versão corrigida do firmware aparecerá se você executar o QTS ou o QuTS hero. É a página que você deve acompanhar, não um artigo de notícias.
• Seu próprio Centro de Pacotes é a palavra final sobre o que está instalado. O aviso informa a configuração desejada, o painel de controle mostra o que você realmente tem e somente ele informa o que está instalado. php -v Indica o que está em execução.

Para obter informações básicas sobre como executar sites públicos em máquinas virtuais Synology, consulte nosso guia passo a passo em Mover um conjunto Docker entre máquinas virtuais VDSM. Abrange os hábitos de captura e reversão que tornaram possível sobreviver a essa emergência.

Limitações e notas de segurança do PHP2Shell

Aplicar patches ao PHP2Shell é simples no DSM, mas complexo em qualquer outro lugar, por isso vale a pena mencionar algumas limitações claramente antes de considerar o trabalho concluído.

Uma atualização do pacote PHP2Shell não é uma auditoria do site. Atualizar o PHP fecha a vulnerabilidade a partir desse momento, mas se o servidor estava acessível pela internet entre 20 e 22 de outubro, isso ocorreu enquanto uma vulnerabilidade funcional estava disponível publicamente. Verifique os logs em busca de volumes inesperados de POST, procure por arquivos que apareceram em diretórios graváveis e alterne quaisquer credenciais que um processo do PHP possa ter utilizado. A variante de divulgação de memória torna a rotação de credenciais uma precaução razoável, e não paranoia.

A verificação do PHP2Shell precisa ter como alvo o interpretador em execução. Painéis, logs de compilação e cabeçalhos de resposta falharam pelo menos uma vez durante esta rodada. Uma CDN pode remover o cabeçalho que indicaria a versão, uma compilação pode reportar sucesso enquanto reutiliza uma camada em cache e um pacote pode mostrar a versão atual enquanto um worker antigo ainda está em execução. php -v O mecanismo que atende às solicitações resolve o problema.

Os contêineres não são cobertos por nenhum aviso do fornecedor sobre o PHP2Shell. Vale a pena repetir isso, pois é a falsa sensação de segurança mais comum em um NAS. Se o seu site estiver rodando no Container Manager, o Package Center informar que tudo está atualizado não diz nada sobre o seu site. O mesmo se aplica a qualquer aplicativo de terceiros que inclua seu próprio ambiente de execução.

As medidas de mitigação de configuração são parciais por natureza. Desativar o progresso de upload da sessão ajuda, remover o limite de memória troca um risco por outro, e um recurso de prevenção de intrusões do roteador não consegue inspecionar o tráfego TLS que termina em outro lugar. Considere tudo isso como tempo ganho enquanto você providencia uma correção definitiva, não como um substituto para ela.

Versões em fim de vida útil não possuem nenhum caminho PHP2Shell. O PHP 7.3 e versões anteriores não receberam nenhuma atualização do repositório principal nem do Synology. Se um site realmente precisa de uma versão sem suporte, a decisão a ser tomada é migrar, isolar ou remover o site da internet pública. Não há uma quarta opção, e fingir o contrário é como um site legado se torna a porta de entrada para todo o resto no mesmo servidor.

Por fim, fique atento ao aviso em vez do ciclo de notícias. O usuário Synology marcou o aviso SA-26:14 como Resolvido e o revisou uma vez em até seis minutos após a publicação. A QNAP informou que o aviso QSA-26-18 será atualizado assim que as versões corrigidas estiverem disponíveis. Ambas as páginas serão alteradas, e os números de versão neste artigo são os que foram publicados em 22 de outubro de 2026.

Referências

• Synology-SA-26:14 Aviso de segurança PHP2Shell, Publicado em 22 de outubro de 2026, status Resolvido, com versões corrigidas para PHP 7.4 a 8.4.
• Declaração Synology sobre vulnerabilidades do PHP2Shell, a nota do PSIRT listando os pacotes afetados e a cobertura do DSM.
• QNAP QSA-26-18, status: Em correção. Produtos afetados listados com versões corrigidas: A serem anunciadas.
• Anúncio da descontinuação do PHP legado da ASUSTOR, removendo o PHP 7, 7.3, 7.4 e 8.1 do App Central.
• Ajude a Net Security nas versões upstream do PHP2Shell., abrangendo PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 e os backports somente de código-fonte para versões mais antigas.

Perguntas frequentes