Diário de segurança.

Vulnerabilidade do kernel Linux CVE-2026-98432 corrigida

Foi detetada a vulnerabilidade CVE-2026-98432 na forma como o kernel Linux processa as ligações TCP de entrada. Afeta servidores Linux independentemente do serviço que executam.

Os kernels dos servidores da plataforma e dos servidores VPN ativos dos parceiros com versões do sistema suportadas foram atualizados para uma versão com a correção.

Limites alinhados no formulário público de suporte

Um relatório de Parth Narula mostrou que, com outro endereço de e-mail, o nosso formulário público de suporte permitia enviar pedidos adicionais. Alinhámos os limites do formulário, pelo que mudar de endereço já não permite enviar mais pedidos. Obrigado pela comunicação responsável.

Foi restringido o acesso à interface do serviço de suporte

Um investigador externo chamou a atenção para o facto de a interface do serviço de suporte estar acessível a partir da internet. A interface exigia autenticação; não foram detetados sinais de acesso não autorizado nem de divulgação de dados de utilizadores.

Excluímos o serviço de suporte da superfície pública: o acesso só é permitido a partir de endereços de confiança e através de um canal interno. As definições da interface foram alinhadas com o domínio em uso, e a restrição foi verificada a partir de fora da nossa rede.

O endereço de retorno está limitado às páginas do painel

Um investigador de segurança descobriu que o endereço de retorno de serviço usado após a restauração da sessão podia ser interpretado pelo navegador como uma navegação para um site externo. O cenário exigia uma sessão válida e não dava acesso à conta nem aos dados.

Agora, o endereço de retorno é escolhido a partir de uma lista fechada de páginas internas. Qualquer outro valor leva à página principal do painel. A correção está coberta por testes negativos automáticos.

Aplicação de DMARC ativada

Um investigador de segurança descobriu que a política DMARC de createyourvpn.com funcionava apenas em modo de monitorização e não exigia a rejeição das mensagens que falhavam a validação. Ativámos p=reject para o domínio principal e sp=reject para os seus subdomínios que não enviam correio. O correio transacional permanece isolado em subdomínios de envio separados com políticas SPF, DKIM e DMARC próprias.

MTA-STS e relatórios TLS ativados

Um investigador de segurança descobriu que MTA-STS e os relatórios TLS não estavam configurados para o correio recebido de createyourvpn.com. Publicámos uma política MTA-STS e ativámos os relatórios TLS. Inicialmente, a política funciona em modo de teste enquanto verificamos o caminho de reencaminhamento de terceiros; a aplicação será ativada após relatórios sem erros.

Adicionado o controlo das sessões da conta

Um investigador de segurança descobriu que uma cópia do token de uma sessão de parceiro podia permanecer ativa após terminar sessão se tivesse sido renovada separadamente. Migrámos as sessões para uma única identidade no servidor: agora, terminar a sessão revoga toda a sessão atual, enquanto a ação «Encerrar sessão em todos os lugares» termina todas as sessões ativas.

No painel surgiu a secção «Sessões da conta». Nela são visíveis os inícios de sessão atuais com o dispositivo, o endereço IP, a hora de início de sessão e a última atividade, bem como o histórico das tentativas de início de sessão bem-sucedidas e falhadas dos últimos 90 dias. Qualquer sessão pode ser terminada individualmente, ou podem ser terminadas todas de uma vez.

Enabled DNSSEC

A researcher found that DNSSEC was not enabled for createyourvpn.com. We signed the DNS zone, published the DS record in .com, and verified the chain of trust.

Proteção reforçada para o formulário público de suporte

O investigador de segurança 0xVicky descobriu que o nosso formulário público de suporte podia ser usado para enviar pedidos em excesso. Adicionámos limites por visitante e para o tráfego total, protegemos o canal interno de envio do formulário e reforçámos a validação dos anexos. Obrigado pela comunicação responsável.

Gestã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.

Cabeç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.

Cada 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.

Os 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.

Foi 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.

Removido 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.

Garantida 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.

Chaves 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.

Reduzida 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.

Adicionada 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.

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.