Moodle MAT: O Risco dos Moodles Departamentais em 2026

Moodle MAT é como alunos e professores da UnB chamam o ambiente virtual do Departamento de Matemática, hospedado em moodle.mat.unb.br, e o termo voltou a subir nas buscas brasileiras nesta semana. A coincidência é desconfortável: em 10 de agosto de 2026 o projeto Moodle publicou correções para as quatro versões ainda vivas. Quem cuida de uma instância departamental tem poucos dias de vantagem.

TL;DR

• Em 10 de agosto de 2026 saíram as versões 5.2.2, 5.1.6, 5.0.9 e 4.5.13 — todas com correções de segurança cujos detalhes só vêm a público cerca de uma semana depois.
• Instâncias departamentais como o Moodle MAT costumam ficar fora do inventário da TI central: sem dono, sem janela de manutenção, sem ambiente de homologação.
• 5 de outubro de 2026 é a data que decide tudo: o 5.1 perde o suporte geral, o 5.0 perde até o suporte de segurança e o 5.3 LTS é lançado.
• O salto para o 5.1 ou superior exige apontar o document root do servidor para a pasta /public e realocar plugins de terceiros. É aí que a maioria dos upgrades trava.
• O 5.2 sobe o piso técnico (PHP 8.3, PostgreSQL 16, MySQL 8.4, MariaDB 10.11) e traz Google Gemini e AWS Bedrock como provedores de IA no núcleo.

O que é o Moodle MAT — e por que isso importa fora da UnB

O Moodle MAT é um caso clássico de instância departamental: um Moodle próprio, mantido por um departamento acadêmico, rodando em paralelo ao ambiente institucional da universidade. Ele existe por um motivo legítimo. Matemática tem necessidades que o ambiente virtual central raramente atende bem — renderização de fórmulas em LaTeX, bancos de questões com variáveis aleatórias, listas de exercícios com correção automática e turmas que atravessam vários semestres sem serem apagadas.

O padrão se repete no Brasil inteiro. Departamentos de exatas, laboratórios, programas de pós-graduação, escolas de governo, setores de treinamento interno: cada um levantou seu Moodle no dia em que precisou de liberdade que a TI central não dava. O resultado é uma malha de instalações que ninguém consegue enxergar de cima.

Para dimensionar o tamanho disso: o painel público do projeto, em stats.moodle.org, contabiliza 146.104 sites Moodle registrados no mundo, com o Brasil em 5º lugar e 6.895 instalações — atrás de Espanha (12.554), Estados Unidos (12.032), Alemanha (7.927) e México (7.800). E aqui está o detalhe que muda a leitura do número: o registro é voluntário. Todo Moodle MAT da vida que nunca foi registrado está fora dessa conta. O total real de instâncias brasileiras é maior — provavelmente muito maior.

A rodada de 10 de agosto de 2026: quatro versões no mesmo dia

Em 10 de agosto de 2026 o projeto liberou, simultaneamente, Moodle 5.2.2, 5.1.6, 5.0.9 e 4.5.13. Publicar todas as branches suportadas no mesmo dia é o comportamento típico do projeto quando há correção de segurança no pacote.

E há. As notas de versão trazem a frase que administradores aprenderam a temer: os detalhes das falhas corrigidas serão divulgados após aproximadamente uma semana. A lógica é sensata — dar tempo de atualizar antes que a receita do ataque vire pública.

Traduzindo para o calendário: quem lê isto em 13 de agosto de 2026 tem poucos dias de folga. Por volta do dia 17, os boletins MSA correspondentes entram no ar em moodle.org/security e qualquer pessoa passa a conseguir mapear quais versões estão vulneráveis e como.

Não é teoria. A rodada anterior, de 22 de junho de 2026, trouxe os boletins MSA-26-0026 a MSA-26-0029: SSRF cego na função de peers do MNet, risco de negação de serviço via descrição de perfil de usuário e duas falhas de verificação de permissão — uma no report builder, outra na alocação de corretores do módulo Tarefa. Antes delas, o MSA-26-0006 tratou de risco de execução remota de código pelo plugin de repositório do Google Drive, catalogado como CVE-2026-7275.

Nenhuma dessas falhas exige um atacante sofisticado. Exige apenas uma instalação parada no tempo — que é exatamente o perfil de um Moodle departamental típico.

O calendário que decide o destino do seu Moodle MAT

O ciclo de vida oficial está publicado em moodledev.io/general/releases e é o documento que deveria estar colado na parede de quem administra qualquer instância:

