Before sandbox escapes became one of AI security’s loudest conversations, pwn spent weeks inside nested KVM, built a 14,338-line exploit harness, and made Google’s live kvmCTF host return the flag. This is the story of what happened inside the sandbox.

Security Advisory

Introduction What if I told you six thousand of your employees were two steps removed from gaining full control over your IT infrastructure. If we told you this was related...

Learn Basic Concepts of Linux. Best site to learn Linux from beginner to Advanced.

Unlocking _everything_ on the CPU with DRAM scrambling - xoreaxeaxeax/skitter-creek-bath-salts

先知社区是一个安全技术社区，旨在为安全技术研究人员提供一个自由、开放、平等的交流平台。

SafeBreach Labs uncovered 3 severe flaws in Telnet and Samba, two CVSS 10.0 RCEs and a root privilege escalation, hiding in legacy Linux services for decades.

Read the research that led to the discovery of Active Directory privilege escalation vulnerabilities CVE-2026-25177 and CVE-2026-27912.

You can outsource the hacking, but not the understanding

GhostLock (CVE-2026-43499) is a Linux kernel vulnerability found by Nebula Security that exists in every major distribution since 2011. After turning it into a stable privilege escalation and container escape, we took one step further and used GhostLock to develop the world’s first public Android 17 root. This writeup covers the additional exploit techniques used to migrate the exploit for Android.

Flowdiss explores how BPF_PROG_TYPE_FLOW_DISSECTOR can be abused to forge the Linux kernel's notion of packet flow identity without modifying packet contents. By manipulating the flow_keys used to derive skb-hash, a privileged eBPF program can influence downstream consumers such as RPS, GRO, ECMP, and other eBPF programs that rely on the cached flow hash. The article presents a proof of concept, validates its effects and limitations, and demonstrates how a separate BPF LSM program can conceal the attack from standard bpftool enumeration, illustrating both an underexplored attack surface and the limits of relying on user-space BPF tooling on a compromised system.

This post walks through a sandbox escape from a Flatpak application via PipeWire. The vulnerability was discovered using my automated research pipeline with …

A clear look into DarkSword, the latest public Kernel Exploit up to iOS 26.0.1, its root cause, and its reimplementation as ClearSword.

On Tuesday, July 14, Microsoft released the largest Patch Tuesday update in its history, fixing more than 600 vulnerabilities. A bug I reported to Microsoft on May 17 was patched as CVE-2026-50458 in this release, so I am publishing the writeup I wrote at the time, while the details were still fresh. I hope you enjoy it!

Technical breakdown of OnlyShells — a five-vulnerability chain in ONLYOFFICE Desktop Editors combining zero-click XSS, a Chromium V8 RCE, and an update-service LPE to achieve remote code execution as NT AUTHORITYSYSTEM when a victim opens a crafted document.

Fraggap (CVE-2026-53362) is a bug in the Linux UDPv6 corking path that allows a 15-byte OOB write into skb_shared_info. The code is here. {.markdown-image-centered} CONFIG_IPV6=y...

