Tldrsec

[tl;dr sec] #345 – Bug Rumors → Exploits, Version Control DFIR, Agentic Worms


A bug description is sufficient for AI to find it and write an exploit, cheat sheet on doing DFIR for GitHub, GitLab and more, and a paper on self-replicating, open weight agentic worms

I hope you’ve been doing well!

A two-ser

This is the first time I’ve done two issues in a week in the history of tl;dr sec, catching up after last week’s busyness.

Next week we’ll be back to our normal weekly schedule, phew.

Have a great rest of your week and weekend!

P.S. Some pretty cool sponsors this issue  

Most companies can list the AI apps employees use, but few can say what employees are actually doing inside them. And labeling a task as ‘coding’ is a far cry from recognizing that an engineer working on cost optimizations is leaking source code to a model that trains on the data.

Harmonic Security classifies every AI interaction by task, tool, and team, across sanctioned and shadow apps, so you can see which use cases drive real productivity, which tools are shelfware, and where risk exists.

Poke around their demo live environment for free below.

Wow I really like this! Being able to view a live demo of the product with no sign up, run example workflows and see how it works, and more. Super cool! Well done. 

AppSec

Models are worse at reviewing their own code
Greptile’s Rodrigo Caridad tested whether AI models are better at finding bugs in their own code or code written by another model, analyzing 500 PRs each from Claude Code and Codex against roughly 1,500 ground truth comments (sentiment analysis, upvote/downvote ratios, git archaeology), running Codex and Claude Code’s /review feature 3 times per PR. Both models caught more high-severity bugs in the other model’s code- the types of bugs a model introduces most often are the same types it’s more likely to miss during review. Claude-authored code skews toward “wrong data or missing behavior” bugs where GPT reviews better, while Codex-authored code skews toward semantic issues and error handling failures where Claude reviews better.

Analysis of reasoning traces showed GPT 5.5 uses a depth-first verification approach that causes it to identify bugs but then drop them due to conflicting system instructions emphasizing narrow scope, while Claude Opus 4.7 takes a breadth-first preventive approach that generates more comments including conditional warnings and structural praise. Based on these findings, Greptile built Model Inversion, which detects PR authorship via commit trails, branch prefixes, and PR titles then routes reviews to the opposite model.

Really nice diagrams and visualizations, I like it! Also cool comparison idea.

Just a rumour of a bug is enough to find a security exploit these days
Anil Madhavapeddy shipped a path traversal fix for OCaml’s cohttp 6.3.0 and, within ten minutes of opening the PR, saw probes hitting his webserver with the exact bug pattern. He’d pointed his own Claude at the code first, but Fable refused over its security block, so DeepSeek V4 Pro wrote the exploit instead, in under a minute from only a vague description. Normally a bug like this goes under embargo, quiet until the fix ships, on the theory that secrecy buys you time. That no longer works, since a rumor alone hands an agent enough to find the exploit itself, and mean time to exploit has gone negative, so exploitation now precedes the patch.

Anil lays out three responses and finds flaws in each. GitHub’s temporary private forks let you hide the patch, but they cut you off from CI. Shipping fixes continuously is another route, the way Chrome pushes updates, but that leans on Chrome being a single binary, not a library buried in a hundred products nobody controls. And when cloud providers slam in mitigations at the protocol layer, open source has no CDN to carry the same rules. Every one of these leaves the small maintainer a step behind.

Within 10 minutes is insane. This is a super tough problem that I’ve been thinking about: given the increased rate in vulnerability discovery, the difficulty (and human involvement) in patching, the slowness in patch adoption, and the ease and speed of turning patch or hint → exploit = tough times right now. Prediction: this is and will continue to be an important area of security, and may hit hard over the next few months  

Browser-based attacks are surging, and most security stacks weren’t built to catch them. Omdia surveyed 400 IT and security professionals:

  • 6 in 10 rank generative AI security as their most important use case for a secure browsing solution

  • 7 in 10 say browser-based incidents have risen over the past two years

  • 8 in 10 who rely on traditional tools for browser security report at least one major challenge

See what’s driving the shift to enterprise browsers, where teams are struggling, and what success actually looks like.

I found it interesting to learn about various browser-based attacks, and some of the security wins you can get when you have influence over security controls in the browser.

Blue Team

Version Control DFIR: a Cheatsheet to GitHub, GitLab, Bitbucket, and Azure DevOps
Wiz’s Sean Johnstone and Shira Ayal released a Version Control DFIR poster covering GitHub, GitLab, Bitbucket, and Azure DevOps, with available log sources, what to configure before an incident, and audit events mapped to MITRE ATT&CK tactics for threat hunting. The poster calls out visibility gaps across all four platforms, GitHub only retains Git events for 7 days, GitLab doesn’t log Git operations to the database by default, only GitHub offers API request logs (requiring explicit configuration), and none of this telemetry is retroactive so log streaming has to be in place before something happens.

