Nuclei is a fast, customizable vulnerability scanner powered by the global security community and built on a simple YAML-based DSL, enabling collaboration to tackle trending vulnerabilities on the internet. It helps you find vulnerabilities in your applications, APIs, networks, DNS, and cloud configurations.
I would like to propose a feature to enhance efficiency in vulnerability detection and make the Nuclei-Interactsh integration more flexible
Please implement a way to use global variables such as {{RDN}} and {{FQDN}} in the self-hosted Interactsh integration with the -iserver option. This would significantly improve vulnerability detection efficiency using a self-hosted long run interactsh server
Sometimes a pingback can be received after hours, days or even weeks and these scenarios are undetectable using current Nuclei-Interactsh integration. Even if we use -iserver with self hosted interatcsh-server, it's very difficult to determine the source of the pingback or identify which host has the issue as currently there is no support for a feature like -iserver "{{FQDN}}.selfhosted.oast.pro" which would allow receiving pingbacks with hostname prefix and issues are easily detectable with respect to the source of pingbacks using a long run self hosted interactsh server
Describe alternatives you've considered
manually running nuclei with -iserver option for each host or a complex bash script with for loop and this is not a feasible way for lists of hosts
Describe your feature request
I would like to propose a feature to enhance efficiency in vulnerability detection and make the Nuclei-Interactsh integration more flexible
Please implement a way to use global variables such as
{{RDN}}
and{{FQDN}}
in the self-hosted Interactsh integration with the-iserver
option. This would significantly improve vulnerability detection efficiency using a self-hosted long run interactsh serverDescribe the use case of the feature
Sometimes a pingback can be received after hours, days or even weeks and these scenarios are undetectable using current Nuclei-Interactsh integration. Even if we use
-iserver
with self hosted interatcsh-server, it's very difficult to determine the source of the pingback or identify which host has the issue as currently there is no support for a feature like-iserver "{{FQDN}}.selfhosted.oast.pro"
which would allow receiving pingbacks with hostname prefix and issues are easily detectable with respect to the source of pingbacks using a long run self hosted interactsh serverDescribe alternatives you've considered
manually running nuclei with
-iserver
option for each host or a complex bash script with for loop and this is not a feasible way for lists of hostsAdditional context
No response