Resposta rápida

• O que aconteceu: duas falhas críticas no PHP, apelidadas de PHP2Shell (CVE-2026-109618 e CVE-2026-109619), permitem execução remota de código sem login. Foram divulgadas em 21 de outubro de 2026 e têm nota 9.2 no CVSS 4.0.
• Por que o Moodle importa: o Moodle é escrito em PHP. A falha está no PHP que serve o site, não no código do Moodle. Atualizar o Moodle ou seus plugins não resolve.
• A correção: atualizar o PHP para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou superior), reiniciar os processos que atendem o tráfego e confirmar qual runtime está de fato em execução.
• Atenção a quem usa PHP 8.1 ou anterior: o projeto PHP não publicou versões oficiais corrigidas para essas ramificações.
• LGPD: se dados pessoais forem expostos, o prazo para comunicar a ANPD e os titulares é de até três dias úteis após o conhecimento do incidente (o dobro para agentes de pequeno porte). Instituições de ensino tratam dados de crianças e adolescentes, um dos critérios de relevância da norma.
• O ponto estrutural: a janela entre a divulgação de uma falha e a tentativa de exploração está cada vez menor. Segurança por revisão trimestral deixa de ser suficiente. É preciso monitoramento contínuo, WAF e atualização automatizada.

O que é o PHP2Shell?

PHP2Shell é o nome coletivo de duas vulnerabilidades críticas no interpretador PHP: a CVE-2026-109618, de execução remota de código por corrupção de memória em condição de falta de memória (out-of-memory), e a CVE-2026-109619, de execução remota de código por estado global obsoleto, em que o PHP mantém referências a memória de requisição já liberada. Ambas receberam 9.2 (crítica) no CVSS 4.0, não exigem autenticação e levam à execução de código com os privilégios do processo que atende o site.

Nome popular

PHP2Shell

Identificadores

CVE-2026-109618 e CVE-2026-109619

Tipo

Execução remota de código (RCE), sem autenticação

Gravidade

9.2 (crítica), CVSS 4.0

Divulgação pública

21 de outubro de 2026

Versões corrigidas

PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12

Sem versão oficial corrigida

PHP 8.1, 8.0, 7.4 e anteriores (apenas backports de fornecedores ou de código-fonte)

Runtimes citados como afetados

PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed (a facilidade de exploração varia)

Correção completa

Somente a atualização do PHP

Linha do tempo resumida

• 20 de outubro de 2026: uma publicação no Hacker News anunciou que duas falhas de RCE no PHP seriam divulgadas, e o projeto PHP publicou um aviso de segurança fora do ciclo regular, segundo a HeroDevs.
• 21 de outubro de 2026: o projeto PHP lançou correções para quatro ramificações e o aviso de segurança sobre as duas CVEs.
• Exploração: veículos como Itdaily, Techzine e Help Net Security relataram exploração ativa e a circulação de uma prova de conceito; o Dark Reading informa que a empresa Calif descobriu as falhas e que a WatchTowr afirmou ter conseguido reproduzir ambas. O boletim inicial da HeroDevs, de 21/10, ainda registrava ausência de exploração confirmada, o que mostra como o cenário mudou em poucas horas.
• Na Holanda, segundo a Techzine, organizações como o centro nacional de cibersegurança (NCSC) tiraram sites do ar por precaução antes dos patches.

Por que o PHP2Shell afeta o Moodle?

O Moodle é um sistema de gestão de aprendizagem escrito em PHP. Toda página que um aluno abre, toda entrega de atividade e todo login passam pelo PHP do servidor. Portanto, a vulnerabilidade não é um defeito do Moodle, mas o Moodle herda o risco do runtime em que roda. Reportagens sobre o caso listam o Moodle entre os gerenciadores de conteúdo que funcionam sobre PHP, ao lado de WordPress, Joomla!, Drupal e Typo3.

Isso tem uma consequência prática que surpreende muitos gestores: manter o Moodle na última versão não protege contra o PHP2Shell. A correção está no PHP, e a exploração acontece durante o processamento da requisição HTTP, antes de o código da aplicação rodar.

Versões de PHP e Moodle: o que corrige o quê?

Cada versão do Moodle aceita uma faixa específica de PHP. Cruzando essa faixa com as versões corrigidas, o cenário fica assim:

