Falha no Open VSX permitia publicar extensões maliciosas sem varredura de segurança

Erro de tratamento de falhas na fila de scanners fazia o registro aprovar extensões quando a conexão com o banco era esgotada sob carga concorrente.

Componente	Pipeline de varredura antes da publicação do Open VSX, registro usado por extensões de VS Code e por ambientes como Cursor, Windsurf e outros derivados.
Vetor	Publicações concorrentes de várias extensões .VSIX podiam gerar carga suficiente para esgotar o pool de conexões do banco de dados, impedindo o enfileiramento dos trabalhos de scanner.
Impacto	Quando os scanners falhavam ou não eram enfileirados, o serviço interpretava o resultado como ausência de scanners configurados e marcava a extensão como aprovada, ativando-a para download.
Prioridade	Atualizar para Open VSX 0.32.0, revisar publicações ocorridas durante períodos de falha de scanner e separar explicitamente estados de sucesso, ausência de scanner e erro operacional.
Versões	A correção foi disponibilizada no Open VSX 0.32.0 após divulgação responsável em 8 de fevereiro de 2026.
Artefatos	Extensões .VSIX, trabalhos de scanner, fila de varredura, serviço de recuperação de varreduras falhas e pool de conexões do banco de dados.
Condição	A exploração não exigia privilégio especial além de uma conta gratuita de publicador no registro.

Resumo técnico

Uma vulnerabilidade já corrigida no Open VSX afetava a etapa de varredura antes da publicação de extensões. O problema estava no modo como o serviço em Java representava o resultado do pipeline de segurança: um único valor booleano era usado para sinalizar tanto o caso legítimo de ausência de scanners configurados quanto o caso operacionalmente crítico em que scanners existentes falhavam ou não conseguiam ser executados. Essa ambiguidade fazia o chamador tratar uma falha de infraestrutura como se não houvesse nada a verificar, permitindo que a extensão seguisse para publicação.

O impacto é relevante porque o Open VSX funciona como registro de extensões para ecossistemas compatíveis com o VS Code, incluindo Cursor, Windsurf e outros derivados. A varredura antes da publicação havia sido adotada para reduzir a entrada de extensões maliciosas no repositório. Em condições normais, extensões reprovadas deveriam ser colocadas em quarentena para análise administrativa. Com a falha, um cenário de carga concorrente podia impedir o enfileiramento dos scanners e, em vez de bloquear a publicação por erro, o pipeline aprovava a extensão e a disponibilizava para download.

A falha recebeu o codinome Open Sesame e foi corrigida no Open VSX 0.32.0. A causa técnica não era uma capacidade de execução remota contra usuários finais nem um desvio de autenticação administrativo; era uma decisão incorreta de tratamento de erro em uma barreira de supply chain. O risco central estava na possibilidade de uma extensão maliciosa atravessar o controle preventivo do registro sem ser analisada, desde que o atacante conseguisse acionar as condições de falha do pipeline durante a publicação.

Fluxo técnico

O fluxo vulnerável começava no endpoint de publicação. Um ator com uma conta gratuita de publicador podia enviar várias extensões .VSIX em paralelo. Essa concorrência aumentava a pressão sobre a infraestrutura que deveria registrar e enfileirar os trabalhos de scanner. Quando o pool de conexões do banco de dados era esgotado, os trabalhos de varredura podiam falhar antes de serem enfileirados. A etapa seguinte deveria distinguir esse erro de infraestrutura de um cenário válido em que nenhum scanner havia sido configurado. O defeito estava justamente nessa fronteira de decisão.

Como os dois estados retornavam o mesmo valor booleano, a lógica consumidora não conseguia diferenciar “não há scanner para executar” de “há scanners, mas eles falharam ou não foram enfileirados”. O resultado prático era um comportamento de falha aberta: o erro não gerava bloqueio, quarentena ou reprovação temporária; gerava aprovação. Assim, uma extensão podia ser marcada como aprovada, ativada imediatamente e publicada no Open VSX sem passar pela verificação que deveria anteceder a disponibilidade pública.

O serviço de recuperação, projetado para tentar novamente varreduras com falha, também sofria do mesmo problema de interpretação. Isso reduzia a eficácia da recuperação automática porque a falha inicial e a tentativa posterior podiam cair na mesma ambiguidade lógica. Em uma arquitetura de publicação segura, falhas de scanner, falhas de fila e indisponibilidade de banco precisam ser estados explícitos e bloqueantes. Neste caso, a reutilização de um único retorno para estados semanticamente diferentes transformou uma camada de segurança preventiva em um controle que podia abrir sob pressão operacional.

Superfície afetada

