Uso inseguro de pickle.loads() em canais gRPC sem autenticação expõe o PolicyServer e o cliente robótico do LeRobot à execução arbitrária de código quando o serviço está acessível pela rede.
| Componente | Hugging Face LeRobot, especialmente o pipeline assíncrono de inferência nos componentes PolicyServer e cliente robótico. |
| Vetor | Envio de payload serializado malicioso por canais gRPC não autenticados e sem TLS, usando chamadas SendPolicyInstructions, SendObservations ou GetActions. |
| Impacto | Execução remota arbitrária de código no servidor ou no cliente que desserializa dados controlados pelo atacante com pickle.loads(). |
| Prioridade | Restringir imediatamente a exposição de rede do PolicyServer e do cliente, bloquear acesso não confiável aos canais gRPC e acompanhar a correção planejada para a versão 0.6.0. |
| CVE | A vulnerabilidade é identificada como CVE-2026-25874, com pontuação CVSS 9.3 no material analisado. |
| Versões | A exploração foi validada contra o LeRobot 0.4.3; o problema permanece sem correção no material analisado, com correção planejada para 0.6.0. |
| Artefatos | Uso de pickle.loads() sobre entrada de rede não autenticada, presença de canais gRPC sem TLS e chamadas SendPolicyInstructions, SendObservations e GetActions. |
A vulnerabilidade CVE-2026-25874 afeta o LeRobot, plataforma aberta de robótica da Hugging Face, e decorre de desserialização insegura de dados não confiáveis no pipeline assíncrono de inferência. O ponto crítico é o uso de pickle.loads() para processar conteúdo recebido por canais gRPC que, no cenário descrito, não exigem autenticação e não utilizam TLS. Como o formato pickle pode carregar objetos com comportamento executável durante a desserialização, aceitar esse conteúdo diretamente da rede transforma chamadas de inferência em um caminho para execução arbitrária de código no host que roda o serviço vulnerável.
O impacto confirmado é execução remota de código no servidor ou no cliente, dependendo de qual componente recebe e processa o payload. O fluxo citado envolve o PolicyServer e o cliente robótico, com exploração por chamadas gRPC como SendPolicyInstructions, SendObservations e GetActions. A condição prática é o atacante conseguir alcançar a porta de rede do serviço vulnerável. Não há necessidade de credenciais no modelo descrito, o que eleva a gravidade operacional quando o serviço fica exposto em redes de laboratório compartilhadas, ambientes de pesquisa conectados a infraestrutura interna ou implantações de inferência utilizadas fora de um perímetro isolado.
O caso é particularmente sensível porque sistemas de inferência para robótica e inteligência artificial frequentemente são executados próximos de recursos de alto valor, como máquinas com GPU, conjuntos de dados, arquivos de modelos e integrações internas. O material analisado também aponta riscos condicionados de acesso a chaves de API, credenciais SSH e arquivos de modelo, além de interrupção de serviços, corrupção de modelos ou sabotagem de operações. Esses efeitos dependem das permissões do processo vulnerável, do alcance de rede do host e dos recursos acessíveis a partir da conta usada para executar o LeRobot.
A falha nasce da combinação de três condições: entrada de rede controlada por terceiros, ausência de autenticação no canal gRPC e desserialização com pickle.loads(). Em um desenho seguro, dados vindos de uma chamada remota deveriam ser tratados como conteúdo não confiável e convertidos por um formato que não execute código durante a leitura. No fluxo vulnerável, porém, o serviço recebe dados serializados por chamadas ligadas à política de inferência e às observações do robô, então entrega esse conteúdo ao mecanismo de desserialização do Python. Um payload pickle construído para disparar comportamento durante o carregamento pode executar comandos no sistema operacional quando o processo interpreta o objeto.
O componente destacado é o PolicyServer do pipeline assíncrono de inferência. O atacante precisa alcançar a porta de rede do PolicyServer ou do cliente que aceita as chamadas gRPC citadas. A partir daí, a exploração não depende de uma sessão autenticada, porque o canal descrito é não autenticado. A falta de TLS também remove uma camada de proteção contra inspeção, manipulação e validação do par remoto no transporte, embora a causa principal da execução de código seja a desserialização insegura de dados controlados pelo atacante.
A exploração foi validada contra o LeRobot 0.4.3, e a correção estava planejada para a versão 0.6.0 no material analisado. O histórico informado também indica que a área afetada do código foi reconhecida como experimental e necessitando refatoração ampla. Essa característica importa para defesa porque o problema não é apenas uma checagem ausente em uma borda isolada: o desenho do fluxo de inferência aceita um formato perigoso em uma fronteira de confiança errada. Enquanto a correção não estiver aplicada, controles compensatórios precisam impedir que entradas não confiáveis cheguem a pickle.loads().
A pontuação CVSS 9.3 reflete a severidade de um caminho remoto e sem autenticação para execução de código. Ainda assim, o impacto final deve ser avaliado pelo contexto de implantação. Se o processo roda como usuário sem privilégios, sem acesso a segredos, sem montagem de diretórios sensíveis e em uma rede isolada, a consequência direta pode ficar limitada ao ambiente do serviço. Se o mesmo processo roda com permissões elevadas, acesso a datasets, credenciais, arquivos de modelos ou recursos caros de computação, a execução de código pode ser usada para ações muito mais danosas dentro do alcance desse processo.
A superfície principal é qualquer implantação do LeRobot em que o PolicyServer ou o cliente robótico aceite tráfego gRPC de origem não confiável e processe esse tráfego com o pipeline assíncrono de inferência vulnerável. A exposição é mais grave quando a porta do serviço está acessível fora de uma rede local estritamente controlada, quando há roteamento entre redes de usuários e hosts de inferência, ou quando ambientes de pesquisa compartilham máquinas entre múltiplos operadores sem segmentação forte.
Ambientes de robótica e aprendizado de máquina costumam crescer a partir de protótipos, notebooks, scripts de laboratório e serviços internos. Esse padrão cria risco quando componentes criados para experimentação passam a ser usados em produção, em bancadas remotas ou em infraestrutura compartilhada sem endurecimento equivalente ao de um serviço exposto. No caso do LeRobot, a combinação de inferência remota, gRPC e pickle exige inventário preciso dos pontos em que o PolicyServer e o cliente estão em execução, quais portas aceitam conexões e quais identidades do sistema operacional executam os processos.
A versão 0.4.3 é a referência concreta de validação da falha no material analisado. Como o problema é descrito no desenho do pipeline assíncrono de inferência e a correção é planejada para 0.6.0, operadores não devem assumir segurança apenas por pequenas alterações locais ou por ausência de exploração observada. A triagem deve verificar o uso real de pickle.loads() em caminhos de entrada gRPC, a exposição da porta do serviço e a presença das chamadas SendPolicyInstructions, SendObservations e GetActions no tráfego ou na configuração da aplicação.
- Instâncias do LeRobot
0.4.3comPolicyServeracessível pela rede são prioridade de verificação. - Clientes robóticos que recebem instruções ou observações por gRPC e desserializam conteúdo com
pickle.loads()entram no escopo técnico da falha. - Ambientes com acesso a chaves de API, credenciais SSH, arquivos de modelo, datasets ou recursos de computação devem ser tratados como de maior impacto potencial.
- Serviços gRPC sem autenticação e sem TLS não devem ficar acessíveis a redes de usuários, redes convidadas, VPNs amplas ou segmentos compartilhados sem controle de origem.
A investigação deve começar pela descoberta de processos e portas associados ao LeRobot, com atenção especial ao PolicyServer. O objetivo é identificar onde o serviço aceita conexões gRPC, quais hosts conseguem alcançá-lo e se há chamadas aos métodos SendPolicyInstructions, SendObservations ou GetActions vindas de origens inesperadas. Como o vetor é rede para desserialização, logs de aplicação, logs de proxy interno, fluxos de rede e registros de firewall podem ajudar a reconstruir o alcance de exposição mesmo quando a aplicação não registra payloads.
No endpoint, a telemetria útil inclui criação de processos filhos a partir do processo do LeRobot, execução de comandos do sistema operacional, leitura incomum de diretórios contendo modelos, datasets ou segredos e falhas/crashes próximos a requisições gRPC. Uma tentativa de exploração pode aparecer como instabilidade do serviço, serializações anômalas ou execução inesperada de binários pelo usuário que roda o serviço. Como o contexto não fornece hashes, domínios ou endereços IP, a detecção não deve depender de IoCs fixos; a abordagem mais confiável é comportamental e baseada na relação entre entrada gRPC e efeitos no host.
Também é importante revisar o código e a configuração em busca de usos explícitos de pickle.loads() em caminhos que recebem dados de rede. Comentários que suprimem ferramentas de análise, como marcações destinadas a ignorar alertas de segurança, devem ser tratados como sinal de revisão obrigatória quando aparecem junto de desserialização. A pergunta operacional é simples: existe algum caminho em que um par remoto consiga influenciar bytes entregues a pickle.loads()? Se a resposta for sim, o serviço precisa ser isolado ou alterado até que a correção oficial esteja disponível e validada.
- Conexões gRPC para o
PolicyServeroriginadas de hosts fora do segmento esperado. - Chamadas
SendPolicyInstructions,SendObservationsouGetActionsem horários, origens ou volumes incompatíveis com a operação normal. - Processos filhos, comandos de shell ou acesso a arquivos sensíveis disparados pelo processo que executa o LeRobot.
- Crashes, corrupção de arquivos de modelo ou reinicializações do serviço próximos a tráfego gRPC anômalo.
- Ocorrências de
pickle.loads()em rotas de entrada remota durante revisão de código, especialmente quando acompanhadas de supressão de alertas de ferramenta.
A resposta imediata deve reduzir a superfície de rede antes de depender de uma atualização ainda planejada. Instâncias do PolicyServer e clientes robóticos não devem aceitar conexões de redes não confiáveis. Regras de firewall, listas de controle de acesso, segmentação e exposição apenas em interfaces internas estritamente necessárias reduzem o caminho de exploração. Quando o serviço for indispensável para pesquisa ou operação, a comunicação deve ficar restrita a hosts conhecidos e monitorados, com validação do fluxo gRPC permitido.
A correção estrutural é remover a desserialização insegura de dados controlados por rede. Enquanto o código continuar usando pickle.loads() para entrada remota, controles de perímetro apenas diminuem probabilidade, mas não eliminam a classe de falha. A migração para um formato de serialização que não execute código durante o carregamento, combinada com autenticação, criptografia de transporte e validação de esquema, é a direção técnica apropriada para esse tipo de pipeline. O material analisado informa que a correção está planejada para 0.6.0, portanto equipes que usam LeRobot devem acompanhar esse ramo de atualização e testar a mudança antes de reexpor serviços.
A contenção deve incluir revisão das permissões do processo. O LeRobot não deve rodar com privilégios além do necessário, nem com acesso irrestrito a credenciais, chaves de API, chaves SSH, datasets e arquivos de modelos. Se houver suspeita de exposição, trate o host como potencialmente executado por código externo dentro do nível de permissão do serviço: preserve logs, identifique processos criados, revise arquivos modificados e avalie rotação de segredos que estavam legíveis pelo usuário do processo. A validação final deve confirmar que a porta gRPC não está acessível por origem não autorizada e que não há mais caminho de desserialização insegura para dados recebidos da rede.
- Inventariar instâncias do LeRobot e localizar
PolicyServere clientes expostos por gRPC. - Bloquear acesso de rede não confiável às portas do serviço e permitir apenas origens operacionais conhecidas.
- Executar o serviço com usuário de baixo privilégio e sem acesso desnecessário a chaves de API, credenciais SSH, datasets ou arquivos de modelo.
- Revisar o código para remover
pickle.loads()de caminhos alimentados por entrada remota não confiável. - Acompanhar e testar a correção planejada para
0.6.0antes de restaurar qualquer exposição de rede mais ampla. - Coletar logs de aplicação, rede e endpoint quando houver indício de chamadas gRPC anômalas ou execução inesperada de comandos.
0 Comentários