• PHP 8.2 chega ao fim de vida em 31 de dezembro de 2026. Corrigi-lo hoje é uma solução de curto prazo. Para o Moodle 4.5, 5.0 e 5.1, o PHP 8.3 ou 8.4 é o destino mais duradouro, respeitando a faixa de cada versão.
• PHP 8.5.12 recebeu a correção, mas a tabela do Moodle Docs consultada não lista o PHP 8.5 como suportado. Não salte para uma versão que o Moodle ainda não declara compatível sem homologar.
• Versões do Moodle fora de suporte não recebem correções de segurança próprias. A orientação do próprio projeto é atualizar para uma versão suportada. Datas de suporte mudam: confirme em docs.moodle.org.

O PHP2Shell também é um lembrete de que o Moodle, como qualquer aplicação grande, recebe correções de segurança frequentes por conta própria. Em 2026, por exemplo, foram publicados avisos como a CVE-2026-26045 (risco de execução de código via restauração de backup malicioso, que exige acesso autenticado privilegiado, corrigida nas versões 4.5.9, 5.0.5 e 5.1.2) e a CVE-2026-58332 (contorno da verificação por e-mail do MFA, para quem já conhece a senha do usuário, aviso MSA-26-0013 do Moodle). São camadas diferentes de risco, e as duas precisam de atenção ao mesmo tempo: o PHP embaixo e o Moodle em cima.

Por que WAF e plugins não bastam sozinhos?

De acordo com a Techzine, a falha se manifesta quando o PHP interpreta a requisição HTTP em memória, antes de qualquer código da aplicação ser executado. Por isso, controles que vivem dentro da aplicação, como permissões, plugins de segurança ou validações do Moodle, não chegam a ser consultados. Um sistema fortemente customizado é tão vulnerável quanto uma instalação padrão.

Um WAF (firewall de aplicação web) ajuda, porque pode bloquear padrões de requisição conhecidos antes de chegarem ao servidor. Mas ele tem limites, que a própria comunidade de segurança aponta: só protege o tráfego que passa por ele, casa com padrões de ataque conhecidos em vez de corrigir a falha e é contornado por conexões diretas ao servidor de origem. A conclusão é consistente em todas as fontes consultadas: WAF reduz a exposição, e a atualização do PHP resolve a causa.

A era das IAs caçando brechas

Pesquisadores da Wiz, citados pela Help Net Security, afirmam que as falhas existiam havia décadas e que demonstrar sua exploração exigia uma cadeia de passos extremamente complexa, no limite do que pesquisadores humanos conseguiriam. Segundo a análise deles, modelos de IA de fronteira reduziram substancialmente essa barreira, transformando uma falha antiga em exploit.

A Itdaily descreve o caso como uma ilustração da janela cada vez mais curta entre a divulgação de uma CVE e a exploração ativa. Para comparação, a HeroDevs lembra que, no caso da CVE-2024-4577, a Akamai viu tentativas de exploração em até 24 horas após a divulgação.

As dores de quem gerencia infraestrutura Moodle

Gestores de TI de universidades, faculdades e colégios costumam conviver com um conjunto parecido de dilemas. Use as perguntas abaixo como um autoexame rápido:

• Você sabe qual PHP está servindo o seu Moodle neste momento? O php -v no terminal pode apontar uma instalação diferente da usada pelo PHP-FPM ou pelo Apache.
• O medo de quebrar plugins e tema impede atualizações? Plugins customizados e integrações com sistemas acadêmicos tornam cada upgrade uma decisão de risco.
• O PHP e o Moodle evoluem em ritmos diferentes? Cada versão do Moodle aceita uma faixa de PHP. Subir um sem planejar o outro gera bloqueios.
• Existe alguém lendo, todos os dias, os avisos de segurança do PHP, do Moodle e dos sistemas operacionais?
• Há WAF com regras pensadas para o Moodle e o servidor de origem aceita só tráfego vindo dele?
• Os backups foram restaurados em teste recentemente? Backup que nunca foi restaurado é uma hipótese, não uma garantia.
• A plataforma aguenta a semana de matrícula ou de provas com um incidente em andamento?
• Se dados de alunos vazarem, você consegue demonstrar à ANPD quais medidas de segurança estavam em vigor?

