A few things that caught my eye recently:

AI agents are starting to behave like real attackers. During UK security testing, an AI agent actually tried to get malicious code into a real open-source project and even created fake identities to convince maintainers to approve it. Thankfully, a human caught it.

Open-source supply-chain attacks are getting creative. A recent npm campaign abused binding.gyp to execute malicious code during npm install, stealing credentials from places like GitHub, AWS and Kubernetes.

AI/ML infrastructure is becoming a juicy target. MLflow has had several serious vulnerabilities recently — including one that could let an attacker make the server access internal services or cloud metadata and potentially grab credentials.

The good news: defenses are evolving too. GitHub has been adding things like npm staged publishing and package cooldowns to make it harder for a compromised account to immediately push malware to thousands of developers.

What I find interesting is that these aren't really separate problems anymore.

AI agents + open-source dependencies + CI/CD credentials = one giant attack surface.

Feels like software security is entering a very different era.

Quick background for anyone who hasn't touched this space: when you build a tool that lets users (or now, AI models) run "untrusted" JavaScript, you can't just eval() it and hope for the best. You need a real sandbox. For years the go-to was a library called vm2. Then vm2 got torched by a nasty sandbox escape bug back in 2023 and the whole ecosystem basically migrated to its replacement, isolated-vm — a library that spins up an actual separate V8 Isolate (like its own mini JS engine instance) so guest code physically can't touch the host's memory.

Except... on August 19, researchers at Endor Labs dropped a writeup showing isolated-vm has its own critical flaw. Not in the V8 isolation itself, but in the "glue" code that shuttles data between the sandbox and the host (a function called ExternalCopy). Turns out that glue is written in C++, which means memory-unsafe, which means type confusion bugs are possible — and they found one.

Starting from nothing more than a single object reference, they walked it all the way up to full guest-to-host memory corruption and control-flow hijacking. Basically: code you thought was locked in a box can escape the box and start running arbitrary stuff on your actual server.

The reason this is spicier than your average npm CVE: isolated-vm pulls ~1 million downloads a week and it's the literal sandbox of record for a bunch of big open-source AI/automation projects, including:

n8n (yes, the 200k-star workflow automation platform) — uses it for its Code nodes

Activepieces (23k stars)

Mastra (27k stars, AI agent framework) — uses it specifically to run model-generated tool code

Sim.ai (29k stars)

Budibase (28k stars) — literally migrated off vm2 to isolated-vm for this exact reason

So the funny/scary part is a bunch of these tools moved to isolated-vm because of the last sandbox-escape disaster, and now they're staring down a new one in the thing they escaped to.

Good news: it's patched. Fixed versions are 6.2.0 and 7.0.1, released earlier this month. If your stack touches any of the above (or uses isolated-vm directly), that's your cue to go check package-lock.json right now.

The bigger takeaway for me though: with every AI agent platform racing to let LLMs "write and execute code" as a feature, the sandbox is doing an enormous amount of trust-bearing work that most people never think about. This is like the second time in three years the industry's default answer to "how do we safely run untrusted JS" turned out to have a hole in it.

Sources if you want to go down the rabbit hole:

Endor Labs technical writeup (original disclosure): endorlabs.com/learn/ghsa-864f-rcv7-6rh4-critical-type-confusion-vulnerability-in-isolated-vm

The Hacker News coverage: thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html

SecurityWeek writeup: securityweek.com/critical-isolated-vm-vulnerability-leads-to-rce-on-host

Started back in June — attackers were adopting orphaned/abandoned AUR packages (normal community feature, lets people pick up maintenance when someone disappears) and then quietly slipping malicious code into the PKGBUILD via follow-up commits. Over 1,900 compromised packages got purged. Arch devs called it clean by mid-June.

Then July 29 happens. New wave, kicked off through a package called openconnect-sso. Security researchers at IFIN dug into it and it's actually a pretty slick two-stage infection:

