Gitea RCE Campaign and Media Discovery Rules

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

[Audio embed placeholder]

News Roundup

CISA Adds 5 Actively Exploited Artifactory, ScreenConnect, and RouterOS Flaws to KEV

The U.S. Cybersecurity and Infrastructure Security Agency has added five security flaws impacting JFrog Artifactory, ConnectWise ScreenConnect, and MikroTik RouterOS to its Known Exploited Vulnerabilities catalog, with reports of active exploitation.

Why it matters: These vulnerabilities are being used in attacks now. Checking your versions of these common enterprise and homelab tools against the KEV catalog is a straightforward way to prioritize critical updates.

Source: The Hacker News

Blockbusterr v2.0.0: self-hosted media discovery with rules, previews, and delivery limits

Blockbusterr is a self-hosted tool that sits between media discovery sources and delivery tools like Radarr and Sonarr. Version 2.0 adds reusable rules, job previews, and delivery limits to filter what gets added to your library.

Why it matters: It provides a smart filtering layer for media automation, helping you avoid filling your library with everything trending and instead only adding content that matches your specific criteria.

Source: github.com

Dockhand update fails with “Failed to rename old container” — only on Quadlet-managed containers?

A user reports that the container update tool Dockhand consistently fails when updating containers managed by Podman’s Quadlet systemd units, due to a race condition with systemd’s restart policy.

Why it matters: It highlights lifecycle management friction when automation tools and init systems both control the same container. The discussion points to using Podman’s built-in AutoUpdate feature for Quadlet-managed containers as a cleaner solution.

Source: github.com

Tool & Software Highlight: Red Heron Exploits Gitea RCE to Compromise 13 Organizations Across Six Countries

A suspected Chinese threat actor tracked as Red Heron has been rapidly exploiting a recently disclosed security vulnerability in Gitea, compromising internet-facing instances across six countries. The group scanned nearly 1,400 Gitea instances and maintained a separate dataset focusing on Taiwan-based systems.

Why it matters: This campaign shows how quickly threat actors move to exploit public vulnerabilities. If you run an internet-facing Gitea instance, patching is urgent, and keeping it behind a VPN or authentication layer is a critical security practice.

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: A suspected Chinese threat actor tracked as Red Heron has been rapidly exploiting a recently disclosed security vulnerability in Gitea, compromising internet-facing instances across six countries. According to The Hacker News, the campaign has already hit thirteen organizations, with the attackers scanning nearly fourteen hundred Gitea instances across seven countries. They maintained a separate dataset focusing specifically on Taiwan-based systems. The article notes the group’s infrastructure includes a command-and-control server hosted on a compromised Gitea instance itself, which is a clever, self-sustaining move.

Host B: That scanning activity shows how quickly these groups move once a vulnerability becomes public. For anyone running Gitea exposed to the internet, this is the kind of campaign that makes patching feel urgent rather than optional. The article doesn’t specify which exact vulnerability was exploited, but given the timing and the public disclosures in recent weeks, it’s likely one of the remote code execution flaws that got patches. The takeaway here is straightforward: if your Gitea instance faces the internet, check your version and update immediately. Better yet, keep it behind a VPN or authentication layer. The report also mentions the attackers were seen deploying a custom backdoor, so it’s not just about disruption—it’s persistent access.

Host A: CISA has added five more vulnerabilities to its Known Exploited Vulnerabilities catalog, all with reports of active exploitation. The flaws impact JFrog Artifactory, ConnectWise ScreenConnect, and MikroTik RouterOS. One of them, CVE-2026-42016 affecting Artifactory, carries a CVSS score of 8.1 for incorrect authorization issues. The other Artifactory flaw, CVE-2026-42017, is a path traversal vulnerability with a 7.5 CVSS score. Federal agencies have until September 28th to patch, but that timeline is a good benchmark for everyone.

Host B: That Artifactory vulnerability looks particularly relevant for anyone running their own artifact repository. ScreenConnect has been a frequent target this year, and MikroTik router flaws often get exploited for initial access. Checking those versions against the KEV catalog is worth the few minutes it takes. The MikroTik RouterOS flaw affects versions before 7.15, and there are reports of it being used in botnet recruitment. It’s a good reminder to check your edge devices, especially if you’re using them for homelab routing or VPN endpoints. The article notes that for the Artifactory flaws, exploitation requires an authenticated user, so it’s a good prompt to review who has access to your internal repos.

