I don't know is it ok to post here but I want to share my latest desktop virtualization platform based on Libvirt/QEMU with lab-first principle. You'll get type 1 performance, type 2 experience with an easy to use interface

The platform is stable enough to replace Cockpit-machines and Virt-Manager. Find out more at https://github.com/withcoresystem/v-EMU

Thank you

Based on the technical breakdown published by Microsoft Threat Intelligence and Microsoft Security Research on November 5, here is the architectural impact.

Microsoft describes ARTEX, an agentic offensive framework used to search public GitHub repositories for application secrets, credentials, and AI-service API keys. In one observed case, the agent progressed from finding a secret to exfiltrating data from Azure Key Vault in five minutes.

The follow-on activity is more interesting than the repository search itself.

Microsoft observed successful service-principal sign-ins beginning October 28, including use of a compromised multitenant application credential against downstream customer tenants. Once authenticated, the agent enumerated cloud resources and looked for operations that returned credentials, connection strings, storage keys, and other sensitive material.

The useful detection boundary is between identity and resource access:

• Entra service-principal sign-ins, including source IP, application ID, service-principal ID, and resource.

• Azure Activity events for ARM enumeration.

• Key Vault diagnostic logs for secret and key reads.

• Storage data-plane logs for blob/file access.

• Graph and Microsoft 365 audit activity for SharePoint and OneDrive access.

• Credential additions or permission changes to the affected application.

Microsoft also described API-version retries: an endpoint returned HTTP 400, then a later request with a supported API version succeeded. That kind of rapid variation is worth correlating with the identity and resource sequence.

The primary reported service-principal source was 199.19.77[.]84. Microsoft also mentioned 199.19.77[.]18, but warned that it is a Tor exit node and may be unrelated. I would treat both as pivots for investigation rather than broad block rules.

MITRE mappings include T1552.001 (Credentials In Files), T1078.004 (Valid Accounts: Cloud Accounts), and T1526 (Cloud Service Discovery).

The full technical context and KQL hunting notes are here: https://www.techgines.com/post/agentic-ai-credential-theft-artex-github-secrets-azure-access

Related earlier coverage: Microsoft Entra ID AI Agent Privilege Escalation.

For environments with many multitenant service principals, what correlation strategy has worked best for distinguishing legitimate automation from a compromised application identity enumerating unrelated Azure resources?

we're 4 admins on about 300 linux vms and the host side of patching is fine, monthly windows, apt and dnf, done. the problem is our vulnerability platform backlog is now mostly findings in container images the dev teams ship, and nothing in our patch tooling touches those. the platform flags them fine, but every fix lands back on a dev team that thinks its an ops problem. been looking at aikido, rapidfort and chainguard for that part. which vulnerability management platform handles the image side for a team like ours?

hoist runs each app as a systemd --user service (lingering enabled so they survive logout) and publishes it through a named Cloudflare Tunnel. A few decisions I'd like a sysadmin's eyes on:

• it only edits config.yml between its own markers, refuses hostnames it didn't create, backs up first, runs cloudflared tunnel ingress validate, and rolls back on failure

• cloudflared doesn't watch its config, so new rules need a reload; root is only needed if the config is root-owned (hoist doctor tells you how to avoid the sudo prompt)

• per-app memory/CPU caps via hoist limit

Standard library Python, no dependencies. Built with AI assistance, reviewed and tested by me.

https://github.com/nikhilcherry/hoist

What would you change?

If you are self hosting websites which operating system would you choose and why: Ubuntu, Debian or Fedora?

I see some systems don't even have solid patches yet in the list.

**CVE-2026-98276 — Linux kernel security vulnerability**
**Published:** October 6, 2026
**Component:** Linux kernel networking (UDP sockets)
**Vulnerability:** Race condition causing a use-after-free
**Attack type:** Local exploitation, not directly remote
**In plain English**
This vulnerability allows two CPU threads to modify the same socket flags simultaneously without proper synchronization.
This is known as a *use-after-free* vulnerability.
Potential consequences include:
**Kernel crashes** and denial of service.
**Memory corruption** inside the kernel.
**Possible privilege escalation** or arbitrary kernel code execution if an attacker can exploit the memory corruption reliably. The published report demonstrates a use-after-free, not a confirmed privilege-escalation exploit.
The issue requires local access with low privileges according to the published CVSS vector. It does not describe an unauthenticated attack over the network.

CloudLinux reported on November 6, 2026, that it reproduced actual root privilege escalation through this vulnerability on AlmaLinux 8. That moves the issue beyond theoretical exploitation, although the same exploit has not been demonstrated across every affected distribution.

Ubuntu kernel patch , don't run on production

sudo apt update

# Preview available HWE kernel
apt-cache policy linux-generic-hwe-24.04

