R·D Intel

I Built an AI That Hacks Itself — And It Found 3 Real CVEs in 20 Minutes | by Bugitrix - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original I Built an AI That Hacks Itself — And It Found 3 Real CVEs in 20 Minutes A 22-minute experiment that changed how I think about AI-assisted recon. Bugitrix Follow ~8 min read · March 24, 2026 (Updated: March 24, 2026) · Free: Yes The terminal went quiet for about three seconds. Then it printed a line I wasn't expecting: "Potential IDOR detected — user ID parameter not validated server-side." I leaned forward. The AI had just found something I'd missed on a manual pass the day before. It was 11:43 PM and I was suddenly very awake. TL;DR I built an AI-assisted recon and vulnerability scanning pipeline using LangChain + GPT-4 and pointed it at a test environment In under 20 minutes, it surfaced 3 real, reportable vulnerabilities — including one that matched a recent CVE pattern AI won't replace ethical hackers, but researchers who use it will lap those who don't Why I Even Tried This I've been doing security research for a while now, and the part that burns the most time isn't the interesting stuff — it's the grunt work. Crawling endpoints. Fuzzing parameters. Re-checking the same patterns across a hundred different routes. It's necessary, but it's also the kind of work where fatigue gets you. You miss things at 1 AM that you'd catch at 9 AM. I'd been watching how AI was being used in offensive security circles, mostly with skepticism. Most of what I saw was prompt-engineered nonsense — people asking ChatGPT to "find vulnerabilities in this code" and pasting in 20 lines. That's not security research. That's Ctrl+F with extra steps. But then I started thinking differently. What if the AI wasn't the analyst, but the automation layer ? What if it handled the repetitive pattern recognition while I handled the actual thinking? That question turned into a project I've been building out and documenting over at Bugitrix — a place where I share real research, not polished marketing. This article is a direct export of what I found. The Stack I Put Together The setup isn't complicated, but every piece matters. I used LangChain as the orchestration layer — it lets you chain prompts together and plug in tools like a web crawler or a custom scanner. On top of that, I wired in the GPT-4 API to do the interpretation work: take raw HTTP responses and ask, "does anything here look exploitable?" For active testing, I kept Burp Suite in the loop as a proxy so I could see exactly what traffic the AI was generating and intercept anything before it hit the real target. The target was a deliberately vulnerable web app running locally — a custom-built environment with some intentionally misconfigured endpoints mixed in with clean ones. I wanted to see if the AI could distinguish signal from noise. The core loop looked like this: crawl a set of endpoints, collect responses, pass them to GPT-4 with a structured prompt asking it to flag anomalies, then log anything that scored above a confidence threshold. Simple. Almost embarrassingly simple. But that's kind of the point. Here's the basic version of the scan loop I was running: import openai import requests def analyze_response(endpoint, response_text): prompt = f""" You are a security researcher reviewing HTTP responses. Endpoint: {endpoint} Response snippet: {response_text[:500]} Identify any patterns suggesting IDOR, XSS, or auth bypass. Be specific. Return JSON: {{"issue": "", "confidence": 0-10, "reason": ""}} """ result = openai.ChatCompletion.create( model="gpt-4", messages=[{"role": "user", "content": prompt}] ) return result.choices[0].message.content endpoints = ["/api/user/1", "/api/user/2", "/api/profile?id=101"] for ep in endpoints: r = requests.get(f"http://localhost:8080{ep}") print(analyze_response(ep, r.text)) Nothing magical. But when you run this across 80 endpoints with varied parameters, the pattern-catching starts to compound. If you want to follow along with what I'm building, I share breakdowns like this on Telegram — join the Bugitrix community at t.me/bugitrix . What the AI Actually Found This is where it gets interesting — and where I'll be honest about what "found" actually means in this context. The first hit was a classic IDOR. The app had an endpoint at /api/orders/{id} where the id was a sequential integer. The AI flagged it almost immediately, noting that the response returned full order details without any ownership check in the visible response headers or body patterns. I verified manually — sure enough, user A could pull user B's orders by incrementing the ID. This matched the behavior pattern described in CVE-2024-21887 , a real advisory involving improper object-level authorization in a widely-used API gateway. Not the same codebase, but textbook same class of flaw. The second was a reflected XSS. There was a search endpoint that was echoing the query parameter back into the response inside a

