Elusive Thoughts

How CLI Automation Becomes an Exploitation Surface Securing Skill Templates Against Malicious Inputs There’s a familiar lie in engineering: it’s just a wrapper . Just a thin layer over a shell command. Just a convenience script. Just a little skill template that saves time. That lie ages badly. The moment a CLI tool starts accepting dynamic input from prompts, templates, files, issue text, documentation, emails, or model-generated content, it stops being “just a wrapper” and becomes an exploitation surface. Same shell. Same filesystem. Same credentials. New attack path. This is where teams get sloppy. They see automation and assume efficiency. Attackers see trust transitivity and start sharpening knives. The Real Problem Isn’t the CLI The shell is not new. Unsafe composition is. Most modern automation stacks don’t fail because Bash suddenly became more dangerous. They fail because developers bolt natural language, templates, or tool-chaining onto CLIs without rethinking ...

When LLMs Get a Shell: The Security Reality of Giving Models CLI Access Giving an LLM access to a CLI feels like the obvious next step. Chat is cute. Tool use is useful. But once a model can run shell commands, read files, edit code, inspect processes, hit internal services, and chain those actions autonomously, you are no longer dealing with a glorified autocomplete. You are operating a semi-autonomous insider with a terminal. That changes everything. The industry keeps framing CLI-enabled agents as a productivity story: faster debugging, automated refactors, ops assistance, incident response acceleration, hands-free DevEx. All true. It is also a direct expansion of the blast radius. The shell is not “just another tool.” It is the universal adapter for your environment. If the model can reach the CLI, it can often reach everything else. The Security Model Changes the Moment the Shell Appears A plain LLM can generate dangerous text. A CLI-enabled LLM can turn dangerous text i...

Browser-Use Agents and Server-Side Request Forgery: Old Vulns, New Vectors SSRF is not new. It’s been on the OWASP Top 10 since 2021, it’s been in every pentester’s playbook for a decade, and it’s the reason you’re not supposed to let user input control outbound HTTP requests from your server. We know how to prevent it. We know how to test for it. We’ve written the cheat sheets, the detection rules, the WAF signatures. And then we gave AI agents a browser and told them to “go look things up.” SSRF is back, and this time it’s wearing a trench coat made of natural language. The Old SSRF: A Quick Refresher Classic SSRF is straightforward: an application takes a URL from user input and makes a server-side request to it. The attacker supplies http://169.254.169.254/latest/meta-data/ instead of a legitimate URL. The server dutifully fetches AWS credentials from the instance metadata service and hands them to the attacker. Game o...

The OWASP Top 10 for AI Agents Is Here. It's Not Enough. In December 2025, OWASP released the Top 10 for Agentic Applications 2026 — the first security framework dedicated to autonomous AI agents. Over 100 researchers and practitioners contributed. NIST, the European Commission, and the Alan Turing Institute reviewed it. Palo Alto Networks, Microsoft, and AWS endorsed it. It’s a solid taxonomy. It gives the industry a shared language for a new class of threats. And it is nowhere near mature enough for what’s already happening in production. Let me explain. What the Framework Gets Right Credit where it’s due. The OWASP Agentic Top 10 correctly identifies the fundamental shift: a chatbot answers questions, an agent executes tasks . That distinction changes the entire threat model. When you give an AI system the ability to call APIs, access databases, send emails, and execute code, you’ve created something with real operational authority. A compromi...

Your App Store Won't Save You: Mobile Malware & Supply Chain Poisoning in 2026 // Elusive Thoughts Your App Store Won't Save You: Mobile Malware & Supply Chain Poisoning in 2026 April 2, 2026 · Jerry · 8 min read There's a comforting lie the industry has been telling consumers for over a decade: "Just download apps from the official store and you'll be fine." In Q1 2026, that lie is unraveling faster than a misconfigured Docker socket on a public VPS. Let's talk about what's actually happening, why app store vetting is a paper shield, and what this means for anyone building or defending mobile applications. 2.3M Devices infected by NoVoice via Google Play 4 Chrome zero-days patched in 2026 (so far) 0 Days Apple warned users before DarkSword emergency patch NoVoice: 2.3 Million Infections Through the Front Door The NoVoice malware didn't sne...

AI Security Research // LLM Red Teaming Subverting Claude: Jailbreaking Anthropic's Flagship LLM Attack taxonomy, real-world breach analysis, and the tooling the suits don't want you to know about. March 2026  ·  Elusive Thoughts  ·  ~12 min read Anthropic markets Claude as the safety-first LLM. Constitutional AI. RLHF. Layered classifiers. The pitch sounds bulletproof on a slide deck. But when you put Claude in front of someone who actually understands adversarial input, the picture shifts. The model's refusal behaviour is predictable, and predictable systems are exploitable systems. This post breaks down the current state of Claude jailbreaking in 2026: what works, what Anthropic has patched, what they haven't, and the open-source tooling that lets you automate the whole assessment. This is written from a security engineering perspective for pentesters, AppSec engineers, and red teamers evaluating LLM integrations in production applicatio...