Library / SDK
projectdiscovery/nuclei avatar
projectdiscovery/nuclei

Nuclei: a Go scanner whose results are only as good as the YAML templates you feed it

Nuclei is a fast, customizable vulnerability scanner powered by the global security community and built on a simple YAML-based DSL, enabling collaboration to tackle trending vulnerabilities on the internet. It helps you find vulnerabilities in your applications, APIs, networks, DNS, and cloud configurations.

32,910 stars4,004 forksGoMIT

At a glance

What is it?
ProjectDiscovery's Nuclei runs YAML-defined vulnerability checks against hosts, applications, APIs, DNS and cloud configurations. The engine is a single Go binary; the judgment calls are which templates to trust, which version to pin, and keeping it a CLI rather than a service.
Who is it for?
Nuclei fits security teams and developers who want scripted, repeatable vulnerability checks in a CLI or CI pipeline and are willing to read the templates they run. It does not fit anyone who wants a long-running scanning service to expose to others, since the project itself warns that running Nuclei as a service may pose security risks.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.

From daily snapshots

Star history

  • projectdiscovery/nuclei32,910 ★ · +1,774
Star history
Repository2026-09-132026-11-14
projectdiscovery/nuclei31.1k32.9k

1,774 Stars in the last 62 days, measured from the daily GitHub snapshot. Compare with other projects

Editorial analysis

The YAML templates decide what Nuclei finds

Nuclei is a template-based vulnerability scanner written in Go and released under the MIT license. The binary itself is an engine: every check it performs is described in a simple YAML-based DSL, and the community templates live in a separate repository, projectdiscovery/nuclei-templates, contributed by thousands of security professionals to cover trending vulnerabilities. That split matters in practice. Upgrading the binary and updating the templates are separate events, and a scan's coverage depends on which template set you point it at.

Templates are not limited to HTTP. The supported protocols include TCP, DNS, HTTP, SSL, WHOIS, JavaScript and Code, among others. The repository ships SYNTAX-REFERENCE.md and a nuclei-jsonschema.json file for anyone writing templates, and the README has a section on scanning with your own custom template. The consequence for a team is that Nuclei is as much a template authoring and review job as a scanning job. A template that runs JavaScript or Code is doing more than sending a request, so templates from outside your own team deserve the same reading as any other code you execute.

Building from source requires Go 1.27.3 or newer

The README states that Nuclei requires Go 1.27.3 or newer to install, and go.mod declares go 1.27.3 for the module github.com/projectdiscovery/nuclei/v3. The source install is one command:

sh
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

The practical failure is a toolchain that is too old. A system Go below 1.27.3 will not build it, so check go version before blaming the module. Other installation routes are covered at https://docs.projectdiscovery.io/tools/nuclei/install.

The Makefile shows how the project builds its own binary. make build compiles cmd/nuclei/main.go into ./bin/nuclei with -pgo=auto, CGO_ENABLED=0, -trimpath and -ldflags -s -w, with GOEXPERIMENT=greenteagc and GODEBUG=tlssha1=1 set. On every platform except macOS it also links statically, and on Windows the output gets an .exe extension. Those settings are a useful reference if you package Nuclei yourself instead of using go install.

The Docker image carries Chromium and DNS tools beside the binary

The repository's Dockerfile is a two-stage build. The builder stage uses golang:1.27-alpine, installs build-base, and runs make verify followed by make build. The release stage starts from alpine:latest and adds three packages: bind-tools, chromium and ca-certificates. The compiled binary is copied to /usr/local/bin/ and set as the entrypoint, so arguments passed to docker run go straight to nuclei.

Two consequences follow. The image is the easiest way to get a working setup on a machine without Go 1.27.3, and it ships Chromium and the bind-tools DNS utilities preinstalled. But the runtime base is alpine:latest rather than a pinned tag, so two builds of the same Nuclei commit can sit on different Alpine releases. If reproducibility matters for audits, build and tag the image yourself and keep that tag.

Targets come from flags, files or inline lists, with exclusions

Every flag is listed by the help output:

sh
nuclei -h

The TARGET group shows how input reaches the scanner. -u or -target takes one or more URLs or hosts. -l or -list takes a path to a file with one target per line. -targets-inline accepts an inline multiline list, intended for template profiles. -eh or -exclude-hosts removes hosts from the input list by IP, CIDR or hostname, which is the flag to reach for when a target list mixes in-scope and out-of-scope systems. -resume continues an interrupted scan.

A single web application scan is the shortest form:

sh
nuclei -target https://example.com

The full flag reference goes well past targets and continues at docs.projectdiscovery.io/getting-started/running. The README also has sections on scanning multiple targets, network scans and connecting Nuclei to ProjectDiscovery. For CI/CD use, which the project supports for vulnerability detection and regression testing, the same flags apply; a fixed target file plus -eh keeps a pipeline from drifting onto hosts it should not touch.