without encoding. The AI caught this by spotting that the reflection pattern — user input appearing verbatim in the HTML response — wasn't wrapped in any encoding artifacts. I tested it with a payload and it fired immediately. This one aligned closely with the pattern documented in CVE-2024-29895 , which covered unescaped input reflection in a web interface layer. Again — same vulnerability class, same root cause, just a different app. The third was the one I didn't see coming. There was an authentication endpoint that accepted a role parameter in the POST body. The AI flagged it as suspicious — not because it found an exploit, but because it noted the parameter shouldn't logically be client-controlled. I dug in manually, tried passing "role": "admin" in the request body, and the app accepted it. Mass assignment vulnerability. Full privilege escalation from a single modified request. Three findings. Twenty-two minutes on the clock. Here's Where It Got Weird I need to be straight with you: the AI also flagged eight things that were completely benign. It got jumpy about standard CORS headers, misread a paginated API response as a potential data leak, and at one point flagged a cookie as "potentially sensitive" because it had the word "session" in the name. Yes, really. The AI is a phenomenal first-pass filter. It is a terrible last word. That sentence matters more than anything else in this article. If I'd shipped those eight false positives to a client or a bug bounty program without manual review, I'd have looked like I didn't know what I was doing — because I wouldn't. The AI doesn't understand context the way a researcher does. It doesn't know that a CORS wildcard is acceptable on a public CDN endpoint. It doesn't know that the "session" cookie it flagged is httpOnly, Secure, and SameSite=Strict. What surprised me most was how the false positives were wrong. They weren't random noise. They were logically coherent but contextually broken. The AI was applying valid heuristics without understanding what those heuristics were for. That's actually a useful failure mode — because it tells you exactly where human judgment still has irreplaceable value. What This Actually Means for Ethical Hackers Let me be direct: AI is not going to replace you. It is going to replace the parts of your job you hate most. The reconnaissance grind, the endpoint enumeration, the first-pass parameter fuzzing — that's automatable now. Not perfectly, but well enough that doing it by hand while your competitors use AI assistance is like doing math by hand when everyone else has a calculator. Technically possible. Strategically insane. What AI can't do is understand the business logic of an application. It can't look at a complex authorization flow and understand that this particular role-switching behavior is a feature, not a bug. It can't read between the lines of a response that looks clean but smells wrong. That's researcher intuition, and it comes from experience, not training data. The framing I find most useful: AI as a junior analyst who's incredibly fast, never tired, and needs supervision. You're still the senior researcher. You're just not spending four hours on the stuff a script can handle. For intermediate hackers specifically — this is a genuine skill gap right now. Most people in the community are either ignoring AI tools entirely or using them naively. There's a middle path where you actually understand the pipeline, know where it fails, and build around those failure modes. That's where the advantage lives. Something You Can Try Today You don't need to build what I built to start experimenting. Here's a minimal version you can run against your own test environment or a legal bug bounty target. Set up a simple LangChain agent with access to the requests library. Give it a target URL and a list of common parameter names. Ask it to iterate through combinations, collect responses, and flag anything where the response length, status code pattern, or content type changes unexpectedly across iterations. That deviation detection alone will surface IDORs and auth bypasses faster than manual testing on most apps. Keep Burp Suite running as your proxy the entire time. Every request the AI generates goes through it. You stay in control, you see everything, and you can pause the agent the moment something looks like it's heading somewhere it shouldn't. Start with a local vulnerable environment — DVWA, Juice Shop, or a custom setup. Get comfortable with the false positive rate before you take it anywhere real. And document everything. The discipline of writing down what the AI flagged, what you verified, and what turned out to be noise is where you actually learn the tool's edges. Where This Is Going I've been doing this long enough to know that the tools change fast and the fundamentals change slow. Vulnerabilities like IDOR and XSS exist because developers make the same categories of mistakes — trusting client input, skipping authorization checks, reflecting data without encoding. AI doesn't change that. It just changes how fast we can sweep for those patterns. What I think is coming — and this is worth paying attention to — is AI that doesn't just flag suspicious patterns but actively generates test cases based on application-specific context. We're already seeing early versions of this with tools that combine code analysis with dynamic testing. The gap between "scanner" and "researcher" is going to keep narrowing. That should be exciting, not threatening. The researchers who will matter most are the ones who understand both the vulnerability classes and the tools deeply enough to know when to trust the output and when to throw it out. This is early days. It's messy and imperfect and the false positive rate is annoying. But I found three real CVE-class vulnerabilities in twenty-two minutes on a test app I'd already reviewed manually. That's not a party trick. That's a workflow shift. For more research, tools, and writeups like this, head over to bugitrix.com . What to Do Now 1. Set up a local vulnerable app (DVWA or OWASP Juice Shop) and run a basic LangChain + GPT-4 scan against it — use the code snippet above as your starting point. 2. Cross-reference every AI flag manually before trusting it. Build the habit of treating AI output as a hypothesis, not a finding. 3. Join the Bugitrix Telegram at t.me/bugitrix — I'm sharing pipeline updates, prompts that work, and ones that don't, as I keep building this out. #cybersecurity #artificial-intelligence #ethical-hacking #bug-bounty #programming Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).

← Back to stories