Security Researchers: Digital Fighters Series
Oligo: “AI is having its American Fuzzy Lop moment”
Uri Katz, Director of Research at Oligo Security, explains why the most critical bugs only turn up when humans step into the loop as part of CTech’s Security Researchers series.
“AI is having its AFL moment,” says Uri Katz, Director of Research at Oligo Security, referring to the automated fuzzing revolution that took place after the tool was released in late 2013. “Right now you can throw AI at a project and it'll find the low-hanging fruit, but that basic attack surface will eventually get covered, the same way it did with fuzzing.” Ultimately, he notes, “the more the research is actually guided by a researcher, the deeper and more impactful the results are.
Within Israel’s cyber companies are small, highly specialized teams trained to think like attackers, find vulnerabilities and stay ahead of a threat landscape increasingly accelerated by AI. In this series, we meet the individuals and teams who make up this frontline of cyber: the digital fighters.
“I truly believe most researchers do this for a greater good, and out of real curiosity, interest, and a love of problem solving,” explains Katz. As a fully self-taught researcher, he says this natural curiosity “pulled me toward security research.” Describing his team at Oligo, he explains how this shared quality “does not stop at security.” He continues: “We currently have carnivorous plants in our research office, and we’ve been trying to figure out whether we can turn them vegetarian. I think that probably explains the mentality better than I can.”
You can read the entire interview below.
ID Card
Company name: OLIGO Security
Founders: Nadav Czerninski (Co-Founder & CEO), Gal Elbaz (Co-Founder & CTO), Avshalom Hilu (Co-Founder & CPO)
Year of founding: 2022
Current number of employees: 90
Company Description:
Oligo is a runtime security platform that addresses today's toughest challenge: stopping attacks in real time without breaking production. The platform allows security teams to see what code is actually executing inside applications and uses that runtime context to stop malicious behavior in real time including zero-days, supply-chain attacks, and threats targeting AI and agentic applications. Unlike some traditional security solutions that react after the damage is done, Oligo can block the exact malicious action without taking the application down.
About Oligo's Security Research Team:
Our research spans a few tracks: vulnerability research, threat research, and innovation research that feeds the product directly. Some of it sits closer to the CTO office and some of it sits closer to R&D, and in practice the lines blur, because the same people end up pulled into the same problems.
If I had to pick between "superstars" and "soccer team," it's much closer to a soccer team. We pull together many different roles from different parts of the company to work a complex problem as one group. People have real specialties, but we don't build hard walls around them, and the interesting results tend to come from several people with different backgrounds looking at the same problem.
What is your background in cyber, and what led you to specialize in security research?
I've always been curious about how technology works, and even more curious about how it breaks. I've been building and breaking things since I was a kid: electronics, robotics, and software. I never stopped learning, exploring, and building. I'm fully self-taught, and that curiosity pulled me toward security research naturally.
I was part of the Claroty research team, where I helped build Team82, their vulnerability research group. One of the biggest milestones for me was leading our research at Pwn2Own Miami 2023, where we took #1 Master of Pwn, one of the biggest competitions in the field. Over the years I've reported and helped close dozens of critical vulnerabilities to some of the largest companies in the world, always with the goal of making those products safer.
At Oligo, that curiosity has taken me into a much broader set of problems. We research everything from application security and open-source software to programming language internals and kernel behavior. I led AirBorne, where we found 23 vulnerabilities in Apple's AirPlay protocol, including wormable zero-click RCEs, and we've continued finding serious issues in core technologies used across modern applications and cloud environments.
What does your security research team look like in action?
Exploitation and vulnerability research are at the core of what we do at Oligo. If we want to block zero-day attacks, we have to understand what real attacks actually look like.
We work with some of the largest enterprises, so we get a front-row seat to the security problems that keep teams up at night. As a researcher, that's an exciting position to be in: find what breaks next, figure out how it can be exploited, and make sure Oligo can stop it.
On any team, people naturally have specialties, but we place a strong emphasis on collaborating on problems together. Research gets much more interesting when someone with a robotics background, someone focused on AI, and someone thinking from an application-runtime perspective all look at the same problem.
And of course, AI has become one of our strongest teammates. Using it to create setups, search for vulnerable patterns, and brainstorm ideas has changed how we work over the past few years, and our research workflow leans on it heavily. It's also genuinely useful for building complex test environments and writing exploits. But we keep seeing the same thing: the more the research is actually guided by a researcher, the deeper and more impactful the results are. Letting AI go off and do the research on its own just isn't enough.
A vulnerability we recently found in Apache Tomcat is a good example. We found the bug manually, and several different AI tools missed it. But once we understood it, AI became invaluable. It was a timing-based padding oracle, and building a working exploit for something like that would normally take days for an experienced researcher. We had it in under an hour.
How does the research team influence your company at large?
Exploitation and vulnerability research are at the core of what we do at Oligo. If we want to block zero-day attacks, we have to understand what real attacks actually look like.
xed, and making Oligo sure can stop it.
On any team, people naturally have specialties, but we place a strong emphasis on collaborating on problems together. Research gets much more interesting when someone with a robotics background, someone focused on AI, and someone thinking from an application-runtime perspective all look at the same problem.
And of course, AI has become one of our strongest teammates. Using it to create setups, search for vulnerable patterns, and brainstorm ideas has changed how we work over the past few years, and our research workflow leans on it heavily. It's also genuinely useful for building complex test environments and writing exploits. But we keep seeing the same thing: the more the research is actually guided by a researcher, the deeper and more impactful the results are. Letting AI go off and do the research on its own just isn't enough.
A vulnerability we recently found in Apache Tomcat is a good example. We found the bug manually, and several different AI tools missed it. But once we understood it, AI became invaluable. It was a timing-based padding oracle, and building a working exploit for something like that would normally take days for an experienced researcher. We had it in under an hour.
What has been your team’s most significant security discovery to date?
The AirBorne vulnerabilities probably had the biggest impact with millions of affected devices. They were in Apple's AirPlay protocol, which lives in macOS devices and in a huge number of third-party speakers, TVs, and even cars using CarPlay.
It started as a curiosity moment rather than planned research. We were looking into another vulnerability the team had found, 0.0.0.0 Day, and while scanning for open ports, we noticed that every MacBook in the office was listening on port 7000. Curious about what that port was for, I started digging and found out it was AirPlay. I started reverse engineering the protocol and almost immediately got a “code smell” – that sense researchers develop for areas of code that are probably prone to issues. I wrote a really quick and dirty fuzzer just to assess which routes were open and accessible. That "fuzzer" found three vulnerabilities. The whole beginning of the research was only a few hours.
That turned into a multi-week effort where the team and I reported 23 vulnerabilities to Apple in total, which resulted in 17 CVEs. In some cases Apple grouped several of our findings into a single CVE based on how they were fixed. We later expanded the research to dissect the Bluetooth protocol and pairing mechanisms Apple CarPlay uses, the IAP2 protocol.
Who or what is your 'Moby Dick'?
I’ve never been very good at leaving questions unanswered. If something catches my attention, I usually end up digging into it until I understand how it works, where it breaks, and what happens when you push it beyond what it was designed to do. Sometimes that becomes a research project at work. Sometimes it means ordering some random piece of hardware and spending the weekend taking it apart.
That kind of curiosity is a big part of our research culture too. It's hard for us to notice something strange and just leave it alone.
And it does not stop at security. We currently have carnivorous plants in our research office, and we’ve been trying to figure out whether we can turn them vegetarian. I think that probably explains the mentality better than I can.
So I don’t have one platform or vulnerability I’ve been chasing for years. The most interesting target is usually the one I haven’t figured out yet.
How would you characterize the competition between research teams today?
Honestly, I'd describe it more as collaboration than competition. The security community in Israel specifically is remarkably collaborative and supportive. Researchers here talk to each other, share what they're seeing, and help each other through roadblocks.
Even in the places where there is real competition, like Pwn2Own, there's a huge sense of community among the researchers. You're all sitting in the same room trying to break the same things, but the atmosphere is much closer to shared obsession than rivalry. At Pwn2Own Miami, once the competition hours were over, all the competing teams went to dinner together. We spent the entire day trying to beat each other and the evening at the same restaurant talking through approaches, life, and everything in between.
I truly believe most researchers do this for a greater good, and out of real curiosity, interest, and a love of problem solving. That's what combines us, more than anything we'd compete over.
What is your take on the future of the human security researcher?
AI automates a lot of the day to day work, but it's the same story as with developers: it helps you write parts of the code, verify things, check your work, operate at higher capacity, and you still need a developer to write good, complex code. It's a force multiplier rather than a replacement.
There are some real parallels to the fuzzing revolution a few years back. When American Fuzzy Lop (AFL) came out and became widely used, you could point it at almost any open source project and get a few vulnerabilities out of it. That first pass was extremely productive. What we're seeing with AI today feels similar. AI is having its AFL moment. Right now you can throw AI at a project and it'll find the low-hanging fruit, but that basic attack surface will eventually get covered, the same way it did with fuzzing.
Once that settles, what's left is what humans are still uniquely good at: holding complex context and state in your head, creativity, critical thinking, and being able to see the full picture of a product and where it's actually weak, not just in the code, but logically.
We ran a test on this. We took an open source project and had a non-security-researcher from our marketing team run multiple AI passes against it looking for vulnerabilities. It produced a few nice findings. But the critical ones, the bugs that led to real impact, only turned up once our researchers stepped into the loop.
On the defender side, AI also makes the old Common Vulnerabilities and Exposures (CVE)-first model much harder to rely on. If attackers can discover and exploit vulnerabilities faster, defenders cannot assume they will always know the CVE in advance or have enough time to patch before exploitation starts. That makes runtime protection much more important. The goal has to be to understand and block the underlying exploit techniques, so when the next zero-day appears, you can stop it even if you've never seen that specific vulnerability before.
