CVEngine v1.2.1

v1.2.1

Update with the in-app updater (Settings > Updates) or make up. Includes everything in v1.2.0. No database migrations.

Changed

• A triage answer the validator rejects is sent back to the AI, with why. "AI review failed (schema_invalid)" meant the model's reply broke the strict answer schema (an extra key, severity_adjust as text, a step kind outside nuclei, nmap, curl and manual, two JSON objects ...) and the finding was left unreviewed until the next sweep. The rejected reply and the exact reason now go back to the model once, and its second answer is used; if that is also rejected the failure is recorded as before, now with the reason (reason, attempts in the diagnostic, never any reply text). The retry is a separate step in AI usage (finding_triage_repair).

Fixed

• Mouse-wheel zoom works on the Live discovery graph and the asset graph in Edge and Chrome. The wheel zoom the graph library provides did not fire in Chromium browsers (it worked in Firefox). The graph now handles the wheel itself in every browser: it zooms around the pointer, keeps the zoom between 0.04x and 6x, stops the page scrolling while the pointer is over the graph, and hands the view over from auto-fit to you, as before (double-click or the Fit button refits).

CVEngine v1.2.0

Update with the in-app updater (Settings > Updates) or make up. A release is only cut after an upgrade rehearsal: CI installs the previous version, seeds it with data (duplicate IP addresses included), updates it with the real update scripts, plain and behind a host proxy, and checks the site, the workers, the migrations and the data. This release adds database migrations; the update applies them and rolls back if one fails.

Changed