A superfície exposta era o processo de publicação de extensões no Open VSX, não uma estáção de trabalho específica nem um editor individual isolado. O ponto crítico ficava antes da entrada da extensão no registro: a extensão submetida deveria passar por scanners e, em caso de reprovação, seguir para quarentena administrativa. Quando a falha era acionada, a extensão podia entrar no catálogo sem essa etapa. Isso afeta a cadeia de confiança de usuários e organizações que dependem do registro para obter extensões em ambientes compatíveis com VS Code.

Ambientes que consomem extensões do Open VSX devem tratar o episódio como risco de supply chain associado ao registro e ao processo de publicação. A exploração não dependia de privilégios especiais no registro, mas de capacidade de publicação e de geração de carga concorrente. A consequência confirmada é o bypass da varredura antes da publicação. Qualquer conclusão além disso, como comprometimento de dados ou execução em endpoints de usuários, depende do conteúdo específico de uma extensão maliciosa publicada e não deve ser presumida sem evidência adicional.

• Registro Open VSX e seu pipeline de varredura antes da publicação.
• Extensões .VSIX submetidas por contas de publicador.
• Fila de trabalhos de scanner e conexão com o banco de dados usada para enfileiramento.
• Serviço de recuperação responsável por tentar novamente varreduras que falharam.
• Consumidores de extensões em editores e derivados compatíveis com VS Code.

Hunting e telemetria

A investigação defensiva deve começar pela correlação entre eventos de publicação e eventos de scanner. Publicações concluídas durante janelas de erro de banco de dados, esgotamento de pool de conexões ou falha de enfileiramento merecem revisão manual, principalmente quando não houver evidência clara de execução bem-sucedida dos scanners. O sinal mais importante não é apenas a presença de uma extensão suspeita, mas a inconsistência entre o estado publicado e a ausência de resultado de varredura associado.

Equipes que operam registros, pipelines de segurança ou catálogos internos devem procurar padrões de falha aberta semelhantes. Um desenho seguro precisa registrar estados distintos para ausência deliberada de scanner, falha ao iniciar scanner, falha ao enfileirar trabalho, falha transitória de banco, reprovação por scanner e aprovação efetiva. Métricas agregadas também ajudam: picos de publicação, aumento de falhas de conexão, crescimento de tentativas de recuperação e queda inesperada na taxa de scanners executados podem indicar uma janela em que o controle preventivo ficou degradado.

• Publicações aprovadas sem registro correspondente de scanner executado com sucesso.
• Erros de enfileiramento de trabalhos de scanner próximos ao horário de publicação.
• Sinais de esgotamento do pool de conexões do banco durante rajadas de submissões.
• Extensões ativadas imediatamente após falhas operacionais do pipeline.
• Tentativas do serviço de recuperação que terminam no mesmo estado ambíguo de aprovação.

Mitigação

A mitigação principal é atualizar o Open VSX para a versão 0.32.0, que contém a correção. Após a atualização, a resposta defensiva deve incluir revisão das extensões publicadas em janelas nas quais o pipeline tenha apresentado falhas de scanner, indisponibilidade de banco ou carga concorrente elevada. Quando não houver prova de varredura concluída, a decisão conservadora é retirar a extensão de disponibilidade automática ou encaminhá-la para análise administrativa até que a verificação seja repetida com sucesso.

Para equipes que mantêm pipelines equivalentes, a lição técnica é separar estados de decisão. “Sem trabalho necessário” não pode compartilhar retorno com “trabalho falhou”. Falhas de scanner devem ser bloqueantes por padrão, com quarentena, reprocessamento controlado e trilha de auditoria. A recuperação automática também precisa preservar a semântica da falha: se o reprocessamento não consegue enfileirar ou executar a análise, o estado final não deve ser aprovação. O objetivo é impedir que degradação de infraestrutura seja convertida em confiança indevida.

Também é recomendável validar limites de concorrência no endpoint de publicação, capacidade do pool de conexões e comportamento do sistema sob carga. Testes de estresse devem verificar não apenas disponibilidade, mas a decisão de segurança resultante quando dependências falham. Uma barreira de publicação pode aceitar degradação temporária desde que degrade para bloqueio ou quarentena, não para liberação. Em supply chain, a segurança do registro depende tanto dos scanners quanto da forma como o sistema interpreta a ausência, falha e recuperação desses scanners.

• Atualizar o Open VSX para 0.32.0.
• Revisar extensões publicadas durante falhas de scanner, falhas de enfileiramento ou esgotamento de conexões.
• Tratar falhas de scanner como estado bloqueante, com quarentena ou reprovação temporária.
• Criar códigos de resultado distintos para ausência de scanner, aprovação, reprovação e erro operacional.
• Testar o pipeline sob carga concorrente para confirmar que falhas degradam para bloqueio, não para aprovação.