Breaking the Chain: Wiz Uncovers a Signature Verification Bypass in Nuclei, the Popular Vulnerability Scanner (CVE-2024-43405)

Summary

Wiz’s engineering team discovered a high-severity signature verification bypass in Nuclei, one of the most popular open-source security tools, which could potentially lead to arbitrary code execution.

Nuclei, with over 21,000 stars on GitHub and an impressive 2.1 million downloads, has become a cornerstone in many organizations' security stacks. Its popularity stems from its flexibility and efficiency in detecting vulnerabilities across various digital assets. This widespread adoption underscores the critical role Nuclei plays in the security community, making it essential to proactively identify and address any potential vulnerabilities to maintain its integrity and trustworthiness.

Technical Detail

How Nuclei Works

Nuclei's power lies in its flexible, YAML-based template system. These templates define the logic for detecting vulnerabilities, misconfigurations, and other security issues across various protocols and technologies.

For example, consider the following template:

This template checks for a vulnerable version of Ollama prone to remote code execution (CVE-2024-37032). It demonstrates how Nuclei templates simplify complex security checks using a clear, YAML-based format.

Nuclei supports a variety of protocols, including HTTP, TCP, DNS, TLS, and Code. The code protocol allows the execution of external code on the host operating system, enabling powerful but risky functionality.

The code Protocol

Templates using the code protocol can execute commands locally on the host operating system. This capability can be useful for security researchers assessing their own systems' security posture. However, when such templates are run on production systems, they risk executing malicious code locally, which could compromise servers or infrastructure.

Real-World Risk: A Malicious Template

The flexibility of Nuclei templates means they can be crafted for legitimate or malicious purposes. For instance, the following template demonstrates how an attacker might exploit the code protocol to exfiltrate sensitive data from the host running the template:

This template exploits the code protocol to read the /etc/shadow file and send it to a remote server. As a basic security principle, untrusted code should not be executed in an unsandboxed environment. Without proper safeguards like signature verification, this could lead to unauthorized data access and system compromise.

Signature Verification Mechanism

To address these risks, ProjectDiscovery implemented a signature verification mechanism. All Nuclei engines trust ProjectDiscovery, and templates in their official templates repository are automatically signed to ensure their integrity and origin. This signature is embedded in the # digest: <signature> comment at the end of each template, serving as a cryptographic guarantee of authenticity.

Since this signature verification is currently the only method available for validating Nuclei templates, it represents a potential single point of failure. This critical role prompted the researchers to investigate its robustness and integrity against potential bypasses.

Uncovering the Signature Verification Bypass

Nuclei’s signature relies on ASN.1 encoding with ECDSA using the P-256 curve and SHA-256, a widely adopted and secure standard known for producing compact and efficient digital signatures.

Nuclei's verification process involves four steps:

1. Extract the Signature: Use regex to find the # digest: line.

2. Remove the Signature: Exclude the signature line from the template content.

3. Compute the Hash: Hash the content without the signature.

4. Validate the Signature: Compare the computed hash with the extracted signature to ensure authenticity.

If the template is successfully verified, it is parsed as YAML using Go’s gopkg.in/yaml.v2 library and then executed.

The following snippet was taken from Nuclei, and contains the important logic of the signature verification code.

Identifying Potential Red Flags

Looking at the above snippet, some potentially vulnerable logic can be identified. While each one of these problematic implementations isn’t very significant on its own, they can be leveraged in combination as a vulnerability.

Security-Critical Logic Using Regex

While regex is effective for pattern matching, relying on it for security-critical operations can be risky. Its complexity and edge cases may lead to subtle discrepancies, opening the door for attackers to exploit unintended behavior. In this context, using regex for signature validation introduces opportunities to bypass intended security checks.

In this signature verification logic it is shown that both the signature extraction and removal were implemented using regex.

Find-First Remove-All Mismatch

The implementation uses ReDigest.Find to find the first signature, but later uses ReDigest.ReplaceAll to remove the signature from the template. ReplaceAll will remove all signatures from the content. This in and of itself isn’t a vulnerability, but it’s a primitive that should be kept in mind.

Consider the following template:

In this template, signature1 will be used for verification while the verified content will be:

In practice, this allows the attacker to “hide” information in redundant # digest lines that won’t be considered when calculating the signature verification digest.

Dual Parser Conflict: Regex and YAML

The same template content is used for both the template parsing logic and signature verification.

Using two different parsers on the same content introduces a risk of inconsistencies in how they interpret the data. While not a vulnerability on its own, these discrepancies could lead to unexpected behavior if exploited.

The regex-based signature parser uses the pattern (?m)^#\sdigest:\s.+$ to identify lines starting with # digest:. Meanwhile, the YAML parser treats # digest: as a comment, ignoring it during execution. This creates a mismatch: the signature verification logic operates based on regex rules, while the execution logic relies on YAML parsing.

This divergence highlights a potential weak point where verification and execution processes might not align perfectly.

