When will we undertake the refactoring and optimization of the nuclei?

[qingchenhh]

I have been using Nuclei for some time, and I must admit that it is excessively bloated. The coexistence of various new and legacy template syntaxes has resulted in a multitude of approaches to writing Nuclei templates, consequently leading to numerous bugs.

Meanwhile, the Nuclei SDK leaves much to be desired. I intend to develop my own scanner and need to invoke the SDK to parse templates for scanning purposes. Nevertheless, I encounter difficulties in retrieving the detailed request and response packets from the execution results. My only recourse is to attempt modifying the SDK, but does this mean I have to revise it every time Nuclei undergoes an update?

When is the planned refactoring of Nuclei? It is imperative to streamline it, standardize the SDK, and unify its output.

[Dhiaelhak-Rached]

I agree with your assessment, especially on the template evolution issue and SDK inconsistencies. It’s been accumulating technical debt for a while, and the fragmentation between legacy and new template logic makes downstream tooling painful.

I’ve also been working around similar limitations in Nuclei, mainly around extracting structured request/response data reliably for custom analysis pipelines. Instead of patching the SDK directly, I ended up wrapping parts of it and building an abstraction layer to isolate myself from upstream changes, but it’s still not ideal.

Your idea of building a cleaner scanner core sounds interesting. If you’re serious about rethinking it, I’d be open to collaborating or at least comparing approaches. There’s probably room for a minimal execution engine + stable template schema that avoids this constant breakage.

Are you aiming for full Nuclei compatibility or something more opinionated and simplified?