snallygaster probes a known list of paths and tells you which ones answer

A fixed list of paths, checked against one target

snallygaster is described as a tool that looks for files accessible on web servers that shouldn't be public and can pose a security risk. The typical examples given are publicly accessible git repositories and backup files potentially containing passwords or database dumps. In addition, it contains a few checks for other security vulnerabilities.

That description defines the whole scope, and the scope is narrow in a way worth stating plainly. The tool does not crawl. It does not map an application. It probes a known set of paths against a target and reports the ones that answer with content they should not have. The categories of leak are conventional rather than discovered: a .git directory left in a web root, a stray SQL dump, a backup archive.

The check catalogue is not in the README. The README directs readers to the TESTS.md file for an overview of all tests and links to further information about the issues, which is the right place to look before deciding what a given finding means.

The README also links a talk titled Attacking with HTTP Requests as an introduction to this kind of issue, which tells you the framing: these are leaks discovered by asking a server for paths that were never meant to be served.

Because the tool targets HTTP servers specifically, its coverage of non-HTTP exposures, filesystem permissions or network services outside the web root is nil.

One script, three dependencies, and the packaging oddity

snallygaster is a simple Python 3 script, which is a real description of its distribution model. You can download the file named snallygaster and execute it directly.

The dependencies are urllib3, lxml and dnspython. On Debian or Ubuntu based systems the README gives the packaged names:

apt install python3-dnspython python3-lxml python3-urllib3

Three dependencies for a path-checking tool is a deliberate restraint. The v0.0.14 release title says the project switched from beautifulsoup to lxml.

The PyPI install is:

pip3 install snallygaster

pyproject.toml declares the version as 0.0.15, requires-python >=3.9, and classifies support for Python 3.9 through 3.14. The build system needs setuptools 61.0.0 or newer and setuptools_scm, which is how the version is derived, with an empty tool.setuptools_scm table confirming automatic versioning.

The one packaging quirk is in the setuptools section: the project uses script-files with a single entry, the snallygaster file. That installs a script rather than a module, which is why the raw file is executable on its own. It also means there is no importable package name to depend on programmatically.

Distribution packages exist for most Linux and BSD flavours

The README lists packaged versions and the list is the interesting part, because it maps where the tool has actually been adopted.

Gentoo packages it as net-analyzer/snallygaster. NetBSD carries it in pkgsrc as security/snallygaster. Arch Linux has a git version in the AUR, snallygaster-git, which tracks the repository rather than a release. openSUSE packages it directly.

Then there is Repology, linked for the rest. The presence of a distribution package in a security or net-analyzer category is a stronger signal than a GitHub release, because packagers accept the tool into a maintained tree with their own review, and from there it inherits updates and security fixes from the distribution rather than from the author.

A recent GitHub release is v0.0.14 from 2025-09-08. That is not a sign of abandonment in the way it would be for a library with many dependents, but it does mean the channel you are most likely to install from is a distribution package rather than a tagged release.

The repository is not archived and the last push was on 2026-10-14, so development is current even though the version number is small. The project is classified as Development Status 4 - Beta and its intended audience is given as system administrators, which is the correct audience for a tool that reports unauthenticated access to files that should require authentication.

What a finding means, and what it does not

The results need interpretation, and the tool's own documentation points at the tests file for that.

A positive result means the server returned something for a path that should not be served. That is a fact about the HTTP response, not a proof of compromise. A .git directory that is reachable exposes the repository, from which a reader can reconstruct source history, and a database dump exposes data directly. But a check that matches on a filename can also match a decoy, an error page that echoes the path, or a file that genuinely is meant to be public and happens to have a suggestive name.

The converse matters too. A negative result is not a clean bill of health, because the check list is fixed and the paths are conventional. A backup named something not in the list, or a repository exposed through a rewrite rule rather than a literal .git path, will not be found. Absence of findings bounds what was probed, nothing more.

This is why the README links TESTS.md for an overview of all tests and further information. The individual checks carry the assumptions, and reading them tells you what each result means before you act on it.

The correct operational use is therefore: run it against hosts you control, read what matched, verify each match by hand, then fix the underlying exposure. Automating the fix is not something this tool attempts.

Where a general scanner or a CI check fits better

Three alternatives, each solving a different part of the problem.

A general web vulnerability scanner covers the same leaks plus a much wider set: injection, misconfiguration, outdated software, header issues. The difference in approach is breadth against signal. A scanner that reports everything also reports everything weak, and on a single host the noise can bury the one exposed repository that matters. A fixed-path checker produces a short list that a human can read.

A CI check on every deploy is the other direction. The exposure this tool finds is usually created by a deployment step that copies a .git directory into the artifact, so the cheapest fix is a check in the pipeline that inspects the built output before it ships. That catches the cause rather than the symptom, and it runs before a scanner would ever see the host.

A secret scanning tool covers a different leak class. Searching the repository for credentials finds the password inside a committed file; snallygaster finds the repository being served. The two are complementary, since a served .git directory effectively publishes every secret ever committed.

What snallygaster has that these do not is distribution packaging across Linux and BSD systems and a test catalogue that documents each finding, which makes it easy to deploy across a fleet without building anything.

Zero-clause BSD and a maintained single-maintainer project

The licence is 0BSD, declared in pyproject.toml and with a LICENSE file at the root. Zero-clause BSD is the permissive licence with the copyright notice clause removed: you can use, modify and redistribute the code with no obligation to retain attribution. For a security tool you may want to embed in an internal scanning pipeline or redistribute alongside your own tooling, that is the least friction of any common open source licence.

The project is maintained by Hanno Böck. The README credits several people with specific contributions rather than listing them generically: Tim Philipp Schäfers and Sebastian Neef from Internetwache for ideas about what to look for, Craig Young for discussions during development, Sebastian Pipping for help with Python programming, and Benjamin Balder Bach for teaching the author about Python packaging. Organisers of Bornhack, Driving IT, SEC-T and the Rights and Freedom track at 34C3 are thanked for letting the work be presented.

Those conference credits explain the project's character: it came out of the hacker and free software community circuit rather than a commercial vendor.

Two files in the repository root are worth knowing about for anyone planning to use the tool seriously. SECURITY.md exists, so there is a defined place to report a problem in the tool itself, and CONTRIBUTIONS.md is what the FAQ points you at before sending a patch or a pull request.

Editorial conclusion

snallygaster fits a system administrator auditing their own hosts, or a security reviewer working with written authorisation, who wants a fast answer to whether a web root is exposing version control data or backups. It does not fit an unauthenticated assessment of someone else's server, and it does not replace a proper scanner, since the check list is fixed and the tool takes a target rather than discovering one. First step is installing it and pointing it at a single host you own, then read TESTS.md before writing a policy around the results, because that file is where the individual checks and their references are documented.

Frequently asked questions

Official sources

1. hannob/snallygaster on GitHub
2. Issues
3. License: 0BSD
4. README
5. Releases