“Life finds a way.”
— Dr. Ian Malcolm, Jurassic Park
Cybersecurity, like nature, is a constant battle between order and chaos. Just as life adapts and thrives in even the harshest conditions, attackers always find a way to breach defenses, no matter how well-crafted they may seem. This is perfectly exemplified by the recent active exploitation of CVE-2025-0108 in Palo Alto’s PAN-OS.
This vulnerability—a high-severity authentication bypass—didn’t grant attackers full control on its own. Instead, they chained it with other lower-severity flaws to escalate privileges and read sensitive files. This is a textbook example of why patching alone is never enough. Organizations must assume that attackers will always find a way, working around fixes and chaining vulnerabilities to devastating effect.
If security teams continue to think of patching as a complete fix, they will always be one step behind attackers. Instead, security must be designed with the assumption that there is no such thing as perfect code. Attackers will find a way in. If not through one flaw, then by chaining multiple. But that doesn’t mean you should throw in the towel. Security can be redesigned to prevent exploitation at runtime. Rather than relying on patch cycles, security should actively neutralize exploits as they execute.
While Waratek doesn’t directly protect firewalls like PAN-OS, this incident shows that defensive strategies must evolve beyond patching to focus on resilience. This is precisely where our technology excels. By enforcing security at runtime, Waratek ensures that even if attackers discover a new vulnerability or chain multiple CVEs, they can’t execute their exploit. As a result, exploit chains break down and attackers hit a dead end. Let’s explore how.
The Lifecycle of a Vulnerability
The exploitation of CVE-2025-0108 didn’t happen in isolation. It was discovered as an authentication bypass affecting PAN-OS’s web management interface. Initially, it was labeled high severity (CVSS 8.8) because it allowed unauthenticated attackers to invoke certain PHP scripts—but it did not enable direct remote code execution.
However, attackers didn’t stop at just one flaw. They chained CVE-2025-0108 with:
- CVE-2024-9474 – A privilege escalation vulnerability.
- CVE-2025-0111 – A file read vulnerability that exposed sensitive configuration files.
This exploit chain enabled attackers to move from bypassing authentication to escalating privileges and reading sensitive system files. This is a common attack pattern across all platforms, including Java applications. Low-severity CVEs are often ignored by defenders—but attackers can weaponize them together for high-impact breaches.
The Workaround Problem: Patching ≠ Security
The assumption that a patch fully mitigates a vulnerability is dangerously optimistic. Attackers analyze patches to understand how security mechanisms work, then find ways to bypass them.
In the case of PAN-OS, its authentication model relied on a proxy layer that forwarded requests to a second layer with different behavior. This led to header smuggling and path confusion attacks, where malicious actors manipulated request headers to sidestep authentication.
This pattern is quite familiar in the world of Java security. A patched SQL injection flaw might still allow attackers to exploit a different injection point within the same database query. A fixed deserialization vulnerability could be bypassed using a new gadget chain in a different class. Security isn’t just about fixing one bug—it’s about recognizing how attackers think and blocking entire classes of exploitation techniques.
Waratek’s Fresh Approach
Traditional security solutions focus on detecting and patching vulnerabilities, but Waratek stops exploits at runtime by enforcing security directly within the Java runtime itself. Unlike firewalls or static analysis tools, Waratek operates by providing a secure execution pathway for vulnerable code, neutralizing threats before they execute—even if attackers attempt to chain multiple vulnerabilities together.
Waratek uses a domain-specific language (called ARMR) that allows security policies to be enforced at runtime. This approach enables precise control over application execution, preventing common exploit techniques like SQL injection, command injection, and insecure deserialization attacks. Waratek achieves this through virtual patching and real-time policy enforcement, applied dynamically within the runtime without modifying the application’s source code.
- Blocking SQL injection Attempts: Waratek monitors SQL queries at runtime, ensuring that only legitimate, pre-approved query structures are executed. Any attempt to introduce malicious SQL payloads through user input is intercepted and blocked before reaching the database driver.
- Blocking Command Injection Attempts: Waratek inspects process execution requests within the JVM, preventing untrusted input from being passed to system commands.
- Neutralizing Deserialization Attacks: Waratek enforces strict input validation on objects before they are instantiated, blocking unsafe classes that could be exploited for remote code execution.
Additionally, Waratek enforces strict request validation to prevent API abuse and unintended behavior. It inspects headers, parameters, and payloads in real time, ensuring that only expected data formats and types are processed. This runtime control makes exploit chaining impossible—even if attackers discover a new vulnerability, they cannot execute their attack path.
Make Life Harder for Attackers
Attackers are relentless. If one exploit path is blocked, they will get creative and find another. Organizations relying solely on patching are trapped in an endless race, always reacting while attackers stay one step ahead. Instead of playing defense, security teams must actively disrupt attack chains by making exploitation as impractical as possible.
Waratek breaks exploit chains before they execute, enforcing security inside the JVM. By neutralizing SQL injection, command execution, and deserialization exploits at runtime, Waratek ensures that even if vulnerabilities exist, they can’t be exploited.