Checklist das primeiras 24 horas

1. Inventário: liste todos os servidores PHP que atendem tráfego web, inclusive homologação e ambientes esquecidos. Confirme a versão do runtime que serve as requisições, não só a do terminal.
2. Atualize o PHP para uma versão corrigida compatível com o seu Moodle (veja a tabela acima). Teste em homologação quando possível, mas não deixe a produção exposta por falta de um ciclo completo de testes.
3. Reinicie ou substitua os processos do servidor web e do PHP-FPM. Trocar a etiqueta de uma imagem sem reimplantar a carga de trabalho é uma correção incompleta.
4. Se não puder atualizar agora, aplique as mitigações provisórias da próxima seção e restrinja o acesso ao servidor de origem.
5. Ative ou revise o WAF com regras para a falha e feche o acesso direto à origem.
6. Garanta backup recente do banco de dados, dos arquivos da plataforma e da configuração, armazenado fora do servidor.
7. Revise logs do período anterior à correção e siga o roteiro da seção de verificação de comprometimento.
8. Avise o encarregado (DPO) e o jurídico se houver qualquer indício de acesso indevido, para que o prazo da LGPD seja acompanhado desde o início.

Mitigações provisórias: ganham tempo, não substituem o patch

O projeto PHP e fornecedores de segurança descrevem configurações temporárias. Todas devem ser aplicadas em php.ini, no pool do PHP-FPM ou em php_admin_value, e não via ini_set() ou .user.ini, que atuam tarde demais, segundo a MassiveGrid. Reinicie os processos depois. Teste o efeito colateral no seu Moodle antes, principalmente sobre envio de arquivos.

• As fontes recomendam não usar RLIMIT_AS ou RLIMIT_DATA como limite de memória, porque provocam justamente a falha de alocação de que a primeira vulnerabilidade depende.
• Controles de borda: WAF com regras atualizadas, restrição do servidor de origem aos IPs do provedor de WAF e, para sites que não recebem envios, bloqueio de requisições multipart. Em um Moodle, que recebe arquivos de usuários, bloquear multipart tende a quebrar funções essenciais.
• Redução de impacto pós-exploração: pools e usuários de sistema separados por site, confinamento com AppArmor ou SELinux, filtragem de tráfego de saída, e desativação de funções de execução de comandos quando não usadas. Teste antes: alguns recursos do Moodle podem depender de programas externos.

Depois do patch: como verificar se houve comprometimento

A Wavect resume o ponto com clareza: uma atualização, por si só, não estabelece que o sistema está limpo. A ThreatLocker reforça que fechar a vulnerabilidade não remove persistência ou código malicioso que já estivesse no servidor. Se o seu Moodle ficou exposto antes da correção, considere:

• Procurar arquivos novos ou alterados em diretórios de código e de dados que não correspondam a atualizações conhecidas.
• Verificar processos filhos incomuns do servidor web e conexões de saída inesperadas.
• Conferir contas administrativas, tarefas agendadas e plugins que ninguém instalou.
• Analisar logs de acesso e de erro por requisições anormais, falhas fatais e esgotamento de memória.
• Trocar credenciais e chaves que estavam acessíveis ao servidor, se houver indício de acesso indevido.
• Acionar uma investigação de incidente, com apoio especializado, em caso de qualquer sinal de comprometimento.

Estas são boas práticas gerais de resposta a incidentes, não um procedimento oficial do projeto PHP ou do Moodle.

LGPD: vazamento de dados, prazos e multas

Uma instituição de ensino que usa Moodle trata dados pessoais de alunos, muitos deles menores de idade, e de colaboradores. A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) trata a segurança como obrigação do agente de tratamento, e não como diferencial.

O que a lei e a regulamentação exigem