Breaking changes are expected between releases

ProjectDiscovery marks Nuclei as in active development and tells users to expect breaking changes with releases and to review the release changelog before updating. The default branch is dev, not main, and the most recent tagged releases are v3.10.0 on June 30, 2026, v3.11.0 on July 6, 2026 and v3.11.1 on August 8, 2026. The last push to the repository was on October 2, 2026.

The consequence is aimed at automation. A pipeline that installs with @latest picks up whatever was released most recently, including changes that alter flags or output. Pinning a tag such as v3.11.1 in CI and upgrading deliberately, after reading the changelog, keeps a scheduled scan from failing or changing its results without anyone noticing. Building from the dev branch gets you unreleased code, which is not the same as the latest release.

Running Nuclei as a service is flagged as a security risk

The README is explicit that Nuclei is built primarily to be used as a standalone CLI tool, and that running it as a service may pose security risks; it asks anyone doing so to use caution and additional security measures. That is a notable warning for a project whose repository also contains a helm/ directory and a lib/ directory alongside cmd/, and examples under examples/simple/, examples/advanced/ and examples/with_speed_control/.

The limit for readers is clear even without more detail. Wrapping Nuclei in an API that accepts targets or templates from other users puts an engine that executes arbitrary templates, including JavaScript and Code ones, behind a network endpoint. If that is your plan, treat it as building your own security boundary around a tool that was not designed as one. The project points teams who want continuous scanning at scale to its hosted Pro and Enterprise editions instead.

Zero false positives is a slogan; reduced false positives is the mechanism

The README's opening line promises detection scenarios that mimic real-world conditions, leading to zero false positives. The feature list underneath is more measured: it says Nuclei reduces false positives by simulating real-world steps to verify a vulnerability. The second statement describes how it works: verification comes from the steps a template performs before it reports a match.

The gap between the two matters because accuracy is a property of each template, not of the engine. A carefully written template that verifies an exploit condition will be precise; a loose matcher will not, and Nuclei runs both the same way. Treat findings from templates you have not reviewed as leads to confirm, and keep the templates that produce noise out of CI gates.

The free cloud tier and paid editions sit on top of the open-source CLI

Alongside the CLI, ProjectDiscovery offers a free cloud tier with monthly limits. It stores and visualizes findings, lets you write and manage templates, gives access to the latest templates, and discovers and stores targets. The open-source CLI also integrates directly with Jira, Splunk, GitHub, Elastic and GitLab.

The Pro and Enterprise editions are a hosted service built on Nuclei OSS. ProjectDiscovery advertises 50x faster scans, large-scale scanning, cloud integrations for AWS, GCP, Azure, Cloudflare, Fastly, Terraform and Kubernetes, Slack, Linear, API and webhook connections, executive and compliance reporting, real-time scanning, SAML SSO, shared team workspaces and a SOC 2 compliant platform with EU and US hosting options. Those are vendor claims for the paid product, not properties of the MIT-licensed binary. A team evaluating Nuclei on its own should judge the CLI and templates by themselves, and treat the hosted features as a separate purchase decision.

Editorial conclusion

Nuclei fits security teams and developers who want scripted, repeatable vulnerability checks in a CLI or CI pipeline and are willing to read the templates they run. It does not fit anyone who wants a long-running scanning service to expose to others, since the project itself warns that running Nuclei as a service may pose security risks. Before adopting it, pin a release such as v3.11.1, read the changelog before each upgrade because breaking changes are expected, and confirm you have Go 1.27.3 or the Docker image available.

Frequently asked questions

How do I install Nuclei?

With Go 1.27.3 or newer, run go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest. Other methods are covered at https://docs.projectdiscovery.io/tools/nuclei/install, and the repository's Dockerfile builds an image with nuclei as its entrypoint.

How do I use Nuclei for a basic scan?

Run nuclei -target https://example.com for a single web application, or pass a file of targets with -l. Use nuclei -h to see every flag, and -eh to exclude hosts by IP, CIDR or hostname.

How do I use Nuclei templates?

Nuclei checks are written as YAML templates, with community templates in the projectdiscovery/nuclei-templates repository. SYNTAX-REFERENCE.md and nuclei-jsonschema.json in the Nuclei repository cover the template format for writing your own.

What is Nuclei used for?

The ProjectDiscovery Nuclei scanner finds vulnerabilities in applications, APIs, networks, DNS and cloud configurations using YAML templates. It can run in CI/CD pipelines for vulnerability detection and regression testing.

Official sources

  1. License: MIT
  2. projectdiscovery/nuclei on GitHub
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/projectdiscovery-nuclei.svg)](https://hysenlabs.com/projects/projectdiscovery-nuclei)

Star history chart for your README

markdown
[![Star history](https://hysenlabs.com/chart/projectdiscovery-nuclei.svg)](https://hysenlabs.com/projects/projectdiscovery-nuclei)

Was this useful?