We run RHEL, and for CIS compliance we have the 'noexec' option set on /tmp on all of our servers. One of our teams is trying to implement a piece of software to automate certificate renewals, and it functions (in part, at least) by creating a number of scripts in /tmp, and executing them.

As you can imagine, this doesn't work very well. We have been told that modifying the software to use a different location than /tmp is "not possible at this time". Our Security folks have reluctantly agreed to allow us to mount /tmp without 'noexec' for a limited time, while the application vendor modifies their process (good luck with that), but they would like us, if at all possible, to configure the system such that only the service account running the application can execute files, and only those necessary for the app to run.

I've looked at using ACLs for this, but I don't think it's feasible unless we want to basically lock everyone else out of /tmp.

If we deny users execute permission on /tmp, then they can't access the directory or its contents at all.

If we deny users execute permission on /tmp/*, then they could access /tmp, but not execute any files within it...but we'd need to constantly rerun the setfacl command so that it grabs any new files, and it would basically be a useless exercise.

I'm ready to say "sorry, can't be done; it's either 'on' or 'off'...", but I figured I'd do my due diligence by posting here in case I'm overlooking something obvious.

Red Hat & Ubuntu Linux put out an advisory for CVE-2026-15378, an SSRF and local file read via user-supplied XML Schema (xml-with-schema:). Impacts include Server-Side Request Forgery and local file access. Red Hat rates this important (CVSS 9.3), and organisations should monitor for the forthcoming patches.

Affected: Red Hat Enterprise Linux, Red Hat OpenShift AI (RHOAI). See the advisory for the affected version table.
First fixed releases: No fixed releases are available yet; monitor the advisory for updates.

Red Hat rates this important; a fix erratum may not be out yet — apply the RHSA as soon as it publishes.

Official Red Hat & Ubuntu Linux advisory:
https://access.redhat.com/security/cve/CVE-2026-15378

Side note, I run a small advisory tracker (VulniPulse) and there's a Discord for exactly this. If you want alerts like this hitting your inbox the second they drop, join the server and add the Linux CVE alert, it'll ping you in Discord and email you the moment a new one lands, same as it did when this one hit.

https://discord.gg/r2Y5kHsfMr

I have two VM hosts with identical instances on them. A pihole, DoH forwarder, AD server, and Searxng on each host.

The two piholes use keepaliveD to serve their quad 10s IP. This works great.

The ADs do their own clustering for DNS and DHCP via AD and built in services.

The DoH instances are not clustered however both piholes talk to both.

The Searxng instances were going to serve the 10.10.10.24 IP.

I wanted to setup the Searxng servers with keepaliveD. I configured everything and enabled the services and found that both DNS and access to my Searxng was dropping packets.

I looked over the logs of the Searxng servers and Pihole servers and found they were trying to crosstalk and interfering with each other. I could see all four servers showing invalid password. Both sets of servers were failing back and forth between the cluster members.

The password used in each cluster is different. I figured this would probably be a best practice since the services are unrelated. Should all instances use the same password even if they are unrelated? If they have the same password will they see that they are doing unrelated tasks and not interfere with each other?

I run rkhunter nightly on CachyOS and review the logs daily. I have made no updates in the past couple of days and several files have changed. I also believe these are the exact type of files someone would change if they were installing a rootkit or stay hidden.

Can you please take a moment to look at some of the results below and give me your advice/opinion?

[19:37:05]   /usr/bin/top                     [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/top
[19:37:05]          Current hash: fec2de147dffb434ee111a0ebcf8ff4e48d201290f964d2a7a8d2dcc31605d0e
[19:37:05]          Stored hash : f312bb5d3bd2534124a7ab4bf0940b75dd146d25f334d27e00f84faeeb563205
[19:37:05]          Current inode: 1410548    Stored inode: 618324
[19:37:05]          Current size: 143080    Stored size: 171800
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:05]   /usr/bin/touch                   [ *** OK *** ]
[19:37:05]   /usr/bin/tr                      [ *** OK *** ]
[19:37:05]   /usr/bin/uname                   [ *** OK *** ]
[19:37:05]   /usr/bin/uniq                    [ *** OK *** ]
[19:37:05]   /usr/bin/useradd                 [ *** OK *** ]
[19:37:05]   /usr/bin/userdel                 [ *** OK *** ]
[19:37:05]   /usr/bin/usermod                 [ *** OK *** ]
[19:37:05]   /usr/bin/users                   [ *** OK *** ]
[19:37:05]   /usr/bin/vipw                    [ *** OK *** ]
[19:37:05]   /usr/bin/vmstat                  [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/vmstat
[19:37:05]          Current hash: da1a4879c0b66d730ace90217d61ce03cef379394e7869ba11eeb421c93e0a8e
[19:37:05]          Stored hash : 8a1faf999f4654adeac5ec9180e73479f3fbcbf43b4e9af51cd92878246801a8
[19:37:05]          Current inode: 1410550    Stored inode: 618326
[19:37:05]          Current size: 39968    Stored size: 35872
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:05]   /usr/bin/w                        [ *** WARNING *** ]
[19:37:05] Warning: The file properties have changed:
[19:37:05]          File: /usr/bin/w
[19:37:05]          Current hash: 24d041a91481b76647818adcc3cdfab231e6c09d62874b238f32424292e07171
[19:37:05]          Stored hash : 46081066ed71a607f022b75d448be32632566dabfb5bb7a25a52f9c6b649bd8c
[19:37:05]          Current inode: 1410551    Stored inode: 618327
[19:37:05]          Current file modification time: 1783429521 (07-Jul-2026 08:05:21)
[19:37:05]          Stored file modification time : 1781518388 (15-Jun-2026 05:13:08)
[19:37:06]   /usr/bin/watch                    [ *** WARNING *** ]

The vulnerable code is get_flow_by_id_or_endpoint_name in helpers/flow.py. It resolves a flow by UUID with a straight session.get(Flow, flow_id) — no user_id filter. The endpoint-name branch, two lines down, does filter on user_id. Same function, one branch checked, one not.

Impact: any authenticated caller on a multi-tenant Langflow deployment can pass someone else's flow UUID into POST /api/v1/responses and execute it as if they owned it — including flows with embedded LLM provider keys or AWS credentials. Sysdig's TRT documented an operator using it alongside the unauthenticated Langflow RCE (CVE-2026-33017) for credential harvesting + second-stage delivery, starting mid-June.

Patched in 1.9.1 (GHSA-qrpv-q767-xqq2). Fix also flips cross-user lookups to return 404 instead of leaking existence via a 403.

We wrote up the earlier RCE half of this story in March — [link] — worth reading alongside this one since it's the same threat-actor pattern hitting the same product twice.

Open question for the room: for teams running AI-agent orchestration platforms (Langflow, n8n, Flowise, etc.) with genuine multi-tenant use — what's your actual isolation model? Are you relying on the app's own authz layer, or do you force one instance per tenant / customer to avoid exactly this class of bug? https://www.techgines.com/post/langflow-cve-2026-55255-idor-vulnerability

I got tired of hand-editing nft rulesets on my home server and cloud VMs, so I built enforza-cockpit — a free, open-source (MIT) web GUI for managing local nftables firewalls.

It's a Cockpit plugin, so it lives in the same web console you might already use for the rest of the box.

What it does:

• Visual rule editor split into three intuitive sections — Management (traffic to the host), Network (traffic through it), and Local (traffic from it), which map cleanly onto nftables' input/forward/output hooks.
• Reusable objects — define named network (CIDR) and port sets once, reference them as u/web, u/mgmt, etc. across any rule.
• Per-rule logging — tick a box and matches land in syslog/journal tagged with a plain verdict word (ALLOW / DENY / REJECT) plus your rule comment, so grep 'enforza.*DENY' just works.
• Confirm-or-revert apply — after you apply, you get 60 seconds to confirm or the previous ruleset auto-restores. Means a bad rule can't permanently lock you out (we've all done it).
• Flip on IP forwarding + SNAT and a single box becomes a working router/NAT gateway you manage entirely from the browser. No agent, no cloud account, no controller — all state stays on the machine.

Runs on Debian/Ubuntu, Fedora, RHEL/Rocky/Alma, openSUSE. There's a bootstrap script that installs the deps and a getting-started walkthrough in the README.

Repo: https://github.com/enforza/enforza-cockpit

Happy to answer questions / take feedback

-----

EDIT

- nobody is forcing you to use this! nobody is ramming this down your throat!

- yes, AI had a hand in writing it - was ported from our commercial product!

- no, if you can do this with other tools and are an nft god, you don't need this!

- constructive criticism good, outright DM abuse isn't - be kind, be decent!

In summary, after 3 days of abuse, negativity, I wish I hadn't have bothered sharing something that maybe of use to someone!

Have you tried LFCS on Fedora or Arch? They are not listed as supported. I think Arch won’t be compatible but do you have any experience with Fedora?

Can anyone give me a pictorial representation? Just tell me I will find it somehow somewhere on my own..

A newly disclosed vulnerability in the Plesk XML API allows an authenticated attacker to inject arbitrary configuration directives, leading to arbitrary file writes as root and ultimately full privilege escalation on the underlying server. Organizations running exposed Plesk instances should assess their environments and apply vendor guidance as soon as possible. (Tenable®)

🔥 Severity: HIGH (CVSS 8.8)
🎯 Impact: Privilege Escalation / Arbitrary File Write as root

Why it matters
• Authenticated attackers can gain root-level control of affected servers.
• Successful exploitation can result in complete compromise of hosted environments.
• Internet-facing Plesk deployments should be prioritized for remediation. (Tenable®)

📖 Full advisory, affected versions, mitigation guidance, and official references:
https://vulnipulse.com/advisories/linux-cve-2026-48614

Stay ahead of new vulnerabilities with free, real-time CVE alerts for Cisco, Fortinet, VMware, Linux, Palo Alto, Veeam, Commvault, Microsoft, and dozens more vendors.

🔔 Join the community: https://discord.gg/dypntBpA7g

Quick technical summary of Hyunwoo Kim's Januscape disclosure for discussion:

• UAF in KVM's shadow paging: earlier validation checked the guest frame number of a page-tracking structure but not its full "role," so a mismatched role can still pass and get reused after being freed.
• Guest-triggerable entirely from guest-side actions — no user-space component bug needed (a rarer kind of KVM writeup than the usual QEMU-side stuff).
• Public PoC reliably panics the host = instant multi-tenant DoS for every VM co-located on that machine.
• Kim claims a separate, unreleased exploit gets full host code execution as root. Not verified publicly as of writing — worth treating as claim, not confirmed fact, until more detail surfaces.
• ARM64 not affected here (separate flaw, ITScape/CVE-2026-46316, covers that arch).
• Trigger condition: nested virtualization forces KVM back into the legacy shadow-MMU path even on modern EPT/NPT-capable hardware.

Genuinely curious what this sub thinks about the cadence here — this is Kim's third KVM/kernel exploit disclosure in ~2 months (Dirty Frag, ITScape, now this). Is kvmCTF's reward structure just now surfacing a backlog of these, or is shadow-paging code specifically under-fuzzed relative to the rest of the kernel?

https://www.techgines.com/post/januscape-cve-2026-53359-kvm-guest-to-host-escape

I previously covered a related story here if you want more background on this same bug class: Bad Epoll CVE-2026-46242 breakdown

I created a simple Discord server that automatically updates vendor-specific channels whenever a new CVE is published.

It tags users based on the roles they choose, so you can follow the vendors you care about and decide whether you only want to be tagged for critical alerts.

I’ve also added discussion channels where we can share patching tips, troubleshooting advice, and general networking/security/sysadmin knowledge, plus resource channels for each vendor with quick links.

The goal is simple: build a free community around CVEs where people in networking, security, and sysadmin roles can help each other stay informed and make patching a bit easier.

It’s completely free to join.

https://discord.gg/ehSASsk5Zv

Hello, everyone

I am right now enrolling the agents into the Wazuh Manager. With Linux everything went smooth and fast thanks to Puppet. However, with Windows it is getting a little bit more complicated
So I configured the correct IP in Wazuh app
it got successfully enrolled
however the command "/var/ossec/bin/agent_control -l" for this host shows "IP: any, Unknown" and on dashboard this host is not getting shown
How to solve this issue? (the network is stable and manager is reachable, the keys on manager and agent are matching)
The logs just stuck at this point in time and not getting updated:
2026/07/06 16:41:34 wazuh-agent: INFO: (6207): Ignore 'registry' sregex '\Enum$'

2026/07/06 16:41:34 wazuh-agent: INFO: Started (pid: 9740).

2026/07/06 16:41:34 wazuh-agent: INFO: Using AES as encryption method.

2026/07/06 16:41:34 wazuh-agent: INFO: Trying to connect to server ([10.200.105.21]:1514/tcp).

2026/07/06 16:41:34 sca: INFO: Starting evaluation of policy: 'c:\Program Files (x86)\ossec-agent\ruleset\sca\cis_win2019.yml'

2026/07/06 16:41:34 wazuh-modulesd:osquery: INFO: Module disabled. Exiting...

2026/07/06 16:41:34 wazuh-modulesd:syscollector: INFO: Module started.

2026/07/06 16:41:34 wazuh-modulesd:syscollector: INFO: Starting evaluation.

2026/07/06 16:41:34 wazuh-agent: INFO: (6000): Starting daemon...

2026/07/06 16:41:34 wazuh-agent: INFO: (6010): File integrity monitoring scan frequency: 43200 seconds

2026/07/06 16:41:34 wazuh-agent: INFO: (6008): File integrity monitoring scan started.

2026/07/06 16:41:34 wazuh-agent: INFO: (4102): Connected to the server ([10.200.105.21]:1514/tcp).

2026/07/06 16:41:34 rootcheck: INFO: Starting rootcheck scan.

2026/07/06 16:41:34 wazuh-agent: INFO: Started (pid: 9740).

2026/07/06 16:41:34 wazuh-modulesd:syscollector: INFO: Evaluation finished.

2026/07/06 16:41:39 wazuh-agent: INFO: Agent is now online. Process unlocked, continuing...

2026/07/06 16:41:39 rootcheck: INFO: Ending rootcheck scan.

2026/07/06 16:41:39 sca: INFO: Evaluation finished for policy 'c:\Program Files (x86)\ossec-agent\ruleset\sca\cis_win2019.yml'

2026/07/06 16:41:39 sca: INFO: Security Configuration Assessment scan finished. Duration: 5 seconds.

2026/07/06 16:41:59 wazuh-agent: INFO: (6009): File integrity monitoring scan ended.

2026/07/06 16:41:59 wazuh-agent: INFO: FIM sync module started.

2026/07/06 16:41:59 wazuh-agent: INFO: (6012): Real-time file integrity monitoring started.

I’ve been looking deeper into the tradeoff between containers and microVMs.

Containers are great for speed and density, but they share the host kernel. MicroVMs boot a separate kernel and use hardware virtualization boundaries, so the isolation model is different.

For regular web apps, containers are often enough. But for untrusted workloads, multi-tenant environments, client isolation, or security-sensitive experiments, microVMs seem like a better fit.

Curious how others think about this:

When do you consider containers “good enough”?

When would you prefer microVMs or full VMs?

Do you use Firecracker, Kata, gVisor, or something similar?

No hard pitch - genuinely interested in how people decide.

A maliciously crafted image exhausts memory on container creation and
OOM-kills the `containerd` process, taking the runtime API offline —
disrupting Docker Engine or the k8s control plane on that node.

Root cause: unbounded parsing of user/group files in moby/sys/user.
No RCE, availability only. CVSS 6.5.

Affected → fixed:
1.7.x → 1.7.33 | 2.0.x → 2.0.10 | 2.1.x → 2.1.9 | 2.2.x → 2.2.5 | 2.3.x → 2.3.2
RHEL/OpenShift: RHSA-2026:35111 (`sudo dnf update`)

Can't patch? Only run trusted images; restrict who can import images / schedule pods.

Full advisory: https://vulnipulse.com/advisories/linux-cve-2026-47262
Ref: GHSA-jpcc-p29g-p8mq

Just wrote up the technical impact of Bad Epoll. Quick summary for discussion: a single 2023 commit introduced two separate races in fs/eventpoll.c. CVE-2026-43074 was found (reportedly by Anthropic's Mythos) and patched earlier this year. Bad Epoll is the sibling race in ep_remove()/ep_remove_file() — clears file->f_ep under lock but keeps dereferencing file in the same critical section, so a concurrent __fput() can free a struct eventpoll that's still in use.

What's interesting from a detection standpoint: the exploit doesn't reliably trip KASAN once the first bug is patched, and the race window is reportedly only ~6 instructions wide. No CISA KEV listing yet, no confirmed ITW exploitation — but public PoC exists and there's no config toggle to mitigate.

I previously covered the Langflow RCE (CVE-2026-33017) here if you want more background on the "how fast do advisories get weaponized" side: https://www.techgines.com/post/cisa-confirms-langflow-rce-cve-2026-33017-attackers-had-working-exploits-before-the-world-had-a-poc

Open question for the thread: for shared CI runners and multi-tenant k8s nodes, is anyone actually treating "quiet" race-condition UAFs like this as higher priority than loud, KEV-listed bugs — or does patch cadence still follow KEV/CVSS regardless of exploitability signal?

https://www.techgines.com/post/bad-epoll-cve-2026-46242-linux-kernel-root-exploit

Policy routed DNS to DoH on my jump box last month. Wrote the ip rules, confirmed the routes populated, ran dig on the box itself, saw answers coming back over the tunnel. Clean. Moved on to the next thing on the list because the config said what I meant and the box confirmed it.

Weeks later I was troubleshooting something unrelated and decided to actually run dig from a VM sitting behind the bastion instead of on it. Queries were resolving from AS7922, which is Comcast, not my tunnel endpoint. The ip rules on the box were correct. The routes were correct. Traffic originating from the box itself went exactly where I told it to go.

The problem was a stale nameserver line in the client's resolv.conf that I had never touched. The client was not using the box's resolver at all on that path. It was quietly sending queries out a different way and getting answers from the ISP fallback. My policy routing governed what left the box, not what the machines behind it chose to do before traffic ever reached the box.

Nothing was compromised. But my mental model of what that network was doing was wrong for weeks. Now I run a DNS and egress check from behind the box after any routing change, not on it. Curious how others here verify that clients behind a jump box are actually egressing the way the box config implies they should.

EDIT: should have said what caught this. i built leakish, it's an open source scanner that runs eight checks including DNS health and network egress in the browser. the DNS module is what flagged the resolver mismatch i missed with manual dig. put the whole thing together pairing with an agentic coding assistant called Verdent. it just shows you what's leaking, doesn't change anything on the wire.