Versão	Lançamento	Fim do suporte geral	Fim do suporte de segurança
4.5 LTS	07/10/2024	06/10/2025	04/10/2027
5.0	14/04/2025	20/04/2026	05/10/2026
5.1	06/10/2025	05/10/2026	19/04/2027
5.2	20/04/2026	19/04/2027	04/10/2027
5.3 LTS	05/10/2026	04/10/2027	01/10/2029

Três leituras práticas dessa tabela:

1. Se o seu Moodle MAT roda 5.0, o relógio para em 5 de outubro de 2026. Depois disso não existe mais correção de segurança para essa branch. Faltam menos de dois meses.
2. Se roda 4.5 LTS, você já não recebe correção de bug comum desde outubro de 2025 — só segurança, e ainda assim até outubro de 2027. Dá para respirar, não para relaxar.
3. Se roda 5.1, o suporte geral termina em 5 de outubro de 2026, mas a segurança segue até abril de 2027. É a posição mais confortável para planejar um upgrade sem correria.

E há uma oportunidade de planejamento que quase ninguém aproveita: o 5.3 LTS chega em 5 de outubro de 2026, com suporte de segurança até 1º de outubro de 2029. Para instância departamental, sem equipe dedicada e sem orçamento recorrente, LTS é quase sempre a escolha certa. Três anos de previsibilidade valem mais que recursos novos que ninguém vai usar.

Por que instâncias departamentais envelhecem mais rápido

Não é preguiça. É estrutura. O Moodle MAT nasce assim em qualquer instituição, e sempre pelos mesmos três motivos.

Não existe dono formal

A instalação foi feita por um professor entusiasta, um bolsista ou um técnico que já mudou de setor. Quando o servidor pede atenção, não há a quem recorrer. O sistema continua funcionando — e funcionar é justamente o que adia a manutenção. Ninguém atualiza o que não está quebrado, mesmo quando o que está quebrado é invisível.

Não existe janela de manutenção

O ambiente institucional tem calendário de paradas negociado com a reitoria. O departamental não tem. Toda semana é semana de prova, entrega de lista ou fechamento de nota. Sem janela combinada, a atualização no Moodle MAT do departamento é sempre adiada para "depois do semestre" — e o semestre nunca acaba.

Não existe homologação

Atualizar direto em produção é uma aposta. Quem já viu um upgrade quebrar um plugin de fórmulas às 23h de um domingo de prova não repete o erro: simplesmente para de atualizar. O medo, aqui, é racional. A solução também é simples — um clone do ambiente para testar antes — mas exige alguém que assuma a tarefa.

A armadilha do /public: por que o salto para o 5.1 trava

A partir do Moodle 5.1 o código foi reestruturado. Só a pasta /public fica acessível pela web; núcleo, bibliotecas e configuração passam a viver fora do diretório servido. É um ganho real de segurança, documentado no guia de reestruturação do código — e é também o motivo pelo qual tantos upgrades empacam.

Três consequências práticas:

• O document root do servidor precisa apontar para a pasta /public. No Apache, DocumentRoot /var/www/moodle/public; no Nginx, root /var/www/moodle/public;. Sem esse ajuste, o Moodle simplesmente não carrega.
• O $CFG->wwwroot no config.php não termina em /public. Alterar essa linha por engano é o erro mais comum de quem faz o upgrade em hospedagem compartilhada, e gera uma mensagem de erro que assusta mais do que deveria.
• Plugins de terceiros instalados na estrutura antiga precisam ser realocados para o caminho equivalente dentro de /public. Temas customizados, plugins de fórmulas, integrações de videoconferência: cada um precisa ser conferido individualmente.

Num Moodle MAT com dez plugins acumulados ao longo de oito anos, o terceiro item costuma ser o que mata o projeto. Ninguém lembra quem instalou, de onde veio, se ainda é mantido. A recomendação prática que damos aos clientes é sempre a mesma: antes de encostar no servidor, exporte a lista de plugins adicionais e verifique a compatibilidade de cada um com a versão-alvo. Um plugin abandonado é motivo suficiente para adiar o upgrade — e para começar a procurar substituto agora, não em outubro.

O Moodle 5.2 sobe o piso técnico (e traz IA no núcleo)

O 5.2, lançado em 20 de abril de 2026, elevou os requisitos mínimos: PHP 8.3 (com 8.4 suportado), PostgreSQL 16, MySQL 8.4, MariaDB 10.11 ou SQL Server 2019. Se o servidor onde vive o Moodle MAT do seu departamento roda PHP 8.1 e MariaDB 10.6 — configuração comuníssima em máquinas provisionadas por volta de 2021 — o upgrade deixa de ser um problema de aplicação e vira um problema de infraestrutura. Isso muda o prazo, o custo e quem precisa aprovar.

