4.6.0

• The CLI now refangs defanged indicators, on by default. A URL, domain or IP pasted straight from a threat-intel report (hxxps[:]//evil[.]com, 127[.]0[.]0[.]1, evil[dot]com) is sent in its live form. A new root option, --refang/--no-refang, controls it.
• Commands it applies to: search url; search metadata -p/-u/-d (the free-form query is never changed); search ioc ip|domain; search known; known add / known update; scan url, including -r/--url-file lines; sandbox url; and metadata analyze-ip. Hashes, ids and a --qrcode-file path are never touched. The rewrite only applies when the whole value is one defanged URL, domain or IP.
• Behaviour change: scan url and sandbox url now accept a defanged URL such as hxxps[:]//evil[.]com and submit https://evil.com, where they used to reject it with "URL … is not valid". A validation error still quotes the URL as typed.
• Behaviour change to stored data: known add / known update now store the live host, so a known-host row an earlier CLI wrote verbatim as evil[.]com is no longer matched by search known -d evil[.]com, which now sends evil.com. Likewise, search url hxxps[:]//evil[.]com no longer reaches a URL artifact an earlier scan url -r stored defanged. Pass --no-refang for the previous behaviour, including to reach rows stored defanged.
• polyswarm search ioc ip|domain|ttp|imphash <value> gains --with-artifacts: instead of bare sha256s it returns the matching artifacts' metadata, printed with the same formatter as search metadata, so the text, json and hash output formats all work. Without the flag the output is unchanged. On a hash lookup (search ioc sha256 …) the flag is a usage error (exit 2), not silently ignored.
• SDK floor raised to polyswarm_api>=4.7.0, the release that adds refang_iocs= and search_by_ioc(with_artifacts=).