Yogesh Ojha
a548afffa2
Settings has six tabs: General, API keys, Proxies, Notifications, AI and Users. Each tab is one card whose controls save on change; list tabs are tables with a row menu and their Add action in the tab row. A non-admin sees General and AI, read-only. Out-of-band testing is the Callback server sheet on the Arsenal Nuclei tab, with a Need a callback count that filters the library to the same rows. Bounty Hub settings are a sheet on the Bounty Hub page. The old settings routes redirect to both. - API keys store the last test result on the row and clear it when the key changes. Providers report whether a test exists. The usage count is gone: only ViewDNS ever incremented it. - Notification channels store the last delivery, written by the notifier on its own connection. A channel offers the seven event types the product emits, program changes on by default, and levels named All events, Warning and critical, Critical only. - A default proxy applies to a scan launched without a context and is preselected for new contexts. A pool hands each scan one endpoint, proxy URLs bracket IPv6 hosts, and deleting a proxy clears it from its contexts. - Users can be added with a role, disabled and promoted. An account cannot change itself, and one that owns records answers 409. - Retention windows are validated and include keep forever. The instance name cannot be blank and names every page title. - The AI list drops the two switches nothing read; each feature states what it sends. The out-of-band Off help says the checks are skipped. Connectors, Bounty Hub and Remote control lose their extra page padding. Migration 5d2e9a8c1b47 adds the test and delivery columns and drops proxies.mode. Claude-Session: https://claude.ai/code/session_01RVAHQxZ7JAkoEiTCDiHYue
reNgine: Open Source Attack Surface Management
reNgine 3.0 Sirius is released
reNgine 3.0 Sirius is a complete rewrite of reNgine as an attack surface management platform. It brings a seven-dimension attack surface model, a query language across all results, correlation of assets across targets, exploit intelligence from EPSS and KEV, software CVE inference, secret mining, run comparison, program watches for bug bounty scopes, an MCP server, remote control over Telegram and a Burp Suite connector. Read What's new in reNgine 3.0.
What is reNgine?
reNgine is an open source attack surface management platform for security teams, penetration testers and bug bounty hunters. It maps the external attack surface of an organisation, finds subdomains, IP addresses, open ports, endpoints and running software, scans them for vulnerabilities, and keeps the results in one place. Scans are built from configurable engines, results are searched with a query language, and every scan can be scheduled, compared with the previous one and reported on.
reNgine runs on your own server with Docker Compose and works with the open source tools the community already trusts, including subfinder, httpx, naabu, katana, ffuf, nuclei and dalfox.
Documentation
Detailed documentation is available at rengine.wiki.
Table of Contents
- About reNgine
- Features
- Quick Installation
- Updating
- Upgrading from reNgine 2.x
- Screenshots
- What's new in reNgine
- Contributing
- reNgine Support
- Support and Sponsoring
- Reporting Security Vulnerabilities
- License
About reNgine
Attack surface, not a subdomain list. Every scan produces seven kinds of result: web assets, endpoints, services, IP addresses, vulnerabilities, software CVEs and secrets. Each kind has its own page across all targets in a project and its own tab on every scan. A target can be a domain, an IP address, an IP range, an ASN or a URL.
Scan engines. A scan engine is a saved set of stages: subdomain discovery, host discovery, port scanning, HTTP probing, screenshots, URL discovery, content discovery, vulnerability scanning, DAST fuzzing, secret mining and more. Each stage has its own settings, every engine can run at passive, normal or aggressive intensity, and a scan context supplies authentication headers, scope exclusions, proxies and rate limits for the target. Any stage can be overridden for a single run, and a focused rescan runs selected stages against selected assets.
Query language. All results are searchable with the same query syntax. is:live tech:nginx finds live nginx hosts, severity:critical is:new finds critical findings that were not in the previous scan, port:22 finds SSH services and cve:CVE-2024-3400 finds every asset affected by one CVE. Queries drive filters, saved rules, dashboard counts, exports and notifications.
Correlation. Hosts that share an IP address, certificate, page title, favicon, body hash, JARM fingerprint, technology or CDN are grouped and drawn as a graph. Links are drawn across targets in a project, and targets are related to each other by certificate, registrant, network and nameserver. Provider infrastructure such as CDN edges and shared platform hostnames is recognised and not drawn as a relation.
Prioritisation. Findings carry CVSS, EPSS and CISA KEV data, refreshed nightly from the feeds without a rescan. Software CVEs are inferred from fingerprinted versions against a local NVD corpus and shown as their own dimension. Every finding sits on one evidence ladder, from inferred to proven, and triage decisions carry across scans.
Continuous monitoring. Scans run once, on an interval, daily at a fixed time or on a cron expression. What's new lists everything found since the last visit, grouped by run, and Compare runs shows the difference between any two scans of a target, including what changed in the configuration between them. Notifications go to Slack, Discord, Telegram, Microsoft Teams, email and webhooks.
Bug bounty mode. Bounty Hub syncs programs and scopes from HackerOne and Intigriti and imports the public program feed. A program watch turns a program's scope into targets, a scan context and a schedule, then follows certificate transparency logs and probes each new in-scope host as its certificate appears.
Integrations. An MCP server exposes reNgine's data and scan controls to AI agents with scoped service tokens. Remote control pairs a Telegram chat with the instance for scans, findings and progress from a phone. The Burp Suite connector feeds proxy traffic into the endpoint inventory and sends endpoints back to Burp. AI providers can be connected for report narration and exposure review.
Reports. PDF reports are assembled from sections such as executive summary, risk summary, findings, web assets, services, hosting, domain posture and remediation plan, styled with themes. Any result set exports as CSV, JSON or text.
Features
- Reconnaissance
- Subdomain discovery from passive sources, certificate transparency, wordlists and permutations
- IP address, ASN and country enrichment without an API key
- Netblock sweeps and reverse DNS for ASN and IP range targets
- Port scanning with service fingerprinting and banner grabbing
- HTTP probing with technology, web server, TLS, CDN, WAF and favicon detection
- URL discovery from crawling, archives and sitemaps
- Content discovery with calibrated fuzzing
- Virtual host discovery, zone transfer checks and subdomain takeover detection
- Screenshot gallery with clustering of pages that look alike
- Vulnerability assessment
- Vulnerability scanning with nuclei over a planned input set
- DAST fuzzing with nuclei and dalfox
- Software CVE inference against a local NVD corpus
- Secret mining across stored responses
- Web hygiene checks on headers, cookies, CSP and CORS
- Domain posture checks on SPF, DMARC, DKIM, MTA-STS, DNSSEC and CAA
- EPSS and CISA KEV exploit intelligence, refreshed nightly
- Evidence ladder and triage carried across scans
- Attack surface management
- Seven result dimensions across targets and per scan
- Query language with autocomplete and saved rules
- Correlation graph and cross-target links
- Exposures from rules and correlation signals
- What's new since the last visit
- Compare any two runs of a target
- Recon notes anchored to assets
- Bulk triage, selection and export
- Scanning
- Scan engines built from stages, with a built-in engine per project
- Passive, normal and aggressive intensity
- Scan contexts for authentication, scope, proxies and rate limits
- Single-run overrides and focused rescans
- Pause, resume and cancel
- One-off, interval, daily and cron schedules
- Projects for separating engagements
- Bug bounty
- Bounty Hub with HackerOne and Intigriti sync and the public program feed
- Program watches with certificate transparency monitoring
- Integrations
- MCP server for AI agents
- Remote control over Telegram
- Burp Suite connector
- OpenAI, Anthropic, Azure OpenAI and Google AI providers
- Notifications on Slack, Discord, Telegram, Microsoft Teams, email and webhooks
- Reporting
- PDF reports from configurable sections and themes
- CSV, JSON and text exports
- Toolbox for one-off lookups: WHOIS, DNS, subdomains, HTTP probe, IP intelligence and CVE
- Arsenal for nuclei templates, wordlists and threat intelligence feeds
- Two-factor authentication and encrypted API keys
Quick Installation
reNgine requires Docker and Docker Compose v2 on a Linux host. The default database settings are sized for 8 GB of memory.
-
Clone the repository
git clone https://github.com/yogeshojha/rengine && cd rengine -
Create the environment file and generate a secret key
cp .env.example .env sed -i "s/^SECRET_KEY=.*/SECRET_KEY=$(openssl rand -hex 32)/" .env -
Set the administrator credentials and the database password in
.envADMIN_USERNAME=rengine ADMIN_EMAIL=admin@example.com ADMIN_PASSWORD=yourStrongPassword POSTGRES_PASSWORD=yourStrongPassword -
Build and start reNgine
docker compose up -d --build -
Apply the database migrations and restart the API
make migrate docker compose restart api
reNgine is now available at http://127.0.0.1:5173, or at the server's address when installed on a VPS. Sign in with the administrator credentials and complete the setup wizard.
The database, Redis and Flower are bound to 127.0.0.1. Place a reverse proxy with TLS in front of port 5173 when exposing reNgine to a network.
For other platforms and a detailed walkthrough, see rengine.wiki/install.
Updating
cd rengine
git pull
docker compose build
docker compose up -d
make migrate
docker compose restart api
Upgrading from reNgine 2.x
reNgine 3.0 uses a new data model and does not import a 2.x database. Install 3.0 as a new instance and add targets again.
Screenshots
Contributing
Contributions of all sizes are welcome: code, documentation, bug reports, feature proposals and interface work.
- Read the Contributing Guide
- Pick an open issue or propose a new one
- Fork the repository and create a branch
- Make the change, run
make lintandmake test, and open a pull request
Development setup and commands are in dev-README.md. First-time open source contributors are welcome.
reNgine Support
Read the documentation before asking for help. Most questions are answered there.
- Do not use GitHub issues for support requests.
- Join the community-maintained Discord. There is no guaranteed response time.
- Open a GitHub issue for confirmed bugs and feature requests.
Support and Sponsoring
reNgine is a passion project developed alongside a day job. Support it by:
- Adding a GitHub Star
- Writing or posting about reNgine
- Nominating the author for GitHub Stars
- Sponsoring through the links in FUNDING.yml
Reporting Security Vulnerabilities
- Do not disclose the vulnerability in a public issue or forum.
- Open the Security tab and choose "Report a vulnerability".
- Include steps to reproduce, the impact and any suggested fix.
Reports are usually answered within 72 hours. Responsible disclosure is credited after the fix is released, unless the reporter prefers to stay anonymous. See SECURITY.md.
License
Distributed under the GNU GPL v3 License. See LICENSE for more information.