Three separate security incidents surfaced within a short window, affecting platforms used by a meaningful portion of the modern software industry. The attack vectors differ — a compromised OAuth integration, a broken authorization model, and a critical flaw in GitHub’s own git infrastructure — but the underlying exposure is consistent: organizations accepted risk they did not fully understand when they handed control of their infrastructure to someone else.
This is not an argument for building everything yourself or for treating all managed services as equally dangerous. It is an argument for making deliberate choices — knowing what you are accepting rather than discovering it after the fact.
What Happened
Vercel. A third-party AI developer tool had been granted OAuth access to Google Workspace at Vercel. When that external tool was compromised, the attacker gained access to one Vercel employee account. From there, the blast radius expanded to encompass source code repositories, NPM publishing tokens, GitHub integration tokens, and production environment secrets — for a platform that hosts a significant fraction of modern web applications. A single OAuth grant, extended to a tool outside Vercel’s security perimeter, became the entry point for an incident affecting customers who had no knowledge of that grant and no control over it.
Lovable. A broken authorization flaw in Lovable’s API meant that any authenticated user — including free accounts — could access the project data of any other user for projects created before November 2025. The flaw was not subtle: querying project endpoints simply did not verify ownership. Source code, database connection strings, service role keys that bypass row-level security, AI conversation history, and customer data were all reachable. A researcher pulled the full source tree of a nonprofit’s admin panel, including live production credentials, from a free account. The vulnerability was reported via HackerOne in March. Forty-eight days later it remained open. This was Lovable’s second material security incident within a twelve-month period.
GitHub (CVE-2026-3854). Wiz Research disclosed a critical remote code execution vulnerability in GitHub’s core git infrastructure in April 2026. The flaw existed in the protocol that handles authenticated git pushes: a boundary condition in how the internal proxy parsed push option headers allowed user-controlled input to override security-critical configuration fields passed between GitHub’s internal components. An attacker with a valid GitHub account needed only a specially crafted git push to achieve code execution on GitHub’s backend servers. Because those servers run on shared storage infrastructure, a successful exploit did not stay within the attacker’s own repository — the git user’s access spanned repository data across millions of accounts and organizations on the same physical nodes. On GitHub Enterprise Server, the same vulnerability yields full server compromise: every repository, every secret, every internal credential hosted on the instance. GitHub patched its cloud platform within six hours of the report. Enterprise Server patches shipped nearly a week later. At the time of public disclosure, the majority of self-hosted Enterprise Server instances had not yet applied the fix.
In all three cases, the affected organizations were not operating negligently. They were using established platforms the way most of the industry does. The security exposures were structural properties of those platforms, not the product of any individual organization’s decisions.
The Structural Problem With SaaS
When you deploy on a SaaS platform, you are not just purchasing compute and storage. You are extending implicit trust to every third-party integration that platform has accepted, every employee at that company with access to production systems, every piece of their infrastructure they have built on top of other SaaS platforms, and every security decision they have made or deferred.
OAuth has become a particularly significant attack surface. Developer tooling increasingly requests broad workspace access — not just the name and email scopes that are clearly justified, but access to repositories, documents, calendars, and email. Each grant extends your organization’s security perimeter outward into systems you cannot audit. The Vercel incident illustrates exactly what happens when one link in that chain is compromised.
The Lovable incident illustrates a different dimension of the same problem: authorization logic in multi-tenant SaaS systems is genuinely difficult to get right, and the consequences of getting it wrong are borne by customers, not the vendor. A flaw that an independent researcher discovered and responsibly disclosed sat unresolved for weeks while the data of employees at major technology companies remained accessible to anyone with a free account.
The GitHub vulnerability exposes a third dimension entirely: when your source code lives on shared infrastructure operated by someone else, a flaw in their internal systems is a flaw in yours. There is no OAuth grant to audit, no authorization model to verify. The exposure exists at the infrastructure layer, below anything you control. Every organization whose repositories lived on the same physical storage nodes as the exploit target was affected — not because of anything they did or did not configure, but because of a parsing flaw in a protocol header they had no visibility into.
None of these vendors set out to expose their customers. The risks are structural, not intentional. That is precisely what makes them worth treating as design decisions rather than incidents to react to.
The Alternative Is Not Theoretical
The argument for on-premises, colocation, or air-gapped infrastructure is not that you can achieve perfect security — no environment can. The argument is that you control the perimeter, the access model, and the response when something goes wrong.
When your source code lives on infrastructure you operate, there is no OAuth grant from a third-party tool that reaches it. When your database credentials are stored in a secrets manager you manage, a broken authorization check in someone else’s API does not expose them. When your production environment is air-gapped from the public internet, the attack surface is fundamentally smaller.
This is not a novel idea. Financial institutions, defense contractors, healthcare systems, and critical infrastructure operators have understood this tradeoff for decades. What has changed is that the tooling for running your own infrastructure is now mature enough that organizations significantly smaller than those sectors can operate it effectively.
We have written in depth about what BYOCH — Bring Your Own Cloud Hardware — actually looks like in practice, including the real cost comparisons, migration timelines, and what it requires technically. The economics already favor on-premises or colocation for most companies spending above a modest threshold on cloud. The security argument is an additional reason to run the numbers seriously.
The platforms and tooling required to operate self-hosted infrastructure at scale are also far more capable than they were even a few years ago. We covered how the growth of AI-generated software is straining existing SaaS-based infrastructure — a problem that organizations running their own infrastructure can address directly rather than waiting for a vendor to prioritize it on their roadmap.
Open source has also matured to the point where SaaS lock-in at the infrastructure layer is increasingly a choice rather than a necessity. The trajectory of vendors who start open source and then close it off is a related reason to think carefully about which parts of your stack you want to own outright.
Practical Steps If You Are Currently SaaS-Dependent
The answer is not to immediately abandon every managed service. It is to make deliberate choices about where the risk is acceptable and where it is not.
The highest-priority areas to evaluate:
Source code and secrets. If your code and production credentials live in a SaaS platform, the Vercel incident is the relevant threat model. Self-hosted Gitea, Forgejo, or GitLab, combined with a self-managed secrets backend, removes the dependency on a third party’s security decisions for your most sensitive assets.
Customer data. The Lovable incident is the relevant threat model here. Multi-tenant SaaS platforms holding your customers’ personal information depend on that vendor’s authorization logic being correct across every endpoint. Running your own database — even a managed one on infrastructure you control — keeps that logic inside your perimeter.
CI/CD and AI tooling integration. The GitHub Actions research is the relevant threat model for any team running AI-powered automation in their pipelines. Audit which GitHub Actions have access to cloud provider credentials or secrets, understand what scopes those credentials carry, and treat any workflow that interpolates user-controlled content into an AI prompt as a potential injection vector. Self-hosted CI/CD infrastructure — running Gitea Actions, Woodpecker, or Tekton on hardware you control — removes the GitHub-as-intermediary dependency entirely.
OAuth hygiene regardless of deployment model. Audit every third-party application that has OAuth access to your Google Workspace, GitHub organization, or other identity-critical systems. Revoke anything that requests broader scopes than the task justifies. Restrict access for unconfigured third-party applications to basic identity scopes only. This is a low-cost step with meaningful risk reduction.
Plan for the incident you have not had yet. Most organizations’ incident response plans assume the breach happened in their own systems. The Vercel scenario — where the entry point was a tool they did not operate — requires a different kind of preparedness. Know what you would rotate, in what order, and how quickly, if a platform you depend on reported a compromise today.
Treating Infrastructure as a Security Decision
The conversation in most engineering organizations frames infrastructure as a cost question: SaaS is convenient and cheap, on-premises is expensive and operationally heavy. Both of those characterizations are increasingly inaccurate, and neither captures the full picture.
The actual question is risk. Security exposure from third-party integrations you cannot audit. Authorization flaws in multi-tenant platforms you cannot patch. Prompt injection vectors introduced by AI tooling in your pipeline that bypass the security controls you thought you had. Self-hosted infrastructure carries its own risks, but they are risks you can see, investigate, and respond to on your own timeline. The risks introduced by SaaS dependency are often invisible until they materialize at scale.
The cost comparison, as we have covered elsewhere, frequently favors self-hosted infrastructure more than the conventional wisdom suggests. The operational burden has decreased substantially as Kubernetes tooling, bare-metal provisioning, and self-hosted observability have matured. And the risk profile of SaaS dependency is more visible now than it has ever been.
The organizations that will be most resilient are the ones that treat “who controls this infrastructure, and what does that mean for us” as a first-class architectural decision — not an afterthought, and not a default inherited from vendor preference.
How BootstrapVC Can Help
If your organization is evaluating a move toward infrastructure you control — whether dedicated servers, colocation, an air-gapped cloud, or a fully private environment — this is work we do directly with our portfolio companies and with companies outside the portfolio.
Our team handles the full migration: architecture assessment, hardware procurement guidance, Kubernetes on bare metal, secrets management, observability, and the operational knowledge transfer that makes a team self-sufficient afterward. We have executed this migration for companies at a range of scales, and the playbook is well-established.
If you want to understand what a move looks like for your specific environment, visit our invest page to see the full scope of what we provide, or reach out directly to start the conversation.
The security case for infrastructure independence has never been stronger. The tooling to act on it has never been more mature.