# Jaeles: a Go framework for building your own web application scanner

> Jaeles turns YAML signatures into an HTTP scanning engine you can extend yourself. The README now carries an archive notice and points readers to a successor project, so the practical question is what the existing release still does well.

**jaeles-project/jaeles** — The Swiss Army knife for automated Web Application Testing

- Repository: https://github.com/jaeles-project/jaeles
- Website: https://jaeles-project.github.io/
- Stars: 2,376 · Forks: 335
- Language: Go
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/jaeles-project-jaeles

## What Jaeles actually solves for a web tester

Most web scanners ship a fixed rule set. You point them at a host, they run the checks their authors wrote, and you get a report. If you want a check that nobody has written yet, your options are a plugin API, a paid edition, or a script you maintain outside the scanner.

Jaeles takes the other position. The README describes it as "a powerful, flexible and easily extensible framework written in Go for building your own Web Application Scanner". The scanner is the runtime; the checks are signatures you supply. The README points to a separate repository, jaeles-project/jaeles-signatures, for installing signatures, which tells you the project expects a community rule set rather than a built-in one.

That model suits a specific kind of user. Someone doing bug bounty work who has already enumerated a set of hosts and wants to sweep them with a handful of targeted checks. Someone who needs to encode an internal detection that no public scanner covers. Someone integrating scanning into a larger recon pipeline, which the README acknowledges by noting the project was part of Osmedeus Engine.

It suits that user less well if the goal is a general purpose audit with no rule authoring. The framework gives you the engine and the signature format, and the quality of your results tracks the quality of the signatures you load.

## How the scan pipeline is put together

The repository layout shows the split. There is a cmd directory for command definitions, a core directory for the engine, a sender directory for outbound requests, a database directory, a dns directory, and a server directory for the long-running mode. The top-level main.go wires the CLI.

The dependency list in go.mod tells you more about behaviour than the README does. resty handles HTTP. goquery and cascadia parse HTML, so signatures can match on DOM structure rather than raw text. The chromedp packages drive a headless browser, which means some checks can execute JavaScript instead of only reading responses. otto embeds a JavaScript interpreter, and sprig supplies template functions, so signature logic is not limited to string comparison. ants provides the goroutine pool behind the concurrency flag. gorm and gin back the server mode and its storage.

The data flow implied by those pieces is straightforward. Targets arrive from a file, a URL flag, or standard input. The engine loads signatures matching a selector, runs them concurrently against each target through the sender layer, evaluates each response against the signature's matching rules, and records hits. Results can go to an output directory, to a web UI, or to a command through the notification hook.

## Installing Jaeles and running a first scan

The README offers two paths. Precompiled binaries are linked from the releases page, and there is a Docker image published as j3ssie/jaeles. If you have a Go environment, the README states Go >= 1.17 with Go Modules enabled, and gives this command.

```bash
go install github.com/jaeles-project/jaeles@latest
```

After that, jaeles should be on your PATH. The README notes that signatures live in a separate repository, so a scan needs a selector that resolves to signature files you have on disk. The Docker path avoids a Go toolchain entirely.

```bash
docker pull j3ssie/jaeles
docker run j3ssie/jaeles scan -s '<selector>' -u http://example.com
```

The repository Dockerfile builds from golang:1.20-buster, installs chromium, runs jaeles config init -y at build time, and exposes port 5000, which is the port the server mode listens on. If you build your own image rather than pulling one, chromium is already present, which matters for signatures that need a browser.

A basic scan against a single host takes a selector and a URL. The README gives this example.

```bash
jaeles scan -s 'jira' -s 'ruby' -u target.com
```

Multiple -s flags stack, so this runs the jira and ruby signature sets against the same target. For a list of hosts, the README shows the -U flag with a concurrency setting and a level filter.

```bash
jaeles scan -c 50 -s 'java' -x 'tomcat' -U list_of_urls.txt
```

Here -c 50 sets concurrency, -s selects signatures, -x excludes a selector, and -U names the target file. The README also documents reading targets from standard input, so piping from another tool works: cat list_target.txt | jaeles scan -c 100 -s <signature>. A -v flag increases verbosity, -o writes output to a directory, and --proxy routes traffic through an HTTP proxy such as http://127.0.0.1:8080. The -p flag passes parameters into signature templates, and -f runs a command on each finding, which the README illustrates with a Slack notification template.

## The archive notice is the first thing to read

The README opens with an important notice stating the repository has been archived and is no longer maintained, and directs readers to github.com/vigolium/vigolium as a successor. The release history is consistent with that. The most recent release listed is beta-v0.17.1 from 2023-07-08, preceded by beta-v0.17 in 2021 and beta-v0.16 in 2021. Every release carries a beta prefix.

