Carbonato targets Docker, CISA flags live exploits, and going local with your vacuum and your NAS

Homelab Highlights for 2026-09-28: self-hosting and homelab notes worth knowing.

[Audio embed placeholder]

News Roundup

SharePoint RCE and MikroTik RouterOS Flaws Actively Exploited in the Wild

CISA adds two vulnerabilities to its Known Exploited Vulnerabilities catalog: a code injection bug in Microsoft SharePoint (CVE-2026-65660) and a buffer overflow in MikroTik RouterOS’s SMB service (CVE-2026-65661), both with evidence of active exploitation.

Why it matters: These additions signal immediate patching priorities for homelabs running SharePoint for testing or MikroTik routers at the network edge, as attackers are actively targeting these flaws.

Source: The Hacker News

Distributed-JBOD: A Garage or MinIO-like storage system for heterogeneous devices

A developer shares Distributed-JBOD, a Rust-based object storage system that pools mismatched drives using Reed-Solomon erasure coding. The latest update improves fault tolerance, allowing the system to serve data even when some nodes or drives are offline.

Why it matters: For homelabs with a collection of old, varied drives, this project offers a way to build a resilient, software-defined storage pool with configurable data protection, though it’s still in pre-1.0 development.

Source: r/HomeServer

AI agent builders: is Claude Code actually worth it?

A solo developer building AI agents for small businesses asks the community for cost-benefit advice on integrating Claude Code into their stack, which currently uses n8n for workflows like WhatsApp assistants that log data to Google Sheets.

Why it matters: The discussion provides a real-world snapshot of the practical considerations and trade-offs developers are weighing when adopting paid AI tools for building more complex, multi-step agent workflows.

Source: r/AI_Agents

Tool & Software Highlight: Carbonato Botnet Compromises Docker Hosts to Deploy Telegram-Controlled Hermes AI Agent

Researchers detail the Carbonato botnet, which targets exposed Docker daemons to install the open-source Hermes AI Agent framework. The malware overwrites the agent’s persona file with a prompt that makes it take commands via a Telegram bot, turning compromised hosts into remotely controlled AI agents.

Why it matters: This attack highlights a novel misuse of AI agent frameworks for command and control, emphasizing the critical need to secure Docker daemons and understand how any local AI runtime accepts tasks.

Source: The Hacker News

Sources

Transcript

Host A: Welcome to Homelab Highlights, the show that surfaces practical homelab wins and useful self-hosted tools.

Host A: Alright, starting with a security story that should get everyone’s attention. ThreatDown researchers have detailed a new botnet called Carbonato that’s specifically hunting for exposed Docker daemons. [with emphasis] But the payload is what makes it interesting. Instead of the usual crypto miner or DDoS tool, this thing installs a legitimate open-source AI agent framework called Hermes Agent. It leaves the framework untouched, but then overwrites the persona file, SOUL.md, with its own prompt. That thirty-nine-line prompt basically tells the agent to take orders through a Telegram bot.

Host B: So the attacker gets command and control over a messaging app that most firewalls don’t even blink at, and it’s all riding on software the malware just installed, so it looks like it belongs there. That’s a clever abuse of the whole agent framework concept. For anyone running Docker at home, an exposed daemon API is already a massive problem—remote access basically means root on the host. [skeptical] But this adds a new layer: if you’re experimenting with any local AI agents, their runtime is literally designed to accept instructions and act on them. Carbonato shows a persona file and a Telegram connection are enough to make it work for someone else.

Host A: The takeaway is pretty straightforward, if unglamorous. Double-check that Docker daemon isn’t listening on every interface. Bind it to localhost or put it behind something that requires authentication. And if you’ve got an agent framework running, know exactly how it accepts tasks and who can send them.

Host B: Next up on the security front. CISA added two vulnerabilities to its Known Exploited Vulnerabilities catalog late last week. The word is there’s active exploitation happening in the wild. One is a code injection bug in Microsoft SharePoint, CVE-2026-65660, with a CVSS score of 8.8. The article notes it’s authenticated remote code execution, so an attacker needs some access first. But if you’re running SharePoint in the lab for testing or as part of a stack, it’s a reminder that internal-facing services need updates too, especially from vendors that get targeted.