• Scans can run every Nuclei template. Settings > Scan engines has a new "Nuclei templates" switch. Off (the default), only templates that make plain GET, HEAD or OPTIONS requests run, as before. On, every template Nuclei ships runs, in the broad scans and when a CVE match is validated; the AI-written templates stay read-only and Nuclei's denial-of-service templates stay excluded. Changing it is recorded in the audit log and makes hosts due for a fresh pass with the new set.
• The AI planning budget is a setting. "AI planning daily budget reached; generic external checks deferred" came from a fixed limit of 20 planning requests a day per project and 200 in total. Both are now fields under Settings > AI model (the same defaults; 0 turns AI planning off), and the message says where to change them.
• Names that point at the same servers are one host. example.com and www.example.com resolving to exactly the same addresses used to be two hosts on the map, the Hosts page and the counts, each with its own copy of every finding. They are now one host (the project's own target name is the one shown, otherwise the shortest) that lists its other names ("Also answers to"), and its CVE matches, findings and exposure are the host's, counted once. Names behind a CDN or other shared edge address, names with a different set of addresses, names that never resolved, and the same addresses in another project stay separate hosts. The dashboard, the Hosts page, the group overview and the history count the same way.

Fixed

• scripts/update.sh no longer refuses to update because of the stack's own ports. Run by an ordinary user (a member of the docker group, not root), ss cannot name the process behind Docker's own listeners, so the port check took the stack's published port 443 for "an unknown process" and stopped the update before building anything. A port the running containers publish themselves is now recognized through docker ps; a port held by anything else still stops the update. Found by the upgrade rehearsal.

• The nuclei WAF and favicon templates no longer lose what they found. Real hosts showed a technology named just WAF or DNS WAF (the template's own name, with the vendor that fired dropped), favicon-detection with the icon's hash stored as its version, and AWS Service -. The WAF and favicon templates now name the product by matcher, a favicon hash is no longer a version, and the dangling dash is gone.

• The node2shell / HTTP2Shell check (CVE-2026-111497) looks at every runtime that carries the decoder. The Brotli decoder is compiled into Node.js, Bun and Envoy, but the check only considered hosts fingerprinted as Node.js or Express. It now also takes Bun, Envoy (and the Istio sidecars built on it) and the frameworks that run on Node (Next.js, Nuxt, NestJS, Fastify, Koa and others), and CVENGINE_NODE2SHELL_SCOPE=all checks every web host for what a name cannot show (a Python service using Brotli, a container base image). It stays off unless CVENGINE_NODE2SHELL=1, because it uploads about 23 MB to each host it checks.

• make redis-auth and make rotate-field-key keep the install's Compose layout. They recreated services from docker-compose.yml alone, the mistake that took a host with an overlay down through the updater. They now use the files, env file and project from CVENGINE_COMPOSE_* (environment or .env), else those the running stack was started with (scripts/compose-layout.sh). make redis-auth also writes the password to the env file the stack is started with (an overlay's .env.vps): Compose reads ${REDIS_PASSWORD} from that file, so a password only in .env left Redis open while the script said it was closed. Found by the upgrade rehearsal.

• scripts/update.sh keeps the running stack's Compose layout too. With no CVENGINE_COMPOSE_* setting it recreated the stack from docker-compose.yml alone (it only noted the difference), the same mistake the in-app updater made. It now uses the files, env file and project the running web container was started with, says so, and stops with the reason when those files are outside the checkout.

• A generic "WAF" label no longer matches a named WAF product. A host that bbot only labelled "WAF" was matched to the MOVEit WAF advisories because "WAF" is a whole word in that product's name. "WAF" and "Web Application Firewall" are now category labels that identify no product; a host that really is MOVEit WAF still matches. Existing wrong matches are cleared the next time matches are refreshed.

• Changing the update branch moves the server to it. Choosing another branch in Settings > Updates and approving used to fail with "not on the branch checked out on this server". The host script now fetches that branch and checks it out (an upgrade only: the branch must contain the installed commit, the local branch must not hold unpushed commits, the checkout must be clean and on a branch), rebuilds, and returns to the previous branch and commit if the build fails before the migration. When it cannot, nothing moves and Settings > Updates says why.

• The in-app updater keeps the Compose layout the stack runs with. It recreated the containers from docker-compose.yml alone, so on a host with an overlay (a host proxy on port 443, memory limits) and its own env file the proxy could not bind its port and the site went down. It now reads CVENGINE_COMPOSE_FILES, CVENGINE_COMPOSE_ENV_FILE and CVENGINE_COMPOSE_PROJECT (environment or .env, as update.sh does), otherwise uses the files, env file and project the running web container was started with, and stops with the reason (approval kept) when the checkout holds an overlay nothing says to use. After the restart it checks that every service is running and reports a failed update when one is not. scripts/update.sh passes its layout on when it installs the watcher.

• A patched jQuery was reported as vulnerable to CVE-2020-11023. The advisory lists jquery (fixed 3.5.0) next to the Ruby gem jquery-rails (fixed 4.4.0), and the matcher tested the detected jQuery 3.5.1 against the gem's version range too, so a host already past the fix was reported as "jquery-rails 3.5.1" inside the affected range. When an advisory names the product itself, only the entries that name it exactly are tested now; wrappers and repackagings that merely contain the name (jquery-rails, org.webjars.npm:jquery) no longer decide the match. Existing matches of this kind close on the next correlation pass.

Added

• The firewall in front of a host is named. A new pipeline stage runs wafw00f against each web host and stores the product it names (FortiWeb, Cloudflare, BIG-IP ...) as a technology of the host, so it is searchable and CVE correlation, the AI and the targeted nuclei pass can use it. It gives a product, never a version. On by default, bounded to 25 hosts per scan and once a week per host; CVENGINE_WAFW00F=0 turns it off (Configuration). bbot's own WAF event, which carries the same product name and was not read at all, is stored the same way.

• An upgrade rehearsal runs before every release. On a pull request into master, CI installs the released version, seeds data, merges the release candidate, updates with the real update scripts (an install with docker-compose.yml only, and one behind a host proxy with an overlay and env file), and checks the services, the site, migrations, workers, data and the overlay. See docs/UPDATES.md.

• Settings > Updates says what will happen and how long it takes. After Approve it shows each step (approved, the host picks it up, scans pause and drain, files update, services rebuild, scanning resumes) with what it is waiting on, how long it usually takes and the time since approval, refreshing on its own. When no host updater is reporting it says so and shows the one command to run on the server, with a Copy button; the orange bar says the same after 20 seconds instead of waiting quietly. scripts/install-updater.sh now starts the watcher straight away, and scripts/apply-update.sh rebuilds when the files are already at the approved commit (after a manual git pull) but the running build is older, instead of declaring the update done.

• A work conductor keeps the discovery queue fed. With a thousand hosts the Live page could still show 0 scans running, because scans started only on request or from a daily or weekly sweep. A watchdog now runs every minute and, when fewer than three scans are running or queued, starts discovery of the targets that have gone longest without one (never scanned first, one per project per round, none scanned in the last two hours, none excluded, nothing while scanning is paused, and no bug bounty project until its engagement has confirmed automated testing). It is visible in the system status, which reports a problem when targets exist and nothing is running or queued. CVENGINE_WORK_DEPTH and CVENGINE_WORK_MIN_GAP_HOURS tune it; CVENGINE_WORK_DEPTH=0 turns it off.

• A pre-populated CVE catalog. A new install no longer rebuilds the catalog one CVE at a time. The published seed (every fire, smoke and ice CVE with its scores, exploitation signals, ranges, references and detection record) is downloaded, verified against its sha256 and imported on first start, then the incremental feed takes over. Maintain...

CVEngine v1.1.2

Changed

• The old reNgine scan engine is retired. Its scan and subscan tasks, the /api/action/initiate/subtask/ endpoint, its extra queues, and about 4,000 lines of code that nothing in the current pipeline called are removed, along with the Go tools only it used (httpx, subfinder, chaos, gospider, hakrawler, katana, gau, waybackurls, ffuf, tlsx, gf, unfurl, dalfox, crlfuzz, s3scanner) and the Python tools it cloned at every start (Sublist3r, OneForAll, EyeWitness, CMSeeK, ctfr, GooFuzz, h8mail). The worker image now builds only nuclei and naabu, next to nmap and bbot, so it builds and starts faster.
• Every CVE match is validated automatically. Before, only fire and smoke matches were queued for AI validation and the rest waited for someone to press Validate now. Now a match of any confidence or score is queued by itself, hottest first (fire, smoke, then ice at the lowest priority, using the capacity the hot ones leave), except one the AI ruled out or the distribution patched. Ice stops at five active jobs per project so it cannot crowd out hot findings, and the daily validation caps still apply. CVENGINE_AUTO_VALIDATE_ALL_MATCHES=0 restores fire and smoke only.
• More nuclei templates run. Installed templates that follow redirects on the same host (host-redirects, at most three hops) now pass the read-only policy, about 1,250 more (6,531 of 13,903 in the current community set, up from 5,280), among them the technology detection template, so hosts get fingerprinted again. A template that merely recognizes an interactsh server by its header is no longer taken for an out-of-band check. Redirects to other hosts stay refused, and AI-written templates still follow none.
• naabu now runs by default. A full port sweep ahead of nmap used to be opt-in; nmap's own top-1,000 guess misses real services often enough (8443, 9200, 27017, and the like) that full coverage up front is worth the extra time for most installs. CVENGINE_NAABU=0 restores the old top-1,000-only behavior for installs scanning many targets on a tight schedule.

Added

• Database metadata and two more exposure checks. nmap now reads MySQL, Microsoft SQL Server, MongoDB, Redis, Memcached, and CouchDB's own pre-authentication greetings for version, role, and, for MySQL and Microsoft SQL Server, the Windows identity their NTLM negotiation discloses, filling in a version or product nmap's own probe missed. Shown on the host page next to each port. Separately, the credential-less exposure check that already covers Redis, Memcached, PostgreSQL, Elasticsearch, and CouchDB now also tries MySQL (root, no password) and MongoDB (listDatabases with no prior authentication): a server that lets either through with nothing at all is a critical finding.
• node2shell (CVE-2026-111497). Checks hosts fingerprinted as Node.js or Express with Assetnote's own read-only detector, no credentials sent and no command executed. Off by default, because its footprint (about 23 MB uploaded per host) is much larger than every other check here; CVENGINE_NODE2SHELL=1 turns it on.
• RDP login-screen screenshots. When nmap shows a server accepts a connection without Network Level Authentication, cvENGINE captures its pre-authentication screen with no credentials sent, stores it, and asks the configured AI model whether an account is already shown signed in and what it is called. A server that requires NLA is never attempted.
• JavaScript libraries and technology columns. The web route check reads jQuery, Bootstrap, AngularJS, React, Vue.js, Lodash, Moment.js, and Underscore.js versions from script names and script banners, and Angular from the page, so old libraries reach CVE matching. Technologies now have version and category columns. The host page shows an overview, a technology table, per-service script output, and what the web archive remembers.
• Deeper service fingerprinting. nmap runs at version intensity 7 with the banner, SSH host key and algorithms, TLS certificate, HTTP header and title, anonymous FTP, RDP NTLM, SMB OS discovery, and NetBIOS scripts, and keeps the output per port. Search reaches it with banner:. Windows build, computer name, and domain from RDP and SMB fill an empty OS guess, and an FTP server that allows anonymous sign-in is a finding with its listing as evidence.
• WPScan for WordPress sites. A host fingerprinted as WordPress is scanned at most once a day (CVENGINE_TTL_WPSCAN=168 for weekly) for its version, plugins, themes, config backups, database exports, and author names, and for known vulnerabilities when a wpscan.com API token is set under Settings, API keys. Findings and versions flow into Findings and CVE matching.
• Archived URLs as passive evidence. The Internet Archive's saved URLs show what a host ran in the past, such as PHP or WordPress. Search finds it and labels it as seen in the web archive.
• Local checks for CVE matches nothing external can settle. When validation finds no read-only check exists for a match, such as a CVE in a specific vendor add-on no banner or template can see, cvENGINE asks the AI once for up to three short, read-only commands a person with shell access could run themselves, with what the output would mean. Shown under Confirm it yourself as a suggestion, never as evidence; the model is told never to suggest a command that changes anything or needs a credential, and to say so when it is not confident of the exact way to detect a product rather than invent one.
• Remediation status on scanner and hygiene findings, and a bulk status route. CVE matches already had open/in_progress/fixed/accepted_risk with a note; scanner and hygiene findings now carry the same fields, set the same way: PATCH projects/{slug}/findings/{match,vulnerability,hygiene}/{id} (update_finding_status) for one finding, POST projects/{slug}/findings/status (bulk_update_finding_status) for up to 200 at once, answering {updated, failed: [{kind, id, error}]} so one bad id never blocks the rest. Marking one of these two statuses drops the finding out of the actionable Findings view immediately, whether or not a later scan still finds it.
• A new install starts loading CVEs by itself. As soon as its workers are up, a once-only bootstrap_first_run task pulls the CVE feed and threat intelligence and backfills recent entries (which in turn correlate and auto-fire), instead of waiting for the first scheduled run, up to 30 minutes for the feed and an hour for threat intelligence. It only acts when the CVE table is empty, so an update or a restart never repeats it, a lock keeps several workers from queuing it twice, and a first try that found no network is retried at the next worker start. A global scan pause does not hold it back.
• The setup wizard has a last, skippable step for search-engine keys. After the first target is added (discovery has already started by then), one page offers Shodan, VirusTotal and SecurityTrails keys next to a live line showing the discovery's progress (queued, running with hosts and IPs found so far, finished), so the first dashboard visit has findings in it. Keys are stored per project, never shown again, and apply from the next scan on. Adding a target twice, or while the scanner is still starting (a clear "try again in a few seconds" instead of an error page), starts discovery without creating a second scan.
• A guide to hosting it online. docs/HOSTING-ONLINE.md covers a public name with a browser-trusted certificate: DNS and firewall, a Let's Encrypt certificate on the bundled proxy (it must be RSA, because the proxy's cipher list is RSA-only) with a renewal hook, running behind Cloudflare with Full (strict), using your own reverse proxy, checks, and a troubleshooting table.
• One command installs it: sudo ./install.sh. It asks nothing and no longer needs .env edited. It checks the machine (root, memory, disk, free ports 443 and 8082, Docker's registry reachable), installs what is missing on Debian and Ubuntu, generates the passwords, detects this machine's address for DOMAIN_NAME (or takes --domain), builds the HTTPS certificate, starts everything, waits until the site answers instead of guessing with a sleep, creates the admin account, and ends with one summary: address, username, generated password, and the certificate note. A failed step prints the log lines of the service that failed. Running it again is safe. The certificate now also covers an IP address as DOMAIN_NAME (before, an IP never matched), plus localhost and 127.0.0.1, and CERT_EXTRA_SANS for more names.
• A new install tells its owner how to sign in. Nothing used to generate or print an admin password: the installer left the owner to invent one at a prompt (or set DJANGO_SUPERUSER_PASSWORD, which the plain prompt then ignored). Now ./scripts/init-env.sh (run by install.sh and by make on first use) creates .env with the database and certificate passwords already generated, and make admin (also the last step of install.sh) creates the admin account, generates a password, and prints it once with the address and username; the owner chooses their own at first sign-in. make admin-password generates a new one for a lost password, and the sign-in page says where to look. A password set in DJANGO_SUPERUSER_PASSWORD is still used (and validated), and nothing is replaced on an install that is already running.
• Scanning pauses for an update's own restart, and Settings, Updates shows live progress. scripts/apply-update.sh now requests a drain pause (new scan dispatch stops; whatever is already running is left to finish, never stopped) before it waits for active scans, and releases it once the run reaches a stable state, whichever commit that ends up being. GET /cve/api/settings/updates reports the current phase (idle, draining...

CVEngine v1.1.1

Changed

• The old reNgine scan engine is retired. Its scan and subscan tasks, the /api/action/initiate/subtask/ endpoint, its extra queues, and about 4,000 lines of code that nothing in the current pipeline called are removed, along with the Go tools only it used (httpx, subfinder, chaos, gospider, hakrawler, katana, gau, waybackurls, ffuf, tlsx, gf, unfurl, dalfox, crlfuzz, s3scanner) and the Python tools it cloned at every start (Sublist3r, OneForAll, EyeWitness, CMSeeK, ctfr, GooFuzz, h8mail). The worker image now builds only nuclei and naabu, next to nmap and bbot, so it builds and starts faster.
• Every CVE match is validated automatically. Before, only fire and smoke matches were queued for AI validation and the rest waited for someone to press Validate now. Now a match of any confidence or score is queued by itself, hottest first (fire, smoke, then ice at the lowest priority, using the capacity the hot ones leave), except one the AI ruled out or the distribution patched. Ice stops at five active jobs per project so it cannot crowd out hot findings, and the daily validation caps still apply. CVENGINE_AUTO_VALIDATE_ALL_MATCHES=0 restores fire and smoke only.
• More nuclei templates run. Installed templates that follow redirects on the same host (host-redirects, at most three hops) now pass the read-only policy, about 1,250 more (6,531 of 13,903 in the current community set, up from 5,280), among them the technology detection template, so hosts get fingerprinted again. A template that merely recognizes an interactsh server by its header is no longer taken for an out-of-band check. Redirects to other hosts stay refused, and AI-written templates still follow none.
• naabu now runs by default. A full port sweep ahead of nmap used to be opt-in; nmap's own top-1,000 guess misses real services often enough (8443, 9200, 27017, and the like) that full coverage up front is worth the extra time for most installs. CVENGINE_NAABU=0 restores the old top-1,000-only behavior for installs scanning many targets on a tight schedule.

Added

• Database metadata and two more exposure checks. nmap now reads MySQL, Microsoft SQL Server, MongoDB, Redis, Memcached, and CouchDB's own pre-authentication greetings for version, role, and, for MySQL and Microsoft SQL Server, the Windows identity their NTLM negotiation discloses, filling in a version or product nmap's own probe missed. Shown on the host page next to each port. Separately, the credential-less exposure check that already covers Redis, Memcached, PostgreSQL, Elasticsearch, and CouchDB now also tries MySQL (root, no password) and MongoDB (listDatabases with no prior authentication): a server that lets either through with nothing at all is a critical finding.
• node2shell (CVE-2026-111497). Checks hosts fingerprinted as Node.js or Express with Assetnote's own read-only detector, no credentials sent and no command executed. Off by default, because its footprint (about 23 MB uploaded per host) is much larger than every other check here; CVENGINE_NODE2SHELL=1 turns it on.
• RDP login-screen screenshots. When nmap shows a server accepts a connection without Network Level Authentication, cvENGINE captures its pre-authentication screen with no credentials sent, stores it, and asks the configured AI model whether an account is already shown signed in and what it is called. A server that requires NLA is never attempted.
• JavaScript libraries and technology columns. The web route check reads jQuery, Bootstrap, AngularJS, React, Vue.js, Lodash, Moment.js, and Underscore.js versions from script names and script banners, and Angular from the page, so old libraries reach CVE matching. Technologies now have version and category columns. The host page shows an overview, a technology table, per-service script output, and what the web archive remembers.
• Deeper service fingerprinting. nmap runs at version intensity 7 with the banner, SSH host key and algorithms, TLS certificate, HTTP header and title, anonymous FTP, RDP NTLM, SMB OS discovery, and NetBIOS scripts, and keeps the output per port. Search reaches it with banner:. Windows build, computer name, and domain from RDP and SMB fill an empty OS guess, and an FTP server that allows anonymous sign-in is a finding with its listing as evidence.
• WPScan for WordPress sites. A host fingerprinted as WordPress is scanned at most once a day (CVENGINE_TTL_WPSCAN=168 for weekly) for its version, plugins, themes, config backups, database exports, and author names, and for known vulnerabilities when a wpscan.com API token is set under Settings, API keys. Findings and versions flow into Findings and CVE matching.
• Archived URLs as passive evidence. The Internet Archive's saved URLs show what a host ran in the past, such as PHP or WordPress. Search finds it and labels it as seen in the web archive.
• Local checks for CVE matches nothing external can settle. When validation finds no read-only check exists for a match, such as a CVE in a specific vendor add-on no banner or template can see, cvENGINE asks the AI once for up to three short, read-only commands a person with shell access could run themselves, with what the output would mean. Shown under Confirm it yourself as a suggestion, never as evidence; the model is told never to suggest a command that changes anything or needs a credential, and to say so when it is not confident of the exact way to detect a product rather than invent one.
• Remediation status on scanner and hygiene findings, and a bulk status route. CVE matches already had open/in_progress/fixed/accepted_risk with a note; scanner and hygiene findings now carry the same fields, set the same way: PATCH projects/{slug}/findings/{match,vulnerability,hygiene}/{id} (update_finding_status) for one finding, POST projects/{slug}/findings/status (bulk_update_finding_status) for up to 200 at once, answering {updated, failed: [{kind, id, error}]} so one bad id never blocks the rest. Marking one of these two statuses drops the finding out of the actionable Findings view immediately, whether or not a later scan still finds it.
• A new install starts loading CVEs by itself. As soon as its workers are up, a once-only bootstrap_first_run task pulls the CVE feed and threat intelligence and backfills recent entries (which in turn correlate and auto-fire), instead of waiting for the first scheduled run, up to 30 minutes for the feed and an hour for threat intelligence. It only acts when the CVE table is empty, so an update or a restart never repeats it, a lock keeps several workers from queuing it twice, and a first try that found no network is retried at the next worker start. A global scan pause does not hold it back.
• The setup wizard has a last, skippable step for search-engine keys. After the first target is added (discovery has already started by then), one page offers Shodan, VirusTotal and SecurityTrails keys next to a live line showing the discovery's progress (queued, running with hosts and IPs found so far, finished), so the first dashboard visit has findings in it. Keys are stored per project, never shown again, and apply from the next scan on. Adding a target twice, or while the scanner is still starting (a clear "try again in a few seconds" instead of an error page), starts discovery without creating a second scan.
• A guide to hosting it online. docs/HOSTING-ONLINE.md covers a public name with a browser-trusted certificate: DNS and firewall, a Let's Encrypt certificate on the bundled proxy (it must be RSA, because the proxy's cipher list is RSA-only) with a renewal hook, running behind Cloudflare with Full (strict), using your own reverse proxy, checks, and a troubleshooting table.
• One command installs it: sudo ./install.sh. It asks nothing and no longer needs .env edited. It checks the machine (root, memory, disk, free ports 443 and 8082, Docker's registry reachable), installs what is missing on Debian and Ubuntu, generates the passwords, detects this machine's address for DOMAIN_NAME (or takes --domain), builds the HTTPS certificate, starts everything, waits until the site answers instead of guessing with a sleep, creates the admin account, and ends with one summary: address, username, generated password, and the certificate note. A failed step prints the log lines of the service that failed. Running it again is safe. The certificate now also covers an IP address as DOMAIN_NAME (before, an IP never matched), plus localhost and 127.0.0.1, and CERT_EXTRA_SANS for more names.
• A new install tells its owner how to sign in. Nothing used to generate or print an admin password: the installer left the owner to invent one at a prompt (or set DJANGO_SUPERUSER_PASSWORD, which the plain prompt then ignored). Now ./scripts/init-env.sh (run by install.sh and by make on first use) creates .env with the database and certificate passwords already generated, and make admin (also the last step of install.sh) creates the admin account, generates a password, and prints it once with the address and username; the owner chooses their own at first sign-in. make admin-password generates a new one for a lost password, and the sign-in page says where to look. A password set in DJANGO_SUPERUSER_PASSWORD is still used (and validated), and nothing is replaced on an install that is already running.
• Scanning pauses for an update's own restart, and Settings, Updates shows live progress. scripts/apply-update.sh now requests a drain pause (new scan dispatch stops; whatever is already running is left to finish, never stopped) before it waits for active scans, and releases it once the run reaches a stable state, whichever commit that ends up being. GET /cve/api/settings/updates reports the current phase (idle, draining...

CVE catalog seed

The pre-processed CVE catalog new installs load on first start. Replaced by scripts/publish-cve-seed.sh; not a software release.

CVEngine v1.1

Changed

• The old reNgine scan engine is retired. Its scan and subscan tasks, the /api/action/initiate/subtask/ endpoint, its extra queues, and about 4,000 lines of code that nothing in the current pipeline called are removed, along with the Go tools only it used (httpx, subfinder, chaos, gospider, hakrawler, katana, gau, waybackurls, ffuf, tlsx, gf, unfurl, dalfox, crlfuzz, s3scanner) and the Python tools it cloned at every start (Sublist3r, OneForAll, EyeWitness, CMSeeK, ctfr, GooFuzz, h8mail). The worker image now builds only nuclei and naabu, next to nmap and bbot, so it builds and starts faster.
• Every CVE match is validated automatically. Before, only fire and smoke matches were queued for AI validation and the rest waited for someone to press Validate now. Now a match of any confidence or score is queued by itself, hottest first (fire, smoke, then ice at the lowest priority, using the capacity the hot ones leave), except one the AI ruled out or the distribution patched. Ice stops at five active jobs per project so it cannot crowd out hot findings, and the daily validation caps still apply. CVENGINE_AUTO_VALIDATE_ALL_MATCHES=0 restores fire and smoke only.
• More nuclei templates run. Installed templates that follow redirects on the same host (host-redirects, at most three hops) now pass the read-only policy, about 1,250 more (6,531 of 13,903 in the current community set, up from 5,280), among them the technology detection template, so hosts get fingerprinted again. A template that merely recognizes an interactsh server by its header is no longer taken for an out-of-band check. Redirects to other hosts stay refused, and AI-written templates still follow none.
• naabu now runs by default. A full port sweep ahead of nmap used to be opt-in; nmap's own top-1,000 guess misses real services often enough (8443, 9200, 27017, and the like) that full coverage up front is worth the extra time for most installs. CVENGINE_NAABU=0 restores the old top-1,000-only behavior for installs scanning many targets on a tight schedule.

Added

• Database metadata and two more exposure checks. nmap now reads MySQL, Microsoft SQL Server, MongoDB, Redis, Memcached, and CouchDB's own pre-authentication greetings for version, role, and, for MySQL and Microsoft SQL Server, the Windows identity their NTLM negotiation discloses, filling in a version or product nmap's own probe missed. Shown on the host page next to each port. Separately, the credential-less exposure check that already covers Redis, Memcached, PostgreSQL, Elasticsearch, and CouchDB now also tries MySQL (root, no password) and MongoDB (listDatabases with no prior authentication): a server that lets either through with nothing at all is a critical finding.
• node2shell (CVE-2026-111497). Checks hosts fingerprinted as Node.js or Express with Assetnote's own read-only detector, no credentials sent and no command executed. Off by default, because its footprint (about 23 MB uploaded per host) is much larger than every other check here; CVENGINE_NODE2SHELL=1 turns it on.
• RDP login-screen screenshots. When nmap shows a server accepts a connection without Network Level Authentication, cvENGINE captures its pre-authentication screen with no credentials sent, stores it, and asks the configured AI model whether an account is already shown signed in and what it is called. A server that requires NLA is never attempted.
• JavaScript libraries and technology columns. The web route check reads jQuery, Bootstrap, AngularJS, React, Vue.js, Lodash, Moment.js, and Underscore.js versions from script names and script banners, and Angular from the page, so old libraries reach CVE matching. Technologies now have version and category columns. The host page shows an overview, a technology table, per-service script output, and what the web archive remembers.
• Deeper service fingerprinting. nmap runs at version intensity 7 with the banner, SSH host key and algorithms, TLS certificate, HTTP header and title, anonymous FTP, RDP NTLM, SMB OS discovery, and NetBIOS scripts, and keeps the output per port. Search reaches it with banner:. Windows build, computer name, and domain from RDP and SMB fill an empty OS guess, and an FTP server that allows anonymous sign-in is a finding with its listing as evidence.
• WPScan for WordPress sites. A host fingerprinted as WordPress is scanned at most once a day (CVENGINE_TTL_WPSCAN=168 for weekly) for its version, plugins, themes, config backups, database exports, and author names, and for known vulnerabilities when a wpscan.com API token is set under Settings, API keys. Findings and versions flow into Findings and CVE matching.
• Archived URLs as passive evidence. The Internet Archive's saved URLs show what a host ran in the past, such as PHP or WordPress. Search finds it and labels it as seen in the web archive.
• Local checks for CVE matches nothing external can settle. When validation finds no read-only check exists for a match, such as a CVE in a specific vendor add-on no banner or template can see, cvENGINE asks the AI once for up to three short, read-only commands a person with shell access could run themselves, with what the output would mean. Shown under Confirm it yourself as a suggestion, never as evidence; the model is told never to suggest a command that changes anything or needs a credential, and to say so when it is not confident of the exact way to detect a product rather than invent one.
• Remediation status on scanner and hygiene findings, and a bulk status route. CVE matches already had open/in_progress/fixed/accepted_risk with a note; scanner and hygiene findings now carry the same fields, set the same way: PATCH projects/{slug}/findings/{match,vulnerability,hygiene}/{id} (update_finding_status) for one finding, POST projects/{slug}/findings/status (bulk_update_finding_status) for up to 200 at once, answering {updated, failed: [{kind, id, error}]} so one bad id never blocks the rest. Marking one of these two statuses drops the finding out of the actionable Findings view immediately, whether or not a later scan still finds it.
• A new install starts loading CVEs by itself. As soon as its workers are up, a once-only bootstrap_first_run task pulls the CVE feed and threat intelligence and backfills recent entries (which in turn correlate and auto-fire), instead of waiting for the first scheduled run, up to 30 minutes for the feed and an hour for threat intelligence. It only acts when the CVE table is empty, so an update or a restart never repeats it, a lock keeps several workers from queuing it twice, and a first try that found no network is retried at the next worker start. A global scan pause does not hold it back.
• The setup wizard has a last, skippable step for search-engine keys. After the first target is added (discovery has already started by then), one page offers Shodan, VirusTotal and SecurityTrails keys next to a live line showing the discovery's progress (queued, running with hosts and IPs found so far, finished), so the first dashboard visit has findings in it. Keys are stored per project, never shown again, and apply from the next scan on. Adding a target twice, or while the scanner is still starting (a clear "try again in a few seconds" instead of an error page), starts discovery without creating a second scan.
• A guide to hosting it online. docs/HOSTING-ONLINE.md covers a public name with a browser-trusted certificate: DNS and firewall, a Let's Encrypt certificate on the bundled proxy (it must be RSA, because the proxy's cipher list is RSA-only) with a renewal hook, running behind Cloudflare with Full (strict), using your own reverse proxy, checks, and a troubleshooting table.
• One command installs it: sudo ./install.sh. It asks nothing and no longer needs .env edited. It checks the machine (root, memory, disk, free ports 443 and 8082, Docker's registry reachable), installs what is missing on Debian and Ubuntu, generates the passwords, detects this machine's address for DOMAIN_NAME (or takes --domain), builds the HTTPS certificate, starts everything, waits until the site answers instead of guessing with a sleep, creates the admin account, and ends with one summary: address, username, generated password, and the certificate note. A failed step prints the log lines of the service that failed. Running it again is safe. The certificate now also covers an IP address as DOMAIN_NAME (before, an IP never matched), plus localhost and 127.0.0.1, and CERT_EXTRA_SANS for more names.
• A new install tells its owner how to sign in. Nothing used to generate or print an admin password: the installer left the owner to invent one at a prompt (or set DJANGO_SUPERUSER_PASSWORD, which the plain prompt then ignored). Now ./scripts/init-env.sh (run by install.sh and by make on first use) creates .env with the database and certificate passwords already generated, and make admin (also the last step of install.sh) creates the admin account, generates a password, and prints it once with the address and username; the owner chooses their own at first sign-in. make admin-password generates a new one for a lost password, and the sign-in page says where to look. A password set in DJANGO_SUPERUSER_PASSWORD is still used (and validated), and nothing is replaced on an install that is already running.
• Scanning pauses for an update's own restart, and Settings, Updates shows live progress. scripts/apply-update.sh now requests a drain pause (new scan dispatch stops; whatever is already running is left to finish, never stopped) before it waits for active scans, and releases it once the run reaches a stable state, whichever commit that ends up being. GET /cve/api/settings/updates reports the current phase (idle, draining, ...

CVEngine v1.0.1

The most advanced external attack surface assessment you can get for free. cvENGINE continuously discovers your internet-facing assets, fingerprints their services, and tells you which of today's CVEs are actually exploitable on them, with evidence.

Highlights

• Continuous discovery. Subdomains, certificates, IPs, and open ports with bbot, scheduled re-discovery, and a change log.
• Service and OS fingerprinting. One host inventory built from nmap, optional naabu, and bbot.
• Fire, smoke, and ice. Every CVE rated by real-world exploitation from CISA KEV, ENISA EUVD, VulnCheck KEV, EPSS, Exploit-DB, and Metasploit, so hosts are matched against historically exploited CVEs, not just the last two weeks.
• Evidence-based validation. Each finding is reproduced with a read-only check (a vetted nuclei template, nmap, an HTTP probe, or a database banner). The AI triages it and drafts a template when none exists; a person reviews drafts before they run.
• One findings view. CVE matches, scanner findings, and email and DNS hygiene together, hottest first.
• Exposure checks. Unauthenticated Redis, PostgreSQL, Elasticsearch, Memcached, and CouchDB, plus a full email-security review (SPF, DKIM, DMARC, MTA-STS, and more).
• Bug bounty workbench. Public program scope, a vulnerability rating per finding, and report drafts (BUG-BOUNTY.md).
• Built for teams and agents. Organizations and projects with data isolation and roles, a REST API and an MCP server, and Shodan-style host search.
• Operations. A pause-all control, scheduler and worker health, an activity and AI-cost log, two-step sign-in, an IP allowlist, an audit log, and automatic deployment of new releases.

Platform

Python 3.14, Django 5.2 LTS, PostgreSQL 18, nmap 7.992, Go 1.27, and Ubuntu 26.04 LTS. GPL-3.0. See docs/, and docs/UPGRADE.md to move an older install.

Security

Hardened against prompt injection and server-side request forgery, with tenant-isolated media, encrypted secrets, bounded scan and probe time, and a static safety gate on AI-generated templates.

v1.0.1

A security patch. Update with make up or the in-app updater.

• Security: two-step sign-in could be skipped at /admin/login/. That URL now only forwards to /login/, which enforces the second step.
• AI-written templates are kept across updates. They now live on a Docker volume, and a worker restores any validated template whose file is missing.
• scripts/uninstall.sh removes only this install, not another reNgine on the same host.
• Proxy docs: CVENGINE_TRUSTED_PROXIES should be left at its default or added to, never replaced.

CVEngine v1.0

CVEngine is an AI-first external attack surface scanner: it continuously
discovers your internet-facing assets, fingerprints their services, and tells
you which of today's CVEs are actually exploitable on them, and provides evidence.

Highlights

• Continuous attack surface discovery subdomains, certificates, IPs and open ports, with scheduled re-discovery and change tracking.
• Service and OS fingerprinting shodan-style host inventory built from nmap, naabu and bbot.
• Exploitability-ranked CVEs (fire / smoke / ice) every CVE scored by real-world exploitation, fed by CISA KEV, ENISA EUVD, EPSS, Exploit-DB and Metasploit so hosts are matched against historically exploited CVEs, not just
  the last two weeks.
• Evidence-based validation each finding is reproduced with a read-only check (a vetted nuclei template, nmap, an HTTP probe, a database banner); the AI triages it and drafts a template when none exists to reduce false positives.
• One findings view CVE matches, scanner findings and email/DNS hygiene together, hottest first.
• Exposure checks unauthenticated Redis, PostgreSQL, Elasticsearch, Memcached and CouchDB, plus a full MailFail email-security review (SPF, DKIM, DMARC, MTA-STS and more).
• Built for teams and agents organizations and projects with data isolation and roles, a REST API and an MCP server, and Shodan-style host search.
• Operations pause-all control, scheduler and worker health, an activity and AI-cost log, two-step sign-in, an IP allowlist and an audit log.

Platform

Python 3.14, Django 5.2 LTS, PostgreSQL 18, nmap 7.9, Go 1.27 and Ubuntu 26.04 LTS. GPL-3.0; a fork of reNgine 2.x. See docs/, and docs/UPGRADE.md to move an older install.

Security

Hardened against prompt injection and server-side request forgery, with tenant-isolated media, encrypted secrets, bounded scan and probe time, and a static safety gate on AI-generated templates.