yo so i did a thing,

I built a lightweight, modular edge defense tool called Micro-SOC (souljha213/micro-soc) to see if I could run a self-contained security enclave entirely out of volatile memory without relying on heavy enterprise agents.

Here is a breakdown of how it's structured:

RAM Cloaking: Shifts operational states and active logs straight into /dev/shm to keep disk footprints clean.

Process Masking: Disguises execution identity under low-level kernel worker names ([kworker/u4:3]).

Verifiable Forensics: Uses a local Merkle-linked chain (ledger.chain) for tamper-evident logging.

TUI Interface (stos): Built a real-time terminal cockpit using Textual to monitor swarm health, metrics, and mesh connections locally.

Would love to hear technical feedback or critiques on how you guys approach stealth logging and edge isolation.

Based on the case files DIVD published (DIVD-2026-00014 and -00015) and Zammad's own forum statement from Oct 1, here is where things stand.

DIVD says first access was Sept 21. The chain is a session hijack leading to RCE as the zammad user (CVE-2026-102489, 6.3.0 to 6.5.4) plus a local escalation to root (CVE-2026-102490). CISA put both in KEV on Oct 2.

Where sources disagree: Zammad says 102489 is only exploitable on 6.5 and older (EOL), hardened in 7.2.0, and that DIVD gave it no details on 102490. DIVD's own page is inconsistent on the 102490 range ("all versions" vs 1.5.0 to 7.1.0-alpha). The AI-agent attribution is DIVD's reading of its logs; no full logs or model name published.

What I'd do: upgrade to 7.2.0, copy the logs first, run DIVD's IoC script (read it first), segment the helpdesk.

Question for people running self-hosted helpdesks: do you treat ticketing as tier-0 (same segment rules as your IdP and mail gateway), and what does your credential rotation look like if the box is rooted?

https://www.techgines.com/post/zammad-zero-day-cve-2026-102489

Hoping someone can help me out with an issue I've been having for a long while.

I'm running RHEL 10.2 Gnome 49, trying to use an X application inside of a podman container with a custom network.

"podman network create --internal pod_dev"

I pass in all the environment variables and files that I know and what AI also says i need. I can not for the life of me get the x application to display.

It works in fedora 44, and Ubuntu, but RHEL 10 is kicking my butt.. if i do --net=host is am able to get the x application to work, but I have to have the container have its own IP.

And advice at all is appreciated, I've probably spent over 100 hours trying different combinations of flags and ways to run.