The Story of a Perfect Exploit Chain: Six Bugs That Looked Harmless Until They Became Pre-Auth RCE in a Security Appliance
It was May 2024, and our internal security team was evaluating the LogPoint SIEM/SOAR platform to replace our existing platform, potentially. As part of a habit I’ve built over the years —and honestly, part of our 3rd party due diligence— I gave myself 24 hours to do what I always do with any technology we’re about to trust: try to break it.
Those 24 hours were enough to uncover three serious vulnerabilities almost immediately. Given their impact, I stopped there and proceeded directly to responsible disclosure.
Months later, with time finally on my side, I came back not to look for more bugs but to better understand the system. That second look revealed something far more interesting: how small, seemingly independent 6 bugs could coalesce into a much larger problem.
This article tells that story. It follows a hacker human’s reasoning as it navigates unfamiliar code, undocumented behavior, and assumptions never meant to be tested. Along the way, it includes wrong turns and dead ends, but also the moments where something subtle feels off and careful inspection turns that feeling into a concrete finding.
I hope you’ll enjoy the journey as much as I did. Happy New Year to everyone 🎊🥳
TL;DR: This write-up walks through the exact process of building a pre-auth RCE exploit chain by chaining 6 small bugs . I start by mapping the appliance’s request flow (two Nginx layers and a split between host Python services and Docker-based Java microservices). From there, the chain forms step by step: exposed internal routes lead to auth primitives, a hard-coded signing secret enables forged access, leaked internal API credentials unlock higher privilege inside the microservice world, an SSRF pivot reaches host-only Python endpoints to mint an admin session, and finally, a rule-engine eval() sink becomes reachable by bypassing validation via a static AES encryption key in imported alert-rule packages. Each section shows the evidence, the reasoning, and how one weakness becomes the leverage for the next, until the final trigger executes code on the appliance.
1. Accessing the main software code-base
This was the part I expected to be boring. The research started the usual way, with an .iso image and a fresh VM in my local lab. Since the product was built on top of Ubuntu without additional hardening at the OS level, the standard Ubuntu recovery workflow was enough to regain root access and enable SSH, leaving me with a stable environment ready for analysis.
With access in place, I moved on to the code. The main web application was written in Python, built on a customized Flask framework, and lived under:
... continue reading