The GitHub metadata in the repository listing shows archived as no and a last push on 2026-06-20, which conflicts with the README banner. Whatever the cause of that discrepancy, the maintainer's own text is the statement a prospective user should weigh, and it says the project is done.

This is not a subtle limitation. It means signature drift is your problem. Web application fingerprints change, endpoints move, and a signature written for a 2021 target may match nothing on a patched 2026 deployment. The separate signatures repository is where that maintenance would happen, and the README gives no indication of its state.

There is a second constraint worth naming. The README's planned features list, which includes more signatures, more input sources, more request properties, proxy plugins, and additional Web UI actions, is a list of things that were intended. A reader should treat it as a historical document, not a roadmap.

## Jaeles against Nuclei, and where the difference bites

The obvious comparison is Nuclei. Both are Go scanners that take YAML templates or signatures and run them against a target list, and both expect users to author or collect rules rather than rely on a fixed set.

The difference is in where the work happens. Nuclei's template format is its own DSL with a defined request and matcher structure, and its ecosystem of templates is the project's centre of gravity. Jaeles exposes a broader runtime: the go.mod dependencies show an embedded JavaScript engine through otto, template functions through sprig, headless browser control through chromedp, and DNS resolution utilities through dnsutil. That means a Jaeles signature can carry logic that a pure request-and-match template cannot, at the cost of a signature format that is harder to write and harder to share.

The practical consequence is that Nuclei is the better default when you want coverage from a maintained community rule set, and Jaeles is the more interesting choice when your detection needs computation inside the check. The archive notice tilts that comparison further, because the Nuclei template ecosystem is alive and the Jaeles signature ecosystem has no stated maintenance. The README also credits the Chaitin xray team for architecture ideas, which places Jaeles in the same design family as other template-driven scanners.

## Licence, upgrades and what running it costs you

Jaeles is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use, modify, and redistribute the code, including in commercial settings, provided the copyright notice and permission notice travel with it. That is the general shape of the licence, not legal advice, and anyone embedding the scanner in a product should read the file itself.

The upgrade cost is where the archive notice lands hardest. There is no supported migration path from beta-v0.17.1 to anything, because there is no next release. If you build signatures against this version, they stay valid for this version. The Go module declares go 1.20 while the README asks for Go >= 1.17, so a build with a newer toolchain is untested territory rather than a documented configuration. The Dockerfile pins golang:1.20-buster, which is the combination the maintainer last built with.

Ongoing cost is mostly signature upkeep. Every target you scan with a stale signature is a scan whose results you have to interpret yourself, and the framework does not distinguish a signature that found nothing from a signature that no longer applies. Budget for that reading time, or budget for rewriting the checks you depend on.

## Conclusion

Jaeles fits engineers who already have a target list and want to write their own detection logic in YAML rather than accept someone else's rule set, and who can live with a scanner whose README states the repository is archived. It does not fit anyone who needs a maintained rule feed, a supported upgrade path, or a tool that answers to a vendor. Before adopting it, check whether the signature repository you intend to use is still being updated, and confirm the Go version your toolchain provides, since the README asks for Go >= 1.17 while go.mod declares go 1.20.

## FAQ

### Is Jaeles still maintained?

The README carries a notice stating the repository has been archived and is no longer maintained, and it points to github.com/vigolium/vigolium as a successor. The latest release listed is beta-v0.17.1 from 2023-07-08.

### How do I install the Jaeles scanner?

The README offers precompiled binaries from the releases page, a Docker image published as j3ssie/jaeles, and a Go install path. For the Go path it states you need Go >= 1.17 with Go Modules enabled and then run go install github.com/jaeles-project/jaeles@latest.

### Where do Jaeles signatures come from?

They are not bundled with the scanner. The README points to a separate repository, jaeles-project/jaeles-signatures, for installing signatures, and it also invites contributions of new signatures to that repository.

### What port does the Jaeles server mode use?

The repository Dockerfile exposes port 5000, and the README shows the server subcommand being started with a signature selector and a level flag. The README does not document what authentication the server mode applies by default.

## Sources

- [jaeles-project/jaeles on GitHub](https://github.com/jaeles-project/jaeles)
- [License: MIT](https://github.com/jaeles-project/jaeles/blob/master/LICENSE)
- [Project website](https://jaeles-project.github.io/)
- [README](https://github.com/jaeles-project/jaeles/blob/master/README.md)
- [Releases](https://github.com/jaeles-project/jaeles/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jaeles-project-jaeles