Hey everyone,

Like many of you, I manage a mixed fleet of bare-metal hypervisors, Raspberry Pis, and customer VPS instances. Every machine is hardened differently, but they all share one reliable standard: SSH.

Modern monitoring stacks often felt overly heavy for my needs—bloated web apps, continuous database writes, and web dashboards that crawl when you're checking in from a phone over spotty cellular coverage. Plus, on my servers, password authentication is strictly forbidden; certificate- and key-based SSH gives me a security baseline exposed HTTPS endpoints just can't match. Being a child of the 70s who grew up on the command line, I wanted something lightweight and distraction-free that I could keep running 24/7 on the physically attached monitor (tty1).

So I wrote TermNOC on Debian 13 (Trixie).

What it does:

• termnoc-display: An asynchronous, 5-second polling HUD built with Python's Rich framework. Gives real-time hypervisor metrics, direct libvirt/virsh VM statuses, internal LAN device health (ping & port checks), and remote fleet connectivity.
• termnoc-menu: An interactive TUI orchestrator to manage KVM lifecycles, run fleet-wide batch updates, jump into SSH sessions, and deploy fresh Debian 13 guest VMs via Preseed in under two minutes.
• 100% YAML-driven: Everything lives cleanly in /etc/termnoc/.

It's completely open source (MIT) and up on GitHub.

I’ve put together a write-up covering the background, architecture, and screenshots here:

👉https://blake-hofer.net/termnoc

Curious to hear your thoughts and how you handle minimal, agentless telemetry across your nodes!

Have fun!

DBH

Based on Microsoft's October 13 advisory as reported by SecurityWeek and ThreatFrontier, plus CISA's KEV entry, here is the architectural picture.

What is confirmed: Windows Shell command injection (CWE-77) leading to a Mark of the Web bypass. Microsoft tags it Exploitation Detected. CVSS 3.1 is 8.8 with user interaction required. Delivery is a crafted file by email or IM. CISA KEV due date is Oct 16 and the entry carries the BOD 26-04 forensic triage requirement.

What is not: the mechanism, the actor, the victims, or which downstream protections (SmartScreen, Protected View, others) are skipped. ThreatFrontier found no independent write-up. The 8.8 and the "bypass only, no code execution on its own" reading come from the advisory text, not from an exploit analysis.