• Medidas de segurança (art. 46): os agentes de tratamento devem adotar medidas técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito.
• Comunicação de incidentes (art. 48): o controlador deve comunicar à ANPD e ao titular a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante.
• Prazo (Resolução CD/ANPD nº 15/2024): até três dias úteis contados do conhecimento de que o incidente afetou dados pessoais, tanto para a ANPD quanto para os titulares. Para agentes de tratamento de pequeno porte, os prazos são dobrados. Informações complementares podem ser enviadas em até 20 dias úteis após a comunicação inicial.
• Quando é obrigatória: quando o incidente pode afetar significativamente interesses e direitos fundamentais e envolve ao menos um destes: dados sensíveis; dados de crianças, adolescentes ou idosos; dados financeiros; dados de autenticação; dados protegidos por sigilo; ou tratamento em larga escala.
• Registro: o controlador deve manter registro de todos os incidentes, inclusive os não comunicados, por no mínimo cinco anos, com data de conhecimento, circunstâncias, dados afetados, avaliação de risco e medidas corretivas. A ANPD pode solicitar esse registro a qualquer momento.

Sanções (art. 52)

As sanções administrativas incluem advertência, multa simples de até 2% do faturamento da pessoa jurídica no último exercício, limitada a R$ 50 milhões por infração, multa diária, publicização da infração, bloqueio e eliminação dos dados. Segundo a Confidata, a ANPD classifica a infração em leve, média ou grave, ajusta a multa conforme agravantes e atenuantes e considera cooperação, ação corretiva e boa governança como fatores de redução. O mesmo levantamento observa que a autoridade vem migrando de uma postura educativa para a fiscalização ativa, e que decisões judiciais com indenização por danos morais ampliam o risco além das multas.

Perda de dados e plataforma fora do ar

Além do vazamento, um incidente em um Moodle pode significar perda de dados (notas, entregas, trilhas de aprendizagem) e indisponibilidade em momentos críticos, como matrícula, prova e fechamento de notas. Para reduzir esse risco:

• Backups completos e fora do servidor: banco de dados, arquivos da plataforma e configuração, com retenção definida.
• Teste periódico de restauração: meça quanto tempo leva para voltar ao ar e quanto de dado você perderia.
• Alta disponibilidade: uma arquitetura em cluster evita que um único servidor seja ponto único de falha.
• Plano de incidente: quem decide, quem comunica e em que ordem, antes de a crise acontecer.
• Calendário acadêmico no radar: evite janelas de manutenção sem plano em períodos de prova, mas não adie correções críticas por causa disso.

Segurança contínua para Moodle: como a Codely resolve

A Codely Tecnologia atua há 19 anos com plataformas EaD e, segundo o site institucional, atende mais de 500 plataformas. Na modalidade Codely SaaS, a manutenção e o suporte da infraestrutura e da aplicação ficam sob responsabilidade da Codely, com cluster na AWS e alta disponibilidade informada de 99,9% ao ano. Em casos como o PHP2Shell, o modelo de segurança contínua se apoia em três mecanismos:

1. Monitoramento contínuo de CVEs: análise das vulnerabilidades publicadas por órgãos e fornecedores internacionais, para identificar rapidamente o que afeta o ambiente Moodle de cada cliente.
2. WAF especializado em Moodle: camada de proteção na borda, com regras pensadas para o comportamento da plataforma, para reduzir a exposição enquanto a correção definitiva é aplicada.
3. Atualização automatizada para a última versão segura: processo de upgrade do Moodle e do ambiente, sem depender de iniciativa manual do cliente a cada boletim.

Um ponto de honestidade: nenhuma camada elimina o risco por completo. O objetivo é reduzir ao máximo a janela entre a divulgação de uma falha e a proteção do ambiente, e garantir que cada instituição tenha processo e evidências quando algo acontecer.

Dez perguntas para avaliar quem hospeda ou mantém o seu Moodle

1. Quem monitora os avisos de segurança do PHP, do Moodle e do sistema operacional, e com que frequência?
2. Qual foi o tempo entre a divulgação do PHP2Shell e a proteção do meu ambiente?
3. Qual versão de PHP e de Moodle eu uso hoje, e até quando cada uma recebe correções de segurança?
4. Há WAF? Com regras específicas para Moodle? O servidor de origem aceita só o tráfego do WAF?
5. Como são feitas as atualizações: automatizadas, validadas em homologação, com plano de retorno?
6. Onde ficam os backups, com que retenção, e quando foi o último teste de restauração?
7. A arquitetura é redundante (cluster) ou depende de um único servidor?
8. Como e em quanto tempo serei avisado se houver incidente que envolva dados pessoais, para cumprir o prazo da LGPD?
9. Que registros de atualização e monitoramento posso apresentar ao DPO ou à ANPD?
10. O contrato define responsabilidades sobre segurança, disponibilidade e tratamento de dados?

