### Resumo Os bancos de dados SQLite são criados em caminhos previsíveis (estáticos) em `/ tmp`. Qualquer usuário pode, portanto, criar um link simbólico nestes caminhos no / tmp apontando para arquivos arbitrários. Os scripts de monitoramento então seguem estes links simbólicos e então criam seu banco de dados no alvo de link simbólico. Isto se torna realmente perigoso para os scripts que podem ser executados como root com sudo. Com isso, um atacante pode escrever em caminhos abitrários. ### PoC O comando docker-stats verifica aqui como exemplo. Porque escrever para / tmp é o comportamento padrão, os outros comandos de verificação que usam um banco de dados SQLite também são muito provavelmente afetados. ``` # Crie o link simbólico como nagios user nagios@test-server:/tmp$Ln -s /root/nagios-was-here /tmp/linuxfabrik-monitoring-plugins-docker-stats.db # Ativar a execução do usuário nagios nagios@test-server:/tmp$ sudo /usr/lib 64 /nagios/plugins/docker-stats ``` Verifique se o arquivo foi criado ou não. ``` root@test-server:/# arquivo /root/nagios-was-here /root/nagios-was-here: SQLite 3 Base de dados.x, escrita pela última vez usando a versão SQLite 3046001, contador de arquivos 2, páginas de banco de dados 3, cookie 0 x 2, esquema 4, UTF- 8, versão- validada- para 2 ``` ### Impacto Em sua forma básica, esta vulnerabilidade pode levar a uma negação de serviço, impactando usuários que usam o arquivo Sudoers fornecido e que não tomaram quaisquer precauções especiais como o "PrivateTemp" do sistemad. Ele requer que um atacante já comprometa a conta nagios (o que é uma barreira bastante alta para ser honesto).
Se qualquer aplicativo no servidor depender de um banco de dados SQLite, existem cenários onde esta vulnerabilidade permite que o conteúdo em bancos de dados SQLite existentes seja modificado. Um atacante pode deixar o link simbólico apontar para um banco de dados SQLite existente e criar no / tmp um SQLite Rollback Journal especialmente criado (`.db- journal`) ou Write- Ahead- Log (`.db- wal`), que então é aplicado ao banco de dados. ### Fix Uma correção proposta seria criar uma pasta separada dentro do /tmp por usuário (por exemplo, ' /tmp/linuxfabrik-monitoring-plugins-{os.geteuid()}`). Após criar este diretório (ou usando um já existente), verifique o seguinte: ``` # Use os.lstat() em vez de os.stat() para que não sigamos acidentalmente os links simbólicos dir_stat = os.lstat(TMP_DIR_PATH).
# Assegure que o diretório é um dir real e não um Symlink se não stat.S_ISDIR(dir_stat.st_mode): # aborte a execução sys.exit( 1 ) # Verifique o proprietário se dir_stat.st_uid!= os.getuid(): # aborte a execução sys.exit( 1 ).
# Verificar as permissões se (dir_stat.st_mode & 0 o 077 )!= 0: # abortar a execução sys. exit( 1 ) ``` Registro de aconselhamento: GHSA-r 35 r- fpx 2 - jgr 4. Identificadores relacionados: CVE- 2026 - 53759.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 06 T 20: 31: 43.000 Z e lista a sua última modificação como 2026 - 07 - 06 T 20: 31: 43.000 Z. Severidade: LOW. Dados de pontuação publicados: CVSS_V 4: CVSS: 4.0 /AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/África do Sul:N/E:P.
Software afetado e informações de versão: pacote PyPI linuxfabrik-lib — ECOSYSTEM: introduzido 0, corrigido 4.2.0. Classificação e evidência: identificadores de fraqueza CWE- 377. O registro contém 2 suporte de referências nestes tipos: WEB, PACKAGE.