Um scanner de vulnerabilidades de servidor que lê o software instalado nos seus servidores.

01  /  o que é

Ele lê o software instalado em cada servidor.

O Termalin lê a lista de software instalado no servidor, por dentro, pelo Connector que você já executa, e compara essa lista, do lado do Termalin, com vulnerabilidades conhecidas. Você fica sabendo o pacote e a versão exatos que estão afetados, se a vulnerabilidade está sendo usada em ataques e o comando para corrigir. Ele olha o que está instalado; não sonda portas nem escaneia a sua rede.

• ▸Por dentro, pelo Connector. O mesmo Connector sem chave que leva o terminal e o monitoramento lê a lista de software instalado. Não há scanner para implantar, nem segundo agente, nem porta aberta.
• ▸Verifica os servidores que você conectou. Lê o software instalado por cada Connector e deixa em paz qualquer máquina sem um.
• ▸Só nomes e versões são consultados. A lista de software instalado e os arquivos de lock das suas aplicações são lidos; só nomes e versões de pacotes são comparados com dados públicos de vulnerabilidades, nunca de qual servidor ou conta vieram.
• ▸No painel web e para os apps de IA. Os achados aparecem na página de Segurança do painel web e chegam ao Claude, ao ChatGPT e a outros apps de IA pela ferramenta updates_list no endpoint MCP hospedado.

02  /  o que é verificado

Tudo o que está instalado, do sistema operacional às dependências das suas aplicações.

• ▸Distribuições Linux. Ubuntu, Debian, AlmaLinux, Rocky, RHEL, CentOS, Alpine, SUSE Linux Enterprise e openSUSE, e Amazon Linux — cada uma com os seus próprios dados de segurança.
• ▸Contêineres em execução. Docker, containerd/Kubernetes, Podman e LXC, até 30 por servidor, cada um verificado pela sua própria distribuição. As listas de pacotes deles são lidas de fora — nada é executado dentro de um contêiner.
• ▸Dependências de aplicações. Arquivos de lock em /var/www, /srv, /opt, pastas pessoais e /app: npm (package-lock, yarn, pnpm), composer.lock, Cargo.lock, Python (versões fixadas em requirements.txt, poetry.lock), Go (go.sum), Gemfile.lock, gradle.lockfile e arquivos jar/war/ear de Java — incluindo os fat jars do Spring Boot.
• ▸Runtimes instalados fora do gerenciador de pacotes. Node.js, PHP, nginx, Python, Redis, Go, PostgreSQL, MariaDB, MongoDB, Apache, Java e .NET.
• ▸Servidores Windows. O build comparado com as atualizações de segurança da Microsoft dos últimos três anos — qual KB corrige cada CVE, quais são exploradas — e o suporte da versão; SQL Server, Exchange, Office (Click-to-Run) e .NET; e os programas instalados.
• ▸macOS. A versão do sistema comparada com o patch mais recente do seu branch, pacotes do Homebrew e aplicativos.
• ▸Cerca de oitenta programas e web apps que nenhuma distribuição fornece, por todo o histórico de CVEs de cada um — WinRAR, 7-Zip, navegadores, Zimbra, WordPress, Joomla, Drupal, Nextcloud, phpMyAdmin, Moodle, Jenkins, GitLab, Grafana, Keycloak, Confluence, Jira, Proxmox e mais.

03  /  fontes

De onde vêm os dados de vulnerabilidades.

A comparação acontece do lado do Termalin, com várias fontes, então um achado carrega mais do que um número de CVE.

• ▸OSV.dev — os dados de segurança das próprias distribuições.
• ▸CISA KEV — vulnerabilidades sabidamente usadas em ataques. Essas aparecem primeiro.
• ▸FIRST EPSS — a chance de uma vulnerabilidade ser explorada nos próximos 30 dias.
• ▸Soluções alternativas da Ubuntu e da Red Hat — o que fazer quando ainda não há correção.
• ▸Avisos de segurança do Node.js e endoflife.date — para runtimes e para branches que já saíram do suporte.
• ▸Microsoft (MSRC) — Windows, SQL Server, Exchange, Office e .NET.
• ▸A CVE List — para um aviso antecipado na hora em que uma CVE alta ou crítica é publicada, antes de os dados da própria distribuição acompanharem.

04  /  como corrigir