Fale com a Codely hoje

Se o seu Moodle roda em PHP, vale uma conversa rápida para saber qual versão está em uso, qual é a sua exposição e como manter a plataforma protegida sem depender de ações manuais a cada novo alerta.

Agendar reunião urgente no WhatsAppEnviar mensagem

WhatsApp: +55 (11) 97979-9102
E-mail: contato@codely.com.br
Site: codely.com.br

Perguntas frequentes sobre PHP2Shell e Moodle

O que é o PHP2Shell?

PHP2Shell é o nome coletivo de duas vulnerabilidades críticas no próprio PHP, identificadas como CVE-2026-109618 e CVE-2026-109619, ambas com nota 9.2 no CVSS 4.0. Elas permitem execução remota de código (RCE) sem login, em servidores que processam requisições web com PHP. Foram divulgadas publicamente em 21 de outubro de 2026.

O Moodle é afetado pelo PHP2Shell?

A falha está no PHP, não no código do Moodle. Como o Moodle é escrito em PHP, qualquer servidor Moodle que rode uma versão de PHP sem a correção fica exposto até que o PHP seja atualizado. Atualizar o Moodle ou os plugins não corrige o problema, porque a correção precisa ser aplicada no PHP que atende as requisições.

Quais versões do PHP corrigem a falha?

As versões corrigidas são PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. As ramificações 8.1, 8.0, 7.4 e anteriores não recebem versões oficiais do projeto PHP. Nesses casos, a correção depende de backports de distribuições, de fornecedores de suporte estendido ou de compilação a partir dos backports de código-fonte publicados.

Atualizar o Moodle ou os plugins resolve?

Não. A vulnerabilidade está no runtime PHP, e a exploração ocorre durante o processamento da requisição HTTP, antes de o código da aplicação rodar. É preciso atualizar o PHP, reiniciar ou substituir os processos que atendem o tráfego e confirmar qual runtime está realmente em execução.

Meu Moodle roda em PHP 8.1. O que fazer?

O Moodle 4.5 LTS aceita PHP de 8.1 a 8.3, mas o projeto PHP não publicou versão oficial corrigida para a ramificação 8.1. A saída é migrar para o PHP 8.3 corrigido (8.3.36 ou superior), que o Moodle 4.5 suporta, ou usar um backport confiável de um fornecedor. Teste em homologação antes e confira a compatibilidade dos plugins.

Posso usar PHP 8.5 com o Moodle?

Na página de requisitos do Moodle Docs consultada em 23/10/2026, o limite máximo listado para as versões 4.5, 5.0, 5.1 e 5.2 é o PHP 8.4. O PHP 8.5.12 recebeu a correção, mas isso não significa que o Moodle o suporte. Use PHP 8.3 ou 8.4 corrigidos, conforme a versão do seu Moodle, e confirme na documentação oficial antes de qualquer salto.

Um WAF protege contra o PHP2Shell?

Um WAF com regras específicas reduz a exposição, mas não substitui a atualização do PHP. Ele protege apenas o tráfego que passa por ele, e conexões diretas ao servidor de origem o contornam. A boa prática é combinar WAF, restrição de acesso à origem e correção do PHP.

Qual é o prazo para comunicar um incidente à ANPD?

Pela Resolução CD/ANPD nº 15/2024, o controlador deve comunicar à ANPD e aos titulares em até três dias úteis após tomar conhecimento de um incidente que possa acarretar risco ou dano relevante. O prazo é dobrado para agentes de tratamento de pequeno porte. Dados de crianças e adolescentes, dados de autenticação e tratamento em larga escala estão entre os critérios de relevância.

Qual é a multa da LGPD por vazamento de dados?

O artigo 52 da LGPD prevê multa simples de até 2% do faturamento da empresa no último exercício, limitada a R$ 50 milhões por infração, além de outras sanções como advertência, publicização da infração e bloqueio ou eliminação dos dados. O valor concreto depende de critérios definidos pela ANPD, como gravidade, reincidência e cooperação.

Como saber se meu Moodle já foi comprometido, mesmo após atualizar o PHP?

