Live Linux Security Brief for July 29, 2026: Kernel, Packages, and Service Risk

Live Linux Security Brief for July 29, 2026: Kernel, Packages, and Service Risk

Current Linux security intelligence for kernel updates, distribution notices, exposed services, package risk, and post-patch verification.

Linux exposure snapshot

Linux teams are handling a high disclosure volume, but the operational question remains specific: which running kernels, packages, services, containers, or appliance components are affected and reachable in this environment?

For July 29, 2026, the lead development is CVE-2026-18107: A flaw was found in CRIU's handling of restartable sequences (rseq) during…. The remaining items below add the product-specific context needed to turn the headline into an owned security decision.

Kernel, package, and service updates

CVE-2026-18107: A flaw was found in CRIU's handling of restartable sequences (rseq) during…

NIST National Vulnerability Database | July 29, 2026 | HIGH | CVSS 7.8

A flaw was found in CRIU's handling of restartable sequences (rseq) during checkpoint/restore. A malicious process inside a container can register an rseq critical section that hijacks CRIU's parasite code injection during checkpoint, allowing it to spoof the process credentials saved in the checkpoint image. On restore, the container process gains elevated capabilities and zeroed UIDs/GIDs. The practical…

Why it matters: CVE-2026-18107 may be embedded across servers, containers, appliances, and administration hosts. Package installation alone does not prove that the corrected code is running.

What to verify: Compare distribution package versions, identify the loaded kernel or library, plan required service restarts or reboots, and validate workload health after the change.

Operational focus: Compare the advisory with distribution package versions and the kernel actually loaded after reboot.

Open the original NIST National Vulnerability Database record

CVE-2026-65590: N8n before 2.29.8 and 2.30.x before 2.30.1 does not enforce shell sandbox…

NIST National Vulnerability Database | July 22, 2026 | CRITICAL | CVSS 9.8

n8n before 2.29.8 and 2.30.x before 2.30.1 does not enforce shell sandbox restrictions on Linux and Windows in the @n8n/computer-use package (sandboxing was applied only on macOS). Shell commands executed by the tool run without any filesystem or network restrictions, allowing unrestricted access to the host filesystem and network from within the computer-use agent process. This issue only…

Why it matters: CVE-2026-65590 is likely connected to identity, collaboration, or privileged Windows workloads, where one exposed role can widen impact beyond a single endpoint.

What to verify: Map supported builds and server roles, prioritize public and identity systems, confirm the installed update plus restart state, and review authentication and EDR telemetry for abnormal activity.

Operational focus: Check whether the affected component is exposed through SSH, web, network, container, or management paths.

Open the original NIST National Vulnerability Database record

CVE-2026-50570: Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption

GitHub Advisory Database | July 29, 2026 | HIGH | CVSS 8.5 | GitHub Advisory Database github.com/fission/fission

Fission v1.24.0 added PodSpec safety validation for tenant-facing Environment and Function CRDs (`ValidatePodSpecSafety` / `ValidateContainerSafety` admission webhook + `sanitizeContainerSecurityContext` executor merge layer), but the capability check was implemented as a fixed **denylist of six Linux capabilities** (SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE). The denylist omitted **CAP_SYS_TIME**, among others. As a result, a tenant who could create a Function…

Why it matters: GitHub Advisory Database github.com/fission/fission may be embedded across servers, containers, appliances, and administration hosts. Package installation alone does not prove that the corrected code is running.

What to verify: Compare distribution package versions, identify the loaded kernel or library, plan required service restarts or reboots, and validate workload health after the change.

Continue reading the full briefing.

Corrections and tips

Need to add context to this briefing?

Send corrections, security tips, source updates, or collaboration notes through the contact page so the editorial team can review them properly.

Contact InfoSecNexus