Livewire vulnerable to remote command execution during property update hydration

Livewire v3 permite que um atacante não autenticado execute comandos remotos no servidor Laravel, explorando como o framework reidrata (desserializa) atualizações de propriedades de componentes enviadas pelo navegador. A falha está confirmada em exploração ativa (catálogo KEV da CISA) e afeta apenas a série 3.x — versões anteriores do Livewire não são impactadas.

O problema está em src/Mechanisms/HandleComponents/HandleComponents.php, no fluxo de hidratação de propriedades durante um update de componente. Antes da correção, quando uma atualização de propriedade já tinha metadados associados, o código chamava o método genérico hydrate() para reconstruir o valor a partir do tuple [valor, meta] enviado pelo cliente. Esse método genérico não distinguia contexto — ele tratava qualquer tuple sintético da mesma forma, independentemente de estar vindo de uma renderização inicial (confiável) ou de um payload de update (controlado pelo atacante).

O patch introduz um método dedicado, hydratePropertyUpdate(), que aplica validações específicas para esse contexto: verifica remoções aninhadas (`__rm__`) antes de hidratar, e usa propertySynth() para selecionar explicitamente o "synth" (serializador/desserializador de tipo) correto a partir dos metadados, chamando hydrate() com um callback controlado que reprocessa filhos recursivamente pelo caminho correto. Isso indica que a vulnerabilidade original era uma falha de desserialização insegura (correlata a CWE-502) que se manifestava como injeção de código (CWE-94, classificação usada pela CISA): o meta `s` de um tuple sintético controla qual synth processa o valor, e sem a validação de contexto adicionada no patch, um atacante podia manipular esse metadado no payload de update para forçar a hidratação por um synth não pretendido para aquele caminho, alcançando execução de código no servidor.

O vetor de entrada é o próprio mecanismo de "snapshot + updates" do Livewire: o estado do componente é serializado e enviado ao cliente, e o cliente devolve um payload de update (JSON) que o servidor deserializa para aplicar a mudança de propriedade. O atacante controla integralmente esse payload de update — incluindo os metadados de tipo — o que é a superfície de ataque explorada.

O vetor é uma requisição HTTP direta ao endpoint de update do Livewire (o mecanismo AJAX que o front-end usa para sincronizar propriedades de componente com o servidor), sem necessidade de autenticação nem de interação do usuário — a exploração é puramente do lado servidor, mediada por um payload malformado. O CVSS v4 reflete isso: AV:N, PR:N, UI:N, mas AC:H (complexidade de ataque alta), o que é consistente com a exigência do fornecedor de que 'um componente esteja montado e configurado de uma forma particular' — ou seja, nem toda aplicação Laravel com Livewire é explorável; depende de quais componentes e tipos de propriedade estão em uso e expostos publicamente sem autenticação.

O fornecedor não detalhou publicamente qual configuração específica torna um componente vulnerável (a advisory diz explicitamente que referências técnicas foram omitidas até o fim da janela de disclosure responsável). Isso significa que não há, nas fontes oficiais, uma lista fechada de traits, tipos de propriedade ou padrões de uso que definam o alvo exato — qualquer afirmação nesse sentido seria especulação.

Há exploração confirmada em ambiente real: a CVE está no catálogo KEV da CISA (classificada como CWE-94, injeção de código), existe PoC pública e template Nuclei, e o EPSS está próximo de 0.95 (probabilidade muito alta de exploração continuada). A combinação de ausência de autenticação, ausência de interação do usuário e existência de PoC público faz desta uma das poucas CVEs de framework PHP com risco real de scanning massivo e exploração automatizada em produção.

Atualizar para Livewire v3.6.4 ou posterior é a única mitigação confirmada pelo fornecedor. Não há workaround oficial: a advisory do GitHub afirma explicitamente 'There is no known workaround at this time' — qualquer configuração alternativa (WAF genérico, ocultar endpoints, etc.) é controle compensatório não endossado pelo fornecedor e não elimina a causa raiz na hidratação de propriedades.

Como controle compensatório temporário, na ausência de patch imediato, avalie restringir exposição de componentes Livewire desnecessariamente públicos (proxy/gateway limitando acesso ao endpoint de update do Livewire a rotas autenticadas quando o modelo de negócio permitir), e monitorar/bloquear via WAF payloads JSON anômalos nos parâmetros de update — mas isso é mitigação de risco, não correção, e pode gerar falsos positivos ou negativos dado que a vulnerabilidade está na lógica de hidratação, não em um padrão de payload trivialmente assinável.

Como a falha está incluída no catálogo KEV da CISA, organizações sujeitas à BOD 22-01 (ou que seguem essa referência como boa prática) devem tratar a atualização como prioridade de prazo curto, aplicando o patch imediatamente em vez de depender de mitigação de borda.

Não há assinatura de exploração amplamente publicada pelo fornecedor — a advisory reteve detalhes técnicos durante a janela de disclosure. Como sinal geral, monitore logs de aplicação e proxy por requisições POST anômalas ao endpoint de update do Livewire com estruturas JSON de 'snapshot'/'updates' fora do padrão esperado (metadados de tipo ou campos de sincronização de propriedade manipulados), erros 500 inesperados nesse endpoint, ou picos de requisições consistentes com scanning automatizado — a existência de template Nuclei público sugere que scanners de massa usam uma assinatura de requisição/resposta específica, que pode ser correlacionada em WAF/IDS caso a assinatura do Nuclei esteja disponível ao time de detecção.

A presença desta CVE no catálogo KEV da CISA confirma exploração ativa, mas não há, nas fontes oficiais consultadas, indicadores de comprometimento (IOCs) publicados que permitam distinção confiável entre tentativa e sucesso sem acesso ao payload exato usado nos ataques reportados.