Learn with me :)

Introduction COM hijacking is one of those vulnerabilities that doesn't come from a coding mistake in the traditional sense — it comes from a design decision in how Windows resolves component lookups, combined with default permissions that favor convenience over security. The result is that a completely standard, unprivileged user can quietly redirect a trusted application into loading a DLL of their choosing, with no admin rights and no UAC prompt involved anywhere in the process. What COM Hijacking is? COM (Component Object Model) is a Windows system that lets applications borrow features from each other without needing to know where those features actually live on disk. An application essentially says "give me the PDF renderer," and Windows looks up a registry key called a CLSID to determine which DLL provides that feature, then loads it. What Is a CLSID? A CLSID is a unique 128-bit identifier (a GUID) assigned to every COM component. It looks something lik...

  Introduction Not every critical vulnerability lives inside an application's source code. Some of the most reliable local privilege escalation paths on Windows come from a single misconfigured line in the registry — no buffer overflow, no malicious input, no clever exploit chain. The Unquoted Service Path vulnerability is one of these: a decades-old, still-common misconfiguration that turns a missing pair of double quotes into a way for a standard user to run code as SYSTEM. This post walks through what's actually vulnerable, how Windows' path-parsing behavior creates the opening, how to find and reproduce the issue, and how to fix it for good. What's Actually Vulnerable — It's Not the Application's Code The first thing to understand is what isn't the problem. The application's executable — say, target.exe — is not buggy, not modified, and not touched in any way by this vulnerability. It sits safely on disk, completely unchanged, before, during...