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.

---

Conclusão

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.

Este post está licenciado sob CC BY-NC.