elttam

For the past few years we've worked with the very talented Pepper Curry on artwork for our team swag, and a couple of years ago one of the pieces even made it onto the back cover of Phrack 71. This year's design is an Interstellar-inspired bookshelf and tesseract scene, with a bit of meaning for us: a reflection on how we've evolved while staying connected to where we've come from. There are also a handful of Easter eggs hidden throughout. How many can you spot? 👀

New blog post: ATT&CKing TACACS+ to Pwn Your Network via a Pre-Auth RCE by Matt J. TACACS+ is one of the ways large networks centralise administrative access to their equipment, and the one chosen where per-command control matters, since RADIUS bundles authentication with authorisation and protects only the password field while TACACS+ separates them and obfuscates the whole packet body. A server in that position sees every command an admin runs across the fleet, usually a single pair of them answering for the lot, which makes it an obvious target for anyone who already has a foothold and wants the rest of it. The protocol is now forty-two years old, and on a lot of those networks the daemon answering is tac_plus, C descended from a Cisco reference kit from the early nineties that passed through Shrubbery, then Facebook, then an unknown number of vendor forks, with nobody owning it start to finish. That is what put it on our backlog. We found a remote, pre-authentication format string vulnerability (CVE pending) in send_authen_error() that yields code execution as root, the default daemon user. Working it through with a few of the elttam team, we also found that the same function hands a known plaintext to unauthenticated clients, a PSK oracle that turns the pre-shared key from an access control into an offline cracking problem. The key protecting the bug can be recovered from the function the bug lives in. It scores 9.8 with no secret configured and 8.1 with one, both assuming you can reach TCP/49. Reaching TCP/49 is the position CISA's AA25-239A already places Salt Typhoon-linked actors in, sniffing and redirecting TACACS+ traffic on compromised routers and pulling shared secrets out of device configs. None of that involves this bug, but it is the same layer, worked by other means. It came off the backlog an hour into an international flight, no internet, nothing but the source, in code that had been sitting untouched for twenty-five years. Getting it fixed took three organisations and several months, which was the harder part by some distance. The full writeup covers the history back to 1984, the PoC, the PSK oracle chain, a third avenue we did not pursue that launders a payload through a trusted client, and the disclosure timeline. https://lnkd.in/gPtEM342

Very happy to support unprompted.au! Several of the elttam team will be there and we're looking forward to it. Hope to see you there!

New blog post: Ruby Marshal Kick-off Gadgets by Luke Jahnke Trail of Bits' 2024 review of RubyGems.org made a hardening recommendation: consider removing the Marshal-based gem specs entirely, even though the finding itself wasn't a vulnerability and the project was out of scope. We wanted to see what happens if that recommendation is ever implemented, so we assumed RubyGems' kick-off gadgets were already gone and asked what Marshal.load still calls on its own. The documented entrypoints turned out to be a handful of deliberate overrides that maintainers can keep hardening away. But Marshal.load reaches six more methods without touching any of them, none written for marshalling, none likely to be removed. Our own Ruby 4.0 chain used one, hash, called on a Gem::StubSpecification placed as a Hash key. As the documented entrypoints close, that's where deserialisation gadgets will increasingly have to come from. The full writeup has working reproductions for all nine entrypoints, the C source backing each one, and a script to count how many are live in your own application. https://lnkd.in/gvSWkKqn

Last night Jia Hao Poh gave his talk "Your House Has an FFmpeg Problem" at SecTalks Perth, walking through the FFmpeg argument injection vulnerability we found while hunting for attack chain primitives in Home Assistant. We first looked at Home Assistant a few years ago, and since then it's had audits from Cure53, a review from GitHub Security Lab, and a spot on the #Pwn2own target list with the Home Assistant Green. Its security posture has genuinely improved over that time, so what's changed on our end is where and how we look at its security, shifting away from straightforward bugs and immediate attack surfaces to the primitives that chain into something with real impact. This talk covered one of those primitives, found while hunting for ways to compromise the supervisor token: a novel technique using FFmpeg's argument injection to stitch together a valid audio header from an existing binary on disk. Jia walked through Home Assistant's attack surface and security history, then the bug, the exploit, and the patch. There's still a lot more to be done, but it's satisfying to see a popular opensource project improve its security over time. Thanks to everyone who came along, and to SecTalks Perth for having us. 

