Diário de segurança.
Publicamos as descobertas depois de serem corrigidas e verificadas — um breve resumo, nunca uma receita de exploit. Os tempos de correção ficam ao lado de cada entrada.
O que aconteceu.
Revisão interna antes do lançamento do programa
Em 15 de julho de 2026 iniciámos uma revisão de segurança interna do CreateYourVPN. As correções que concluímos e voltámos a verificar são publicadas abaixo; seguir-se-ão outras à medida que forem implementadas e confirmadas.
— equipa CreateYourVPNAdicionada uma salvaguarda contra uma configuração cross-origin insegura
A configuração de production atual não permitia origens arbitrárias, mas o código permitia uma combinação perigosa de parâmetros caso um operador a configurasse incorretamente. Essa combinação é agora rejeitada no arranque e coberta por um teste automatizado.
— equipa CreateYourVPNReduzida a superfície pública da API de production
A documentação técnica interativa da API estava acessível sem autenticação. Não dava acesso a dados protegidos, mas facilitava o estudo da estrutura interna da API. Em production a documentação está agora desativada, mantendo-se disponível num ambiente isolado para desenvolvimento.
— equipa CreateYourVPNChaves criptográficas da plataforma separadas por finalidade
Uma revisão interna constatou que um único segredo era usado para duas tarefas criptográficas diferentes. Isto não criava qualquer contorno direto, mas ampliava o alcance de um comprometimento da chave. As duas finalidades foram separadas e cada uma passa agora por rotação independente.
— equipa CreateYourVPNGarantida a limpeza da chave de gestão após a eliminação do servidor
A limpeza da chave de gestão cifrada corria depois de operações de rede em segundo plano e podia não se repetir se essas operações falhassem. Separámos a limpeza da chave da cascata de rede e adicionámos uma nova tentativa garantida. Os cenários de servidor inacessível e de processo interrompido estão cobertos por testes.
— equipa CreateYourVPNRemovido um caminho de autorização não utilizado da API de parceiros
A API suportava um caminho de autorização adicional baseado em cookie de que a arquitetura server-side atual não precisava. Não foi encontrado nenhum ataque entre sítios em production, mas o caminho adicional ampliava a superfície para erros futuros. A API usa agora um único método de autorização definido explicitamente, coberto por testes negativos.
— equipa CreateYourVPNFoi restringido o acesso ao painel de gestão da infraestrutura
Um investigador externo comunicou que uma interface administrativa de gestão da infraestrutura respondia a partir da internet. A interface estava protegida por autenticação e não foram encontrados sinais de acesso não autorizado. O relatório foi aceite e o acesso restringido.
A interface está agora acessível apenas a partir de endereços autorizados, os requisitos de autenticação foram reforçados e os componentes envolvidos atualizados. O resultado foi verificado a partir de fora da nossa rede. Revimos ainda a nossa superfície pública e acrescentámos uma verificação periódica. A recompensa foi paga no escalão mais alto.
— Gaurang MahetaOs endereços de e-mail dos utilizadores das lojas deixaram de ser guardados
Uma pessoa escreve o seu e-mail para entrar na loja de um parceiro, mas o endereço não fica connosco: o e-mail com o código segue e o endereço é apagado de imediato. A conta é reconhecida por uma impressão irreversível da qual o endereço não pode ser recuperado, e o nome da conta também não o contém.
— equipa CreateYourVPNCada utilizador pode repor o seu link de subscrição
Um link de subscrição é um segredo: quem o tiver obtém o mesmo acesso que o seu titular. O utilizador pode repô-lo na sua área pessoal: o link anterior deixa de funcionar e as credenciais associadas são emitidas de novo. Um link fechado assim permanece fechado, mesmo quando os dados são restaurados a partir de uma cópia de segurança.
— equipa CreateYourVPNCabeçalhos de segurança nas páginas das lojas
As lojas dos parceiros não enviavam os cabeçalhos de segurança que o painel e a API já enviavam, entre eles o que impede outros sites de mostrar a página num iframe. Por esta via não era possível ler dados da conta nem sessões. Agora o conjunto completo acompanha cada resposta das lojas, e a afirmação SR-15 nomeia cada frontend que alojamos.
— Abhinav RajGestão de sessões e envio de códigos de acesso
Na sequência de relatórios de um investigador externo, revimos duas áreas contíguas: o ciclo de vida de uma sessão de parceiro e o percurso do e-mail com o código de acesso. Nenhuma das constatações dava acesso a contas, dados de parceiros ou tráfego de utilizadores.
As alterações no envio de códigos de acesso estão implementadas e verificadas. Uma ação própria de «terminar sessão em todos os dispositivos» está em preparação; até lá, terminar sessão encerra a sessão atual.
— Ganesh RKO que entra aqui.
Resumos e cronologias
A essência de uma descoberta, a classe de vulnerabilidade, a data do relatório e a data da correção. Se uma descoberta refutou uma afirmação SR — uma correção pública do relatório.
Receitas de exploits
Instruções passo a passo, código PoC e detalhes que ajudariam a atacar outros servidores antes de todos atualizarem.
Encontrou algo?
Escreva-nos com uma prova de conceito reproduzível. Respondemos no prazo de 72 horas e fazemos a triagem internamente.