Vexta's Script Engine: 26 Bundled Checks Without an Nmap Dependency

Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and its script engine is the part that turns an open port into a specific, checked finding rather than just a number on a list. After the port scan finishes, Vexta fans out a built-in scripting engine across every open port, running 26 bundled checks as pure Go code inside the same binary, with no external nmap install required. The engine's category names and filter syntax follow the same conventions bug hunters already know from the Nmap Scripting Engine (NSE), so there is nothing new to learn before you can start scoping a scan down to exactly the checks you want.

How does the script engine fit into a Vexta scan?

Every Vexta scan runs a port scan first. Once open ports are mapped, the script engine fans out across each one and runs the checks that apply to that port and service. Each script carries its own timeout, and the engine runs scripts with bounded concurrency, so a single hung check on one host does not stall the rest of the scan.

Progress streams back through an OnProgress hook, which is what feeds the live updates in the Vexta dashboard while a scan runs: which host, which port, which check is executing right now. On a scan against a large scope, that visibility is the difference between watching a spinner for twenty minutes and knowing exactly which of forty hosts the engine is currently sitting on.

Which categories and checks does the engine cover?

Vexta groups its scripts into ten categories: safe, default, discovery, version, vuln, auth, brute, intrusive, exploit, and external. A filter language lets you combine those the same way NSE hunters already do, expressions like safe and default, vuln, or not intrusive scope a run to exactly the checks that fit an engagement's rules. On an authorized test where the client has asked for a quiet footprint, running vuln and not intrusive keeps a scan inside detection and version checks without touching anything that could disrupt a service. An args namespace, the equivalent of NSE's script-args, and a shared State object across scripts in one run let checks pass data to each other instead of rediscovering the same thing twice.

The 26 bundled scripts span discovery and vulnerability detection. On the discovery side, banner does a generic TCP banner grab, http-enum walks a curated 40-path list of admin, config and.git paths, http-headers inventories security headers, http-methods probes every HTTP method plus OPTIONS, http-robots parses robots.txt, and http-title pulls page titles and tech hints. ftp-anon tests for anonymous FTP login. smb-os-discovery reports SMB OS and domain, nbstat covers NetBIOS name-service status, and ssh-hostkey and ssh-auth-methods report host key fingerprints and OpenSSH version, flagging outdated builds. ssl-cert and ssl-enum-ciphers cover TLS leaf-certificate summary and per-protocol cipher inventory. Protocol info scripts round out the set for mssql-info, mysql-info, redis-info, mongodb-info, snmp-info, smtp-commands, pop3-capabilities, imap-capabilities, ntp-info and vnc-info, most of which double as auth checks by testing whether the service is reachable without credentials at all.

None of that requires touching a config file to enable. The engine ships with all 26 scripts built in, and the filter expression on a scan decides which of them actually run against a given target.

What does this look like on an authorized engagement?

Say a scope includes a mixed estate: a handful of web servers, a mail relay, and some internal-facing management ports the client flagged as in scope but sensitive. A hunter can start wide, safe and default, to get banner grabs, TLS summaries and version reporting across everything with negligible risk of side effects, then narrow to vuln and not intrusive once the asset list looks right, picking up checks like http-log4shell, ssl-heartbleed and dns-recursion without running anything in the brute or exploit categories that the engagement's rules of engagement do not cover.

Because the same shared State carries data between scripts in one run, a version fact picked up by one check, an OpenSSH build number, a TLS certificate's expiry, is available to the checks that run after it on that host without a second round trip. That is a small detail, but on a large scope it adds up to a scan that finishes with fewer redundant requests against the same target.

Which of these checks catch known CVEs?

A subset of the bundled scripts are tagged vuln category and mapped to a specific, named CVE, so a hit is not just a description, it is a reference a client can look up on their own.

What happens after a script check finds something?

Vuln-severity script output does not just sit in a log. Vexta promotes it to a first-class finding, tags it nse followed by the script name so you can trace it back to exactly which check fired, and decorates it with the relevant CVE where one applies. That finding then goes through the same pipeline as every other Vexta finding, including a place in the Vexta Confidence Score, which weighs severity, detector confidence, proof status, reachability, and public exploitation signals such as EPSS, the exploit-probability score published by FIRST, and CISA's Known Exploited Vulnerabilities list.

Every host also gets its own script_results.json file inside the scan folder, so if you need to hand a client raw evidence for a specific check, banner text, CVE reference, and timestamp included, it is already sitting there rather than something you have to reconstruct from a terminal scrollback. Which categories a given license can run follows the same pattern as the rest of Vexta: same binary, features by license. Check the pricing page for what is included at each tier.

Key takeaways