Debugando o httpx no stack ProjectDiscovery conflitos de binário go modules e PATH

Debugando o httpx no Stack ProjectDiscovery: Conflitos de Binário, Go Modules e PATH#

Fui montar um pipeline simples de recon (subfinder + httpx + nuclei) e o cenário virou aula prática de sistema operacional: colisão de nome de binário, prioridade de PATH e cache interno do shell.

O objetivo do artigo é mostrar exatamente o que quebrou, como confirmei a causa raiz e o que deixei como baseline para não repetir incidente em produção.

1) Pipeline alvo#

subfinder -d domain.com -silent | httpx -silent -status-code -title -tech-detect | nuclei -severity critical,high

2) Primeiro sintoma: flag "fantasma"#

Erro recebido:

Usage: httpx [OPTIONS] URL
Error: No such option: -s

Eu não usei -s, usei -silent. Quando a ferramenta reclama de flag que você não digitou, quase sempre você está executando o programa errado com nome certo.

3) Diagnóstico real: colisão de binários#

Comando-chave:

type -a httpx

Achado no ambiente:

1. /usr/bin/httpx (cliente Python instalado por apt/pip)
2. /root/go/bin/httpx (binário da ProjectDiscovery)

O shell estava pegando /usr/bin/httpx, então toda sintaxe de flags da ProjectDiscovery falhava.

4) Go install não resolve sozinho se PATH estiver errado#

Mesmo instalando a ferramenta certa:

go install github.com/projectdiscovery/httpx/cmd/httpx@latest

o terminal continuava chamando a versão errada por causa da ordem do $PATH (/usr/bin antes de $GOPATH/bin).

Correção aplicada no host de recon#

# remover binário conflitante (quando não necessário)
rm -f /usr/bin/httpx /bin/httpx

# padronizar binário oficial em local previsível
cp "$(go env GOPATH)"/bin/httpx /usr/local/bin/httpx
chmod +x /usr/local/bin/httpx

Depois disso, type -a httpx passou a apontar primeiro para /usr/local/bin/httpx.

5) Cache de hash do shell: o "fantasma" pós-correção#

Após remover /usr/bin/httpx, o Bash ainda retornava:

-bash: /usr/bin/httpx: No such file or directory

Causa: cache interno de caminhos do shell.

Correção imediata:

hash -r

Sem isso, você corrige o sistema e continua executando caminho morto no cache.

6) Versão e go modules: o mito do /v3#

Durante o debug, apareceu tentativa de instalar httpx/v3. No momento da análise, a linha oficial da ferramenta estava em v1.x (ex.: v1.7.4).

Se o módulo não usa sufixo semântico /v3, forçar esse caminho no go install quebra o processo.

Regra prática:

• confirme repositório e tag oficial;
• só use sufixo de major quando o módulo realmente adota aquele caminho.

7) Baseline de hardening para stack ProjectDiscovery#

Checklist que deixei no playbook:

1. validar resolução de binário com type -a;
2. validar versão da ferramenta:

   httpx -version

1. limpar hash do shell após troca de binário:

   hash -r

1. preferir /usr/local/bin para binários operacionais do time;
2. avaliar uso de pdtm para update padronizado da suíte.

8) Verificação final do pipeline#

Depois do ajuste:

subfinder -d domain.com -silent | httpx -silent -status-code -title -tech-detect | nuclei -severity critical,high

O pipeline voltou a operar com saída consistente e sem erro de flag.

Considerações práticas#

O problema não era bug no httpx. Era resolução de nome no Linux com colisão entre binários diferentes.

Quando você trata PATH, cache de shell e governança de binários como parte da infraestrutura, o recon deixa de ser loteria e vira processo reprodutível.

Veja também

Infraestrutura Troubleshooting no Linux: o dia em que o 'command not found' me fez revisar o $PATH e o sudo su

Cibersegurança Anatomia de um incidente: mitigando ataques L7 simultâneos, dos no Dovecot e gargalos de CPU

Cibersegurança Análise forense de um comprometimento no CloudLinux e cPanel: da armadilha do sshd_config à persistência no PAM e IPMI

Este post está licenciado sob CC BY-NC.