<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Essam Alanazi</title><link>https://xpw6.github.io/</link><description>Recent content on Essam Alanazi</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 12 Apr 2026 12:00:00 +0300</lastBuildDate><atom:link href="https://xpw6.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>Escaping Kubernetes Operators: Hardlink Traversal and the ZipSlip Blind Spot</title><link>https://xpw6.github.io/research/escaping-kubernetes-operators/</link><pubDate>Sun, 12 Apr 2026 12:00:00 +0300</pubDate><guid>https://xpw6.github.io/research/escaping-kubernetes-operators/</guid><description>&lt;h1 id="escaping-kubernetes-operators-hardlink-traversal-and-the-zipslip-blind-spot"&gt;Escaping Kubernetes Operators: Hardlink Traversal and the ZipSlip Blind Spot&lt;/h1&gt;
&lt;p&gt;&lt;strong&gt;Note:&lt;/strong&gt; This vulnerability was independently discovered during a bug bounty engagement. Although it was ultimately marked as a duplicate, I am sharing this write-up due to its critical severity (CVSS 10.0) and to highlight the interesting technical mechanics of hardlink traversal in Kubernetes operators. The vulnerability has since been confirmed patched by the vendor.&lt;/p&gt;
&lt;p&gt;Kubernetes operators run at a position of extraordinary trust. They typically execute as highly privileged DaemonSets, pulling external state like container images, configs, and agent binaries, then unpacking it directly onto host nodes so it can be mounted into user workloads. That makes the unpacking step a critical security boundary: if it&amp;rsquo;s flawed, the operator becomes a confused deputy, faithfully writing files on behalf of an attacker.&lt;/p&gt;</description></item></channel></rss>