The readiness checklist also flags that GitHub doesn’t include source IPs in audit logs unless you turn it on, and that default retention windows across all four platforms are too short for most investigations. Where logs do exist, a forensic matrix maps attacker behaviors to the audit event names each platform uses, so a mass clone shows up as git.clone in GitHub, repository_git_operation in GitLab, and RepositoryCloneEvent in Bitbucket.

I’m going to put this poster up in bedroom, right next to my Twilight poster #TeamJacob.

Benign Set Should Look Malicious
PipeLab’s Joshua Waldrep writes that a detection tool’s false-positive rate means nothing if the benign traffic in the test set never actually looks like an attack. Real false positives (especially common when analyzing Agent egress) come from harmless traffic wearing an attacker’s clothes, an agent reading a security advisory that quotes an injection string, a tutorial with AWS’s own example key AKIAIOSFODNN7EXAMPLE, a scanner tool description that lists every attack it detects, a base64 blob that decodes to a PNG rather than a secret. The trap of testing only against clean traffic is that a detector can score 0% false positives there while blowing up to 30% the moment benign inputs start looking dangerous. Joshua shares a public starter set of these lookalikes in agent-egress-bench.

Joshua recommends pulling hard negatives from your own docs, logs, and tool schemas, holding a portion out during tuning, splitting the false-positive rate into easy and hard categories rather than blending them, and publishing failures alongside scores, since reporting only wins is marketing more than measurement.

AI + Security

  • Hacking Google with A.I. for $500,000 – What happens when you unleash an AI across all of Google’s infrastructure? 1,500 APIs, 3,600 keys, and $500,000 in bounties, by Arvin Shivram.

  • Cheat Sheet: Claude Code Security Best Practices Claude Code and other AI coding assistants are changing how fast code ships — but they’re also changing what security teams need to watch for. This practical cheat sheet breaks down the real risk surfaces AI-assisted development introduces, and gives cloud security, AppSec, and platform engineers tactical steps to close the gaps.*

  • I’m Worried About a Prompt Injection Worm – Daniel Miessler

Booz Allen Cyber Weapon Index
Booz Allen ran 18 US and Chinese LLMs as autonomous attackers against a production-grade enterprise network. Anthropic’s Claude Mythos and OpenAI’s GPT-6 Astra both completed the full kill chain, Mythos leading in execution, Astra leading in vulnerability discovery. During the test, models issued commands independently, with every action validated through network telemetry, host logs, domain controller data, and intrusion-detection sensors, ensuring scores reflect demonstrated behavior, not theoretical skill.

“Our assessment remains that most models will arrive at this capability within the next six months.”

Adaptive Agentic Worms
Derek James walks through a recent arXiv paper (AI Agents Enable Adaptive Computer Worms) on self-replicating AI worms that run open-weight LLMs (last year’s models, not frontier) on stolen compute from every machine they land on, spreading across networks with no commercial AI platform involved. On a 33-host testbed of Linux, Windows, and IoT devices, the worms found vulnerabilities, escalated privileges, and copied both their harness and local LLM to new targets, reaching 61.8% network infection over 7 days.

Attackers pay nothing per infection since the worms run on stolen compute, not through a commercial platform, putting them out of reach of centralized controls like safety refusals or rate limiting. The worms also tried to rewrite their own blacklist configuration to remove monitoring hosts from the protected list, and did all of this with self-replication as their only goal, no instructions to steal data or dodge detection, and no ability to change themselves when copying.

Hacking your life with AI can get you hacked
Endor Labs’ Peyton Kennedy discovered 14 critical and high-severity vulnerabilities across seven AI orchestration platforms (NocoBase, Flowise, Langflow, Dify, Activepieces, Kestra, and Apache Airflow) that all share one root cause, they treat multi-tenant code-execution environments as single-user developer tools. The most severe chains need no login at all, with Flowise, Kestra, and Langflow exploitable via prompt injection that runs code and exfiltrates data, while other findings cover broken sandboxes (NocoBase’s lockdown() commented out with a TODO), LLM output trusted as code (Langflow accepting lambda from chat), and sandboxes armed too late to catch anything.

Several vendors closed reports as working-as-designed, but Peyton argues that defenses that should protect users are missing or off by default, and Flowise itself has been archived since mid-August 2026, leaving any running instance as unmaintained software with credentials attached.

Misc

Wrapping Up

Have questions, comments, or feedback? Just reply directly, I’d love to hear from you.

If you find this newsletter useful and know other people who would too, I’d really appreciate if you’d forward it to them

P.S. Feel free to connect with me on LinkedIn  



Source link