Do lado das funcionalidades, a novidade que interessa a quem dá aula é a entrada de dois provedores de inteligência artificial no núcleo do Moodle: Google Gemini (plugin da comunidade promovido a core) e AWS Bedrock. Na prática, dá para ligar geração de resumos, apoio à correção e assistentes de curso sem depender de plugin externo — algo que até 2025 exigia integração feita à mão.

E aqui mora um risco novo. Um dos boletins de junho, o MSA-26-0024, tratou justamente de verificação de permissão ausente nos web services de placement de IA. Recurso novo significa superfície de ataque nova. Se a decisão é habilitar IA no ambiente, a disciplina de atualização deixa de ser opcional no mesmo dia.

Consolidar no ambiente institucional ou manter o Moodle MAT separado?

Não existe resposta única. Existe critério. Depois de operar ambientes críticos de EAD por mais de uma década, é assim que avaliamos:

Consolide no ambiente central quando:

• O departamento usa apenas recursos padrão (tarefa, questionário, fórum, nota).
• Não há plugin exclusivo em uso real — só instalado.
• A base ativa é pequena e o custo de manter servidor próprio não se paga.
• Ninguém no departamento quer (ou pode) assumir responsabilidade técnica formal.

Mantenha separado quando:

• Existe dependência real de plugins que a TI central não homologa.
• O calendário acadêmico do departamento não bate com o institucional.
• Há pesquisa, extensão ou curso pago rodando ali, com requisitos próprios.
• Existe orçamento e pessoa designada para manutenção — não boa vontade, designação.

O erro clássico é o meio-termo por inércia: manter o Moodle MAT separado sem assumir a responsabilidade técnica que a separação exige. É o pior dos dois mundos — a autonomia sem o suporte, o risco sem o benefício.

Checklist: auditando um Moodle departamental em uma tarde

Este roteiro serve para auditar o Moodle MAT ou qualquer instância que você tenha herdado. Leva menos de três horas e já entrega um diagnóstico defensável:

1. Descubra a versão exata. Administração do site → Notificações mostra a release instalada. Compare com a tabela de ciclo de vida acima.
2. Confira PHP e banco de dados. Administração do site → Servidor → Ambiente aponta o que está abaixo do mínimo da próxima versão.
3. Liste os plugins adicionais. Para cada um, anote nome, versão e se ainda recebe atualização no diretório oficial.
4. Teste a restauração de um backup. Backup que nunca foi restaurado não é backup, é esperança.
5. Verifique o cron. Sem cron rodando com regularidade, notificações, backups e filas param silenciosamente.
6. Cheque o certificado HTTPS e a data de expiração. Renovação automática configurada, de preferência.
7. Revise as contas com papel de administrador. Ex-bolsistas e ex-professores costumam continuar lá.
8. Confirme o registro do site em moodle.org — é o que garante recebimento de alertas de segurança por e-mail.
9. Verifique os web services do app mobile. Se estiverem ligados, o app é uma porta de entrada que também precisa de atenção.
10. Registre um dono e uma janela mensal. Sem esses dois itens no papel, o checklist inteiro vira um retrato — e não um processo.

O que fazer com isso ainda em agosto

A janela é curta e a conta é simples: um Moodle MAT ou qualquer outro Moodle departamental parado no 5.0 perde o suporte de segurança em 5 de outubro de 2026, e os detalhes das falhas corrigidas em 10 de agosto ficam públicos ainda nesta semana. A ordem de prioridade que sugerimos é aplicar o patch da branch atual agora, auditar plugins e ambiente em seguida, e só então planejar o salto — de preferência mirando o 5.3 LTS de outubro.

Sou Cleverson Gouvêa, desenvolvedor full stack, certificado em Moodle e CTO do IEJUR. Desde 2008, à frente da Agathas Web, opero ambientes de EAD em servidores Linux com Redis e cuido exatamente desse tipo de instalação órfã: upgrade de versão, migração para a estrutura /public, ajuste de infraestrutura e consolidação de instâncias espalhadas. Já vi Moodle de 2016 em produção com plugin sem manutenção desde 2019 — o cenário é mais comum do que parece.

Se o próximo passo do seu departamento é levar o ambiente para o celular do aluno, vale entender antes as opções: comparamos o app oficial e o app próprio em Moodle Mobile App vs app personalizado, detalhamos o processo de publicar o app Moodle na Google Play e na App Store e mostramos o impacto real das notificações push no engajamento. Só que nada disso funciona bem sobre uma base desatualizada. A atualização vem primeiro.

Quer um diagnóstico da sua instância antes de outubro? Fale com a gente — a auditoria inicial não custa nada e o relatório é seu, independentemente de contratar ou não.