Workflows enable multi-step vulnerability detection by chaining multiple templates together with conditional logic. They allow you to build complex detection scenarios where subsequent templates execute based on previous results.
What are workflows? Workflows are templates that orchestrate the execution of other templates. Instead of defining protocol requests directly, workflows specify which templates to run and in what order.
id : workflow-example info : name : Test Workflow Template author : pdteam severity : info workflows : - template : workflow/match-1.yaml - template : workflow/match-2.yaml
Workflows are identified by the workflows field instead of protocol-specific fields like http, dns, or network.
Basic workflow structure A workflow consists of multiple workflow templates that execute in sequence:
id : basic-security-workflow info : name : Basic Security Assessment Workflow author : pdteam severity : medium description : Multi-stage security assessment workflows : # Step 1: Check for basic vulnerabilities - template : vulnerabilities/basic-xss.yaml # Step 2: Check for SQL injection - template : vulnerabilities/sqli-detection.yaml # Step 3: Check for exposed files - template : exposures/git-config.yaml
Conditional execution Workflows support conditional execution based on matcher results from previous templates.
Subtemplates Execute templates only when a parent template matches:
id : conditional-workflow info : name : Conditional Template Execution author : pdteam severity : high workflows : - template : tech-detect/wordpress-detect.yaml subtemplates : # Only run WordPress checks if WordPress is detected - template : wordpress/wp-login-detect.yaml - template : wordpress/wp-admin-exposure.yaml - template : wordpress/xmlrpc-enabled.yaml
Matcher-based conditions Execute different templates based on specific matcher names:
id : matcher-based-workflow info : name : Matcher Name Based Workflow author : pdteam severity : medium workflows : - template : detection/cms-detection.yaml matchers : - name : wordpress subtemplates : - template : wordpress/wp-version-detect.yaml - template : wordpress/wp-plugins-enum.yaml - name : drupal subtemplates : - template : drupal/drupal-version.yaml - template : drupal/drupal-default-files.yaml - name : joomla subtemplates : - template : joomla/joomla-config-exposure.yaml
Matcher names must be defined in the referenced template for matcher-based workflows to work correctly.
Tag-based workflows Instead of specifying individual templates, you can execute all templates with specific tags:
id : tag-based-workflow info : name : Apache Security Assessment author : pdteam severity : high workflows : # Run all templates tagged with 'apache' - tags : apache,exposure # If exposures found, run CVE checks - tags : apache,cve matchers : - name : apache-exposed
Value sharing between templates Workflows can share extracted values between templates using internal extractors.
HTTP value sharing Template 1 (Extract)
Template 2 (Use extracted value)
Workflow (Chain templates)
id : value-sharing-template1 info : name : value-sharing-template1 author : pdteam severity : info http : - path : - "{{BaseURL}}/path1" extractors : - type : regex part : body name : extracted regex : - 'href="(.*)"' group : 1
Multi-protocol value sharing Share values across different protocols:
id : multiprotocol-workflow info : name : Multi-Protocol Value Sharing author : pdteam severity : medium workflows : # Extract IP from HTTP response - template : extract-ip-from-http.yaml # Use extracted IP in DNS query - template : dns-reverse-lookup.yaml # Use results in network probe - template : network-port-check.yaml
Complex workflow conditions Combine multiple conditions for advanced logic:
id : complex-workflow info : name : Complex Conditional Workflow author : pdteam severity : critical workflows : - template : detection/service-detection.yaml matchers : # MySQL detected - check for vulnerabilities - name : mysql-detected subtemplates : - template : mysql/mysql-unauth.yaml matchers : - name : unauth-access subtemplates : - template : mysql/mysql-dump.yaml - template : mysql/mysql-privesc.yaml # PostgreSQL detected - name : postgres-detected subtemplates : - template : postgres/postgres-default-creds.yaml
Workflow execution flow Understanding how workflows execute helps build effective detection chains:
Parse workflow
Nuclei parses the workflow file and identifies all template references
Load templates
Referenced templates are loaded and compiled with their operators
Execute sequentially
Templates execute in the order defined in the workflow
Evaluate conditions
After each template, matchers are evaluated to determine next steps
Share context
Extracted values and variables are passed to subsequent templates
Aggregate results
All results are collected and reported together
Workflow vs flow templates Nuclei offers two approaches for multi-step execution:
YAML-based template chaining workflows : - template : step1.yaml subtemplates : - template : step2.yaml
Pros:
Declarative and easy to understand
Reuses existing templates
No programming knowledge required
Cons:
Limited conditional logic
Cannot manipulate data between steps
JavaScript-based execution control flow : | http(0); if (http_1_status_code === 200) { http(1); dns(0); }
Pros:
Full programming capabilities
Complex conditional logic
Data manipulation between steps
Cons:
Requires JavaScript knowledge
More complex to debug
Practical workflow examples Technology detection workflow id : tech-stack-assessment info : name : Technology Stack Assessment author : pdteam severity : info description : Detect technologies and run specific checks workflows : - template : tech-detect/wappalyzer.yaml matchers : - name : nginx subtemplates : - tags : nginx - name : apache subtemplates : - tags : apache - name : iis subtemplates : - tags : iis
Cloud security workflow id : cloud-security-workflow info : name : Cloud Infrastructure Security author : pdteam severity : high workflows : - template : cloud/aws/s3-bucket-enum.yaml - template : cloud/aws/s3-public-access.yaml matchers : - name : public-bucket subtemplates : - template : cloud/aws/s3-sensitive-files.yaml
Authentication bypass workflow id : auth-bypass-workflow info : name : Authentication Bypass Assessment author : pdteam severity : critical workflows : - template : auth/login-page-detect.yaml - template : auth/default-credentials.yaml matchers : - name : login-successful subtemplates : - template : privesc/admin-panel-access.yaml - template : privesc/user-enumeration.yaml
Best practices
Logical grouping Group related templates together for easier maintenance and understanding
Minimize dependencies Keep workflows as independent as possible to improve reliability
Use descriptive names Name matchers clearly to make conditional logic self-documenting
Test each step Verify individual templates work before chaining them in workflows
Debugging workflows When workflows don’t behave as expected:
Enable debug mode
Run with -debug flag to see detailed execution information
Test templates individually
Verify each template works standalone before adding to workflow
Check matcher names
Ensure matcher names in workflow match those defined in templates
Verify value extraction
Confirm extractors properly extract and name values for sharing
Templates Learn template fundamentals
Matchers Deep dive into matchers
Protocols Explore protocol capabilities