Nuclei v3.2 Release with Authenticated Scanning, Advanced Fuzzing & more

Nuclei v3.2 Release with Authenticated Scanning, Advanced Fuzzing & more

We're thrilled to announce the launch of Nuclei v3.2.0. This latest version introduces a host of new features, enhancements, and bug fixes, significantly elevating the Nuclei engine's performance and capabilities. Notably, the inclusion of authentication support and advanced fuzzing support positions this release as a pivotal milestone, further building upon the foundation laid by version 3.0.0.

In this blog, and a number of upcoming feature spotlights, you'll learn a lot more about all that nuclei now has to offer!

New Features

Authenticated Scanning Support

Nuclei has been enhanced to support scanning targets that require authentication. By leveraging a secrets.yaml file, it's now simpler to supply authentication details for these targets. In line with our philosophy of not reinventing the wheel, we've chosen to utilize our native, straightforward, and adaptable nuclei templates for dynamic login support, foregoing the need for browser-based login scripts. This approach allows us to repurpose over 50 existing default-login templates for this task, a number we plan to increase in the future.

πŸ”
Check out our blog post on Scanning Targets Behind Authentication with Nuclei v3.2 for more details. You can also read the documentation here.

Extended Fuzzing Support

In Nuclei v2.8.0, we established the groundwork for identifying unknown or yet-to-be-discovered vulnerabilities through fuzzing, initially offering support solely for Query Fuzzing. We are now excited to announce a significant expansion in our capabilities: Nuclei now enables all the requirements for creating fuzzing templates. This comprehensive support extends to various components such as Headers, Cookies, Paths, and Bodies (including JSON, XML, Form, and Multipart/Form-Data). Additionally, we've introduced filters to determine the execution of specific fuzzing templates based on certain conditions, enhancing the precision and efficiency of the fuzzing process.

πŸ”€
Check out our blog post on Fuzzing for Unknown Vulnerabilities in Nuclei v3.2.0 for more details. You can also read the updated fuzzing documentation here.
Click here to subscribe and get notified when this blog comes out!

HTTP Request Input Support

We're excited to announce an enhancement in our support for HTTP Request Input, now accommodating multiple formats alongside fuzzing capabilities. Previously, input was limited to URLs, IPs, and hosts. However, we've broadened our scope to include common HTTP request input formats, such as:

  • BurpSuite XML
  • Proxify Logs, httpx output, katana output
  • OpenAPI Specification
  • Swagger Specification
  • And others!

This expansion significantly enhances the versatility and power of our fuzzing support.

πŸ”€
Coming Soon!

For more detailed information and insights into how these enhancements synergize with fuzzing capabilities, we invite you to explore "Fuzzing for Unknown Vulnerabilities in Nuclei v3.2.0"

You can also read the documentation on input formats here.
Click here to subscribe and get notified when this blog comes out!

LDAP Support

Thanks to our community contributor valerio casalino (@5amu)!

Nuclei now supports the LDAP protocol via the JavaScript Protocol. This includes most of the support for brute-forcing, kerberoasting, fingerprinting, and much more. Check out the documentation on LDAP Module to get started with writing LDAP Checks and exploits.

Support for Writing Self-Contained Templates with Flow

We have observed that it was previously not possible to write self-contained templates with the flow or multi-protocol protocols, which is extremely useful for writing checks like finding a Stripe key and validating it with Stripe API in a single template. To support this, we have added a self-contained field at the protocol level in the HTTP protocol, which is now scoped only for that protocol.

πŸ—’οΈ
You can check out Pull Request #4812 for more details.

Export Filters at Integration Level

Thanks to our community contributor (@leonjza) Leon Jacobs (@leonjza)!

