The Cloudflare Illusion
We scanned 100 Product Hunt startups from the outside. 11% had confirmed high-severity exposures. ~20% show signals a security engineer would flag as critical.
By Orb44 Research | October 2026
What we reviewed
We reviewed external snapshots of 100 recently launched Product Hunt startups. The run was passive and GET-safe. It did not use credentials, attempt passwords, test account logic, inspect private servers, or perform port scans. The reports are partial excerpts, so the counts below are minimums unless marked as approximate.
| The scan could show | The scan could not show |
|---|---|
| Public DNS, HTTP responses, visible headers, client-side code, and public files. | Whether a login, admin panel, or endpoint could be accessed with credentials or abused through business logic. |
| Directly readable exposures such as a listable storage bucket or exposed Git metadata. | Whether a 200 response on a path such as /n8n/ means the underlying panel has no authentication. |
What appeared most often was missing hygiene.
The most common result was not an exploit. About 58 of the 100 startups had no visible security.txt file, which makes responsible disclosure harder. We also saw no Content Security Policy in about 19 cases, no DNSSEC in about 17, clickjacking exposure in about 15, and no Cross-Origin-Opener-Policy in about 12. Missing mobile deep-link files appeared in about 60 reports, but that is informational rather than a vulnerability.
The scanner produced 12 B grades and 88 C grades. Those grades should not be read as a count of breached or exploitable companies. The score range was narrow, and a C can cover several very different situations, including a forgotten staging host or a configuration that needs manual review.
Fig. 1 — Research data canvas: overview of passive external scan findings across 100 recently launched startups.
The smaller set that deserves follow-up
Eleven companies had an explicit high-severity finding in the supplied excerpts. No critical-severity section was visible. The direct examples included listable cloud storage, exposed Git metadata, and reachable backup directories. Those cases merit responsible disclosure and manual verification first.
Read the evidence in order
- A hostname or framework name in DNS or JS — context, not a finding.
- A 200 response shows that a route is reachable, not that it is unprotected.
- Readable data without a login is the strongest observation.
AI Agent Infrastructure: The New Exposed / phpMyAdmin
In 2015, the most cliché way to pop a server was hunting for a forgotten /phpmyadmin directory. In 2026, exposed AI agent frameworks and orchestration endpoints have taken its place. Traditional security scanners haven't learned to look for these patterns yet, even though the vulnerabilities are sitting in plain sight:
MCP endpoints in public DNS. Several AI startups expose MCP hostnames (e.g. mcp.) in public DNS. In some cases, readable config files like /mcp.json or /openapi.json were served to anyone who asked. A hostname alone is context - readable config is a finding.
Langfuse on a public subdomain. One AI startup returned HTTP 200 on a live Langfuse instance. Langfuse stores full prompt and model response traces if the instance is truly unauthenticated, that is customer data on the open internet. A 200 alone does not prove that; it is a follow-up signal.
Automation panels and frameworks. Automation paths like /n8n/ are sitting out there with zero protection. Underlying agent frameworks (CrewAI, LangGraph) are entirely visible in production JavaScript.
Beyond AI-specific infrastructure, the broader attack surface showed the same pattern.
The 20% Reality: High-Severity Vulnerabilities
Because orb44 operates strictly outside the perimeter, it doesn't test authenticated business logic, IDOR, or brute-force admin panels. But even with this limited, unauthenticated view, 11% of the startups demonstrated explicit, confirmed high-severity vulnerabilities. Realistically, that number sits comfortably at 20% (one in five) when you factor in highly probable high-severity risks that any senior security engineer would classify as critical. In a matter of minutes, the scanner flagged:
- Publicly listable Google Cloud Storage (GCS) buckets.
- Exposed .git directories and publicly accessible backup plugin folders (e.g., /wp-content/updraft/).
- Wildly permissive CORS misconfigurations on core /api/ routes.
- Public dev/staging hosts returning HTTP 200 without a hint of authentication.
Basic hygiene is virtually non-existent. Roughly 58 out of 100 startups lack a basic security.txt file (RFC 9116). If a researcher finds a gaping hole, there is literally no one to report it to.
The Cloudflare question
Engineers love pointing DNS to Cloudflare and calling it a day. In reality, this "protection" frequently works in reverse. At least 14 startups had a Cloudflare record in DNS alongside a destination that did not look like a Cloudflare edge. That is a review signal, not proof that all production traffic bypasses a WAF. Multi-CDN routing, regional steering, and platform infrastructure can produce the same pattern. Check a direct request before publishing a company-level claim.
An AI startup hid its careers page safely behind a Web Application Firewall (WAF), but left its production API wide open. Another platform boasts about its WAF protection on its marketing landing page, but the client browser is never actually routed through it. Often, the bare apex domain - the one actual paying customers interact with is left entirely defenseless. DNS resolvers behave differently depending on the region: the same hostname can resolve to different pools of IP addresses depending on where the query comes from. As a result, geo-steering is sending a chunk of global users to infrastructure that nobody on the core team is actually monitoring.
Bonus Patterns: Irony, Phishing, and PCI Violations
The Cobbler's Children
Security vendors have blind spots too. One security SDK developer had no security.txt. Another security tool had unpatched DOM XSS vectors next to an active typosquat domain with a valid SSL certificate already issued.
A Phishing Goldmine via DNS
One company exposed employee first and last names through app-<firstname><lastname> subdomain conventions in passive DNS. Combined with lookalike domains that already have active certificates, this is the kind of setup a spear-phishing campaign would find useful.
Payment-page telemetry
At least seven projects run PostHog session replay. One appears to record sessions on checkout pages - a pattern that, if confirmed, would raise PCI DSS concerns. This needs manual verification before any public claim.
The Founder's Reality Check: The Cost of Illusion in the AI Race
The sprint for market dominance is forcing teams to ship features faster than ever before. In the rush to deploy agents, wire up orchestration layers, and show traction to investors, security is routinely punted to a hypothetical "post-Series A" roadmap. Our analysis of 100 startups makes one thing abundantly clear. In 2026, treating security as an afterthought has become an existential business risk.
When one in five projects is bleeding critical data to the public internet, this is no longer just a technical debt issue for DevOps. It is a direct threat to company survival for three key reasons:
- B2B Deals Die in Due Diligence: Enterprise clients do not buy software from companies that cannot control their own perimeter. A corporate security team only needs a five-minute external scan to spot your exposed staging environment or misconfigured WAF. That six-figure contract is dead before you even finish the pitch deck.
- Leaking Your Core IP: In this new wave of startups, prompts, chain-of-thought architecture, and context data are the crown jewels. Wide-open Langfuse dashboards or readable MCP config files put your entire product engine on public display. Competitors and malicious actors are walking away with your proprietary IP and customer data without executing a single complex hack.
- Reputational Death Before PMF: A mature enterprise can survive a public breach by throwing money at lawyers and PR crisis firms. Early-stage startups do not have that luxury. Leaking early adopters' data or violating payment compliance standards destroys market trust instantly and scares away venture capital permanently.
Fig. 2 — Distribution of the most common security hygiene gaps across 100 scanned startups.
The Pivot: Security as a Go-To-Market Advantage
Attackers are no longer wasting time hunting manually. Automated botnets are continuously crawling the web, specifically looking for the exact misconfigurations this new technology stack creates.
For founders, this is not a mandate to hire bloated security teams or slow down engineering. It is a signal to rethink basic risk management. Founders do not need to know how to write exploits, but they do need to look at their business exactly the way an attacker does. Knowing the true state of your perimeter before your clients, competitors, or automated bots find out is not a cost center. It is a baseline requirement for protecting your valuation.
What to do next
External review does not replace a penetration test. But it surfaces the things attackers check first: a forgotten host, a public file, an exposed setting.
Three concrete steps:
- Verify any direct-access finding before acting on it.
- Fix clear hygiene gaps (security.txt, CSP, DNSSEC).
- Inventory every public service and subdomain you own. See what the bots already see. Orb44 provides this external snapshot without an installed agent: orb44.com.
Methodology note: All findings are based on passive, unauthenticated external observation on 6–7 October 2026. A 200 response, a hostname, or a framework fingerprint is a signal for review, not proof of exploitability. Counts are minimums unless marked approximate. No company is named. Orb44 does not test authenticated logic, business logic, or private infrastructure.