Moodle 5.3.1: como aplicar a atualização sem parar o AVA

O Moodle 5.3.1 saiu em 12 de novembro de 2026 junto com o 5.2.5, o 5.1.9, o 5.0.12 e o 4.5.16, todos como atualizações de segurança. Os detalhes das falhas só ficam públicos cerca de uma semana depois, e esse é o prazo real que você tem. Este guia mostra como aplicar a versão menor sem tirar o AVA do ar no meio do expediente e o que fazer se o seu ainda roda 5.0.

TL;DR

• Em 12/11/2026 saíram Moodle 5.3.1, 5.2.5, 5.1.9, 5.0.12 e 4.5.16. As notas oficiais dizem apenas que "uma série de problemas de segurança foi resolvida"; os boletins com os detalhes saem cerca de uma semana depois.
• O 5.0.12 não traz correção de segurança. O suporte de segurança do 5.0 terminou em 05/10/2026. Quem está nele precisa migrar, não apenas atualizar.
• O Moodle 5.3.1 avisa o usuário quando um token de acesso pessoal ou um segredo de cliente é criado e quando um token está prestes a expirar.
• Uma atualização menor como o Moodle 5.3.1 não é migração: com backup, janela curta e modo manutenção, o AVA fica fora do ar por minutos, não por horas.
• Próxima rodada prevista: 07/12/2026 (4.5.17, 5.1.10, 5.2.6 e 5.3.2).

Cuido de ambientes Moodle desde 2008. A regra que aprendi com os anos é simples: atualização de segurança atrasada é a que dá trabalho. A que você aplica na primeira semana costuma ser a mais tranquila do ano.

O que saiu em 12 de novembro e por que a pressa é real

O Moodle mantém várias linhas de versão ao mesmo tempo. Quando sai uma correção de segurança, ela é publicada em todas as linhas ainda cobertas, no mesmo dia. Foi o que aconteceu em 12/11: cinco versões menores de uma vez, conforme o calendário oficial em moodledev.io.

O detalhe que muda o seu planejamento está na nota de cada versão: os detalhes das falhas serão divulgados "após um período de aproximadamente uma semana, para permitir que administradores atualizem com segurança". Na prática, a partir de 19 ou 20 de novembro qualquer pessoa vai poder ler o que foi corrigido. Incluindo quem procura AVAs desatualizados para explorar.

A janela de uma semana funciona como um cronômetro

Antes da divulgação, quem quer atacar precisa descobrir a falha comparando o código das versões. Depois dela, o boletim de segurança (MSA, Moodle Security Announcement) entrega a descrição, a gravidade e as versões afetadas. O risco não nasce no dia do boletim, mas fica muito mais barato de explorar a partir dele.

Por isso a minha recomendação é aplicar o Moodle 5.3.1 (ou a versão menor da sua linha) antes dos boletins. Se não der, que seja na primeira janela depois deles.

Qual versão cabe no seu AVA

Linha	Versão de 12/11/2026	Fim do suporte de segurança	Correção de segurança nesta rodada?
5.3 LTS	5.3.1	01/10/2029	Sim
5.2	5.2.5	04/10/2027	Sim
5.1	5.1.9	19/04/2027	Sim
5.0	5.0.12	05/10/2026 (encerrado)	Não
4.5 LTS	4.5.16	04/10/2027	Sim

As datas são as de moodledev.io, consultadas em 15/11/2026. O próprio calendário avisa que as datas futuras podem se mover um pouco.

O que muda no Moodle 5.3.1 para quem administra o AVA

Além das correções sigilosas, a nota do Moodle 5.3.1 lista melhorias de segurança visíveis para o administrador. Elas mexem justamente no ponto mais esquecido de um AVA integrado: as credenciais de API.

Avisos sobre tokens e segredos de cliente

• MDL-89760: usuários e administradores passam a ser notificados quando um token de acesso pessoal ou um segredo de cliente (client secret) é criado. Se alguém gerar uma credencial sem você saber, você fica sabendo.
• MDL-89442: o usuário é avisado quando o token de acesso pessoal está prestes a expirar. Acaba a integração que para numa segunda-feira de manhã sem explicação.
• MDL-90024: aviso quando um segredo de cliente OAuth 2 expira.
• MDL-89990: ações em clientes OAuth 2 passam a ir para o log administrativo.
• MDL-69961: o token de "esqueci a senha" é invalidado quando o e-mail da conta muda ou quando um novo token é pedido.