pHi everyone! Today gongjae is back with Step 5 — the crown jewel of the Wipeload project, haha./p pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image.png" alt="image"/p blockquote pPrevious research postsbra href="https://hackyboiz.github.io/2026/06/06/OUYA77/Wipeload_step1/kr/"https://hackyboiz.github.io/2026/06/06/OUYA77/Wipeload_step1/kr//abra href="https://hackyboiz.github.io/2026/06/21/ji9umi/Wipeload_step2/kr/"https://hackyboiz.github.io/2026/06/21/ji9umi/Wipeload_step2/kr//abra href="https://hackyboiz.github.io/2026/06/26/ji9umi/Wipeload_step3/kr/"https://hackyboiz.github.io/2026/06/26/ji9umi/Wipeload_step3/kr//abra href="https://hackyboiz.github.io/2026/07/13/OUYA77/Wipeload_step4/kr/"https://hackyboiz.github.io/2026/07/13/OUYA77/Wipeload_step4/kr//a/p /blockquote pSteps 2–3 covered ji9umi’s Renderer RCE, and in Step 4 OUYA77 gave us a detailed tour of the Chrome sandbox. Picking up that Way from both of them, I’m going to walk you through — in detail — stronghow do we actually get to Medium-privilege code execution from Chrome?/strong In today’s Step 5 I’ll explain ALPC, the key ingredient of the Sandbox Escape, and in Step 6 we’ll take that ALPC and see how it takes us all the way to Medium-privilege code execution!/p pShall we get right into it? Let’s go~/p h1 id="1-Sorry-I-studied-ALPC-just-to-show-you-this"a href="#1-Sorry-I-studied-ALPC-just-to-show-you-this" class="headerlink" title="1. Sorry, I studied ALPC just to show you this"/a1. Sorry, I studied ALPC just to show you this/h1pALPC (Advanced Local Procedure Call) is the IPC that sits at the very bottom of process-to-process conversations inside Windows. The local RPC we’re all familiar with, at the kernel level, mostly ends up riding ALPC too, and system services everyone has heard of like “csrss.exe” or “lsass.exe”, DCOM, WinRT activation… pretty much every user-mode service is talking over an ALPC port somewhere. Chrome is no exception — the Mojo IPC pipe between the renderer and the browser has ALPC partially baked into its underlying transport. Which is to say: the object we’re going to be poking at today is dead common, but the kind of thing you’d miss unless you look closely!!/p pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image2.png" alt="image"/p blockquote p?? : You studied ALPC just to do THIS?brgongjae : delNope, just did it for fun/del/p /blockquote pInside the kernel, two objects star in this show. code_ALPC_PORT/code is the communication endpoint, and codeKALPC_MESSAGE/code is a single message flowing through that endpoint. Easiest mental model: server opens a port, clients attach, they exchange messages!/p pa href="https://hackyboiz.github.io/2025/11/29/gongjae/Windows_ALPC/KR/"https://hackyboiz.github.io/2025/11/29/gongjae/Windows_ALPC/KR//a/p pActually, we already went over ALPC once in a previous research post, right? Stuff like the port splitting into two tiers of connection port / communication port, and basic message-attribute concepts — I put all of that together in the earlier ALPC post! If this is your first time hearing about ALPC, I’d recommend giving that one a skim first… but honestly the single most important fact is: stronghow does the Chrome sandbox treat ALPC?/strong/p pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image3.png" alt="image"/p pThe answer: the codeNtAlpc*/code family of syscalls themselves are strongnot/strong on the sandbox’s filter list!! Even though it’s an undocumented interface with nothing on the official docs, it’s a very-much-alive API, so even an Untrusted IL renderer can call the stubs codentdll/code exports directly./p h2 id="1-1-Sync-vs-Async"a href="#1-1-Sync-vs-Async" class="headerlink" title="1.1 Sync vs Async"/a1.1 Sync vs Async/h2pThere are two ways to send a message over ALPC. strongAsync/strong requests toss the request onto a queue and the calling thread goes on its merry way. strongSync/strong requests, on the other hand, park the calling thread inside the kernel until an answer comes back!/p pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image4.png" alt="image"/p pFor the kernel to sustain that “parked” state, it obviously needs some info, right? Which thread is waiting on which message, who to wake up when the reply lands — that stuff has to be recorded somewhere!/p aside 💡 Quick aside on why the two modes are asymmetric here: async requests don’t need the kernel to know “who’s waiting on this reply?” As long as the completion callback is correctly registered, we’re done. 🫠 Sync is a different story though. The moment the reply arrives, the kernel code handling it has to figure out **“okay, I got this — who exactly am I supposed to wake up??”**, and that answer has to be pre-stored as a back-pointer somewhere. /aside h2 id="1-2-Waiting-thread"a href="#1-2-Waiting-thread" class="headerlink" title="1.2 Waiting thread"/a1.2 Waiting thread/h2pSo when a sync request comes in, the kernel slips a back-pocket pointer into the message object that says “the thread waiting on this message’s reply is THIS guy!!” That’s the code_KALPC_MESSAGE.WaitingThread/code field, and in the environment I’m experimenting with today, Windows 22H2 22621.963, it lives at offset +0x20./p pThere’s a matching field going the other direction too. On the thread side there’s a field that records “the message I’m currently waiting on is THIS guy!!” — that’s code_ETHREAD.AlpcMessageId/code, located at offset +0x578. WaitingThread from earlier and this AlpcMessageId form a pair of back-pointers pointing at each other!/p pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image5.png" alt="image"/p blockquote pKind of like how Tai Lung and Master Shifu shared a special bond back when Tai Lung was little…/p /blockquote pThere’s a reason the kernel bothers to write this pair with code_InterlockedExchange/code atomically… since the same thread can be touched from multiple places at once, you need atomicity to avoid races. 😂/p pBut even so — when the pair matches it’s beautiful, and the moment one side falls out of step, that’s when things go sideways. The main character of today’s vuln is this very field, and an unmanaged back-pointer is guaranteed to blow up in your face sooner or later, haha!/p h1 id="2-Root-Cause"a href="#2-Root-Cause" class="headerlink" title="2. Root Cause"/a2. Root Cause/h1pAlright, as I said above, we need to see why this unmanaged back-pointer is the seed of the vuln, right? But first, let’s quickly review sync vs async messaging through some code!/p h2 id="2-1-ALPC-MSGFLG-SYNC-REQUEST"a href="#2-1-ALPC-MSGFLG-SYNC-REQUEST" class="headerlink" title="2.1 ALPC_MSGFLG_SYNC_REQUEST"/a2.1 ALPC_MSGFLG_SYNC_REQUEST/h2pThe entry point where a message actually lands on the queue is codeAlpcpDispatchNewMessage/code. That “somewhere in the middle” I mentioned earlier is right here! Looking at it in IDA it feels like this:/p precode class="hljs cpp"span class="hljs-keyword"if/span ((SendFlags & span class="hljs-number"0x20000/span) != span class="hljs-number"0/span) { span class="hljs-comment"// ALPC_MSGFLG_SYNC_REQUEST/span span class="hljs-comment"// plant the thread back-pointer/span *(_QWORD *)(msg + span class="hljs-number"0x20/span) = curthread; span class="hljs-comment"// msg.WaitingThread = current _ETHREAD/span _InterlockedExchange64(curthread + span class="hljs-number"0x578/span, msg); span class="hljs-comment"// _ETHREAD.AlpcMessageId = msg/span }/code/pre pTwo lines, that’s the whole trick. Stuff the current thread’s code_ETHREAD/code directly into codemsg+0x20/code, and conversely plant the message at codecurthread + 0x578/code. That completes the pair of back-pointers pointing at each other./p pLet’s also briefly trace how SendFlags gets here./p aside 💡 When user code calls `NtAlpcSendWaitReceivePort`, the kernel enters `AlpcpSendMessage`, decides routing, and then hands off to this `AlpcpDispatchNewMessage`. The trigger I’m using today goes through `NtWaitForWorkViaWorkerFactory`, but even there — the moment it processes a deferred send — we end up at that same dispatch site. → Bottom line: no matter which road you take, if `SendFlags & 0x20000` is satisfied, those two lines run!! /aside pcodeSendFlags & 0x20000/code is checking the codeALPC_MSGFLG_SYNC_REQUEST/code flag — if it were an async request, those two lines get skipped wholesale, right? So to hit this vuln you absolutely have to set 0x20000 in SendFlags and take the sync-request branch. The original Theori blog really emphasized this too!!/p pOne more thing worth noting: the reason the setting is stamped in both directions is to leave no gaps when routing the reply. But this pair hides a fun little asymmetry — would you believe me???/p pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image6.png" alt="image"/p ol liWhen the thread dies, the code_ETHREAD/code gets deleted entirely, so the codeAlpcMessageId/code on the other side also disappears with it/li liBut the WaitingThread planted on the message side stays right there as long as the message is alive/li /ol pThis asymmetry is exactly the starting point of the vulnerabi

