* Add wildcard certificate detection in JSON output
This commit implements wildcard certificate detection for subdomains that
are covered by wildcard certificates (e.g., *.example.com). When sources
return results containing wildcard patterns, the subdomain is now marked
with a wildcard_certificate field in JSON output mode.
Key changes:
- Added WildcardCertificate field to HostEntry and Result structs
- Detection logic: checks if result.Value contains "*.subdomain" pattern
- Propagates wildcard flag through resolution pipeline
- JSON output includes wildcard_certificate field (omitted if false)
- Updates version to v2.9.1-dev
- Fix .goreleaser.yml 386 architecture quoting
- Add /subfinder to .gitignore
Note: wildcard_certificate field is not included when using -cs flag to
avoid breaking changes to the library API.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
* Fix wildcard certificate flag propagation with -nW flag
Fixed a bug where the wildcard_certificate field was being lost when using
the -nW flag (DNS resolution with wildcard filtering). The issue occurred
because when multiple sources find the same subdomain, only the first
occurrence is sent to the resolution pool. If a later source marks the
subdomain as having a wildcard certificate, that information was stored
in uniqueMap but never propagated to foundResults.
Solution: After resolution completes, merge wildcard certificate information
from uniqueMap into foundResults. This ensures that if any source marked a
subdomain as having a wildcard certificate, that flag is preserved in the
final output.
This ensures consistent behavior - wildcard_certificate field appears in
JSON output regardless of whether -nW flag is used.
Validation:
- Without -nW: api.nuclei.sh shows wildcard_certificate:true ✓
- With -nW: api.nuclei.sh shows wildcard_certificate:true ✓
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
This uses two _different_ variables for the two _different_ HTTP
requests, since two `defer` functions referenced the same `resp`
variable.
This setup could cause a nil pointer dereference in the following
scenario:
1. The first request succeeds (a `defer` on `resp` is added).
2. The second request fails (which sets `resp` to nil, and then
the first `defer` attempts to reference `resp.Body`).
This change prevents that by not reusing the same variable for
the second request.
Tarun Koyalwar