[{"content":"What I Do I break things for a living — systems, applications, infrastructure, whatever runs code. Security engineer by trade, offensive operator by mindset. I spend my time finding the cracks before someone else does, and building the defenses that actually hold.\nMy work spans red teaming, application security, cloud infrastructure hardening, and the kind of deep technical analysis that makes developers uncomfortable and security teams better.\nExperience Security Engineer Current\nWorking across offensive and defensive security — red team operations, vulnerability research, and building security tooling that scales. Focus areas include cloud security, application security, and supply chain risk.\nCertifications Offensive Security Certified Professional (OSCP) CompTIA Security+ CompTIA PenTest+ eLearnSecurity Certified Professional Penetration Tester (eCPPT) Focus Areas Red Teaming \u0026amp; Offensive Operations — Adversary simulation, breach simulation, and testing defenses under realistic conditions Application Security — Code review, threat modeling, and secure architecture design Cloud Security — AWS, GCP, and Azure security hardening, IAM policy review, and infrastructure-as-code auditing Supply Chain Security — Dependency analysis, build system integrity, and software composition analysis Vulnerability Research — Deep dives into how things break, responsible disclosure, and building exploit chains Contact GitHub: izhax X: @izhax LinkedIn: izhax This page is a living document. Updated as things change.\n","permalink":"https://izhax.pages.dev/about/","summary":"\u003ch2 id=\"what-i-do\"\u003eWhat I Do\u003c/h2\u003e\n\u003cp\u003eI break things for a living — systems, applications, infrastructure, whatever runs code. Security engineer by trade, offensive operator by mindset. I spend my time finding the cracks before someone else does, and building the defenses that actually hold.\u003c/p\u003e\n\u003cp\u003eMy work spans red teaming, application security, cloud infrastructure hardening, and the kind of deep technical analysis that makes developers uncomfortable and security teams better.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"experience\"\u003eExperience\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eSecurity Engineer\u003c/strong\u003e\n\u003cem\u003eCurrent\u003c/em\u003e\u003c/p\u003e","title":"About"},{"content":"A curated collection of blogs, tools, and resources I find valuable. This page is a work in progress — more coming soon.\nLast updated: May 2026\n","permalink":"https://izhax.pages.dev/recommendations/","summary":"\u003cp\u003eA curated collection of blogs, tools, and resources I find valuable. This page is a work in progress — more coming soon.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cem\u003eLast updated: May 2026\u003c/em\u003e\u003c/p\u003e","title":"Links"},{"content":"The Worm That Doesn\u0026rsquo;t Need a Vulnerability In February 2026, researchers documented something that should have made every security team stop and reassess their AI strategy: a self-propagating generative worm that spreads through AI agents without exploiting a single code vulnerability.\nNo buffer overflow. No unpatched CVE. No zero-day.\nThe worm exploits the agent itself — its ability to read context, make decisions, and take actions. An infected agent propagates the attack to other agents through shared context. The agent\u0026rsquo;s intelligence becomes the attack vector.\nWe\u0026rsquo;ve spent years building defenses against code-level exploits. We have scanners for known vulnerabilities, signature-based detection, behavioral analysis of binary execution. None of that applies here. The attack lives in the space between the code — in the natural language instructions, the tool descriptions, the context windows that shape how agents behave.\nThis isn\u0026rsquo;t theoretical. The research is published. The attack chains are documented. And most organizations running AI agents in production have no defenses against any of it.\nWhat\u0026rsquo;s Actually Happening The scale of the problem is worse than most people realize. Researchers built the first labeled dataset of AI agent skills by behaviorally verifying 98,380 skills from community registries. The findings were stark:\n157 malicious skills confirmed, carrying 632 vulnerabilities between them Malicious skills average 4.03 vulnerabilities across a median of three kill chain phases A single actor was responsible for 54.1% of confirmed cases — using templated brand impersonation, not sophisticated techniques A separate analysis of 42,447 skills found that 26.1% contain at least one vulnerability. The most common: data exfiltration (13.3%) and privilege escalation (11.8%). Skills with executable scripts are 2.12x more likely to be vulnerable than instruction-only skills.\nThese aren\u0026rsquo;t edge cases. This is the baseline.\nThe ClawHavoc Campaign The clearest example of what\u0026rsquo;s coming is the ClawHavoc campaign from early 2026. Over 1,200 malicious skills were injected into the OpenClaw marketplace. A companion catalog documented 6,487 malicious tools that evade conventional detection.\nThis wasn\u0026rsquo;t a nation-state operation. It was systematic marketplace poisoning — the AI equivalent of typosquatting on npm, but with a critical difference: these skills execute with user privileges and interact directly with sensitive systems.\nThe barrier to entry was a well-crafted description and a few lines of code. The marketplace had minimal vetting. The skills looked legitimate because the descriptions were optimized to game the agent\u0026rsquo;s own selection process.\nWhen a developer asked their agent to \u0026ldquo;help with database management,\u0026rdquo; the agent would search for relevant skills, find the malicious one (because its description was engineered to rank highly), and execute it with full user privileges. The developer never saw the code. The agent never questioned the source.\nAttack Vectors You Can\u0026rsquo;t Scan For Weaponized Config Files The most insidious attack vector isn\u0026rsquo;t code — it\u0026rsquo;s configuration. Researchers demonstrated that SKILL.md files, the natural-language metadata that tells agents what a skill does, can be weaponized to hijack agent behavior.\nBy manipulating these files, attackers achieved 86% pairwise win rate in embedding-based retrieval and 80% Top-10 placement in skill recommendation systems. Adversarial variants were selected in 77.6% of paired trials.\nThis is supply chain poisoning through language. Traditional scanners don\u0026rsquo;t catch it because there\u0026rsquo;s nothing to scan. The attack vector is a sentence, not a script.\nBackdoors That Survive Model Swaps The chat template attack is particularly concerning for anyone using open-weight models. Researchers showed that maliciously modified Jinja2 chat templates can implant backdoors without touching model weights. Under triggered conditions, factual accuracy drops from 90% to 15%, and attacker-controlled URLs are emitted with success rates exceeding 80%.\nThese backdoors evade every automated security scan applied by the largest open-weight distribution platform. When you download a model from Hugging Face, the chat template is a separate file. Modify that, and you\u0026rsquo;ve compromised every inference call.\nThe LoRA Problem LoRA adapters are the primary way organizations customize foundation models. They\u0026rsquo;re shared freely, downloaded casually, and integrated without the scrutiny you\u0026rsquo;d apply to traditional dependencies.\nMasqLoRA demonstrated that standalone LoRA modules can serve as attack vehicles with a 99.8% attack success rate. For robotics applications, LoRA-based backdoors in LLM-mediated ROS2 systems achieved 83% attack success while maintaining 93% clean performance accuracy.\nThe model works fine. It passes all your tests. It also exfiltrates data when it sees a specific trigger.\nPickle Deserialization: The Old Problem in a New Context Every time you load a model with torch.load() or pickle.load(), you\u0026rsquo;re trusting that the file doesn\u0026rsquo;t contain malicious code. Researchers identified 22 distinct pickle-based model loading paths across five major frameworks. 19 of those paths are entirely missed by existing scanners. They found 133 exploitable gadgets achieving almost 100% bypass rate.\nThis is the same deserialization vulnerability class we\u0026rsquo;ve been dealing with in web applications for a decade, now living in the ML supply chain. The only difference is that nobody\u0026rsquo;s patching it because it\u0026rsquo;s not in a CVE database.\nThe MCP Problem The Model Context Protocol is becoming the standard for connecting AI agents to external tools and data sources. It\u0026rsquo;s also becoming a significant attack surface.\nThe protocol itself isn\u0026rsquo;t broken. The problem is that we\u0026rsquo;re connecting agents to external systems with the same trust model we used for human users. Agents operate at machine speed and scale — a compromised MCP server can serve thousands of agent invocations before anyone notices.\nThree adversary types exploit MCP:\nContent-injection attackers who manipulate tool descriptions to influence agent behavior Supply-chain attackers who distribute compromised MCP servers through community registries Agents that over-step their roles, escalating privileges beyond their intended scope The most concerning finding: three moderate/high-severity advisories in OpenClaw composed into a complete unauthenticated remote code execution path. A malicious skill executed a two-stage dropper within the LLM context, bypassing the exec pipeline entirely.\nIndividual vulnerabilities that seem manageable in isolation compose into critical attack chains when agents are involved.\nWhat This Means for Your Monday Morning If you\u0026rsquo;re running AI agents in production — whether it\u0026rsquo;s coding assistants, customer service bots, or internal tooling — here\u0026rsquo;s what you need to do this week:\n1. Audit your agent\u0026rsquo;s tool access. Map every MCP server, every skill, every external tool your agent can reach. If you can\u0026rsquo;t enumerate it, you can\u0026rsquo;t secure it.\n2. Treat agent skills as dependencies, not config. Apply the same scrutiny you\u0026rsquo;d apply to npm packages. Cryptographic signing, dependency analysis, reproducible builds.\n3. Sandbox agent execution. Every skill invocation should run in an isolated environment with least-privilege defaults. If a skill needs database access, it gets read-only access to a specific table, not a connection string.\n4. Monitor agent behavior, not just code. Traditional security tools scan code. Agent attacks live in natural language. You need behavioral monitoring that catches anomalous agent actions — unexpected network calls, unusual data access patterns, privilege escalation attempts.\n5. Implement kill switches. If an agent starts behaving anomalously, you need the ability to halt execution immediately. Not after the incident review. Now.\n6. Audit your model supply chain. Every model, LoRA adapter, and chat template should have provenance. If you can\u0026rsquo;t trace where it came from and verify its integrity, don\u0026rsquo;t use it in production.\nThe Uncomfortable Truth We\u0026rsquo;re making the same mistakes with AI agents that we made with traditional software supply chains — trusting too much, verifying too little, and assuming the best about our dependencies.\nThe difference is that AI agents operate at machine speed, interact with sensitive systems directly, and make decisions that affect real outcomes. A compromised agent isn\u0026rsquo;t just a vulnerability in a library. It\u0026rsquo;s a compromised decision-maker with access to your infrastructure.\nThe research is clear. The attack vectors are real. The defenses are lagging.\nThe question isn\u0026rsquo;t whether AI agents will be used in supply chain attacks. It\u0026rsquo;s whether you\u0026rsquo;ll have defenses ready when it happens.\n","permalink":"https://izhax.pages.dev/posts/ai-agents-supply-chain-disaster/","summary":"Self-propagating worms, weaponized config files, and backdoors that survive model swaps. The research is in, and it\u0026rsquo;s worse than most people realize.","title":"Your AI Agent Is a Supply Chain Attack Waiting to Happen"}]