Como Corrigir Vulnerabilidades de Segurança Antes que Outros as Descubram

Imagine: você está de plantão, e de repente chega um alerta sobre uma invasão bem-sucedida em uma versão antiga de um CMS que todos esqueceram há muito tempo. Um cenário desagradável, não é? Na prática, a segurança frequentemente perde para a velocidade de desenvolvimento, e os administradores simplesmente não conseguem acompanhar o fluxo de novos CVEs. Felizmente, existem entusiastas que reúnem todas as "armas" de ataque em um só lugar. Hoje vamos analisar o repositório PoC do usuário eeeeeeeeee-code — um enorme arquivo de exploits e scripts prontos para testar vulnerabilidades.

O Que É Esse Projeto e Por Que Você Precisa Dele

O repositório é um banco de dados vivo de Proof of Concept (PoC). Originalmente, o projeto era um backup da conhecida biblioteca de vulnerabilidades wy876, mas o autor decidiu não apenas armazenar o arquivo — escolheu desenvolvê-lo ativamente. Agora é uma das coleções mais atualizadas de cenários de ataque voltados tanto para softwares chineses quanto internacionais.

Por que um desenvolvedor ou administrador de sistemas precisa disso? A resposta é simples: para testar seus sistemas "em combate." Em vez de ler descrições secas em bancos de dados de CVE, você pega um cenário pronto e vê se funciona contra seu servidor. Se funcionar — é hora de atualizar urgentemente ou fechar aquela porta.

O Que Observar Por Dentro

O repositório tem centenas de pastas, divididas por fornecedores e tipos de sistemas. Tem de tudo aqui: desde falhas em roteadores até bugs críticos em frameworks modernos de IA como o Langflow.

O Favorito de Todos: Injeção SQL

O banco de dados está literalmente lotado de exemplos de injeção SQL. Isso se aplica tanto a sistemas CRM quanto a portais corporativos de gerenciamento de energia. Depois de ver esses exemplos, você percebe que erros clássicos de filtragem de parâmetros ainda estão muito vivos.

Execução Remota de Código (RCE)

A coisa mais perigosa. O banco de dados tem cenários recentes para sistemas Zhiyuan OA e até bugs críticos no Kubernetes Ingress-Nginx. Por exemplo, a vulnerabilidade CVE-2025-1974 demonstra claramente como uma configuração incorreta pode levar ao controle de um cluster.

Leitura Arbitrária de Arquivos

Um problema frequentemente subestimado. Cenários para sistemas como MasterSAM ou DeepFlow mostram como um atacante pode extrair arquivos de configuração com senhas de banco de dados simplesmente acessando um determinado endpoint.

Valor Prático para a Equipe

Normalmente, esses repositórios são usados por pentesters, mas há muita coisa útil aqui também para uma equipe de desenvolvimento comum.

1. Testes de regressão de segurança. Se sua empresa usa algum software específico (por exemplo, sistemas Dify ou Langflow), você pode adicionar verificações deste repositório aos seus pipelines de CI/CD.
2. Aprendendo com os erros dos outros. Os arquivos internos são excelentes materiais de aprendizado. Você abre uma pasta com uma vulnerabilidade do WordPress ou Grafana e vê exatamente onde o desenvolvedor errou.
3. Verificações rápidas da infraestrutura. Quando surge uma notícia sobre um novo CVE em algum framework, um PoC funcional provavelmente aparecerá aqui em poucos dias.

Dê uma olhada no log de atualizações do último mês — há dezenas de entradas.

Algumas Considerações sobre Segurança

Ao trabalhar com essas ferramentas, é importante lembrar de duas coisas. Primeiro, é uma "espada de dois gumes." Use apenas em seu próprio sandbox ou em sistemas onde você tem permissão oficial para caça de bugs. Segundo, o README do projeto está em chinês, o que pode dificultar um pouco a navegação, mas a estrutura de pastas wpoc/VendorName/VulnerabilityName.md é intuitiva.

Dentro de cada arquivo .md, você geralmente encontrará uma descrição da vulnerabilidade, parâmetros de requisição e um exemplo de payload. Tudo é o mais específico possível, sem enrolação desnecessária.

Vale a Pena Experimentar

Se você é responsável pela segurança da infraestrutura ou constrói serviços empresariais, este repositório vale um favorito. Não é apenas uma "lista de falhas" — é uma ferramenta de defesa ativa.

O projeto é alimentado ativamente — literalmente há apenas alguns dias, foram adicionados métodos frescos de bypass de autenticação para plugins WordPress e RCE em servidores SSH no Erlang-OTP. Esse é um bom motivo para auditar suas dependências e garantir que você não está usando software com mais de uma década que pode ser invadido com uma única requisição HTTP.

Claro, a documentação é um pouco escassa em algumas partes, e alguns links levam a recursos externos chineses, mas para um especialista técnico, há mais do que código suficiente e exemplos de requisições. Lembre-se: é melhor encontrar a falha você mesmo usando PoC do que descobrir sobre ela com hackers.