Token de acesso pessoal é a credencial que um usuário gera para que um sistema externo fale com o Moodle em nome dele: a secretaria acadêmica, o CRM, o gateway de pagamento, a automação de WhatsApp. Se você já passou as integrações para OAuth 2, o guia OAuth2 no Moodle 5.3 explica a parte de configuração. O que o Moodle 5.3.1 acrescenta é visibilidade.

Correções que afetam a operação

Duas correções gerais merecem atenção. A MDL-90205 fecha um caminho em que a correção rápida de tarefas podia liberar notas sem a permissão necessária. Coordenação pedagógica costuma descobrir esse tipo de coisa da pior forma. A MDL-89848 faz tokens inválidos, expirados ou revogados pararem de devolver erro 500. Isso limpa o seu monitoramento: um erro 500 deixa de significar "alguém com token velho".

E uma de upgrade: a MDL-90273 trata o erro core\composer que aparecia em todas as páginas depois de subir para o 5.3 até os caches serem limpos. Se você viu isso no upgrade de outubro, sabe do que estou falando.

O que fazer depois de atualizar

Aproveite os avisos novos e faça o inventário das credenciais: quem tem token de acesso pessoal, para qual serviço, com que validade. Na nossa base, toda auditoria desse tipo encontra pelo menos um token de ex-funcionário ou de fornecedor que já saiu. Os avisos do Moodle 5.3.1 ajudam daqui para frente, mas não limpam o que já existe.

Atualização menor não é migração

Aqui mora a confusão que faz muita instituição adiar o patch. Ir do 5.3.0 para o Moodle 5.3.1 é uma atualização menor: mesma linha, mesmos requisitos de PHP e banco, plugins compatíveis com a linha 5.3 continuam compatíveis. Ir do 4.5 para o 5.3 é migração: muda requisito de servidor, muda estrutura de pastas, muda tema.

Se a sua dúvida é a migração, ela já está coberta em outros textos: o Moodle 5.3 LTS e quando migrar e o checklist para atualizar do 4.5 para o 5. Este guia trata só do patch.

O que torna a atualização menor rápida

• O banco recebe poucos passos de atualização, ou nenhum.
• Não há mudança de requisito de PHP dentro da mesma linha.
• O tema e os plugins não precisam de nova versão, salvo exceções raras.

O que ainda pode dar errado

• Código copiado por cima do antigo. Arquivos removidos na versão nova ficam para trás e causam erros estranhos. A documentação oficial manda mover o código antigo para outro lugar e descompactar o novo, não sobrescrever.
• config.php esquecido. No 5.1 em diante, ele fica na raiz do código, fora da pasta public.
• Plugins fora do lugar. No 5.1+, plugins de terceiros ficam dentro de public. Quem subiu do 5.0 às pressas às vezes deixou plugin no caminho antigo.
• Pasta vendor/ desatualizada. O Composer é opcional no 5.3 e será obrigatório no 6.0. Se a raiz tem vendor/, rode composer install --no-dev --classmap-authoritative a cada atualização.

Passo a passo: como aplicar o Moodle 5.3.1 sem parar o AVA

"Sem parar" não significa zero segundo fora do ar. Significa que ninguém percebe: a janela cai num horário vazio, dura minutos e tem caminho de volta pronto. É assim que fazemos nos ambientes que administramos.

1. Escolha a janela pelo uso real, não pelo relógio

Olhe os logs de acesso das últimas semanas e encontre o vale. Em AVA de graduação, costuma ser de madrugada. Em treinamento corporativo, fim de semana. Evite três situações: prazo de envio de tarefa, questionário com tempo marcado aberto e fechamento de notas. Questionário aberto durante o modo manutenção é reclamação certa.

2. Faça o backup das três partes

A documentação do Moodle é clara: backup do código, do moodledata (os arquivos enviados) e do banco de dados. Backup só do banco não restaura AVA nenhum. E o backup tem que ter sido testado. Backup que nunca foi restaurado é uma hipótese, não uma garantia.

