Skip to main content
Workflows enable multi-step template execution with conditional logic, allowing you to chain multiple templates together based on the results of previous templates. They provide a powerful way to create complex vulnerability detection scenarios that require multiple steps.

Basic workflow structure

Workflows are defined in a separate YAML file:
id: workflow-example

info:
  name: Test Workflow Template
  author: pdteam
  severity: info

workflows:
  - template: templates/tech-detect.yaml
  - template: templates/wordpress-check.yaml
  - template: templates/wordpress-plugins.yaml

Workflow components

template
string
required
Path to the template file to execute (relative to nuclei-templates directory).
workflows:
  - template: http/tech-detect.yaml
tags
array
Execute all templates matching specified tags.
workflows:
  - tags:
      - wordpress
      - plugins
subtemplates
array
Templates to execute if the parent template matches.
workflows:
  - template: tech-detect.yaml
    subtemplates:
      - template: wordpress-plugins.yaml
matchers
array
Execute subtemplates based on specific matcher results.
workflows:
  - template: tech-detect.yaml
    matchers:
      - name: wordpress
        subtemplates:
          - template: wordpress-vulns.yaml

Simple workflows

Execute templates one after another:
id: sequential-workflow

info:
  name: Sequential Workflow
  author: pdteam
  severity: info

workflows:
  - template: workflow/match-1.yaml
  - template: workflow/match-2.yaml
  - template: workflow/match-3.yaml

Conditional workflows

Execute templates based on previous results:
id: conditional-workflow

info:
  name: WordPress Vulnerability Detection
  author: pdteam
  severity: high

workflows:
  # Step 1: Detect if target is WordPress
  - template: wordpress-detect.yaml
    
    # Step 2: Only run if WordPress is detected
    subtemplates:
      # Check WordPress version
      - template: wordpress-version.yaml
      
      # Enumerate plugins
      - template: wordpress-plugins.yaml
        
        # Step 3: Only run if vulnerable plugins found
        subtemplates:
          - template: wordpress-plugin-exploits.yaml

Matcher-based workflows

Execute different templates based on specific matcher results:
id: matcher-workflow

info:
  name: Technology-Specific Checks
  author: pdteam
  severity: info

workflows:
  - template: tech-detect.yaml
    
    matchers:
      - name: wordpress-detected
        subtemplates:
          - template: wordpress-vulns.yaml
      
      - name: joomla-detected
        subtemplates:
          - template: joomla-vulns.yaml
      
      - name: drupal-detected
        subtemplates:
          - template: drupal-vulns.yaml

Complex workflows

id: complex-workflow

info:
  name: Complex Multi-Level Workflow
  author: pdteam
  severity: high

workflows:
  # Level 1: Initial detection
  - template: workflow/match-1.yaml
    
    subtemplates:
      # Level 2: Deep inspection if match
      - template: workflow/nomatch-1.yaml
        
        subtemplates:
          # Level 3: Exploitation if vulnerable
          - template: workflow/match-2.yaml
  
  # Parallel execution path
  - template: workflow/match-3.yaml
  
  # Another conditional path
  - template: workflow/match-2.yaml
    matchers:
      - name: test-matcher
        subtemplates:
          - template: workflow/nomatch-1.yaml
            subtemplates:
              - template: workflow/match-1.yaml

Workflow execution flow

Value sharing between templates

Workflows can share extracted values between templates:
id: http-value-sharing-workflow

info:
  name: HTTP Value Sharing Test
  author: pdteam
  severity: info

workflows:
  - template: workflow/http-value-share-template-1.yaml
    subtemplates:
      - template: workflow/http-value-share-template-2.yaml

Multi-protocol workflows

Combine different protocol types in workflows:
id: multi-protocol-workflow

info:
  name: Multi-Protocol Workflow
  author: pdteam
  severity: info

workflows:
  # DNS reconnaissance
  - template: dns/dns-recon.yaml
    subtemplates:
      # HTTP probing
      - template: http/http-probe.yaml
        subtemplates:
          # Network service detection
          - template: network/service-detect.yaml

Real-world examples

id: wordpress-security-audit

info:
  name: Complete WordPress Security Audit
  author: pdteam
  severity: high

workflows:
  - template: wordpress/wp-detect.yaml
    
    subtemplates:
      # Information gathering
      - template: wordpress/wp-version.yaml
      - template: wordpress/wp-debug-log.yaml
      - template: wordpress/wp-config-backup.yaml
      
      # User enumeration
      - template: wordpress/wp-user-enum.yaml
        
        subtemplates:
          # Brute force if users found
          - template: wordpress/wp-login-brute.yaml
      
      # Plugin detection
      - template: wordpress/wp-plugins-enum.yaml
        
        subtemplates:
          # Check for vulnerable plugins
          - tags:
              - wordpress-plugin
              - cve

Workflow vs flow

Best for:
  • Multi-template orchestration
  • Technology-specific checks
  • Modular template organization
  • Community template reuse
Limitations:
  • Separate file required
  • Less flexible than flow
  • No custom logic

Best practices

  1. Organize by purpose - Group related templates in workflows
  2. Use descriptive names - Name workflows and matchers clearly
  3. Minimize depth - Avoid deeply nested workflows (max 3-4 levels)
  4. Share values efficiently - Use internal extractors for template communication
  5. Handle failures gracefully - Design workflows to continue if individual templates fail
  6. Test thoroughly - Verify workflow execution paths with different targets
  7. Document dependencies - Comment on template relationships and required data
  8. Consider performance - Limit the number of templates in high-frequency workflows

Execution control

stop-at-first-match
boolean
default:"false"
Stop workflow execution after first successful match (set on individual templates).
Workflows execute templates sequentially. If a parent template doesn’t match, its subtemplates are skipped. Design workflows to handle both match and no-match scenarios.

Common patterns

Technology stack detection

workflows:
  - template: tech-detect.yaml
    matchers:
      - name: php
        subtemplates:
          - tags: [php]
      - name: nodejs
        subtemplates:
          - tags: [nodejs]
      - name: python
        subtemplates:
          - tags: [python]

Progressive exploitation

workflows:
  - template: recon.yaml
    subtemplates:
      - template: vulnerability-scan.yaml
        subtemplates:
          - template: exploitation.yaml
            subtemplates:
              - template: post-exploitation.yaml

Parallel checks

workflows:
  - template: check-1.yaml
  - template: check-2.yaml
  - template: check-3.yaml
  # All execute regardless of previous results

Flow Control

JavaScript-based orchestration

Matchers

Conditional execution

Extractors

Value sharing

Variables

Template context

Build docs developers (and LLMs) love