Cada achado diz o que fazer.

Cada achado vem com a correção para aquele servidor. Nada é instalado automaticamente — você ou o app de IA só aplica quando você concorda.

• ▸Pacotes do sistema. O comando de atualização do gerenciador de pacotes daquele servidor, e se é preciso um reinício (um novo kernel) ou uma reinicialização de serviço — com o comando.
• ▸Ainda sem correção. Um build corrigido ainda em testes, ou a solução alternativa do fornecedor (Ubuntu, Red Hat) — desligar um módulo, adicionar uma regra de firewall.
• ▸Contêineres. Atualize a imagem e recrie o contêiner.
• ▸Dependências de aplicações. O comando de atualização para executar na pasta do arquivo de lock e, depois, implantar de novo.
• ▸Um runtime que veio dentro de outro programa (o Node.js de um runner do GitHub Actions, o VS Code Server, um snap) — atualize esse programa, não substitua o arquivo.
• ▸Um branch fora de suporte. Migre para um branch com suporte.

05  /  a página de Segurança

As vulnerabilidades de todos os servidores, num só lugar.

Abra termal.in/account e a página de Segurança (o ícone de escudo) reúne tudo.

• ▸Blocos — usadas em ataques, críticas, com correção, reinício necessário, atualizações de segurança à espera.
• ▸Uma lista “Corrigir primeiro” — o que é usado em ataques ou crítico e já tem correção, com o comando para copiar.
• ▸Cada servidor com as suas contagens, e a lista completa de cada servidor — primeiro os pacotes dele, depois cada contêiner sob a sua imagem.
• ▸Pontuação CVSS e chance de exploração em cada achado, e a descrição completa quando você pedir.

06  /  alertas

Alertas para vulnerabilidades usadas em ataques.

Um alerta dispara assim que uma vulnerabilidade usada em ataques e que já tem correção aparece em um servidor, pelos canais de sempre: e-mail, Telegram, push e webhook. As outras CVEs ficam listadas na página de Segurança, mas não geram alerta.

• ▸Um resumo noturno para servidores verificados pela primeira vez (um Connector adicionado naquele dia): quais têm vulnerabilidades usadas em ataques, e quantas.
• ▸Lembretes discretos. Novidades no máximo uma vez por dia, um lembrete depois de uma semana, depois mensal — e uma mensagem de “resolvido” quando a última some.
• ▸Um tipo próprio nas configurações de alertas, para você silenciá-lo sem mexer no resto.

07  /  apps de IA

“Quais dos meus servidores estão expostos, e como eu corrijo?”

Pelo endpoint MCP hospedado, um app de IA lê os mesmos achados com duas ferramentas somente leitura. updates_list devolve as atualizações de segurança pendentes e as vulnerabilidades conhecidas com a correção e a chance de exploração de cada uma — para um host, uma tag ou todos os servidores; cve responde “quais dos meus servidores têm a CVE-2026-…?”. Exemplos de prompts:

• ▸“Quais dos meus servidores estão expostos a vulnerabilidades usadas em ataques, e como eu corrijo?”
• ▸“Algum dos meus servidores tem a CVE-2024-3094?”
• ▸“Corrija as críticas em prod, um servidor por vez, e confira depois.”

Nada é instalado sem o seu aval, e um app conectado só vê os servidores que a sua regra de comandos permite.

08  /  leve para os seus servidores

Um inventário por dia, na menor prioridade.

A verificação é feita para não atrapalhar.

• ▸Uma vez por dia, a lista completa de software instalado é lida na menor prioridade de CPU e disco.
• ▸A cada hora, só os poucos pacotes com uma correção pendente são verificados, numa única consulta.
• ▸Toda a comparação acontece do lado do Termalin. Novos avisos são comparados com as listas guardadas a cada hora sem consultar o servidor, então uma CVE nova aparece dentro de uma hora — e uma correção aplicada aparece como resolvida dentro de uma hora também.
• ▸Só nomes e versões de pacotes são consultados, nunca de qual servidor ou conta vieram.

09  /  planos

Parte do Pro e do Team.

A verificação precisa de um Connector, e os Connectors são um recurso dos planos pagos — por isso as verificações de vulnerabilidades vêm com o Pro e o Team, e os 14 dias de teste do Pro as incluem. Não estão no plano Free. Ver preços →