Experiments

Protecting your company from the future

Protecting your company from the future

TL;DR: Finding and exploiting bugs is getting cheaper, and the attackers now include software with superhuman abilities. You cannot fix your vendors' security. You can control how many of them hold your data, and where they run. The best security is by removing attack surface areas.

Your customer data can be compromised without anyone breaking into your systems: Every vendor holding a copy gives an attacker another place to look.

This week PHP shipped emergency patches for two bugs, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution on an exposed PHP web server. Both are rated 9.2 out of 10, and CISA told everyone to patch outside their normal cycle.

PHP still runs almost three-quarters of the websites, so there is a good chance something you depend on- a vendor, an agency, a plugin- was exposed for at least a day. (GrowthBook was not exposed and doesn’t use PHP).

The same day, a malicious build of LiteLLM, a popular Python library for calling LLMs, was pushed to PyPI and Docker Hub with a credential stealer inside. It ran at Python startup, before the library was even imported, and went looking for cloud, GitHub, browser, and AI provider keys. The attackers got in through exposed tokens from three maintainers' GitHub accounts.

While these are quite different, they point to a growing trend of AI-driven security exploits and attacks:

AI has reached a level of understanding code and system interactions that far exceeds even the best security researchers' abilities. The good news is that AI will help patch these vulnerabilities faster. The bad news is that we expect the number and severity of these attack vectors will keep increasing in frequency and impact, as AI finds ever more creative attacks.

SaaS Convenience

For twenty years, the standard advice when a company needed tools was to use a SaaS tool, because they're very convenient. But the thing that made SaaS the obvious choice also makes it a target for attackers. Find one exploit, and you get access to hundreds or thousands of company records.

Customer records, usage events, revenue, the behavioral history that runs your experiments and trains your models, are key to your business success.

Now that code is cheap, your data represents a key asset. It is the one thing a competitor cannot generate with a prompt, and it is the thing every attack above was actually after. The LiteLLM payload did not want the library. It wanted the keys and access to data.

So the question isn’t "build or buy" anymore. It’s “how can I build a robust system that protects my data?”

Exposure is multiplicative

Your exposure is roughly the number of systems holding a copy of your data, multiplied by each system's attack surface.

A typical mid-sized company has copies of its customer data in a CRM, a support desk, a product analytics tool, an A/B testing tool, an email platform, a data warehouse, two or three AI vendors, and a dozen integrations between them. Every one of those vendors represents a surface that an AI attack can target.

How many copies are out there?

One dataset can spread across tools, accounts, and integrations.

Your companyCustomer data
Copies + credentials
  • CRMData copy
  • SupportData copy
  • EmailData copy
  • AnalyticsData copy
  • A/B testsData copy
  • AI serviceData copy

A breach at one recipient can expose the data it holds.

Vendors often don’t reveal how quickly they patch any exploits. Sometimes these patches get stuck behind months-long prioritization schedules. This is where being open-source is an advantage. Not only can you easily scan to see if any exploit has been patched yourself, but you can also see how seriously the vendor takes security, and how often they update the product.

You can’t fix a vendor’s security practices. You can only decide whether they have your data in the first place.

Self-host where you can

The most reliable way to shrink that attack surface area is to run the systems that hold your most valuable data yourself, inside your own network, behind your own access controls and firewalls. This is routinely done for warehouses, but less often with platform tools.

Self-hosting does not make you immune to bugs. The PHP vulnerabilities hit self-hosted servers exactly as hard as managed ones. The difference is that with a system that is correctly locked down behind a firewall, there are no ways to run the exploit.

A self-hosted system behind your VPN, reachable only by your own services, is not sitting on the public internet waiting for an attacker. A vendor's multi-tenant SaaS tool is.

The second benefit is subtler: Self-hosting is a forcing function for sending less. When it is your database on your disk, you can give a system only the data it needs. When you set up a SaaS tool, the integration wizard has to work with all kinds of systems, and it’s often easier to give it permissions for everything rather than just what it needs.

Are there other options?

Yes, and most are worth doing even if you self-host, because self-hosting without them just moves the problem to your own servers.

Warehouse-native tools are a great way to protect your data. A growing class of tools, including analytics and experimentation tools like GrowthBook, run their queries inside your data warehouse and never copy the events out. Even if you use our SaaS product, you can still lock down what data it has access to.

Narrow the access

With warehouse-native analysis, raw events stay in your warehouse. You also choose where the tool runs.

Tool hosted in the cloud
Your infrastructure
Your warehouseRaw events stay here
Scoped query
Aggregate results
Vendor infrastructure
Analysis toolFor example, GrowthBook Cloud
Tool hosted inside your network
Your infrastructure · access restricted by your network controls
Your warehouseRaw events stay here
Scoped query
Aggregate results
Analysis toolFor example, Self-Hosted GrowthBook

Minimize, then minimize again. Scope every credential. Rotate on a schedule. Every long-lived, broadly scoped token on an engineer's laptop is a potential vector for attack.

The LiteLLM compromise was three tokens.

Looking forward

The economics of software have flipped.

Building is cheap, and so is attacking. What is scarce—and what is worth protecting—is the data your company has accumulated about its users and its business. You can do a lot to protect these key assets.

At the same time, the rapid development of AI tools is going to cause an ever-increasing number of exploits.

Today, the AI models are the worst they’ll ever be. They are getting better every day.

In this uncertain world, the best advice is to limit exposure and attack surface areas as much as possible: Self-host and run the things that hold your data, behind your own firewalls and access control layers, and give everyone else as little of it as you can.

Get started with more control

Run experiments on your existing warehouse data, with the flexibility to self-host GrowthBook on your own infrastructure.

Start for Free

Table of Contents

Related articles

See All Articles
The bottlenecks slowing down your experimentation velocity
Experiments
The bottlenecks slowing down your experimentation velocity
Experiments
Feature Flags
AI
Introducing the official GrowthBook Slack app
AI
Experiments
Beyond evals: A/B test AI features with LLM traces and business metrics

Ready to ship faster?

No credit card required. Start with feature flags, experimentation, and product analytics — free.

Simplified white illustration of a right angle ruler or carpenter's square tool.White checkmark symbol with a scattered pixelated effect around its edges on a transparent background.