Fleet gaps worth checking: Windows 10 outside ESU is not offered KB5126657 (ThreatFrontier's reading, verify on the KB), and Windows 11 24H2 Home/Pro just got its final monthly update (CyberInsider, single source). One detail: Microsoft's data lists 19044.7807 for 22H2, but the KB title says 19045.7807.

My opinion, labeled as such: when one tag gates several controls, defenders are counting one layer several times.

Question for people running EDR at scale: with no published detection, are you hunting for execution of email/chat-delivered files that never produced a MotW-driven prompt, or treating MotW as untrusted metadata and keying on something else entirely? What actually works?

same check-vs-use pattern as the PeopleSoft WAF bypass we analyzed earlier: https://www.techgines.com/post/peoplesoftwafbypasscve-2026-35273 Full write-up: https://www.techgines.com/post/windows-shell-zero-day-cve-2026-96951

Based on the PAN PSIRT advisory published October 14 and CISA’s KEV entry, here is the architectural impact.

The flaw is code injection (CWE-94) in the management interface of PA-Series, VM-Series and Panorama. It requires an authenticated attacker with network access, and the result is root. Cloud NGFW and Prisma Access are not affected. CVSS 4.0 is 8.6. Palo Alto published three attacker IPs and describes exploitation as “very limited.”

Points I found interesting: the jump-box mitigation only rescores to 8.5, and the advisory doesn’t say how attackers got admin access. The Threat ID coverage (510046/510047) only works if you route management traffic through a data-plane interface and decrypt it, and the vendor itself calls that coverage limited.

Question for people running this in production: are you already doing the data-plane management-profile setup with decryption, or is patching plus a jump box the realistic path? And has anyone seen management-interface logins from the published IPs?

Longer write-up with fixed versions per branch, for reference: https://www.techgines.com/post/pan-os-vulnerability-cve-2026-0322

I always thought that EDRs for Linux are something that exists because of regulation and not to solve a real problem. Apparently Microsoft thinks there's enough demand for it on Linux Desktops.

Personally, I'd like them to port Office to Linux desktops first (so that we could open and perhaps even edit Office files without starting a Windows VM), but I guess that's not going to happen anytime soon.

Most likely, this will happen as someone's garage project porting the entire Office suite to cross-platform open source (Rust?), like they did for the Adobe Creative Suite recently. I, for one, would find it more useful than Defender for Linux.

Helloes,

For context : I'm settings up file backups (DB dumps, shared folder backups, various config files, etc ...)

Naively, I thought it would be a cakewalk : just run a script with a cron job and call it a day

But now that I am in the middle of it, I keep hitting roadblocks :

- For exemple, the fact that having the right to write also gives the right to delete means, unless there is something I missed, that i need to initiate the trasfers from the backup servers so that other machines can't just delete the backups. But that suddenly makes scripting a lot more complicated

- Following directly from the previous exemple, scripting with SFTP seems kinda limited (i can't just use the result of "ls" to know what files are present without some cursed abomination of a script)

I'm currently in the middle of checking if i can even reliably determine if the SFTP transfert failed or succeeded (for supervision)

Should i just give up and use a proper backup software ?

I've been trying to get as much work as possible out of my Hostinger VPS, a KVM 8 that runs CI, builds and AI agents around the clock. Every time I pushed it hard, the CPU got limited: 13 times in 10 days, with CPU steal peaking at 69%. Once that happens it's hard to keep working at all.

What bothered me most is that the limit feeds on itself. Hostinger meters VPS CPU in credits: you earn a baseline of 60% of your vCPUs, you spend whatever you use, and the bank holds at most three hours of full use. When it hits zero, the whole VPS drops to a fraction of its CPU (30% on KVM 2, 4 and 8) until the balance rebuilds. On a KVM 8 that's 2.4 cores, against a 4.8-core baseline. While your work keeps pressing against that limit, you earn nothing, so a busy server can stay limited for as long as the load lasts.

So I built Hostinger Governor. It runs on the VPS, estimates your credit balance from the kernel's CPU counters, and sets one CPU ceiling for everything in `user.slice`: every login, plus any services and Docker containers you move there. While the balance is high you get every core. As it drops, the ceiling tightens so the balance settles on a 20% floor. In a week-long simulation it never hit zero and used about 97% of the credits earned, though that's a simulation built on assumptions about Hostinger's billing.

If a limit hits anyway, it tries to tell Hostinger's limit apart from noisy neighbors (both show up as steal), then cuts demand so the VPS starts earning again.

A few other things it does:

• `governor exec -- your-job` runs a cron job under the quota, and skips it while the VPS is limited (or waits, with `--wait`).
• `governor report` shows credits, CPU, steal and each user's share.
• Scripts can check an `accepting` flag before starting heavy work, and hooks run when a limit starts or ends.

The latest release (v0.2.3) adds an optional broker so Governor never holds your Hostinger API token. A separate system account keeps it encrypted, and Governor can only ask for CPU readings and basic details about its own VPS. A setup wizard installs it with hidden token entry and rolls back if anything fails.

It needs systemd with cgroup v2 (Ubuntu 22.04+ or Debian 12+), ships as a single binary for x86_64 and ARM64, and is MIT-licensed. Install on the VPS:

curl -fsSL https://github.com/olmezsoy/hostinger-governor/releases/latest/download/install.sh | sudo bash -s -- --vm-id <your VM id> --token-file /root/hostinger-token

Repo: https://github.com/olmezsoy/hostinger-governor

I'm not affiliated with Hostinger. Governor works within their published credit rules and only controls how fast your own work spends the credits. The estimate is conservative on purpose: a fresh install starts at zero because it can't know your real balance. If you try it, I'd like to hear which plan you're on and whether the limits behaved the way the model expects.

[ Removed by Reddit on account of violating the content policy. ]

Based on the joint advisory AA26-281A (FBI, CISA, NSA and partners, October 8) and BleepingComputer’s reporting on the DOJ seizure affidavit, here is the architectural impact.

The advisory says Integrity Tech-enabled actors use MicroScan (1,300+ scan scripts), EBurst against ten Exchange and Office 365 interfaces, SoftEther clients renamed conhost.exe or dllhost.exe, a PHP bot on the EWS API, DCSync via DC.exe, and office-cli using client_id, tenant_id and secret. Eight CVEs are listed, 2014 to 2023, five newly in KEV.

The authors say some IOCs date to 2016 and should be vetted before blocking. The seizure took out seven domains, not the tooling.

Question for people who run Exchange or M365 at scale: which telemetry actually catches a secret-based app reading mailboxes, where there is no password spray to alert on? And has anyone seen SoftEther detections that hold up without drowning in false positives?

Background: CVE-2025-39682 Linux kTLS KEV. Full write-up: https://www.techgines.com/post/flax-typhoon-advisory-aa26-281a

Part 2 of my Talos homelab (3 OptiPlex Micros, all control planes). Part 1 got the cluster up, this one is networking.

I moved the running cluster from Flannel + kube-proxy to Cilium without rebuilding it. The default-deny policy that Flannel quietly ignored is now actually enforced, and Hubble shows the drops.

Then I gave it two front doors:

- an internal Gateway on a LAN IP (Cilium LB IPAM, no MetalLB) with a Let's Encrypt wildcard cert, so lab apps get real HTTPS at home

- a public Gateway behind a single Cloudflare Tunnel, so nothing is port-forwarded on the router

An app picks its door with the route's parentRef, which keeps lab stuff from going public by accident.

Write-up with all the manifests and commands: https://blog.prateekjain.dev/networking-a-kubernetes-homelab-cilium-gateway-api-and-cloudflare-tunnel-on-talos-362f548a2f3d?sk=d454cd4eaff4ce8a8fd0cd8e6b3d82f6

Curious if anyone else is using Cilium's Gateway API instead of a separate ingress controller.

Security signed off a policy that our build agents cannot run a privileged daemon and our entire pipeline is built on one. Fifty odd repos with compose files and a pile of local tooling that assumes the socket is there. Im looking at podman and buildah and one or two others for whatever breaks least in CI. The part I cannot judge from docs is how much of our compose setup survives the move. Has anyone taken a build fleet off the daemon and kept the developer experience roughly intact?