How GuardianX Found 23 Vulnerabilities in 2 Hours

This case study walks through a real GuardianX engagement with a mid-size fintech company (name anonymized as "FinCo"). FinCo had 12 microservices, ~80,000 lines of code across Node.js, Python, and Go, and was preparing for a SOC 2 audit. Their previous VAPT vendor took 3 weeks and produced a 90-page report that the engineering team couldn't action.

Engagement Setup

We connected FinCo's repositories via Git URL and provided staging URLs for DAST. Total setup time: 12 minutes. We then launched a full VAPT scan across all 12 services in parallel.

Phase 1: Recon (0:00–0:15)

GuardianX's recon module ran:

• nmap port scans on staging URLs
• ffuf directory brute-force with the SecLists wordlist
• Tech fingerprinting (Wappalyzer-style)
• Subdomain enumeration via certificate transparency logs

Discovered: 3 forgotten staging endpoints (admin.insecure.staging.finco.com, old.finco.com, api-v1.finco.com), 2 exposed .git/config files, 1 exposed .env file containing a Stripe secret key.

Phase 2: SAST (0:15–0:45)

GuardianX indexed all 12 repositories and ran static analysis for 27 vulnerability classes. Found:

• 8 SQL injection points in a legacy Node.js service (string-concatenated queries in a 4-year-old billing module)
• 5 hardcoded secrets (AWS access keys, database passwords, JWT secrets) in 3 repos
• 3 SSRF vulnerabilities in a webhook delivery service
• 2 path traversal issues in a file upload handler
• 4 insecure deserialization uses of Python pickle in a worker service

Phase 3: DAST (0:30–1:30)

The RedAgent engine crawled each staging URL with Playwright, then sent safe, non-destructive payloads. Confirmed:

• 2 SQL injection (the SAST-found ones, plus response signature confirmation)
• 1 stored XSS in a profile bio field (stored in Postgres, rendered without escaping in the admin dashboard)
• 1 IDOR — /api/v1/transactions/{id} returned any user's transactions without ownership check
• 1 broken authentication — JWT alg: none accepted on 2 services
• 1 missing rate limit on the login endpoint (allowed 10,000 attempts/min)

Phase 4: AI Triage & Patch Generation (1:30–1:50)

The AI triage layer correlated SAST + DAST findings, removed 9 false positives (suspected SQLi that wasn't actually exploitable), and confirmed 23 real vulnerabilities:

• 4 Critical (SQLi, IDOR, JWT alg:none, exposed Stripe key)
• 7 High (hardcoded secrets, SSRF, stored XSS, broken auth)
• 8 Medium (path traversal, deserialization, missing headers)
• 4 Low (information disclosure, verbose errors)

For each finding, GuardianX generated a code patch. Sandbox-tested each patch (spun up a microservice container with the patch applied, ran the original exploit, confirmed it no longer worked). 21 of 23 patches passed sandbox on first try; 2 needed a second AI iteration.

Phase 5: Report & Attestation (1:50–2:00)

GuardianX generated a 42-page PDF report containing:

• AI-written executive summary (1 page, board-ready)
• Technical findings table with CVSS v3.1 scores
• Risk heat map
• Per-finding: location, evidence, suggested patch, sandbox result
• Attestation ledger (SHA-256 hashes of each finding + patch, signed and timestamped)

Total elapsed: 1 hour 52 minutes. Compare to their previous vendor's 3 weeks.

Key Findings Walkthrough

Finding 1: JWT alg:none (Critical)

The auth service accepted JWTs with alg: "none", which means no signature verification. An attacker could forge any JWT, including {role: "admin"}.

Patch: Added algorithms: ["HS256"] to the jwt.verify() call, rejecting any token that doesn't use HS256.

Finding 2: IDOR on transactions endpoint (Critical)

/api/v1/transactions/{id} returned any transaction by ID, regardless of the authenticated user's ownership.

Patch: Added ownership check — if (transaction.userId !== req.user.id) return 403.

Finding 3: Exposed Stripe secret key (Critical)

An old .env file was served at https://old.finco.com/.env containing a live Stripe secret key (sk_live_...).

Remediation: Rotated the Stripe key immediately, removed the file, blocked .env serving via Nginx config, and added GuardianX's exposure-path scanner to CI to catch this in future.

Finding 4: SQL injection in billing (Critical)

The billing service concatenated user input into SQL strings in 8 places. One was exploitable via the search filter — ?search=product%' UNION SELECT * FROM users-- returned all user records.

Patch: Replaced all 8 string-concatenated queries with parameterized versions using Prisma's queryRaw with bound parameters.

Outcomes

• 23 vulnerabilities found and patched in under 2 hours
• SOC 2 audit passed 3 weeks later with zero security findings
• MTTR (mean time to remediate) dropped from 14 days (previous vendor) to under 2 hours
• FinCo replaced their retainer VAPT vendor with a GuardianX Enterprise subscription

Lessons for Other Fintechs

1. Forgotten staging endpoints are gold for attackers — they're often less hardened than production. Inventory all subdomains. 2. Old code is dangerous code — the SQLi was in a 4-year-old module nobody had touched. Scan your whole codebase, not just recent commits. 3. Exposed secrets are the easiest critical to find and fix. Rotate immediately, scan continuously. 4. Speed matters for remediation — a 3-week delay between finding and fixing a Critical is unacceptable when attackers can exploit within hours.

Want similar results for your org? Sign up for a GuardianX Enterprise scan.