Wordlist Management in Vexta: Custom Lists for Recon

Vexta's wordlist management feature lets a hunter upload, edit, and select custom subdomain, directory, and parameter wordlists before a scan runs, instead of relying only on the lists that ship in the binary. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and the wordlist manager sits on its own dashboard page at /wordlists, where lists are uploaded, edited in place, and selected per scan.

Where does wordlist management live in Vexta?

The wordlist manager sits on its own page in the Vexta dashboard at /wordlists. It handles three list types: subdomain wordlists, directory wordlists, and parameter wordlists, the three inputs that drive most active discovery work during a scan.

A hunter uploads a list, and it becomes available the next time they configure a scan. There is no separate config file to hand-edit and no restart required to pick it up.

Why bring your own wordlist to an engagement?

General-purpose wordlists are a reasonable default, but they miss the naming patterns specific to one organization. A bank's internal apps might follow a pattern like corp-, vpn-, or a regional code baked into every subdomain; a SaaS company might expose staging environments under a completely different scheme. A hunter who has already mapped that pattern from OSINT, a client-provided asset list, or a previous engagement gets more value out of active discovery by feeding it back in as a custom subdomain or directory list.

The same logic applies to parameters. If a JavaScript bundle or an API spec references parameter names like acct_id or region_code that a generic list would never guess, adding them to a parameter wordlist means the next fuzzing pass actually tests them.

Directory wordlists follow the same idea. A content management system or an internal admin panel often lives under a predictable but non-default path, /manage, /portal-internal, /staging-api, that a hunter learns about from a previous assessment, a changelog, or a support forum post. Feeding that into a directory wordlist means the next scan checks for it directly instead of relying on defaults that were never going to catch it.

Editing a list without leaving the dashboard

Because lists can be edited in place, a hunter does not have to delete and re-upload a file every time they spot one more subdomain candidate or parameter name worth testing. Add the line, save, and it is ready for the next scan that selects that list.

That matters most mid-engagement, when new information shows up constantly: a leaked internal hostname in a certificate transparency log, a parameter name pulled from a minified JS file, a directory referenced in a robots.txt disallow line. Each one is a one-line addition instead of a new file to manage.

This also matters for team hand-offs. If one hunter on an engagement adds a wordlist entry after finding something interesting in a JS bundle, a teammate picking up the same target the next day is scanning against the same, updated list instead of working from whatever was there at the start of the week.

How custom wordlists fit into Vexta's recon pass

Vexta's recon draws on 40+ passive sources plus active discovery, and active discovery is exactly where a selected wordlist gets used: brute-forcing subdomains, walking directories, and fuzzing parameters against the list a hunter picked for that target. WAF-aware throttling (pacing requests so they don't look like a flood to a web application firewall) keeps that active pass quiet, which matters more, not less, once a hunter starts pointing a large custom list at a target sitting behind one.

Because list selection happens per scan rather than globally, a hunter running scans across several clients in the same day can keep each engagement's list separate: one target's internal naming convention never bleeds into another's results.

That also means a wordlist built for one client doesn't quietly leak into a different scope. A hunter juggling three retainer clients in the same week can keep three distinct subdomain lists, each shaped by that client's own naming habits, and pick the right one at scan setup instead of running everyone through a single, diluted master list.

Wordlist management isn't called out against one specific license tier in Vexta's public feature list; check the pricing page for what your plan includes before you build out a big library of client-specific lists.

Building a starter list from real reconnaissance

In practice, a custom wordlist rarely starts from nothing. It grows out of whatever a hunter already turned up before the scan: certificate transparency logs that reveal a naming pattern across a company's subdomains, a careers page that mentions an internal tool by name, an archived changelog that references a staging environment, or a client-supplied asset inventory that lists hostnames the public internet has never indexed. Each of those becomes a line in a subdomain or directory wordlist rather than a fact that lives only in a notebook.

The parameter side works the same way. Reading through a target's JavaScript for API calls, or reviewing an OpenAPI spec a client hands over as part of scope, turns up parameter names a stock list was never going to include. Once those names are in a parameter wordlist and selected for the scan, fuzzing has something specific to test instead of guessing from a generic dictionary.

None of this requires touching the scanner's configuration directly. The list lives in the dashboard, gets picked from a dropdown or similar selector when the scan is set up, and is available for the next engagement on the same target without anyone needing to remember where a file was saved.