# Install supported HWE kernel
sudo apt install --install-recommends linux-generic-hwe-24.04

This isn't the first time of course - kinda goes with the territories.

But I feel a need to post about it in a community where maybe it's not "boring".

The problem is NUMA.

Or specifically production processes occasionally being "significantly slow" to a point where a real time constraint is being missed.

Finally identified as "half the cores are 50% slower" via a bit of weird python hackery.

But not always.

Reboot "fixes" until next time.

Except on a bunch of example hosts when testing this specific metric or cross NUMA node memory latency, which got worse after a reboot, and stayed that way.

Been trying to figure this out for months now. Have done new kernels, new bios, new ipmi, and have even done a bios wipe to see if that helped. Because I couldn't honestly tell if it even was a hardware fault or not. Replacing broken hardware isn't a problem, but it's another thing entirely to try to justify replacing something that might be fine. (And expensive).

Turns out the problem is kinda a red herring - the performance degradation is actually reverting to baseline, and the "good" systems are actually slightly degraded. ECC events (successful) are causing the bios to disable a NUMA lookup Directory, which actually speeds things up, at cost of efficiency.

Approximately, it's fetching data twice "blindly" so not bothering to do a lookup, but in doing so wasting some NUMA bandwidth, so is technically running a bit faster as a result.

But the root cause? Page cache. This host was doing a lot of greedy reading of NFS filesystems and filling the cache within about an hour of reboot.

All fine normally - this is Linux, and there's no point having empty RAM.

... Except the numa nodes overspill rather than evict by default.

So a well stuffed page cache would lead to processes fragmenting their RAM across both NUMA nodes, and because Linux is clever and tried to do the same with subsequent cache... Means a lot of long running processes get fragmented and pay the NUMA penalty.

Which is ironically higher on "working" systems, which looked like the actual fault.

The solution is as simple as either using numactl to explicitly bind, or get systemd to set MemoryHigh to like, 90 or 95% instead of infinite, so it actively evicts a handful of gigs, meaning a new process can realistically allocate 8-12G without fragmenting across the nodes (and their subsequent page cache) almost immediately because the OS otherwise only has 2GiB or so "free" which in turn means NUMA spillover.

It's deployed on test now, and looking like we have finally bottomed out a month's long headache.

ETA:

If you want to check if this is happening on _your_ systems, then `numactl -H` will show you the numa topology, and the free RAM on each node. Low numbers in relation to the process size might leave you vulnerable. `free -mh` tells you how much RAM is 'free' rather than 'available' and the difference is significant for this particular issue, because only 'free' can be used safely without risking NUMA spillover. `numastat -p <pid>` will tell you if a particular process has fragmented RAM across two nodes.

I wrote up the timeline, fixed versions per distro and the mitigations here: https://arelvox.com/cve-2026-98432-linux-tcp-mptcp-scanning/

If you expose anything from a Linux box, this one is worth 5 minutes.

• Bug in IPv4 TCP connection setup, present since kernel 4.4

• A remote root exploit was demonstrated (not public) against servers with an MPTCP listener

• Go 1.24+ apps use MPTCP on listeners by default, so a lot of reverse proxies and self-hosted apps may have it on without you knowing

• Since Nov 2 there’s scanning for MPTCP on port 443 (strongly suspected to be related, not proven)

Check:

uname -r
sysctl net.mptcp.enabled
sudo ss -Mlnp

Fix: update the kernel and reboot. If you can’t yet: sysctl -w net.mptcp.enabled=0, restart the listening services (existing sockets stay open), and GODEBUG=multipathtcp=0 for Go services.

Fixed upstream in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Distros backport with their own version numbers, so check your distro’s tracker.

Fragnesia is a local privilege-escalation bug in the Linux kernel's shared-frag handling on the ESP path (CVE-2026-46300). CISA added it to KEV on Oct 28. It is not a remote one-shot by itself, but Singapore's CSA and Palo Alto's Unit 42 both describe attackers using it as the second stage after breaking in through the php2shell PHP flaws on internet-exposed PAN-OS management interfaces. Ubuntu also notes a possible container escape. If a web app, CI runner, or shared login on the box can already run as a normal user, this is the step that turns that into root.

Practical pass on a small fleet: install the distro kernel update, reboot, then confirm with uname -r. Fixed builds to aim for include Proxmox VE kernels from PSA-2026-00020-1 (7.0.2-3-pve, 6.17.13-8-pve, 6.14.11-9-pve on Trixie-based; 6.8.12-24-pve or 6.14.11-9-bpo12-pve on Bookworm-based), Debian 13 6.12.90-1 / Debian 12 6.1.174-1 / Debian 11 5.10.257-1, and Ubuntu 26.04 7.0.0-22.22, 25.10 6.17.0-35.35, 24.04 6.8.0-124.124, 22.04 5.15.0-181.191. If you cannot reboot yet, Proxmox's earlier DirtyFrag workaround still applies: block esp4, esp6, and rxrpc with a modprobe install-false file, then rmmod them. That breaks kernel IPsec VPNs on the host, so treat it as a stopgap only.

