From WAF Bypass to Full Attack Chain: How Moderna Tests Like a Real Attacker

Background

When Farzan Karimi became Deputy CISO at Moderna, he inherited responsibility for one of the most complex security environments in biotech, and a clear-eyed view of what his team could and couldn't cover on their own.

Farzan has spent 20 years in offensive security, running red teams for large organizations. He still pentests on weekends because he genuinely enjoys it. That background shaped how he approached Moderna's security program from day one: not just managing risk, but thinking like an attacker across every domain, from manufacturing to enterprise to customer-facing applications.

Moderna operates in an industry where the consequences of a breach extend well beyond data loss. Their environment spans manufacturing systems that run around the clock, enterprise infrastructure, and a growing catalog of custom applications built by scientists and engineers who move fast. A breach anywhere in that stack, from a dev environment, to a custom dashboard, or a production app, is not just a security incident. At Moderna, it can mean compromised research, disrupted manufacturing, or patient data at risk.

Moderna's security program is mature and well-resourced, covering network security, cloud security, AI security, code security, and pentesting. What Farzan saw was not a gap in the program. It was a math problem. The environment was growing faster than any team, no matter how skilled, could manually keep up with.

Challenge

The pace of development was the core pressure. Engineers and scientists were building and publishing custom applications faster than any manual review process could track. A scientist might build a dashboard to capture sensitive research data, share it with a colleague, and depending on which AI tool handled the request, accidentally expose it to the internet. Farzan described exactly this kind of scenario as something the industry was already seeing. In Moderna's environment, with the data they handle, that kind of exposure is not a minor incident.

Even with a strong team in place, penetration testing is periodic by nature. You scope an engagement, you test for a few days, you write a report, and by the time the report is done, the application has already changed. Skilled testers have limited time on any given engagement, and limited time means limited coverage. A senior pentester running a test on a Wednesday, trying to finish by Friday, does not bring the same attention to every endpoint they would with unlimited time. Farzan had experienced this firsthand, having run these tests himself.

The other pressure was prioritization. Findings came in from three directions: internal risk assessments, external bug bounty submissions, and manual pentests. Most were ranked by CVSS score. A 9.2 is critical, fix it. But when thousands of findings are competing for the same limited developer time, a CVSS score alone tells you nothing about where to actually start. The queue was full, but the signal was weak.

What the team needed was a way to test more of the environment more often, at a quality bar that matched how a real attacker thinks, without depending entirely on human availability to get there.

Why XBOW

Farzan ran the proof of concept the way any serious practitioner would: he pointed XBOW at an application he had already personally tested. Not a simple one. His worst publicly facing custom application, the one he knew best, the one he had already found vulnerabilities in. If XBOW was going to earn a place in their program, it needed to find something he had not.

The application ran behind a web application firewall. Farzan had tested it, found vulnerabilities, and those vulnerabilities had been patched. The WAF was holding. XBOW found a gap he had missed entirely.

The application used Spring Boot, a framework that exposes debugging endpoints and environment variables that are useful for developers, but dangerous if exposed to the internet. Farzan had tested the actuator endpoint. The WAF blocked it. He moved on. XBOW did not. It tried the same request with one small change: it replaced the letter A in the URL with its percent-encoded equivalent, %61. The WAF read it as a routine request and let it through. What came back was a full dump of the environment, including API keys, MongoDB credentials, and connection strings. Everything a real attacker would need to turn an initial foothold into something far worse.

That finding mattered for two reasons. The obvious one is the vulnerability itself, a real exposure that would have been serious in the hands of an attacker. The less obvious one is what it revealed about how XBOW works. It was not running a checklist. It was reasoning about how a WAF interprets requests, finding the gap between what the firewall expected and what the application actually received, and exploiting that gap the way a real attacker would.

The WAF bypass was what closed the deal. But it also pointed toward something Farzan cared about even more than individual findings: the connections between them. Most tools hand you a list of bugs. What Farzan wanted to know was which bugs were connected, because connected bugs become attack chains, and attack chains are how real attackers operate.

What a Real Attack Chain Looks Like

To understand what exploit chaining looks like in practice, it helps to walk through what XBOW did with a cluster of Moderna's internal applications.

The target was an external-facing ordering application, the only public entry point into a tightly coupled ecosystem of roughly 30 to 40 internal apps, including routing, authentication, and inventory systems. XBOW was given source code but no login credentials. The instruction was simple: here is the application, go find what you can find.

The first thing XBOW did was search the source code for API keys. It found one: a valid key belonging to a user whose credentials had not been rotated. It used the key to authenticate, then began probing the APIs. One of them handled malformed SQL input in an unexpected way. Rather than failing cleanly, the bad input started cascading into the Gateway application, the routing layer that handled authentication for every other app in the cluster. Containers started throwing errors. The ordering app went down. Then the inventory app. Then everything else. The entire dev environment went offline.

XBOW had also confirmed the IDOR vulnerability Farzan suspected was there: a logged-in user could access the order history of any other user, with no special access required. Human pentesters who reviewed the findings afterward confirmed the same attack chain could have compromised confidentiality as well as availability, not just taken the system down, but exposed data in the process.

The whole chain ran in under 18 hours. For context, developing an equivalent multi-stage attack chain manually can take anywhere from days to months depending on the target. On complex systems, where exploit primitives need to be built from scratch and stability validated across multiple components, months of work is realistic. Farzan's team had seen exactly that at prior organizations. XBOW compressed that timeline to less than a day.

Farzan's reaction was not alarm, it was relief. Finding an outage safely in a test environment is exactly what you want, because it means a real threat actor did not find it first.

From Noise to Signal

Finding a WAF bypass and building a full attack chain are the headline moments. But what changed day to day at Moderna was something more practical: how the team decides what to fix.

Before XBOW, the vulnerability queue was a volume problem. Findings piled up from bug bounty submissions, risk assessments, and periodic manual tests, all ranked by CVSS score, all competing for the same limited developer time. The team was not ignoring the queue. They just had no reliable way to know which items in it reflected real, exploitable risk versus theoretical exposure. As Farzan described it, you can have a hundred 9.2s in your environment and a CVSS score alone tells you nothing about which one to fix first.

XBOW changed that by attaching an exploit proof to every finding. Not a theoretical vulnerability, but reproducible, demonstrated evidence with a working proof of concept attached. A developer looking at an XBOW finding knows exactly how the vulnerability would be reached, what an attacker would do with it, and why it matters more than the other items on their list.

That clarity collapses the distance between finding and fix, and it changed how Moderna thinks about remediation. The issues identified as part of the attack chain were resolved within 24 hours of discovery.

The exploit proof made the combined impact of the three vulnerabilities clear enough that the development team did not need to debate prioritization. They could see exactly what was at risk and act on it. With higher quality findings coming in at higher volume, the team is now building out a remediation pipeline to match, including exploring remediation agents that can accelerate how fast validated vulnerabilities get resolved.

A Program Built to Scale

The result is a security program that operates at a different pace than it did before. XBOW handles application security testing across Moderna's portfolio, running parallel pentests at a consistent quality bar, on demand, without scheduling or coordination overhead. That frees Farzan's team to focus on the work that requires human judgment: network environments, complex integrations, applications with logic flows that benefit from a practitioner's experience and context.

For Farzan, the shift is concrete. He can still pentest on Friday nights, but now he is working on the applications that actually warrant his full attention, not trying to stretch coverage across an entire portfolio by hand. His human red team can go deep on the areas where depth matters most, because XBOW is covering everything else.

Download the Moderna Customer Story PDF