3. Teste numa cópia antes, se der

Um ambiente de homologação com cópia de produção pega 90% das surpresas: plugin que não carrega, tema que quebra, script de integração que dependia de um comportamento corrigido. Numa versão menor, o teste é curto. Mesmo assim, vale fazer.

4. Ative o modo manutenção e espere o cron

Ative pelo painel (Administração do site > Servidor > Modo manutenção) ou pela linha de comando, a partir da raiz do código:

php admin/cli/maintenance.php --enable

Depois, espere as tarefas do cron em execução terminarem. Atualizar com o cron rodando é como trocar o pneu com o carro andando.

5. Troque o código e rode o upgrade

Mova o diretório antigo, descompacte o Moodle 5.3.1 no lugar, copie de volta o config.php e os plugins de terceiros para os caminhos certos. Rode o Composer se houver vendor/. Em seguida:

php admin/cli/upgrade.php --non-interactive
php admin/cli/purge_caches.php
php admin/cli/maintenance.php --disable

Confira os caminhos na sua árvore: depois da reorganização do 5.1, vale testar os comandos na homologação antes. A CLI é o caminho que a própria documentação recomenda para sites grandes.

6. Confirme antes de liberar

Abra Administração do site > Notificações e confira se a versão exibida é o Moodle 5.3.1 (ou a da sua linha). Faça login como aluno e como professor, abra um curso, envie um arquivo, rode o cron uma vez. Só então avise que acabou.

Plugins: o ponto que mais derruba atualização

Num patch como o Moodle 5.3.1 os plugins raramente quebram. Quando quebra, quase sempre é plugin abandonado ou customização feita direto no código do núcleo.

Antes da janela

• Liste os plugins adicionais em Administração do site > Plugins > Visão geral dos plugins.
• Veja no diretório oficial se cada um declara compatibilidade com a linha 5.3.
• Procure alteração no núcleo: arquivo do Moodle editado à mão some na troca de código.

Se um plugin travar o upgrade

A documentação oficial dá uma saída: apagar o código do plugin em vez de desinstalá-lo. Assim os dados dele continuam no banco, e você reinstala uma versão compatível depois. Desinstalar pela interface apaga os dados. Numa sexta à noite, essa diferença vale um semestre de notas.

Quando NÃO aplicar a atualização agora

Aplicar o Moodle 5.3.1 rápido é a regra. Há exceções, e todas têm prazo curto.

1. Prova on-line em andamento. Espere o fim da janela de avaliação, nem que sejam 48 horas.
2. Sem backup testado. Primeiro o backup, depois o patch. Inverter a ordem é apostar o AVA.
3. Customização no núcleo sem documentação. Faça a cópia de homologação, descubra o que foi alterado e só depois atualize. Se a customização não puder ser reaplicada, o problema é ela, não o patch.
4. AVA no 5.0. Aqui a atualização para o 5.0.12 não resolve o que você precisa. Veja a próxima seção.

O que não vale como motivo para esperar: "vamos juntar com a próxima". A próxima rodada está prevista para 07/12/2026. São três semanas com falhas conhecidas abertas, e com boletim público no meio.

O plano para quem ainda está no Moodle 5.0

Este é o caso mais delicado. O 5.0.12 saiu no mesmo dia que o Moodle 5.3.1, mas a nota dele diz, com todas as letras, que correções de segurança não foram aplicadas, porque o suporte de segurança do 5.0 terminou em 05/10/2026. A única correção listada é a MDL-90215: os pacotes H5P voltaram a funcionar off-line, uma regressão causada por uma correção de segurança anterior (MSA-26-0044).

Ou seja: aplicar o 5.0.12 corrige o H5P, mas deixa o AVA exposto às falhas que serão detalhadas nos próximos dias. A partir do boletim, o seu 5.0 fica com vulnerabilidades públicas e sem patch.

O que fazer, em ordem

