XingRin turns a list of scanners into an attack surface inventory

The pipeline is stages of well known tools, not a new scanner

XingRin describes itself as an open source attack surface management platform for authorized security testing and defensive research, covering asset discovery, service probing, scan orchestration and security result management. The scanning itself is done by established tools, and the table of capabilities is explicit about which ones.

Subdomain scanning uses Subfinder, Amass and PureDNS, combining passive collection with active enumeration and aggregating more than fifty data sources. Port scanning uses Naabu with custom port ranges. Site discovery uses HTTPX, which fetches titles, status codes and technology stacks. URL collection uses Waymore and Katana for historical data and active crawling, directory scanning uses FFUF with a curated dictionary, site screenshots are taken with Playwright and stored as compressed WebP, and security detection runs Nuclei and Dalfox against more than nine thousand detection templates covering common web risks and configuration issues.

Two of those rows are the project's own work rather than a wrapper. Fingerprint identification is done by XingFinger, which carries more than twenty-seven thousand fingerprint rules from multiple fingerprint sources, and the detection templates are managed through their own storage and synchronisation architecture, described in a dedicated document alongside a separate one for dictionary files.

The scan flow itself is three stages. Stage one is asset discovery, running subdomain discovery, port scanning, site identification and fingerprinting in that order. Stage two is deep analysis, covering URL collection, directory scanning and screenshots. Stage three is security detection. Each stage feeds the next, and the diagram in the documentation makes the ordering explicit.

Target management and blacklists decide what gets scanned at all

Before any scanner runs, the platform has to know what it is allowed to touch, and that is what the platform capability table is about.

Target management supports multi-level organisation and accepts both domain and IP targets. Blacklist filtering applies globally and at the target level, and supports wildcards and CIDR ranges. Scheduled tasks run on cron expressions so that the same scan recurs on a schedule rather than being triggered by hand.

For an attack surface tool the blacklist is the most safety-critical setting in the product, and the fact that it exists at two levels, global and per target, with wildcard and CIDR support, is the difference between a tool that is safe to point at a large list and one that is not. A global rule can exclude ranges that must never be probed, for example a third party hosting range that your organisation does not own, and a per target rule can narrow a single engagement.

The results side of the platform is where the value accumulates. Asset snapshots let you compare one scan against another and track how the estate changes over time, which is the actual question an attack surface programme exists to answer. Notifications go out to WeCom, Telegram and Discord, and API key management gives a visual place to configure the keys for the data sources that need them, rather than scattering them across environment files on several machines.

Workers register themselves, report load, and get skipped when busy

The distributed architecture is the part that distinguishes this from a shell script that chains the same tools together.

A master server holds a Redis load cache and a task distributor that receives scan tasks, selects a node based on load, and dispatches. Around it sit worker nodes, and the diagram shows the intended behaviour: a worker reporting a high CPU and memory figure is skipped for dispatch while the lightly loaded ones take the task, with each worker reporting back to the cache by heartbeat.

Three deployment modes are described. Multiple worker nodes can be deployed to scale scanning horizontally. A local node is zero configuration, since installing the software registers a local Docker worker automatically. A remote node is deployed to a remote VPS over SSH with a single command, which is how a team spreads scanning across several machines without maintaining the same setup on each.

The node monitoring covers heartbeats and the CPU, memory and disk state of each machine, and a node that goes offline is detected automatically and rejoins once it is back.

The honest caveat is in the maintenance note below: the current code has weak native distribution capability, and that limitation is the stated reason for the rewrite. The architecture in the documentation is the design being aimed at, and the workers described here are what the current implementation delivers.

The asset inventory is a query language, not a list

Global asset search is the feature that turns scan output into something a team can work with. It covers two asset types, Website and Endpoint, and it uses an expression syntax rather than a form of filters.

Three comparison operators are supported, and the distinction between the first two is the kind of detail that changes your results. A single equals sign is a fuzzy match, a double equals sign is an exact match, and an exclamation with equals means not equal. Those combine with logical operators, && for AND and || for OR. The searchable fields are host, url, title, tech, status, body and header.

The syntax is small enough to learn in a minute:

host="admin" && tech="php" && status=="200"
url="/api/v1" && status!="404"

That last pair is the kind of query that does real work, since it finds endpoints that return something other than a 404, which is how a misconfigured route shows up in a crawl.

Results export to CSV as a stream with no limit on the number of rows, which matters because the alternative, a browser that tries to render a hundred thousand rows, is a good way to lose a finding. The interface adds dashboards for asset and vulnerability counts and WebSocket push for live notifications, so a scan that finds something does not have to be polled for.

One install script, and a mirror flag for constrained networks

The requirements are modest for a platform of this kind: Ubuntu 20.04 or later or Debian 11 or later, AMD64 or ARM64, a minimum of two cores and 4 GB of memory, and 20 GB or more of disk space.

Installation is a clone and a script:

git clone https://github.com/yyhuni/xingrin.git
cd xingrin
sudo ./install.sh

The script configures Docker and starts the stack in production mode, and the repository also carries start.sh, stop.sh, restart.sh, update.sh and uninstall.sh for the individual operations, plus docker-push.sh and a docker directory.

There is one flag worth knowing about. A mirror option exists for users in mainland China, and the documentation is careful about it: the mirror is a third party acceleration service, it may stop working, and long term availability is not guaranteed. That is the right way to describe a mirror, and it means the default path is the one to prefer if your network can reach the upstream registry.

The public demo at the project's site is explicitly a user interface demonstration with no backend database attached, so nothing you do there touches a real scan. The documentation set behind the quick start covers the technical navigation, the version management scheme, which is driven by Git tags, the nuclei template architecture, the wordlist architecture and the full scan flow, and it also ships a security policy describing how vulnerability reports are handled.

The TypeScript codebase is on its way out, in favour of a Go rewrite

The most important fact about this project is stated plainly in the README rather than buried in a roadmap. The project is under continued maintenance, and the reason given is that with the current architecture the code is very hard for AI-assisted development to evolve, the code has weak native distributed capability, and to fit the long term development of the project a new generation architecture refactor was carried out, with the backend written in Go as the core, on the grounds that its distributed capability is the better answer.

The new project lives in a separate repository, yyhuni/lunafox, and the Go choice is explicitly motivated by distribution rather than by raw performance.

That reframes everything else in this article. The TypeScript frontend and backend you can read today are the previous generation, and the distributed worker design described in the documentation is a target rather than a finished system. The last push to this repository was on 2026-09-21, and the most recent release tags are v1.5.7 on 2026-01-10 and v1.5.8 on 2026-01-11, which is consistent with a project whose commits continued after the last tagged release.

The licensing is MIT, which matters for a security tool that organisations may want to run internally and modify. The tree also carries the usual governance files, a contribution guide, a code of conduct, a security policy and a VERSION file, alongside the backend, frontend, docker and docs directories.

Editorial conclusion

XingRin is worth adopting if your team already runs Subfinder, Naabu, HTTPX and Nuclei by hand and wants the output to land in one searchable inventory with snapshots, scheduled reruns and notification channels, because the orchestration layer is the value rather than the scanning. It is the wrong tool if you want a single binary, and it is the wrong tool to build on for anything long-lived, since the maintainers state that the current architecture is being replaced by a Go rewrite in a separate repository. Verify first that your target scope and blacklist rules are configured before the first run, that the API keys for your data sources are set through the key management screen, and that the workers you add are machines you are authorised to scan from.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yyhuni/xingrin on GitHub