Environment variables have been an underrated attack surface for well over a decade, and CVE-2026-22708 in Cursor shows why that's about to matter more. Shellshock proved back in 2014 that a Bash parsing flaw in environment variables could produce remote code execution across huge parts of the internet. Pillar Security's Cursor disclosure is the same pattern in an agentic IDE: shell built-ins like export and typeset ran without approval, letting an attacker poison environment variables and turn an already-approved command like git branch into RCE. Their write-up credits Luke Jahnke's 2020 research on hacking with environment variables. In 2020 that chain needed manual, sequential access to trigger RCE but now an agent following poisoned instructions does it alone. We've run into the same gap ourselves more than once: Flowise reintroduced almost exactly the denylist we'd already broken, while GoAhead's CGI handler abused LD_PRELOAD and Jupyter's Enterprise Gateway abused Jinja2 templating via the same untrusted-environment-variable path. Environment variables are rarely treated as a source worth tracking, just ambient configuration sitting outside the data flow. Shellshock, Cursor, GoAhead, Flowise and Jupyter are all the same blind spot, and closing it means tracing environment variables through interpreters and template engines the same way you'd trace a query parameter. It's good to see a 2020 blog post still get referenced in a 2026 disclosure. References below: https://lnkd.in/dU7Th4HA https://lnkd.in/guDAB_DV https://lnkd.in/g2GjmtAK https://lnkd.in/gvbD2eEg https://lnkd.in/gc6qQZrD https://lnkd.in/gntGpTNJ

We're growing our team. elttam is looking for a Senior Security Consultant to join us. We're a tight knit team of specialists working on varied, technically deep engagements. The role is remote-friendly, with a preference for Perth, Sydney, or Melbourne, and our customers are leading organisations across various industry verticals who genuinely want to improve their security. The role covers code-assisted web app and mobile security assessments, cloud security reviews, and adversary simulation, backed by tooling and research, including AI-assisted vulnerability discovery, that keep our methods sharp. We're looking for someone with strong web application, cloud security, and source code review skills, senior consulting experience, and good written and verbal communication. Development experience, and exposure to embedded, IoT, ICS, or reverse engineering work, is a nice to have. In return, we offer autonomy on complex engagements, a supportive environment for research and publication, flexible and sustainable remote work, and competitive compensation reflecting experience and contribution. Full details: https://lnkd.in/gSi89pqS

New blog post: Ruby 4.0 Universal RCE Deserialization Gadget Chain by Luke Jahnke On August 5, 2026, OpenAI disclosed that AI agents under evaluation broke out of their sandboxes and took admin control of their cluster, partly via Ruby deserialization. We've seen this cycle before, having published the first universal Ruby deserialization chain back in 2018, and the most recent one only lasted until Ruby 3.4-rc before RubyGems patched its gadgets out in the 3.4 release. We built a new chain that turns a single Marshal.load into command execution on Ruby 4.0.6, the current release, and it works unchanged as far back as 3.3 (the oldest version that has not reached end-of-life status). Deserialization bugs tend to live or die on gadget availability, which usually plays out as a cat and mouse game where a chain gets published, its gadgets get patched, and researchers go looking for new ones. That cycle can run for years, but it isn't infinite. Some of the gadgets in this chain are baked into how the language itself works rather than sitting in a Ruby method a maintainer can quietly tighten, and that's much harder to patch. Because the chain is universal, any Ruby deserialization vulnerability now becomes instant remote code execution again. We'd rather see this vulnerability class eradicated than keep patching individual chains and relying on cat and mouse mitigations. The real fix is prohibiting known dangerous routines like Marshal.load from ever being called on untrusted input. The full writeup covers how the chain was built and includes a working PoC against the official ruby:4.0.6 Docker image. https://lnkd.in/gqwy23d4

Next Thursday on August 20th, Jia Hao Poh is speaking at SecTalks Perth. His talk, "Your House Has an FFmpeg Problem" is about how we went hunting for attack chain primitives in Home Assistant and found an argument injection vulnerability in FFmpeg along the way. He'll cover Home Assistant's attack surface, its security history, and the technical details behind the bug, the exploit, and its patch. More details on the Meetup page: https://lnkd.in/gnMFYNH8

New blog post: Cruising for Shells in Flowise by Jia Hao Poh, Luke Jahnke, and Alex Brown Flowise is one of the most popular AI agent/workflow platforms on GitHub. Researchers have been submitting a steady stream of bugs through programs like ZDI, riding the current wave of AI-assisted vulnerability research. We wanted to see what human-driven review would still turn up. We found 6 new remote code execution vulnerabilities across Flowise's two most recent versions, including a sandbox escape that survived two rounds of patching, and an arbitrary file write we turned into a SQLite database crafted as a polyglot shell script, later executed via Chromium. We also ran Claude's AI security review over the same codebase, alongside our own analysis. AI is good at finding vulnerabilities and confirming they're true positives, and it did flag genuine issues here. But the only RCE it caught was an already-known outdated vm2 dependency, not the sandbox escape we found by hand, or the other five. There's a lot less discussion about false negatives: the critical vulnerabilities automated analysis can walk right past. The full writeup covers all 6 vulnerabilities with working PoCs, patch bypasses, and the GHSA advisories. https://lnkd.in/gvbD2eEg