Feeding a version string to an LLM and asking it to "find CVEs" produces a convincing but fabricated report. The model doesn't know your target, can't see the actual service banner, and will happily invent a vulnerability that doesn't exist. The right model is different: the LLM is an analyst that reads raw scanner output, builds a test plan from OWASP Top 10, writes payload hypotheses for manual verification, and drafts a report with reproducible steps. This playbook gives you concrete prompts for each stage — scoping, parsing nmap/nikto, generating IDOR/SQLi/XSS/SSRF hypotheses, reading HTTP history, threat modeling, and writing a CVSS-backed report. Use them as a DevSecOps workflow, not as a replacement for Burp Suite or manual testing.
Why "find CVEs" prompts fail (and what to do instead)
LLMs are pattern-completion engines. Given a service name and version, they will generate a plausible CVE ID, a plausible CVSS score, and a plausible exploit description — none of which may correspond to reality. The failure mode is subtle: the output looks like a pentest report, so it gets past a quick review and into a ticket.
The correct mental model: the LLM is a senior analyst who reads your raw data and writes the next action. It doesn't know the target; you supply the evidence (nmap XML, HTTP history, source snippets) and ask for structured reasoning. Every claim must be traceable to a line in the input.
Before you start, set the ground rules. The model must never invent CVE IDs, must cite the exact input line for every finding, and must mark anything speculative as "hypothesis — needs verification." Without these constraints, you get fiction.
Stage 1: Scope, rules of engagement, and the anti-hallucination contract
Every engagement starts with scope. The prompt below forces the model to treat the scope as a hard boundary and to refuse out-of-scope analysis. It also encodes the anti-hallucination contract.
Prompt:
You are a senior penetration tester. I will give you raw scan output and HTTP traffic from an authorized test. Your job is analysis, not guessing.
Rules:
1. Never invent CVE IDs, CVSS scores, or exploit names. If you are not certain a CVE applies to the exact version and configuration shown, write "no confirmed CVE — manual verification required."
2. For every finding, cite the exact input line or request ID that supports it.
3. Separate facts (observed in input) from hypotheses (to be tested manually).
4. Map every hypothesis to an OWASP Top 10 category.
5. If input is insufficient, ask for the specific missing artifact instead of assuming.
Scope: [DOMAIN/IP RANGE]. Out of scope: [LIST]. Test window: [DATES].
Acknowledge the rules and wait for input.
Usage example: you paste the scope, the model replies "Rules acknowledged. Send nmap XML or HTTP history." Only then do you feed data. This two-step handshake prevents the model from front-running with assumptions.
Trade-off: the contract costs one extra turn per session, but it eliminates the most common failure — a confident CVE that doesn't exist. In a real engagement, one fabricated finding can burn hours of verification and damage trust with the client.
Stage 2: Parsing nmap and nikto without hallucinating services
nmap XML is verbose. The model is good at summarizing it, but only if you force it to quote the raw evidence. Ask for a table with one row per open port, and require the exact <service> attributes.
Prompt:
Here is nmap XML output. Build a table with columns: host, port, protocol, state, service, version, product, extra info. Quote the exact XML attributes for each row. Do not add services that are not in the XML. Then list services where the version string is ambiguous or missing — those need manual banner grabbing.
After the table, for each service, state whether a known CVE can be confirmed from the version alone. If not, say so explicitly.
<nmap XML>
Usage example: a scan shows 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.4. The model should not claim a specific CVE unless the version mapping is unambiguous. Instead it flags "OpenSSH 8.9p1 — check Ubuntu security notices for the exact patch level; version alone is insufficient." That is the correct answer.
nmap -sV -oX scan.xml and feed the XML, not the console output. The XML preserves service fingerprints and script output that the console truncates. The model can then cite exact attributes.
A common mistake is to paste only the open-port list. Without service versions and script output, the model has nothing to reason about and will fill the gap with guesses. Always include <script> output from --script runs — that's where the real evidence lives.
Stage 3: Turning OWASP Top 10 into a test plan
The OWASP Top 10 is a categorization, not a checklist. The model's job is to convert it into concrete tests for your specific stack. Give it the tech stack and the observed endpoints, and ask for a prioritized plan.
Prompt:
Given this tech stack [e.g., Node.js/Express, PostgreSQL, React SPA, JWT auth] and these observed endpoints [list], produce a test plan mapped to OWASP Top 10 (2021). For each category that applies, list: the specific endpoint or parameter to test, the test technique, the expected evidence of a finding, and the tool (Burp Suite Repeater, sqlmap, manual). Prioritize by likelihood given the stack. Skip categories that clearly do not apply and say why.
Usage example: for a JWT-based API, the model should prioritize A01 (Broken Access Control — IDOR on object IDs), A03 (Injection — SQLi in search/filter params), and A07 (Identification and Authentication Failures — JWT alg confusion, weak secrets). It should deprioritize A05 (Security Misconfiguration) only if you've already confirmed headers and TLS.
| OWASP category | Typical test | Evidence to capture |
|---|---|---|
| A01 Broken Access Control | Change object ID in request | 200 with another user's data |
| A03 Injection | ' OR 1=1-- in filter param |
SQL error or boolean difference |
| A07 Auth Failures | JWT alg:none or weak secret |
Token accepted without signature |
| A10 SSRF | URL param pointing to internal IP | Response from internal service |
This table is a starting point — the model should expand it with your specific endpoints, not just repeat generic examples.
Stage 4: Payload hypotheses for IDOR, SQLi, XSS, SSRF
This is where the model earns its keep. Ask for payload variants with a rationale, not a fuzzing list. The goal is a handful of high-signal tests you will run manually in Burp Suite.
Prompt:
For the endpoint [METHOD /path?param=value], generate 5 payload hypotheses for [IDOR
| SQLi | XSS | SSRF]. For each: the exact payload, where to place it (query, body, header, cookie), what a positive result looks like, and what a false positive looks like. Do not generate payloads for categories that don't fit the parameter type. Mark destructive payloads (DROP, DELETE, sleep-based blind) and suggest a safe alternative first.
Usage example — IDOR: the model suggests replacing a numeric user_id=1042 with 1041, 1043, and a UUID if the app uses them, and checking whether the response differs. It should also suggest testing user_id[]=1042 for array-parameter bypasses. That last variant is the non-obvious insight: many frameworks treat array params differently in authorization checks.
Usage example — SSRF: for a url= parameter, the model proposes http://127.0.0.1:80, http://169.254.169.254/latest/meta-data/ (cloud metadata), and a DNS-rebinding hostname. It should mark the metadata endpoint as high-impact and suggest testing it only after confirming the app fetches external URLs.
Stage 5: Reading HTTP history like an analyst
Burp Suite's HTTP history is the richest evidence you have. The model can scan it for patterns: missing auth headers, reflected parameters, inconsistent status codes, and parameter pollution. But it needs structured input — export as HAR or a filtered request list.
Prompt:
Here is a HAR export of 40 requests from an authenticated session. Identify: (1) endpoints that return 200 but should require auth — check for missing Authorization headers; (2) parameters reflected in the response body without encoding; (3) requests where the same parameter appears twice (HTTP parameter pollution); (4) responses with verbose error messages or stack traces. For each, cite the request URL and the evidence line. Do not speculate beyond the data.
Usage example: the model flags GET /api/v1/users/1042/profile returning 200 with a Set-Cookie for a different user — a potential session fixation or IDOR. It cites the exact request and response headers. You then reproduce in Repeater.
A real trade-off: HAR files are large and can exceed context limits. Filter to the endpoints you care about (auth, admin, file upload) before feeding. The model's accuracy drops sharply when the input is diluted with hundreds of static asset requests.
Stage 6: Threat model in 20 minutes, not two days
A lightweight threat model up front saves hours of blind testing. The model can draft it from the architecture description and the scan data.
Prompt:
Based on this architecture [describe: components, data flows, trust boundaries] and these scan findings [paste summary], draft a threat model. For each trust boundary, list: assets, threat actors, likely attack paths, and the OWASP Top 10 categories involved. Rank attack paths by ease of exploitation and impact. Keep it to one page — this is a working document, not a compliance artifact.
Usage example: for a React SPA + API + PostgreSQL setup, the model identifies the browser-to-API boundary as the highest-risk path (token theft, CSRF, IDOR) and the API-to-DB boundary as lower-risk if the ORM is used consistently. It flags the admin panel as a separate boundary needing its own auth review.
This is where the model adds value a scanner cannot: it reasons about trust boundaries, not just ports. A scanner sees an open 443; the model sees that the admin panel shares a cookie domain with the public app — a session-scoping risk worth testing.
Stage 7: The report — CVSS, reproducible steps, and fix recommendations
The final stage is the deliverable. The model drafts it, but every finding must trace back to evidence you captured. Require CVSS vectors with justification and fix recommendations that a developer can act on.
Prompt:
Draft a penetration test report from these verified findings [paste finding list with evidence]. For each finding: title, OWASP category, CVSS v3.1 vector with a one-line justification for each metric, reproduction steps (numbered, with exact requests), impact in business terms, and a fix recommendation with a code-level example where possible. Do not include findings that are not in the verified list. Mark severity as Critical/High/Medium/Low per CVSS.
Usage example: an IDOR finding gets CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (7.1 High) with the justification "authenticated low-privilege user can read any user's profile by changing the ID." The fix recommendation includes a code snippet showing a server-side ownership check before returning the record.
For teams wiring this into a pipeline, the report stage is where the LLM fits naturally into CI/CD — see CI/CD as an Art: A Real Pipeline Breakdown and Costly Mistakes for how to gate merges on security findings without blocking every build.
Putting it together: a workflow, not a magic prompt
The prompts above form a loop: scope → parse scans → plan tests → generate hypotheses → read traffic → threat model → report. Each stage feeds the next, and each stage has a verification step where a human confirms the model's output against the raw data.
The non-obvious insight: the model's value is inversely proportional to how much you ask it to guess. Give it raw evidence and it behaves like a senior analyst. Ask it to "find CVEs" and it behaves like a confident intern. The difference is entirely in the input.
If you want to go deeper on the vulnerability classes behind these prompts, our Web Security (OWASP Top 10) course walks through real injection cases and the fixes. And if you're building a DevSecOps pipeline around this workflow, start with the scoping prompt and the anti-hallucination contract — they are the foundation everything else stands on.
Stop asking the model what it thinks. Show it what you see, and ask what to test next.