TL;DR: it was possible to obtain NT AUTHORITY\SYSTEM privileges from the perspective of an unprivileged user using Foxit PDF Reader. The…

See how the "There and Back Again" NTLM relay attack coerces outbound auth to compromise Active Directory, plus the defenses that stop it.

Essential Kubernetes security best practices — pod security, RBAC, network policies, and runtime protection for containerized workloads.

By Oliver Sieber Overview In this blog post, we discuss a use-after-free vulnerability that we found in the nftables subsystem of the Linux kernel in early 2025. This vulnerability was patched upstream on 5 February 2026 and assigned CVE-2026-23111. This blog post covers a technical analysis of the vulnerability and how we exploited it to perform a local ... Read more Off By !: Exploiting a Use-after-Free in the Linux Kernel

The Problem If you are like me, you have found yourself digging through Microsoft specifications and RFC documentation trying to wrangle with a new exploit or tooling to get DA faster than your peers. The biggest problem one may encounter is the specifications are meant for developers; they will tell you the song and dance in its entirety, but it never goes beyond in any way that may be useful for you to weaponize. Fixing that may potentially lay with using the Windows 2003 Source code.

A journey into the USR-G806AU 4G LTE industrial router. From fake root accounts to real and undocumented root accounts, and the discovery of hardcoded credentials that expose devices to remote compromise.

Vulnerability research blog

When this bug shipped, the dinosaurs had just gone extinct, only 64.999979 million years prior.