1. Esta semana: aplique o 5.0.12 se usa H5P off-line. Reforce o perímetro: WAF, limite de tentativas no login, revisão de contas de administrador e de tokens.
2. Nas próximas semanas: monte a homologação e escolha o destino. Para quem sai do 5.0, as rotas com prazo longo são o 5.3 LTS, com segurança até 01/10/2029, ou o 4.5 LTS, com segurança até 04/10/2027. Do 5.0 para o 4.5 seria um rebaixamento de versão, que o Moodle não suporta, então na prática o caminho é para frente.
3. No recesso de dezembro/janeiro: execute a migração, com o AVA vazio.

O raciocínio completo de prazos está em suporte do Moodle 5.1 acabou: o que fazer, que trata dos dois casos. E se o motivo de estar no 5.0 é falta de braço técnico, esse é exatamente o cenário em que a hospedagem Moodle gerenciada da Agathas Web se paga: a migração entra no pacote e a esteira de atualizações deixa de depender de alguém lembrar.

Quanto custa atualizar, e quanto custa não atualizar

O custo direto de aplicar o Moodle 5.3.1 ou outra versão menor é baixo: algumas horas de trabalho técnico, contando backup, homologação, janela e verificação. O custo de não atualizar não aparece na planilha até virar incidente.

Cenário	Custo visível	Custo escondido
Atualizar na primeira semana	Horas técnicas e uma janela curta	Quase nenhum
Atualizar depois do boletim	O mesmo	Dias com falha pública aberta
Ficar no 5.0	Zero hoje	Falhas sem correção, auditoria de TI e LGPD difíceis de responder
Restaurar depois de invasão	Dias de AVA fora do ar	Dados de alunos expostos, reputação, notificação à ANPD

Vimos isso de perto no caso do PHP2Shell no Moodle: quem tinha rotina de atualização passou pelo episódio em uma janela. Quem não tinha passou semanas apagando incêndio.

O custo que mais pesa, na minha experiência, nem é o técnico. É a coordenação explicando para a diretoria por que a plataforma ficou fora no meio da avaliação.

Como a Agathas Web resolve isso

Na hospedagem Moodle da Agathas Web, a rodada de 12/11 é rotina, não projeto. O que está incluso:

• Stack dedicada a Moodle: PHP 8.3 com OPcache, PHP-FPM com pool por instância, Redis para sessões e cache, MariaDB e Nginx afinados para o padrão de acesso de AVA.
• Backup diário completo, binlog a cada 15 minutos e armazenamento externo criptografado, com restauração testada todo mês.
• Ambiente de homologação nos planos Professional e Enterprise, espelhando a produção, onde a atualização é validada antes de tocar o AVA real.
• Janela combinada com você, fora do horário de aula e de avaliação, com modo manutenção e verificação pós-upgrade.
• Monitoramento 24/7 com Grafana, Sentry e UptimeRobot, alertas no WhatsApp da equipe e uptime contratual de 99,9%.
• Atualização de LTS em até 90 dias do lançamento, e plano de rollback com o ambiente anterior preservado por 30 dias nas migrações.

Como funciona na prática: quando sai uma rodada como a de 12/11, nossa equipe lê as notas, atualiza a homologação, roda os testes de fumaça e marca a janela com a sua coordenação. Você recebe o aviso antes e o relatório depois. Quem atende é a mesma equipe que configura o servidor, em português e pelo WhatsApp.

Para contratar, escolha o plano na página de hospedagem Moodle gerenciada e fale com a gente. A migração do seu AVA atual entra no setup: usuários, cursos, notas e arquivos, homologados por você antes da virada. Se o seu AVA está no 5.0, começamos pelo diagnóstico de versão e plugins.

Conclusão: aplique agora e prepare a próxima

O Moodle 5.3.1 e as versões irmãs de 12/11 são o tipo de atualização que deveria levar uma janela curta e nenhum drama. A semana antes dos boletins é o melhor momento. Backup das três partes, homologação, modo manutenção, CLI e verificação: esse é o roteiro inteiro.

Depois, coloque 07/12/2026 na agenda, data prevista da próxima rodada. E se o seu AVA ainda está no 5.0, trate a migração como prioridade do recesso.

Se você prefere que essa esteira rode sem depender de alguém da sua equipe lembrar, conheça a hospedagem Moodle gerenciada da Agathas Web. A próxima rodada já fica no nosso calendário, não no seu.