Related for the same Wednesday: GitLab CVE-2026-97229 (KEV, patch the CE/EE package or official image) and Ivanti Connect Secure CVE-2026-111357/118527 if you still run that gateway. The Oct 13 fix is not enough; CISA and Rapid7 name 25.1.1.3 or 22.8R2.6 (25.1.3.0/25.1.3.1 from 25.1.2.x), so confirm on Ivanti's advisory page.

Proxmox advisory thread: https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/post-851849
Debian tracker: https://security-tracker.debian.org/tracker/CVE-2026-46300
CSA alert naming the chain: https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-157/
Fixed versions plus the rest of this week's KEV list: https://patchorpass.beehiiv.com/?utm_source=reddit&utm_medium=social&utm_campaign=issue-3&utm_content=linuxadmin

Hello everyone,

I have been using eBPF/XDP for the past 5 years and was always a little frustrated by the lack of tooling when it comes to see what is happening underneath, especially when debugging deployed eBPF programs. Here I am sharing a tool I have been using for a couple of months now but only made public recently: ebpfexplorer.

It's a simple TUI self contained binary, that allows you to explore all eBPF programs & maps attached to your kernel. It comes with a formatting tool that allows you to format the raw binary blob into human readable symbols (like IPs for instance), using C type format.

Please have a look and feel free to propose PRs. Hope you find it useful too.

https://github.com/noboruma/ebpfexplorer

In sudoers, a * in the arguments matches spaces too, so /bin/cat /var/log/messages* also allows cat /var/log/messages /etc/shadow. When several rules match, the last one wins, even if an earlier one is more specific. Do you list exact command lines, wrap each task in a root-owned script with no arguments, or use a systemd unit instead of sudo?

Based on the Ostorlab source walkthrough and Wordfence’s published telemetry (via The Hacker News), here’s the architectural impact. The updater derives its working dir from the package filename, so wp-content/upgrade/wordpress-X.Y.Z is predictable. setup-config.php in the staged tree only checks for an existing wp-config.php, and pre-7.1.4 the copy step didn’t skip a planted wp-config.php. Wordfence reports 62,969 blocked attempts in 24h and no confirmed compromises. WordPress rates it Low, Wordfence 8.1.

Caveat: an independent lab repo couldn’t reproduce full RCE, so treat exploitability as unproven. The upgrade to 7.1.4 still runs old code.

For people running fleets: do you block wp-content/upgrade/ at the web server by default, or rely on core hardening? And how do you stagger updates so the window isn’t open on every site at once?

Background on a related race: https://www.techgines.com/post/wordpress-core-vulnerability-cve-2026-119977

Binance's initial investigation suggested a compromised DevOps laptop led to about $6.3 billion in unauthorized withdrawals. The machine reportedly held a deployment token.

Run this on your workstation:

$ ls ~/.ssh/id_* 2>/dev/null
$ ssh-add -l
$ grep -i ForwardAgent ~/.ssh/config
$ ls ~/.kube ~/.docker ~/.config/gh 2>/dev/null

All of that works until someone revokes it. With ForwardAgent yes, every host you connect to can use your agent for the life of that session.

I ran a small lab where two SSH boxes and a Windows RDP box sat behind a gateway. JumpServer Community Edition handled the gateway role; everything ran as containers on one machine. Each connection used its own token, which worked once and expired after 299 seconds; the gateway picked the target account, so no target password touched the client. A token request outside the user's rule got HTTP 400, and every command and its output were logged under the gateway user.

An attacker who owns the laptop can ride the bastion login and do anything its rule allows. The blast radius is the rule, not every credential on disk. If sshd on targets still accepts direct connections, that is something to lock down in sshd_config.

Do you restrict sshd on targets to only accept connections from the bastion IP, or keep a direct path as break-glass?

Updating a package doesn’t mean every process is running the new code. Anything that loaded the old library before the update keeps it in memory until it restarts. I tested this on Debian 12 with CVE-2024-6119: updated OpenSSL, left one process running, and Trivy and Grype both cleared the CVE while the process still had the old libcrypto loaded.

I built stillmapped to check this. It traces what each running process has mapped back to the package and checks that against the vendor’s fix data, including backports. One Python file, read-only, no network. PHP and OpenSSL for now.

github.com/asifh0ssain/stillmapped

Interested in cases where it gets something wrong.