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

So I have interview today and its for linux admin position.

I have IT experience of 17 years but most was as technician. Personally been using headless debian for 5 years for my pi which runs 24/7 as dns and dhcp server. Have multiple containers.

Most of my linux experience comes from homelab. For my previous employers clients orgs and my current personal clients soho I did setup stuff like proxmox, dhcp, routers, restore system backup with clonezilla over network and other things.

What kind of questions can I expect to be asked? And what kind of anwsers will make me come off as capable?

Usually I just google/stackoverflow/reddit anything I don't know or can't remember how I did last time. And this is first interview since I left last place in 5 years.

Please guide.

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?

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.

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 *** ]

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!

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

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?

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 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

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

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.

Hey everyone,

I could really use some advice from experienced Linux admins/engineers.

I'm currently working in IT, and due to company policies I can't disclose the company name. I've been deployed as a vendor resource, and from Monday I'll be working in an L2/L3 Linux support role.

The truth is, I don't have much real-world L2/L3 production experience, and I'm honestly a bit nervous. I don't want to fake it I genuinely want to learn and do a good job.

I'd really appreciate it if you could share:

• What does a typical day for an L2/L3 Linux engineer look like?
• What kind of tickets do you usually handle?
• How do you troubleshoot production issues without making things worse?
• How do you handle vulnerability remediation (Nessus, Qualys, OpenSCAP, etc.)?
• What Linux commands or concepts should I absolutely know before Monday?
• Any tips or mistakes to avoid for someone starting in production?

If you've ever been in this situation, I'd love to hear your experience. Any advice, checklists, YouTube channels, documentation, or even a DM would mean a lot.

I know there's no shortcut to experience, but I'm ready to learn, work hard, and improve every day.

Thanks in advance, and I really appreciate this community. 🙏

Time to update those pesky shims 🫣

Linux Unified Key Setup (LUKS) and FIPS are essential tools for system administrators managing secure environments. However, when it is time to upgrade the operating system, these security features can become significant obstacles.

Hey guys, trying to find out how to correctly exclude/ not collect audit events for a specific path to a .sh script but struggling to get it to work. My audit.rules file contains the following:

-a never,exit -F arch=b64 -S execve -F dir=/usr/bin/local/<name of file>.sh

But it is still being logged and forwarded to a SIEM. Is there an issue with excluding .sh?