Host A: On a different front, a community thread is surfacing an ongoing issue with Plex and Tailscale integration. Users report that while they can access their Plex server via browser using the Tailscale IP, mobile apps like Plexamp and Infuse fail to connect when outside the home network. This started happening after a recent Plex Media Server update, and the core of the problem seems to be how Plex publishes server addresses to its clients. The thread is full of people hitting this exact wall, with some speculating it’s related to Plex’s move to deprecate certain IP ranges for remote access.

Host B: The discussion points to a recent change where Plex stopped publishing Tailscale IPs in the 100.64.0.0/10 subnet through its API, which is how clients discover the server. The workaround mentioned involves setting up Tailscale’s subnet router functionality instead of relying on Plex’s custom server access URL field. That approach seems to still work for people who had it configured before the change. Some users are also having success by manually adding the server via IP in the mobile app, though that’s less seamless. It’s one of those integration pains that pops up when two independent systems change. A few commenters noted that rolling back to Plex Media Server version 1.40.3 temporarily resolves it, but that’s obviously not a long-term fix.

Host A: Moving to container management, a user running rootless Podman with Quadlet-managed containers hit a consistent failure when using Dockhand for updates. The tool fails at the ‘rename old container’ step for every Quadlet-managed container with Restart=always set. They provided specific logs showing the error occurs because the container name is already in use right after Dockhand stops it. The exact sequence is: Dockhand stops the container, but within milliseconds, systemd’s restart policy kicks in and recreates it, causing the name collision.

Host B: Their theory sounds plausible: when Dockhand stops the container via the Podman API, systemd immediately restarts it with the same name before the rename can happen. Basically, two systems trying to manage the same container at the same time. The suggested fix is to use Podman’s own AutoUpdate=registry feature in the Quadlet file instead, which works through systemd rather than competing with it. The Dockhand developer acknowledged the issue on GitHub and suggested the AutoUpdate path as the proper solution for Quadlet-managed containers. It’s a good case study in the friction that can happen when automation tools and init systems both try to manage the same lifecycle. The developer’s comment clarified that Dockhand is designed more for standalone containers, not those tightly integrated with an init system like Quadlet.

Host A: For our tool highlight, Blockbusterr just hit version 2.0. This is a self-hosted media discovery tool that sits between your discovery sources—like TMDB, Trakt, or Simkl—and your delivery tools such as Radarr and Sonarr. Instead of importing entire trending lists or watchlists, it evaluates candidates against your rules before sending anything downstream. The developer announced v2.0 with reusable movie and show rules, job previews that show what would be accepted or rejected before automation kicks in, and per-job delivery limits.

Host B: That preview feature looks genuinely useful. You could follow a trending movie feed but only deliver titles that meet specific language, year, rating, and genre criteria, then check the choices before turning on automation. It runs as a single Docker container with SQLite, and the developer notes that v2.0.1 already fixed some setup bugs reported after the initial release. For anyone tired of their media library filling up with everything that’s popular rather than what they actually want, this kind of filtering layer makes sense. The rule system supports complex conditions—like requiring a minimum IMDb rating unless the movie is in a specific genre you collect. The release notes also mention improved logging and the ability to run discovery jobs on a schedule, which makes it feel more like a set-and-forget component. The developer also mentioned support for Letterboxd scraping as an experimental opt-in integration, so if you track your watch history there, that’s another discovery source to pull from.

Host A: Our community highlight comes from someone sharing their homelab after eight years of evolution. They recently downsized from three Proxmox hosts to a single Ryzen 9 3950x system on an Asrock Rack board, while their TrueNAS setup moved into a Supermicro 36-bay chassis with a Ryzen 5 5600. The whole rack is a Dell EMC unit they had to modify with custom brackets to make the rear rails work properly. They mentioned the consolidation cut their idle power draw from around 450 watts to under 200, which is a huge win.

Host B: What stands out is the practical problem-solving around that proprietary rack. They ended up using U-style clip nuts for the round, unthreaded holes and fabricated brackets to relocate the rear rails to a standard distance. The lab now runs Jellyfin with an RTX A400, Immich, UrBackup, and includes a separate Windows gaming machine accessed via Parsec. It’s a good example of how these setups evolve from simple beginnings to consolidated, purpose-built systems over years. They also highlighted using ZFS replication for backups between the main TrueNAS and a smaller backup server, which is a solid, production-inspired practice. The networking side includes a Ubiquiti UDM for routing and VoIP, a 48-port PoE switch handling most traffic, and a previous-gen 10G switch they picked up used. They specifically called out the power savings as a major driver for the consolidation, noting the new setup handles the same workload more efficiently. It’s a nice reminder that sometimes the best upgrade is consolidating what you already have rather than adding more.

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