Atualizar não prova que o servidor está limpo. Se a plataforma ficou exposta antes da correção, vale investigar arquivos inesperados, processos filhos incomuns do servidor web, novas contas administrativas, plugins desconhecidos e acessos suspeitos nos logs. Em caso de indício, acione uma investigação de incidente em paralelo à correção.

Como a Codely protege plataformas Moodle contra falhas como essa?

A Codely opera a plataforma Moodle em cluster na AWS com monitoramento contínuo de vulnerabilidades (CVEs) publicadas por órgãos e fornecedores, WAF especializado em Moodle e atualização automatizada da aplicação para a última versão segura. O objetivo é reduzir a janela entre a divulgação de uma falha e a proteção do ambiente, sem depender de ação manual do cliente.

Glossário

CVE

Identificador público de uma vulnerabilidade de segurança conhecida (Common Vulnerabilities and Exposures).

CVSS

Sistema de pontuação da gravidade de vulnerabilidades, de 0 a 10. Notas a partir de 9.0 são críticas.

RCE

Execução remota de código: o atacante consegue rodar comandos no servidor da vítima à distância.

PHP

Linguagem de programação executada no servidor, na qual o Moodle é escrito.

Runtime

O ambiente que executa o código, aqui o PHP instalado no servidor web (PHP-FPM, Apache com mod_php e outros).

WAF

Firewall de aplicação web: filtra requisições maliciosas antes de chegarem ao servidor.

Backport

Correção levada para uma versão antiga, sem migrar para uma versão nova. Não equivale a uma versão mantida pelo projeto.

LGPD

Lei Geral de Proteção de Dados (Lei nº 13.709/2018).

ANPD

Autoridade Nacional de Proteção de Dados, órgão que fiscaliza a LGPD.

Controlador e DPO

Controlador é quem decide sobre o tratamento dos dados. O encarregado (DPO) é o canal entre o controlador, os titulares e a ANPD.

Cluster

Conjunto de servidores que operam juntos, para aumentar disponibilidade e resiliência.

Fontes e metodologia

Este artigo foi elaborado em 23 de outubro de 2026 com base nas fontes abaixo. A situação do PHP2Shell evolui rapidamente: confirme versões e orientações no aviso oficial do projeto PHP (php.net) e na documentação do Moodle (docs.moodle.org) antes de agir. As datas de suporte do Moodle e as informações de exploração foram obtidas de veículos e fornecedores de segurança, e podem ter sido atualizadas.

1. Help Net Security — PHP2Shell: Critical PHP vulnerabilities patched
2. Dark Reading — 'PHP2Shell' Bugs Signal Red Alert for Security Industry
3. Techzine — PHP shuts the internet: why PHP2Shell affects every company
4. Itdaily — PHP2Shell: major PHP vulnerability actively exploited ahead of patch availability
5. HeroDevs — PHP2Shell (CVE-2026-109618 / CVE-2026-109619) PHP RCE
6. MassiveGrid — PHP CVE-2026-109618/109619: mitigations when you cannot patch
7. Vercel — PHP security advisory: php2shell
8. Wavect — PHP2Shell: legacy PHP upgrade and migration
9. ThreatLocker — PHP2Shell: why organizations must patch critical PHP vulnerabilities now
10. ImpactoTIC — Vulnerabilidades PHP: PHP2Shell obliga a actualizar servidores web
11. Moodle Docs — PHP (versões de PHP suportadas por versão do Moodle)
12. endoflife.ai — Moodle 5.0 EOL (datas de suporte por versão)
13. HeroDevs — CVE-2026-58332 (Moodle, MFA por e-mail)
14. GitLab Advisory Database — CVE-2026-26045 (Moodle, restauração de backup)
15. Mattos Filho — Regulamento de Comunicação de Incidente de Segurança (Resolução CD/ANPD nº 15/2024)
16. Confidata — Multas da LGPD: valores, critérios e casos
17. Planalto — Lei nº 13.709/2018 (LGPD), texto oficial
18. Codely Tecnologia — site institucional

Informações sobre a oferta da Codely foram extraídas do site codely.com.br e das práticas de operação da empresa. Este conteúdo é informativo e não constitui aconselhamento jurídico.