Published by the Greyhound Security team · May 2026 Reading time: 8 minutes
The short version
Over the last few months, we ran our AI-driven continuous security scanner across 9 startup applications — a mix of SaaS products, fintech platforms, and AI-first tools across India and Canada. We found 394 real exploitable vulnerabilities in total. 1 in 4 of those companies had at least one critical issue that could be exploited by anyone on the internet within minutes — without any specialized skills, custom tooling, or insider knowledge.
This is not a marketing post. These are real findings from real scans on real production applications. Every company has been notified, and the vulnerabilities have been remediated. Names and identifying details have been anonymized.
If you are a founder shipping fast in 2026 — particularly if you are using AI coding tools to ship features faster than your team can review them — this post is for you.
Why are we publishing this
When we tell founders that startups have critical security issues, we get one of two reactions.
The first reaction: “Yeah, obviously, but it is not a priority right now. We will deal with it after Series A.”
The second reaction: “Our codebase is clean, we have not had issues.”
Both are wrong. The first is wrong because attackers do not wait for your Series A. The second is wrong because the absence of a known breach is not the same as the absence of vulnerabilities. Most companies that are breached did not know they were vulnerable until after the breach.
We are publishing this because the gap between “we are probably fine” and “we are actually fine” is significant and dangerous. Real data closes that gap.
The methodology
Here is what we did, transparently:
- 9 production web applications — running real customer traffic
- All scans authorized — every company explicitly consented to testing
- No social engineering, no DDoS, no destructive testing — only authenticated security analysis
- Scans ran continuously over 30-90 days — not a single snapshot but ongoing testing
- Every finding validated for actual exploitability — we do not surface theoretical vulnerabilities
Our scanner combines autonomous AI agents that plan attack sequences, traditional security tools (nmap, ffuf, feroxbuster, httpx), and machine learning classifiers that distinguish real exploits from false positives. Every critical finding was manually verified before being reported to the company.
The 9 companies in the sample included:
- 3 fintech startups handling user financial data
- 2 SaaS platforms with B2B customers
- 2 healthcare-adjacent products with PII
- 2 AI-powered consumer applications
Stage ranged from pre-seed to Series A. Team sizes ranged from 4 to 47 engineers.
The top 5 things we found
Here are the most frequently occurring vulnerability types across the 9 applications.
1. Insecure Direct Object Reference (IDOR) — found in 6 out of 9 applications
This was the most common critical issue and the most damaging when exploited.
What it is: An IDOR vulnerability exists when an application uses user-supplied input to access objects directly without verifying the user has permission. For example, an API endpoint like /api/user/1 that returns the data for user ID 1 — and you can simply change the URL to /api/user/2 to see another user’s data.
What we found: One fintech had IDOR across nearly every API endpoint. We could read any user’s KYC documents, transaction history, and bank account details by incrementing user IDs. Another SaaS product had IDOR on document downloads — every customer’s uploaded files were accessible by anyone who guessed the file ID.
Why it happens: Modern frameworks make it incredibly easy to write User.find(params[:id]) without checking whether the current logged-in user is authorised to view that user. AI coding assistants particularly tend to generate this pattern by default.
How to fix it: Every API endpoint that accesses user-specific data must verify ownership before returning the response. The pattern should be, not just User.find(params[:id]). Add automated tests that confirm User A cannot access User B’s resources.
2. SQL Injection — found in 4 out of 9 applications
We expected SQL injection to be dead in 2026. It is not.
What it is: SQL injection occurs when user input is concatenated directly into SQL queries without parameterization. The classic example: a login form where typing ' OR '1'='1 In the username field, bypasses authentication entirely.
What we found: Two applications had SQL injection in their search functions — typing certain payloads in the search bar would expose entire database tables. One had SQL injection in product ID lookups. One had it in the login form itself, allowing trivial account takeover.
Why it happens: Direct string interpolation in queries. Modern ORMs prevent this, but raw SQL still appears in custom queries, reporting endpoints, and legacy code. AI coding tools sometimes generate raw SQL when given ambiguous prompts.
How to fix it: Use parameterized queries everywhere. ORM-generated queries are safe by default. For raw SQL, always use placeholders (? or $1) rather than string interpolation. Run a static analysis tool like Semgrep or Bandit in your CI pipeline.
3. CORS Misconfiguration — found in 5 out of 9 applications
This is the silent killer because it does not appear to be a vulnerability until it is exploited.
What it is: Cross-Origin Resource Sharing (CORS) controls which external websites can make authenticated requests to your API. A misconfiguration — typically using the wildcard * or echoing the Origin header back without validation — lets any malicious website make requests on behalf of your logged-in users.
What we found: 3 of the 9 applications accepted CORS requests from any origin. One SaaS platform accepted credentialed cross-origin requests, allowing a malicious site to silently trigger actions on behalf of any logged-in user who visited it.
Why it happens: During development, CORS errors block local testing. The fastest fix is to set Access-Control-Allow-Origin: *. Developers intend to fix it before production. Most do not.
How to fix it: Allowlist specific origins only. Never use * in production. Never echo back the Origin header without validation against an allowlist. Use middleware like helmet.js or framework defaults that prevent misconfiguration.
4. Directory Traversal — found in 4 out of 9 applications
What it is: Directory traversal lets an attacker access files outside the intended directory by using sequences ../ in file path parameters. A request to /download?file=report.pdf become /download?file=../../../etc/passwd.
What we found: Three applications allowed reading server configuration files, environment variables, and in one case, database credentials via directory traversal in file download endpoints.
Why it happens: When user input directly informs filesystem operations without proper sanitization. Common in file upload and download features.
How to fix it: Never pass user input directly to filesystem operations. Use UUIDs as file identifiers and store the actual filesystem paths on the server. Validate that resolved paths stay within the expected directory using path.resolve() comparisons.
5. Missing Security Headers — found in 8 out of 9 applications
This is the easiest fix and almost universally ignored.
What it is: HTTP security headers tell the browser how to behave when handling your site. Without them, browsers default to permissive behavior that enables many client-side attacks. The critical headers are Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and Referrer-Policy.
What we found: Almost every application was missing at least 3 of these 5 headers. Missing X-Frame-Options means your site can be embedded invisibly in a malicious page (clickjacking). Missing Strict-Transport-Security means man-in-the-middle attacks are possible on the first visit. Missing Content-Security-Policy means stored XSS gets executed.
Why it happens: Headers are infrastructure-level configurations that developers forget. They do not break anything when missing, so nobody adds them.
How to fix it: Add these 5 headers to your reverse proxy or framework middleware. It takes 30 minutes and prevents an entire class of attacks. Test your setup at securityheaders.com.
What this means for your startup
If you are a founder reading this, here are the honest takeaways.
The base rate of critical vulnerabilities in early-stage startups is approximately 25%. Your application is statistically as likely to have a critical issue as not. The question is not “do we have vulnerabilities” but “which ones do we have, and how do we know.”
AI coding tools have changed the security model. Claude Code, Cursor, GitHub Copilot — these tools generate working code faster than ever, but they tend toward simpler patterns that often miss authorization checks, input validation, and security headers. Your codebase is growing 5x faster than it did in 2023. Your security review process probably has not kept up.
Manual pentests do not solve this. A traditional pentest costs Rs.3-6 lakh and takes 4-6 weeks. By the time you receive the report, your application has shipped 200+ new features. The findings are out of date the day they arrive.
Compliance requirements are coming whether you are ready or not. RBI mandates for fintechs, DPDP Act for any company handling Indian personal data, and SOC 2 for enterprise sales — all require evidence of continuous security testing. Most startups discover this requirement during a stalled enterprise deal.
What to do this week
If you read this and want to take action — even without using Greyhound — here is what we suggest:
- Run a single command in your codebase right now. Search for direct
params[:id]usage in your controllers without authorization checks. If you find any, those are your IDOR candidates. - Test your CORS configuration. Open browser DevTools, send a request from a different origin to your API, and check if it succeeds. If it does without complaint, you have a CORS issue.
- Visit securityheaders.com and enter your domain. Anything below grade B means you are missing critical headers.
- Set up Semgrep or Bandit in your CI pipeline. Free, takes one hour to configure, catches common security issues before code merges.
- Document the security work you do. When the enterprise customer asks for SOC 2 evidence in 6 months, you will be glad you started early.
How Greyhound works if you want continuous coverage
We do not believe in scaring founders into buying. Most of the recommendations above are free, and you can do them yourself.
But if you want continuous testing without the manual effort — AI agents that scan every day, validate findings, file GitHub PRs with proposed patches, and generate compliance evidence automatically — that is what Greyhound does.
We offer a free scan to any startup. You point us at a domain, we find what is there, and you get a plain-English report. No credit card required; no sales call unless you ask for one.
If the findings warrant ongoing coverage, our Pro plan starts at Rs. 90,000/month and includes everything mentioned in this post — continuous scanning, exploit validation, GitHub PR generation, and SOC 2 audit evidence.
You can email us at business@greyhoundsecurity.com or visit greyhoundsecurity.com to learn more.
One last thing
If you are reading this and recognize some of these patterns in your own application, do not panic. Almost everyone has at least one of these issues at some point. The difference between companies that get breached and companies that do not is not the presence or absence of vulnerabilities. It is whether they find them first.
Security is not a destination. It is a continuous process. The earlier you start, the cheaper it stays.
Build fast. Ship hard. Just do not skip the part where you check what you actually shipped.
Greyhound Security is an AI-driven continuous security platform for startups. We help fintechs, SaaS companies, and AI-first products find real exploitable vulnerabilities before attackers do. IIT Bombay IDEAS incubated, currently at UC Berkeley.
Contact: business@greyhoundsecurity.com · greyhoundsecurity.com
Leave a Reply