Host A: The other is a flaw in MikroTik RouterOS. These boxes often sit at the network edge and get forgotten. If you’ve got one facing the internet, patching isn’t optional. The specific flaw is a buffer overflow in the SMB service, CVE-2026-65661. [with a small lift] If SMB is enabled on a RouterOS device facing the internet—which, please don’t—that’s a direct path in. The fix is available in updates.

Host B: Switching topics to storage. Over on r/HomeServer, a developer shared Distributed-JBOD. It’s a software storage system built for mixing mismatched drives into a single, erasure-coded object store. It uses Reed-Solomon coding, you can tune the parity shards, and recent updates let it keep serving data even when some drives or nodes go offline. Worth noting the developer’s own disclaimer: it’s pre-1.0, there could be breaking changes, and they recommend only using it with data you have another copy of elsewhere.

Host A: The developer also mentioned it’s written in Rust, which is an interesting choice for storage. It can handle drives from a few hundred gigs up to multiple terabytes in the same pool. That’s the kind of flexibility a homelabber with a drawer of old drives might actually use. The trade-off is the computational overhead from erasure coding compared to simple RAID, so you’ll want a CPU with some headroom.

Host B: And a quick note from the community boards. Over on r/AI_Agents, a solo builder asked whether Claude Code is worth adding to their stack for making AI agents for small businesses. They’re currently using n8n for workflows like WhatsApp assistants that handle FAQs and log leads to Google Sheets. The thread is a useful snapshot of the cost-benefit calculations people are making as they move into more complex, multi-step agent workflows.

Host A: Tool highlight time. This one’s been in the works for about six months. Local Roborock Server is a project that finally lets you control Roborock vacuums completely offline, and it’s now out of beta. The idea is beautifully simple. The server impersonates Roborock’s cloud backend. So the vacuum thinks it’s talking to the servers in China, but it’s actually talking to a box in your closet. Everything else works like normal. The new release adds support for the v2 protocol that newer flagship vacuums use. It can onboard vacuums that have never touched the official cloud. There’s a Home Assistant add-on, reverse proxy support, and even a third-party mobile app called LocalRock built for it.

Host B: [thoughtful] The v2 support only happened because researcher Dennis Giese—the person behind Valetudo—dumped the firmware from a vacuum board the developer shipped him. Worth noting the Q Series, like the Q7, isn’t supported yet. That’s pending a responsible disclosure process. One catch from the FAQ: the vacuum validates TLS certificates. So DNS trickery alone doesn’t cut it; you need a real domain and a valid cert. A commenter pointed out a Let’s Encrypt cert via DNS-01 works fine pointing at a private ZeroTier IP with no ports open. So ‘valid’ doesn’t have to mean ‘internet-exposed.’

Host A: The developer’s own Home Assistant setup is a nice pattern: clean a different room every night, and start cleaning whenever everyone—including the dog—leaves the house. Docs are admittedly thin right now, and the developer is openly asking for help improving them.

Host B: Community highlight. Someone documented a solid three-week run with a Minisforum N5 Max—that’s the Strix Halo box with a Ryzen AI Max+ 395 and 128 gigs of unified memory. They ran it as a single Proxmox machine handling NAS duty, media, SSO, and local AI. The setup details are great. ZFS raidz2 across five fourteen-terabyte drives, Jellyfin with iGPU transcoding, Immich, Authentik, Caddy. Plus Ollama running a 70B model and ComfyUI generating full-quality FLUX.2 images, all offline.

Host A: But the gotchas list is the real gold here. The HDD fans follow ambient temperature, not drive temperature, so the base fan speed is what actually cools the disks. GPU memory isn’t counted against container limits, so a big model can starve the host while every limit looks fine. Ubuntu’s stock nftables service wipes Docker’s firewall rules on package updates. In their case, that happened in a DNS container and took the whole house offline. And passing the GPU device into Jellyfin wasn’t enough; theirs transcoded on the CPU for two weeks before anyone noticed.

Host B: [conversational] Couple more details worth stealing. They tested SSO fallback paths with Authentik actually powered off and found documented recovery passwords that didn’t work—a genuinely good exercise for any lab. And they steered people away from Minisforum’s factory OS: no real backup story, no SSH, an obfuscated filesystem. For a box holding family files, wiping it for Proxmox was the call. On value, they argue that with 128 gigs of DDR5 alone costing a small fortune this year, nothing else really matches the price for storage plus local AI capability, even if a FLUX.2 render takes about eighteen minutes.

Host A: That’s Homelab Highlights for Monday. Until next time, happy hosting!