Nuclei now supports specifying Export Filters at the Integration Level. Until now, allow-list/deny-list could be specified in `reporting-config. YAML, but it was impossible to specify them at the integration level; for example, only export high, critical for Jira, but all for GitHub. This will provide more flexibility in exporting findings to different integrations. Check out #4780 for more details.

Gitea Reporting Support

Thanks to our community contributor Leon Jacobs (@leonjza)!

Nuclei now supports reporting results to Gitea in addition to existing integrations of Jira, GitLab, GitHub, etc.

πŸ—’οΈ
You can check out Pull Request #4522 for reporting-config updates and other details.

Added Support for passing PDCP API Key Via Flag

Until now, the ProjectDiscovery Cloud Platform (PDCP) API Key could only be passed via the environment variable PDCP_API_KEY . With nuclei v0.3.2, the API key can also be passed via flag -auth, which will take precedence over the environment variable.

πŸ—’οΈ
You can check out Pull Request #4763 for more details.

Updated JS Module Documentation generation using Typescript

JS Module docs were generated using code generation and JS Doc comments + LLM, which lacked details and had missing information. We have now opted for a more static approach by generating Typescript files using code generation and generating corresponding typescript definition files and documentation using TypeDoc. This will result in more detailed and accurate documentation for JS Modules. We are pleased to share that every function and class in JavaScript modules is now documented with examples. Visit JS Module Docs for updated documentation.

Security Fixes

Fixed Unsigned Code Template Execution through Workflows

A high-severity security vulnerability was found in Nuclei thanks to @gpc1996. It affected users running unvalidated third-party code protocol templates. Successful exploitation would allow an attacker to execute arbitrary code on the system. We recommend all users upgrade to v3.2.0 to mitigate this vulnerability or disable workflows as a temporary mitigation.

πŸ›‘οΈ
Check our Security Advisory for more details.

Performance Improvements

Transparent Memoization to cache repeated JS Function Calls

We have added transparent memoization to cache repeated JS Function Calls in JavaScript Modules. This reduces redundant sending requests, resulting in a 10x reduction in traffic and secondary performance improvement.

πŸ—’οΈ
You can check out Pull Request #4742 for or details regarding the newly introduced memoization function.

This release also includes secondary performance improvements due to bug fixes that caused OOM and memory leaks.

Bug Fixes

Removed Forceful Read at End of Network Protocol

Earlier, Nuclei would always try to perform a final read at the end of a network protocol request, which resulted in the failure of C2 templates. This has been fixed in this release and should also result in fewer i/o timeout warnings in the network protocol. Check out #4737 for more details.

Nuclei now prioritizes system resolvers over others

Until now, Nuclei has used system resolvers as a DNS resolution fallback, resulting in issues when overriding DNS entries in the/etc/hosts file. This has been fixed in this release, and nuclei will now prioritize system resolvers over others. Check out #4498 for more details.

Fixed stop-at-first-match option not working in HTTP protocol

The stop-at-first-match option was not working in the HTTP protocol, which resulted in extra requests being sent even after the first match. This has been resolved in #4752 and included in this release. This PR also adds cancellation of in-flight requests when stop-at-first-match is enabled.

Fixed Panic on HTTP Response body read error

It was observed that nuclei would panic on HTTP response read failure due to nil pointer dereferences. This has been fixed, and panic handlers have been added to handle such panics. Check out #4759 for more info

Fixed -response-size-read flag not working in HTTP protocol

The -response-size-read flag limits the maximum response size read from the server to avoid DOS. A change in an earlier release overwritten this value by the default value of 4MB. This has been fixed by respecting the user-provided value.

Remove Residual Files generated by Code protocol

It was observed that temporary files generated by the code protocol during compile in the temp directory were not removed after execution. This has been fixed in this release, and any files generated by the code protocol will be removed after execution.

Fix Nuclei Loading Ignored Templates

Nuclei would load ignored templates when using the -tags flag instead of the -tags flag, which resulted in default ignored templates like dos being loaded and executed. This has been fixed in this release, and nuclei will only override ignored templates when explicitly specified in the -tags flag. For more details, check out #4841

Fix Escaped Extracted Value in Nuclei Output

Due to a change in an earlier release, extracted values returned by nuclei in CLI output were escaped, affecting the output's readability and usability. This has been fixed in this release, and extracted values will be returned as is, and only new lines will be escaped. For more details, check out #4841.

Subscribe to our newsletter and stay updated.

Don't miss anything. Get all the latest posts delivered straight to your inbox. It's free!
Great! Check your inbox and click the link to confirm your subscription.
Error! Please enter a valid email address!
--