A compromised third-party script drained $2.6 million from Polymarket users. Here's what we know about the attack and how we protect the Fathom script.

On October 29, Polymarket’s international exchange was drained and ~$2.6 million was stolen from 700 user accounts. The cause was a compromised third-party monitoring script from DebugBear. I’m going to get into what we know about the attack, and then what Fathom does to defend against this.

How did Polymarket get hacked?

Polymarket included a third-party JavaScript file from DebugBear, and that file was replaced with a malicious one. What’s interesting is that only Polymarket was targeted. DebugBear served a custom JavaScript file specifically for Polymarket, and that was the file the attackers replaced.

We don’t know the specifics yet, but it could’ve been done via a DebugBear employee being phished, access keys for the CDN/storage leaking, a compromised CDN/hosting account (e.g. a stolen login), a DNS takeover, a vulnerability in the DebugBear application code, a compromised CI/deploy pipeline, or potentially an insider (contractor/employee). There are so many potential attack vectors, and I’m hoping we’ll find out the specifics soon.

How does Fathom protect the analytics script?

We’ve always put a lot of effort into protecting our script, especially with regard to limiting who can alter it. I wanted to highlight what we do.

We limit production access

This isn’t the norm, and we’re probably the only analytics company in the world doing this. We have our environments set up so that I’m the only person who can push code to production. Other people can only contribute via pull requests. The downside of me being the only person with production access is that I have to be available 24/7. This was a choice we made, and it’s worked well for eight years at Fathom and at my previous company. In the event that I were to pass away, we have a policy for handover.

People have raised “key person risk” with me for years, but it hasn’t been our experience in practice. Even when we were hit with a DDoS attack, I handled it directly with AWS Support. If we ever expand production access beyond me, it would be limited, audited, emergency-only access, not day-to-day access.

We lock the domain and DNS

Our domain and DNS are held in Route 53, in a dedicated AWS account. Again, only one person has access to this, intentionally. Transfer lock is enabled on the domain, so it can’t be moved to another registrar without us knowing.

We protect access to our CDN

Our CDN provider has an API, which we don’t use, but we still rotate the API key regularly. Only one account has access to our CDN, and it’s protected by a unique, randomly generated password and 2FA. Our CDN only pulls script.js from our own servers. There’s no file storage or edge code configured on it that could be used to serve something else.

We have a static filesystem

Our script.js file is bundled into our deployment package, and the filesystem it’s served from is read-only at runtime. Nothing running in production can modify it. The only way to change it is a new deploy, and I’m the only person who can authorise deploys. In addition, we host our ingest environment (where we collect analytics and serve our script) completely separately from our main application, so anything happening in our main application can’t touch it.

Every customer gets the same script

DebugBear served Polymarket its own custom file, which let the attackers target one company quietly. We serve one identical script.js to every customer. If it were ever tampered with, it would affect every site using Fathom at once, and our monitoring would catch it within minutes. Our script also never downloads or runs any additional code, so our ingest endpoint can only receive data, never send instructions.

We monitor our script.js file 24/7

We use an external provider to monitor the contents of our script file from multiple locations around the world, every 5 minutes. If a single character changes, the sirens go off and we jump into action: redeploy the known-good file, rotate credentials, and notify customers.

What’s next

We’re not going to disclose our entire approach to security here, but I want to reiterate that we have always taken the security of our analytics script seriously. We will keep working to do even better, including looking at self-hosted script options, Subresource Integrity (SRI), and more. But we wanted to make it clear that this is something we’ve always protected.

Jack Ellis, founder

Discover the expertise of Jack Ellis, a technical writer, teacher, and software engineer with a wealth of experience in building software.