# Comunicado: proteção contra uma falha de segurança no PHP ## O que aconteceu? O ILLI funciona graças a várias peças de software. Uma delas se chama **PHP**: ela recebe os pedidos que você faz no sistema (abrir uma tela, salvar uma venda, enviar uma foto) e entrega as respostas. Em outubro de 2026, especialistas do mundo todo descobriram **duas falhas no PHP**. Ele é usado por milhões de sites, então o problema não é só do ILLI: atinge a internet inteira. ## Como seria um ataque? Pense no PHP como um **carteiro** que recebe pacotes na porta do prédio. 1. Um espertinho manda um pacote **gigante e muito embrulhado**: uma caixa dentro de outra caixa, dentro de outra caixa... 2. O carteiro tenta abrir tudo, fica sem espaço nos braços e **se atrapalha**. 3. Nessa confusão, ele pode **esquecer um bilhete do pacote anterior no bolso** e entregá-lo para a pessoa errada. Um atacante esperto conseguiria usar essa confusão para dar ordens ao carteiro, como se fosse o dono do prédio. ## O que a Illimitar fez? Ainda não existe uma versão consertada para a peça que usamos. Por isso colocamos **várias proteções em volta dela**, como um condomínio que reforça a segurança: | Proteção | Comparação | |---|---| | 🚪 **Porteiro na entrada** | Antes de o pacote chegar ao carteiro, um porteiro confere o tamanho. Pacote grande demais nem entra. | | 🐢 **Fila organizada** | Se alguém tenta mandar pacotes demais, rápido demais, o porteiro pede para esperar. | | 📦 **Caixas dentro de caixas, só até certo ponto** | Pacotes com embrulhos demais são recusados. | | 🧹 **Bolsos sempre vazios** | Depois de cada entrega, o carteiro troca de uniforme. Não sobra bilhete de ninguém para o próximo. | | 🧠 **Sem pânico por falta de espaço** | O carteiro não se atrapalha mais quando o pacote é grande. Se algo der muito errado, ele é trocado por outro, descansado e com os bolsos vazios. | | 🔒 **O resto do prédio continua seguro** | O sistema dele tem um limite próprio e não afeta o restante do servidor. | Também guardamos uma **cópia de tudo como estava antes**, para desfazer as mudanças rapidamente se for preciso. ## Meus dados estão seguros? As proteções já estão sendo aplicadas nos servidores, e cada um passa por uma verificação depois da mudança. Também procuramos sinais de tentativas de ataque nos registros dos servidores e continuamos de olho. Quando a versão consertada do PHP estiver disponível e testada com o ILLI, vamos instalá-la também. Será como trocar a fechadura velha por uma nova, além de manter o porteiro. ## Vou perceber alguma diferença? Quase nenhuma. O ILLI, as vendas e o sincronismo das lojas continuam funcionando normalmente. A única mudança que você pode notar: - **Arquivos muito grandes** (mais de 32 MB) não podem mais ser enviados de uma vez. Fotos, logos e planilhas do dia a dia são bem menores que isso. ## Preciso fazer alguma coisa? **Não.** Tudo foi feito do nosso lado. Só entre em contato com o suporte se: - aparecer um erro ao **enviar um arquivo** que antes funcionava; - a **sincronização** de alguma loja parar. Assim conseguimos ajustar rapidinho. --- ## Informações técnicas *Esta seção é para a equipe de TI da sua empresa. Quem não é da área pode pular.* ### Vulnerabilidades | Identificação | Descrição | Gravidade | |---|---|---| | **CVE-2026-109618** | *Use-after-free* quando o PHP atinge o `memory_limit` durante o parsing de requisições `multipart/form-data`. O erro fatal deixa o estado da requisição corrompido. | Crítica | | **CVE-2026-109619** | Estado global do `session.upload_progress` reaproveitado entre requisições atendidas pelo mesmo processo do PHP-FPM. | Crítica | Combinadas, as duas permitem execução remota de código no servidor web sem autenticação. A correção oficial existe a partir do PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Versões anteriores dependem de correções publicadas pelas distribuições e mantenedores de pacotes. ### Mitigações aplicadas pela Illimitar | Camada | Medida | Efeito | |---|---|---| | PHP | `session.upload_progress.enabled = Off` | Remove o estado global explorado pela CVE-2026-109619. | | PHP | `memory_limit = -1`, com teto de memória no cgroup do serviço (systemd) | O PHP não aborta no meio do parsing. Se o limite for atingido, o sistema operacional encerra o processo inteiro, que é recriado limpo. | | PHP | `max_input_nesting_level` reduzido; `post_max_size` e `upload_max_filesize` em 32 MB | Reduz a amplificação de memória por campos aninhados e o tamanho máximo do corpo. | | PHP-FPM | `pm.max_requests = 1` | Cada processo atende uma única requisição e é recriado, então nenhum estado passa para a próxima. | | NGINX | `client_max_body_size` de 32 MB e `fastcgi_request_buffering on` | Corpos grandes são recusados antes do PHP (HTTP 413), e o PHP só recebe requisições completas, com tamanho declarado. | | NGINX | Limite de requisições `multipart` por IP | Reduz tentativas em massa (HTTP 503 para o excesso). Outros tipos de requisição não são afetados. | Todas as alterações têm backup e podem ser desfeitas, e cada servidor recebe um laudo automático antes e depois da aplicação. O laudo verifica a configuração efetiva de cada pool do PHP-FPM e procura indícios de exploração nos logs. ### Próximas etapas - Substituição do PHP por pacotes com a correção oficial (*backport*), servidor a servidor, após homologação com o ILLI e em janela de manutenção. - Depois disso, os ajustes temporários de memória e de reciclagem de processos voltam aos valores normais. As demais proteções continuam. ### Referências - PHP Security Advisories: - Google Cloud: - Cloudflare: --- *Equipe Illimitar*