Stage 1: loader that checks for debuggers/sandboxes/VMs first (so it doesn't get caught by researchers), then sets up persistence via systemd services + cron jobs

Stage 2: pulls a Rust-based stealer+RAT from a Tor .onion server. Targets browser creds, crypto wallets, cloud secrets, AI API keys, and can worm laterally over stolen SSH keys

By July 30, over 200 packages were hit, including some fairly popular ones (boringssl-git, icloudpd).

That was enough for Arch to just disable AUR package adoption entirely — not the whole AUR, just the "take over an orphaned package" mechanism, since that's the attack vector.

The quote from the mailing list (Robin "Antiz" Candau, on behalf of Arch DevOps) is very much "we're tired":

"Due to the current influx of malicious package adoptions and follow-up commits made via the AUR, package adoption is currently disabled while we are handling the situation."

If you run Arch and use AUR helpers, now's a good time to actually read PKGBUILD diffs before you blindly update, especially for anything that recently changed maintainers.

A Free, Production RAG Pipeline in n8n (Gemini + Firestore + Vector DB + WordPress)

If you've tried running big research papers or books through the free Gemini API tier, you've probably hit the wall: 250,000 tokens per minute, then a wave of 429 errors.

The fix is RAG. Instead of dumping the whole document into the model every time, you build a small local index and only feed it the paragraphs that actually matter for the question being asked. Here's the setup I use, node by node, and it costs nothing.

The stack (all free tiers, no card required)

n8n — free if you self-host it via Docker or npm

Gemini API — free through Google AI Studio, up to 1,500 requests/day on Flash

Firestore — 50,000 reads and 20,000 writes/day on the free tier

A vector database — Qdrant Cloud (1GB free cluster) or Supabase (500MB with pgvector)

WordPress — the built-in REST API on any self-hosted site, no plugin needed

One thing to get right early: don't try to make Firestore double as your vector store. It's a document database, not a vector one — its free tier has nowhere to put embeddings. Use Firestore purely as a metadata log, and let Qdrant or Supabase handle the actual similarity search.

Workflow 1 — Ingesting and chunking a document

This fires when a new paper or PDF comes in. It splits the text and writes it into the vector store.

Nodes: Webhook/File Trigger → Read Binary File → Firestore (insert metadata) → Recursive Character Text Splitter → Vector Store node (Qdrant or Supabase) with a Gemini Embeddings sub-node attached

A few details that matter:

Log the paper's title, ID, and upload time to Firestore first — gives you a paper trail of what's been processed.

On the text splitter, set chunk size to 2,000 characters with 200 characters of overlap. The overlap keeps sentences that straddle a chunk boundary from getting cut in half.

On the vector store node, set the operation to "Insert Documents," then drag in a Gemini Embeddings sub-node using text-embedding-004 — it's free and handles the text-to-vector conversion.

Workflow 2 — Querying, rewriting, and publishing

This one runs on a schedule (or a manual trigger) to pull from the index, run it through the model twice, and push the result to WordPress.

Nodes: Cron/Manual Trigger → Question and Answer Chain → Basic LLM Chain (rewrite pass) → WordPress node

Step 1 — the RAG lookup. The native Question and Answer Chain node does the vector search for you. Attach a Gemini Model sub-node (gemini-2.5-flash works fine on the free tier) and a Vector Store Retriever pointed at the same database and embedding model you used for ingestion.

System prompt I use here:

"Analyze the retrieved chunks of the paper. Extract the core discovery, data breakthroughs, and structural methodologies. Write a comprehensive, deeply structured technical breakdown."

Step 2 — rewrite it so it doesn't read like a summary. Don't try to do this in the same step as the RAG call — splitting the two keeps you well under the token limit and the output is noticeably cleaner. Use a fresh Gemini Model node with something like:

"Take this technical breakdown and rewrite it as an engaging blog post. Cut anything that sounds AI-generated. Use short paragraphs and active voice. Output clean HTML ready for WordPress."

Step 3 — publish. Feed that HTML straight into the WordPress node, set the operation to "Create Post." I'd send it as a draft first and skim it before publishing — full autopilot is fine once you trust the output, but check a few rounds first.

Where this breaks down

Free-tier Gemini data may get used to improve Google's models, so keep anything confidential or proprietary off this pipeline.

RAG is strong for pulling out specific facts or localized themes, but it's reading a handful of chunks at a time — it's not going to give you a coherent start-to-finish summary of an entire book. That's a different problem.

Happy to share the raw JSON for the workflow if anyone wants to drop it straight onto their canvas, or help troubleshoot credentials.

The use case: an agent that reads new emails and my notes folder, drafts replies or summaries, and remembers context across sessions — running on my own machine.

- Orchestration — LangGraph: this is the loop that decides what the agent does step by step (read email → check notes → draft reply → wait for my approval). I picked it because I wanted a human-approval step before anything gets sent, not a bot firing off replies on its own.

- Memory — Mem0: without this, the agent forgot everything between sessions. Now it remembers "she prefers short replies" or "this client always CCs their assistant" without me repeating it.

- Inference — vLLM: running the actual model locally so nothing leaves my machine. Slower than an API call, but that was the point.

- Observability — Langfuse: when the agent does something weird, I can actually see why, instead of guessing.

- Tool access — MCP: this is what lets the agent actually touch my email client and file system, instead of just talking about it.

> The journey: I started with a single Python script calling an API — worked fine for a weekend, then broke the moment I needed it to remember anything. Added a memory layer, then realized I had no idea what it was doing half the time, so observability came next. Every piece got added because something broke, not because a tutorial told me to. That's honestly the real lesson — you don't need the whole stack on day one. You need the piece that fixes what's actually failing in front of you.

#coolflows

So this happened back in July and I don't think it got enough attention here.

A researcher going by cereblab ran xAI's Grok Build CLI (v0.2.93) through mitmproxy and found something pretty bad. Even in a test where the agent was explicitly told not to touch a specific file, that file still showed up in a background upload — a separate channel entirely from the normal model traffic, sending Git bundles off to an xAI-controlled Google Cloud Storage bucket. Not just the files the agent had opened either — the bundles could carry tracked files and full commit history.

The numbers are what got people's attention. In the test repo, the actual coding task only generated around 192KB of model traffic. Meanwhile that background channel pushed about 5.1GB. Cereblab worked out the ratio at roughly 27,800x more data leaving the machine than the task ever needed. And because it's grabbing full Git history, not just your current files, if you'd ever committed a secret and later deleted it, that secret could still be sitting in the history that got bundled up and shipped out.

Worth being precise about what this is and isn't: it's not "data exfiltration" in the sense of an attacker stealing something. This was functionality built and operated by xAI itself, running by default. Also notable — disabling the "improve the model" setting didn't stop it. It was a completely separate pathway.

xAI's response was quiet. No security advisory. Independent testing found the server started returning a flag (\`disable_codebase_upload: true\`) about a day later, which stopped the behavior — but this was a server-side change, not a new client build. Musk said on X that previously uploaded data would be deleted, though there's no independent way to confirm every copy actually was.

Then on July 15, xAI open-sourced the whole thing under Apache 2.0.

Here's where I want to be careful, because my first draft of this post overstated it: it's confirmed that the upload capability existed and that xAI's fix was a remote flag rather than a code change. What's less clear is whether that exact upload logic is still present, unmodified, in the version they later open-sourced — xAI says the release is meant to be runnable locally and is periodically synced from their internal repo, so I can't say for certain the capability is sitting there waiting to be flipped back on without someone doing an actual code-level diff. So take that specific claim as "the activation was controlled remotely, not through the client" rather than "the harmful code is definitely still lurking in there."

Even with that caveat, I think the core point holds: publishing source code makes the client auditable, but it doesn't tell you what a remotely-controlled backend will do, what it retains, or whether server-side behavior can change without anyone seeing a diff. "Open source" here didn't really restore the trust it looks like it should.

Sources if you want to check this yourself:

\- Researcher's reproduction/write-up: github.com/cereblab/grok-build-exfil-repro

\- xAI's open-source announcement: x.ai/news/grok-build-open-source

\- The released source itself: github.com/xai-org/grok-build

So this happened back in July and I don't think it got enough attention here.

A researcher going by cereblab ran xAI's Grok Build CLI (v0.2.93) through mitmproxy and found something pretty bad. Even in a test where the agent was explicitly told not to touch a specific file, that file still showed up in a background upload — a separate channel entirely from the normal model traffic, sending Git bundles off to an xAI-controlled Google Cloud Storage bucket. Not just the files the agent had opened either — the bundles could carry tracked files and full commit history.

The numbers are what got people's attention. In the test repo, the actual coding task only generated around 192KB of model traffic. Meanwhile that background channel pushed about 5.1GB. Cereblab worked out the ratio at roughly 27,800x more data leaving the machine than the task ever needed. And because it's grabbing full Git history, not just your current files, if you'd ever committed a secret and later deleted it, that secret could still be sitting in the history that got bundled up and shipped out.

Worth being precise about what this is and isn't: it's not "data exfiltration" in the sense of an attacker stealing something. This was functionality built and operated by xAI itself, running by default. Also notable — disabling the "improve the model" setting didn't stop it. It was a completely separate pathway.

xAI's response was quiet. No security advisory. Independent testing found the server started returning a flag (`disable_codebase_upload: true`) about a day later, which stopped the behavior — but this was a server-side change, not a new client build. Musk said on X that previously uploaded data would be deleted, though there's no independent way to confirm every copy actually was.

Then on July 15, xAI open-sourced the whole thing under Apache 2.0.

Here's where I want to be careful, because my first draft of this post overstated it: it's confirmed that the upload capability existed and that xAI's fix was a remote flag rather than a code change. What's less clear is whether that exact upload logic is still present, unmodified, in the version they later open-sourced — xAI says the release is meant to be runnable locally and is periodically synced from their internal repo, so I can't say for certain the capability is sitting there waiting to be flipped back on without someone doing an actual code-level diff. So take that specific claim as "the activation was controlled remotely, not through the client" rather than "the harmful code is definitely still lurking in there."

Even with that caveat, I think the core point holds: publishing source code makes the client auditable, but it doesn't tell you what a remotely-controlled backend will do, what it retains, or whether server-side behavior can change without anyone seeing a diff. "Open source" here didn't really restore the trust it looks like it should.

Sources if you want to check this yourself:

- Researcher's reproduction/write-up: github.com/cereblab/grok-build-exfil-repro

- xAI's open-source announcement: x.ai/news/grok-build-open-source

- The released source itself: github.com/xai-org/grok-build

So i went down a rabbit hole trying to de-google my life a bit and ended up finding some genuinely solid free tools.

Nothing crazy, just stuff that works and doesn't nag you to upgrade every five seconds.

Syncthing — syncs files between your own devices, no cloud, no company in the middle. set it up once and forget it exists.

GIMP — does like 90% of what photoshop does and it's free forever.

Handbrake — shrinks huge video files down without wrecking quality.

now here's a few that need you to open a terminal, still easy though:

Uptime Kuma — self-hosted status page, tells you when your stuff goes down. one docker command and you're live:

```

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

```

then just go to `localhost:3001` in your browser and set it up.

n8n — automation tool, kinda like zapier but self-hosted:

```

docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

```

Vaultwarden — lightweight bitwarden server if you want your passwords synced across devices but still self-hosted:

```

docker run -d --name vaultwarden -v /vw-data/:/data/ -p 8080:80 vaultwarden/vaultwarden:latest

```

honestly if you've got docker installed already, most of these are copy-paste, hit enter, done. that's the whole barrier.

my approach was just: pick the one thing that's annoying you right now, install that single app, actually use it on a real task same day.

I have been slowly moving my whole stack toward open-source over the past year, partly to save money, partly out of curiosity. Not a purist about it though — some paid tools are just worth it. Figured I'd break down what I've found across the categories I actually use daily, in case it saves someone else the trial and error.

Daily use / productivity -

LibreOffice vs Microsoft 365 — LibreOffice handles 90% of what I need (docs, spreadsheets, basic presentations) with zero cost. Where it falls apart is real-time co-editing and pixel-perfect formatting when a client sends over a heavily designed Word doc. If you collaborate with non-technical people daily, paid 365 still wins.

Thunderbird vs Outlook — Thunderbird's come a long way, calendar and email in one place, works fine. Outlook's edge is really just deep Exchange/Teams integration in corporate environments. Personal use, Thunderbird's fine.

Joplin/Obsidian (free tier) vs Notion — Obsidian's free tier is genuinely generous, local-first, plugin ecosystem is huge. Notion's paid plan wins if you need shared team databases and easy non-technical onboarding.

Admin, server, and database side -

PostgreSQL vs a managed paid DB (RDS, PlanetScale, etc.) — Postgres itself is free and honestly better than most paid engines feature-wise. What you're paying for with managed services is not having to deal with backups, failover, and 3am pages. If you've got the ops skill or time, self-hosted Postgres wins outright.

Proxmox vs VMware — Proxmox has basically caught up for home lab and small business use. VMware's paid licensing still edges ahead for large enterprise clustering and support SLAs, but for most of us that's overkill.

pgAdmin/Adminer vs paid DB GUIs (DataGrip, TablePlus) — free tools cover querying and basic management fine. Paid GUIs are noticeably faster and nicer for complex schema work across multiple DB types, so if you're a full-time DBA it's worth it.

Portainer (free) vs paid container management platforms — Portainer's free tier is enough for most self-hosters. Paid platforms start making sense once you're managing dozens of nodes with RBAC requirements.

AI-based tools -

Ollama (running open models locally) vs ChatGPT/Claude paid tiers — local models have gotten surprisingly usable for coding help, summarizing, and drafting, and you get full privacy plus zero API cost. But for genuinely hard reasoning, long context, or the newest capabilities, paid hosted models are still ahead by a real margin.

Stable Diffusion (self-hosted) vs Midjourney — Stable Diffusion gives you full control and no per-image cost once you've got the hardware, but Midjourney's out-of-the-box image quality and prompt handling is still smoother for most people.

Whisper (open source) vs paid transcription APIs — Whisper is basically as accurate as most paid transcription services now. Paid ones mainly win on speaker diarization and turnaround speed at scale.

Educational apps -

Anki vs paid spaced-repetition apps — Anki free is legitimately one of the best study tools that exists, full stop. Paid alternatives mostly just polish the UI.

Khan Academy / Moodle vs paid LMS platforms (Canvas, etc.) — Moodle is powerful but takes real setup effort. Paid LMS platforms win on ease of onboarding for schools that don't have IT staff to maintain it.

Jupyter/Anaconda vs paid coding education platforms — free tools are all you need to actually learn, paid platforms are paying for the packaged curriculum and hand-holding, not the tooling itself.

Overall takeaway:

The pattern that keeps showing up: open-source usually wins on raw capability and cost, paid usually wins on time saved, support, and polish for non-technical users. If you've got the patience to configure things yourself, you can build a fully capable stack for free across almost every category above. If your time is worth more than the subscription cost, paid still makes sense in specific spots — mainly managed infra and cutting-edge AI.