From Weaknesses to Vulnerability

Now that we’ve identified these suspicious patterns, it is possible to explore how they can be chained together into a practical vulnerability.

The key insight lies in the mismatch between how the signature verification process and the YAML parser handle template content. Specifically:

1. First-Signature-Only Verification: The signature verification process checks only the first # digest: line but removes all such lines from the hashed content. This allows additional, unverified # digest: lines to exist in the template unnoticed by the verification mechanism.

2. Line Break Ambiguity: For the regex-based parser to remove a line, it must start with #, which the YAML parser treats as a comment. But what if the YAML parser considers [if !supportLists]1. [endif]the line to have ended, while the regex parser doesn’t? Such an inconsistency could allow an attacker to inject extra content into the template—content that bypasses verification yet is executed by the YAML parser.

To better understand this, The researchers turn to the YAML Specification:

According to this specification, YAML treats the following characters as line breaks: x0A (\n), x0D (\r), or a combination of the two (\r\n).

Regex parsing in Go, however, has its own interpretation of line breaks. To test this, The Go’s regex engine behavior is examined with the signature extraction regex.

Specifically, the regex used to find the signature ensures that a line starts (^) with the string # digest: and captures everything until the end of the line ($).

From this output, it is shown that Go’s regex parser considers \n as a line break, but not \r.

This means content separated by \r can bypass the regex-based signature verification yet be interpreted as separate lines by the YAML parser.

Chaining The Primitives

Armed with the insights about mismatched newline interpretations, Wiz researchers crafted a template that exploits the disparity between Go’s regex implementation and the YAML parser. By using \r as a line break, a second # digest: line is included in the template that evades the signature verification process but gets parsed and executed by the YAML interpreter.

Why This Works

This exploit is possible due to the following key weaknesses described above:

1. Parser Inconsistencies: Go’s regex-based signature verification treats \r as part of the same line, while the YAML parser interprets it as a line break. This mismatch allows attackers to inject content that bypasses verification but is executed by the YAML parser.

2. First-Signature Trust: The verification logic validates only the first # digest: line. Additional # digest: lines are ignored during verification but remain in the content to be parsed and executed by YAML.

3. Inconsistent Signature Removal: The ReplaceAll function removes all # digest: lines from the hashed content, ensuring only the first line is verified. Malicious content in subsequent lines remains unverified but executable.

By chaining these weaknesses, an attacker can inject unverified, executable content into Nuclei templates—exploiting the identified weaknesses to create a practical vulnerability.

Responsible Disclosure Timeline

Wiz Researchers have responsibly disclosed this vulnerability to ProjectDiscovery's development team in August 2024. ProjectDiscovery investigated the issue thoroughly and worked diligently on implementing a comprehensive fix while maintaining clear communication throughout the process.

● August 14, 2024 – Wiz reported the issue to ProjectDiscovery

● August 14, 2024 – ProjectDiscovery acknowledged the receipt of the report and provided an initial fix proposal

● August 19, 2024 – ProjectDiscovery committed a fix for the vulnerability

● September 4, 2024 – ProjectDiscovery released a patched version

● January 3, 2025 – Wiz published a blog about the issue

ProjectDiscovery's swift initial response and thorough approach to addressing the vulnerability demonstrates their strong commitment to security. Their team worked methodically to implement, test, and release a comprehensive fix, ensuring the continued security of their widely-used tool.

Mitigation

To protect against this vulnerability, the following steps are strongly recommended:

● Upgrade to Nuclei 3.3.2 or Above: Ensure you are running the patched version of Nuclei (3.3.2 or later), which addresses the signature verification bypass.

● Run in an Isolated Environment: Always execute Nuclei in a sandboxed or highly isolated environment to prevent potential exploitation of untrusted or community-contributed templates.

By following these practices, you can significantly reduce the risk of malicious exploitation and maintain a secure and robust security scanning workflow.

Conclusion

The discovery of CVE-2024-43405 reveals how vulnerabilities can emerge from subtle inconsistencies in parsing and verification systems. For example, attackers could craft malicious templates containing manipulated # digest lines or carefully placed \r line breaks to bypass Nuclei’s signature verification.

An attack vector for this vulnerability arises when organizations run untrusted or community-contributed templates without proper validation or isolation. Additionally, services that allow users to modify or upload Nuclei templates, such as automated scanning platforms or shared security pipelines, become particularly vulnerable. An attacker could exploit this functionality to inject malicious templates, leading to arbitrary command execution, data exfiltration, or system compromise.

By identifying and responsibly disclosing this vulnerability, this research strengthens the security ecosystem by emphasizing the importance of parser consistency and robust verification mechanisms.

This work highlights the critical need for defense-in-depth approaches, such as running tools like Nuclei in isolated, sandboxed environments and strictly validating template sources. Through collaboration with the security community, the researchers continue to advance security research and ensure the tools they rely on remain safe and trustworthy.