CVE-2024-43429 e CVE-2024-28593: por que um Moodle desatualizado é um risco

Caso real de produção, contado sem identificar o cliente. Numa manutenção de segurança, uma plataforma Moodle que atendemos estava rodando uma versão desatualizada — e, por isso, exposta a vulnerabilidades públicas, já catalogadas como CVE. Duas delas ilustram bem o ponto, porque atingem partes bem diferentes do sistema. E servem para desfazer um mal-entendido comum sobre vulnerabilidades.

CVE-2024-43429 — vazamento de dados no gradebook

Falha de exposição de informação nos relatórios do gradebook (livro de notas). Na versão afetada, campos ocultos do perfil do usuário ficavam visíveis para quem não tinha a permissão "ver campos ocultos do usuário". Ou seja: dado que deveria estar escondido acabava aparecendo para quem não deveria vê-lo. Severidade CVSS 5.3 (média). Foi corrigida nas versões de manutenção 4.4.2, 4.3.6, 4.2.9 e 4.1.12 do Moodle. Detalhes públicos: CVE-2024-43429 no NVD.

Num contexto corporativo ou educacional, isso não é detalhe: exposição indevida de dados pessoais é exatamente o tipo de coisa que a LGPD cobra.

CVE-2024-28593 — injeção de HTML no Chat

Falha na atividade de Chat: era possível inserir elementos HTML (como <a> ou <img>) ou conteúdo que degradava o desempenho da atividade. É uma injeção de HTML — o tipo de brecha que, dependendo do cenário, abre porta para conteúdo indesejado dentro de uma área usada por alunos. Severidade CVSS 5.4 (média), também resolvida nas versões de manutenção do Moodle. Detalhes públicos: CVE-2024-28593 no NVD.

O mal-entendido que vale corrigir

É comum imaginar que uma vulnerabilidade "habilita" a outra, como um dominó. Não é o caso aqui. Estas duas são independentes: uma vive no gradebook, a outra no Chat, com causas e efeitos distintos. O que elas realmente têm em comum é o essencial — e é aí que está a lição: ambas só afetam versões desatualizadas, e ambas são resolvidas pela mesma coisa — manter o Moodle numa versão suportada, com as atualizações de segurança aplicadas.

O diagnóstico e a solução

Não há mágica nem "hardening" heroico a fazer para casos assim: o certo é identificar a versão em uso, cruzá-la com as CVEs publicadas que a afetam e aplicar a atualização de segurança que as corrige — validando em ambiente de teste antes de tocar na produção, para não trocar um problema por outro. Foi o que fizemos: subir a plataforma para uma versão com as correções, preservando cursos, notas e inscrições.

O resultado

Plataforma numa versão com as correções aplicadas, as duas CVEs eliminadas, e — o que mais importa — um processo para não repetir: acompanhar os anúncios de segurança do Moodle e atualizar antes de virar manchete. Segurança de Moodle não é um evento, é rotina.

A leitura do caso: "o Moodle é seguro?" é a pergunta errada. Como explicamos em o Moodle é seguro?, o software é seguro por design — mas a segurança final depende de estar atualizado. Rodar uma versão antiga é deixar CVEs públicas de porta aberta; qualquer um lê o aviso de segurança e sabe o que procurar.