#privilegeescalation

Read Time:4 Minute, 24 Second

A publicly released proof-of-concept exploit is putting fresh pressure on administrators running virtualized Linux infrastructure to patch a high-severity kernel vulnerability, nicknamed “Vghost” by the researchers who disclosed it, before attackers build their own working version from the technical writeup already circulating.

What’s Actually BrokenThe flaw, tracked as CVE-2026-74580 and rated 8.8 on the CVSS v3.1 scale, lives inside the Linux kernel’s vhost subsystem, the piece of infrastructure that lets virtual machines push network and device traffic through the kernel more efficiently by sharing data structures called virtqueues directly between a guest and the host, rather than routing every packet through a slower emulation layer.

The bug centers on how vhost caches IOTLB mappings, the lookup tables it uses to translate a guest’s view of memory into real addresses it can use to locate those virtqueues. When a virtual ring gets reconfigured, say, its address or size changes, the kernel is supposed to invalidate any cached mapping tied to that ring’s descriptor, available, or used data. Vghost exists because, in certain paths, it doesn’t. A later cache hit can skip the address validation that’s supposed to happen and instead reuse a stale mapping to translate the new, reconfigured address, handing kernel memory-copy routines a pointer that was never actually checked.

Researchers tracing the bug’s history on the oss-security mailing list linked it to two earlier, seemingly unrelated kernel changes: one that introduced the metadata caching mechanism in the first place, and a second that deferred when guest I/O address validation actually occurs. Individually benign, the two changes combined to create the gap now being exploited.

Two Separate Attack PathsThe published proof-of-concept demonstrates two distinct ways to abuse the flaw. The more straightforward path is local privilege escalation: any user with permission to open a vhost device node, such as /dev/vhost-net or /dev/vhost-vsock, can prime the stale cache, reconfigure a ring’s address without triggering invalidation, and then fire the queue to read and write arbitrary kernel memory. From there, the demonstrated exploit chain reads kernel memory to calculate the address-space-randomization offset protecting the kernel, then overwrites the kernel’s modprobe_path setting, a trick that lets an attacker redirect the kernel’s module-loading mechanism to execute an attacker-controlled binary with full root privileges.

The researchers say they successfully reproduced this chain across a notably wide range of mainstream distributions, including Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0, and Oracle Linux 10.2. Exposure varies by default configuration: on the tested Ubuntu system, access to vhost devices was restricted to members of the kvm group, while the other distributions tested left the relevant device nodes open to ordinary, unprivileged users by default, a meaningfully larger attack surface on systems that haven’t customized those permissions.

The second attack path is more specialized but more alarming: a configuration-dependent route to escaping a virtual machine entirely. It requires a vhost device configured with a virtual IOMMU, the iommu_platform flag enabled, and support for the virtio queue-reset feature (VIRTIO_F_RING_RESET). Under those specific conditions, a guest VM can reset and re-enable one of its own virtqueues in a way that causes the host to reconfigure the ring while the stale cached metadata lingers. When the guest subsequently triggers that queue, the resulting stale mapping can cause a used-ring write that lands outside the guest’s allotted memory and into the heap of the QEMU process running on the host, a condition the researchers say can crash QEMU outright or potentially be steered to influence its control flow. The researchers are careful to frame this as a configuration-dependent risk rather than a universal “every VM can escape” claim.

The Fix, and What to Do Until You’ve Applied ItUpstream Linux maintainers have already shipped a fix that clears the vring metadata cache whenever a ring’s address or size changes, forcing any new configuration to pass IOTLB validation again rather than relying on cached data. Fixed versions are available in the stable kernel series at 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, and 7.2, and administrators should install whichever fixed kernel or vendor backport applies to their distribution and reboot into it as soon as practical.

For systems that can’t be patched immediately, the researchers and downstream advisories recommend:

Restricting access to all vhost device nodes, not just /dev/vhost-net, but also /dev/vhost-vsock, /dev/vhost-scsi, and the /dev/vhost-vdpa-* family.

Avoiding passing any of those device nodes through to untrusted or multi-tenant containers.

On virtualization hosts, avoiding exposing vhost devices configured with iommu_platform behind a virtual IOMMU to guests you don’t fully trust.

It’s worth stressing that tightening permissions is a stopgap, not a substitute for patching: revoking group membership or device access doesn’t retroactively close file descriptors a process already has open, and it does nothing at all to address the second, guest-triggered attack path. With a working exploit now public and reproducible across most major enterprise Linux distributions, the realistic window for patching before opportunistic exploitation begins is already narrowing.

Read Time:3 Minute, 25 Second

An intruder using an AI agent breached the Dutch Institute for Vulnerability Disclosure by combining two previously unknown weaknesses in Zammad, the open-source helpdesk platform. The September 21 attack progressed from a stolen web session to remote code execution and then root privileges within seconds, illustrating how automated offensive tooling can compress an intrusion timeline faster than a conventional human response process.

DIVD detected the compromise the following day and cut affected systems off from its data center. By October 1, investigators had confirmed the theft of volunteer email addresses. They were still assessing possible access to contact information, support conversations and sensitive security research. No public attribution has tied the activity to a named operator or established threat group.

Two flaws created a complete takeover pathThe initial vulnerability, CVE-2026-102489, enabled session hijacking followed by code execution as the Zammad service account. Sysdig assigned the flaw a severity score of 8.7 and reported that the attack did not require existing privileges. Because the helpdesk was exposed to the internet, it provided the agent with a direct entry point into DIVD’s environment.

The second issue, CVE-2026-102490, allowed the service account to elevate its privileges locally to root. It received a score of 8.5, while the combined chain was assessed at a critical 9.4. The exploitable chain affects Zammad 6.3.0 through 6.5.4. The first weakness also exists in versions 7.0.0 through 7.1.3, although reported environmental conditions prevent the same exploitation route there. The privilege-escalation issue spans versions 1.5.0 through 7.1.0-alpha.

Automation was fast, adaptive and noisyInvestigators described the agent’s behavior as rapid but disorderly. After obtaining root, it attempted password spraying across accounts as well as an interception technique, yet the two activities interfered with each other. Scripts left behind explanatory comments, including claims that the activity was harmless. Those artifacts and operational mistakes helped responders identify and reconstruct the intrusion.

The mixed performance is important. AI-driven attacks do not need flawless reasoning to be dangerous; they can compensate with speed, persistence and the ability to select follow-up actions from previous results. At the same time, noisy execution can create valuable detection opportunities. In this case, network segmentation limited further movement even after the public-facing server had been completely compromised.

Potential exposure extends beyond email addressesDIVD found compromise indicators in ticketing, project-support and operational systems, though that does not prove every investigated system lost data. The organization believes its archive of security-response tickets was only partially extracted. Such records can contain vulnerability submissions, communications with owners of exposed systems and extracts from credential dumps, even when passwords are masked.

Preliminary findings indicated no known impact to accounting details, bank accounts or the initial intake of security notifications. Nevertheless, stolen volunteer addresses can support convincing impersonation attempts. People who work with DIVD should treat unexpected requests, links and document shares with additional caution while the investigation continues.

Containment must match machine-speed intrusionAdministrators should move to Zammad 7.2.0 or the vendor’s latest safe release and investigate systems rather than treating an upgrade as proof they were never compromised. Vulnerable instances that cannot be updated should be removed from exposure. Application and web logs need to be preserved before rebuilding, and DIVD’s log-checking utility can support triage, although a clean result cannot rule out intrusion.

Watch service accounts for unexpected shells and transitions to root.

Alert on unusual outbound connections and unexpectedly large uploads.

Investigate broad credential-file reads and bursts of failed logins.

Rotate every credential that the helpdesk host could access after confirmed exploitation.

Restrict helpdesk connectivity to internal services and allow outbound traffic only when required.

Once exploitation evidence is present, responders should treat the server as fully controlled by the attacker. The speed of this chain also supports carefully governed automated containment for high-confidence alerts. Waiting for manual escalation may leave an AI agent enough time to complete privilege escalation and data collection before an analyst even opens the case.

Read Time:3 Minute, 25 Second

Red Hat has fixed a serious access-control weakness in Red Hat Satellite that can expose protected host information to a low-privileged user. In affected environments, an account holding only the Viewer role may be able to retrieve sensitive attributes, including root passwords used for managed systems.

The vulnerability is tracked as CVE-2026-96659 and carries a CVSS v3 score of 9.1. Red Hat rates it Important. The issue affects Foreman, the provisioning and lifecycle-management component at the center of Satellite. No victim interaction is required, but an attacker must have network access and a valid low-privileged account.

Satellite commonly manages large fleets of enterprise Linux hosts and holds inventory data, templates, configuration details and provisioning credentials. That concentration of trust means disclosure through a nominally read-only account can have consequences far beyond the management console.

Viewer role crosses an authorization boundaryThe weakness resides in Foreman template-preview endpoints. A user assigned the Viewer role can send crafted requests that cause those endpoints to reveal information intended for more privileged administrators. Red Hat classifies the problem as CWE-267, an access-control weakness involving privileges, identities or restricted functionality.

Host attributes exposed through the vulnerable path may include root passwords. If an attacker obtains a valid credential for a managed machine, they can bypass the intended separation between Satellite roles and host administration. The result could include lateral movement, workload modification, data access or persistent control across parts of the Linux estate.

This is why the account prerequisite should not be mistaken for a minor barrier. Viewer access may be more widely distributed than administrative access, and credentials for low-impact roles can be obtained through phishing, password reuse, leaked tokens or compromised endpoints. A vulnerability that upgrades that foothold into sensitive credential access is a meaningful escalation path.

Unsafe Safemode settings increase the impactInformation disclosure is the primary impact under normal conditions. Red Hat warns, however, that the vulnerability can become more severe when Foreman template Safemode protections are disabled or can be bypassed. In that situation, crafted template activity may lead to arbitrary commands running as the Foreman service account.

Command execution on the Satellite server would put a central management system at risk. Even where the service account is not root, it may have access to application secrets, host records, content-management functions and trusted connections. Attackers could use that position to deepen access or alter provisioning workflows.

The Satellite 6.16 advisory also includes CVE-2026-96658, a separate Foreman Safemode bypass that can lead to remote code execution. Administrators should therefore treat the release as a coordinated Foreman security update and address the listed issues together, rather than patching only the password-disclosure path.

Fixed releasesRed Hat has published corrected packages for Satellite 6.16 on Red Hat Enterprise Linux 8 and 9 under advisory RHSA-2026:74506. Satellite 6.18 on RHEL 9 is covered by RHSA-2026:74504, and Satellite 6.19 on RHEL 9 by RHSA-2026:74503.

For Satellite 6.16, the fix includes Foreman 3.12.0.23-1 in the Satellite 6.16.14 update. The relevant advisories contain additional fixes for Foreman and related components, so teams should follow the product-specific update procedure and confirm that all required packages and services have been refreshed.

Response steps for Satellite administratorsApply the security errata for the installed Satellite release without delay.

Confirm Foreman template Safemode remains enabled and cannot be bypassed.

Review Viewer-role memberships and remove accounts that no longer require access.

Inspect template-preview requests for unusual parameters or access to sensitive attributes.

Rotate exposed root credentials and investigate the affected hosts for unauthorized access.

Teams should also review authentication logs for compromised Viewer accounts and correlate them with host login records. If audit data suggests that sensitive template output was retrieved, containment should extend to the managed systems whose credentials may have appeared. Patching closes the authorization weakness; credential rotation and investigation address the possibility that information was already taken.

Source: Cyber Security News, based on Red Hat’s Satellite security advisories.

Read Time:4 Minute, 0 Second

Debian has published one of its larger security advisories in recent memory, bundling fixes for 1,313 CVE entries into a single Linux kernel update for its current stable release, Trixie. Debian security team member Salvatore Bonaccorso published the advisory, designated DSA-6528-1, on September 29, 2026, covering kernel source package version 6.12.111-1. The scale of the number alone has drawn attention, but understanding what it actually represents matters more than the headline figure.

What a 1,313-CVE Advisory Actually MeansIt’s tempting to read “1,313 flaws” as 1,313 separate holes actively being exploited across the internet, but that’s not what Debian’s advisory says. These are individual CVE identifiers rolled into one consolidated kernel update — not 1,313 distinct Debian packages, and not a confirmed count of real-world attacks. Debian’s own security team evaluates each CVE in the context of how the Debian kernel build actually uses the affected code, and lower-impact entries routinely get bundled in alongside more serious ones within the same advisory. A CVE identifier by itself doesn’t establish that a given system is seriously at risk; it establishes that a flaw exists somewhere in the kernel source tree that Debian decided was worth including in this patch cycle.

That said, the advisory is explicit about the categories of risk involved: privilege escalation, denial of service, and information leaks. Privilege escalation flaws can let an attacker who already has limited access on a system climb to higher permissions — potentially root — once they’re past the initial foothold. Denial-of-service issues threaten uptime and availability rather than confidentiality. Information leak bugs can expose data that was supposed to stay protected, such as kernel memory contents. Crucially, Debian’s advisory doesn’t provide a CVE-by-CVE technical breakdown, a shared root cause across the batch, or an overall severity score for the release as a whole — so any claim that the entire set enables remote takeover would be reading more into the advisory than it actually states.

Among the specific CVE identifiers named in coverage of the advisory are CVE-2024-52560, CVE-2025-21817, CVE-2026-23137, and CVE-2026-100079, spanning disclosures from 2024 through 2026 that had accumulated and were addressed together in this kernel refresh. For context on what a serious kernel privilege escalation bug can look like in isolation, Cyber Security News has previously covered CVE-2023-3390, an integer overflow in Netfilter that could allow writes to kernel memory and potentially grant root access — a useful illustration of the risk category, though that particular CVE is not among the ones addressed in this specific advisory.

Version Tracking Matters More Than the Headline CountFor administrators, the practically useful detail buried in the advisory is the version information: Debian’s security tracker flags Linux kernel version 6.12.107-1 in Trixie as vulnerable, with 6.12.111-1 from the security repository marked as the fixed version. That gives system administrators something concrete to check against their own fleets, rather than relying on a vague sense that “the system has been updated recently.”

How to Apply the Fix CorrectlyBecause this is a kernel update, simply downloading the new package isn’t the end of the process — the fix only takes effect once the system is actually running the patched kernel. The standard update sequence is straightforward:

Refresh package lists with sudo apt-get update, then apply available updates with sudo apt-get upgrade.

Remember that Debian’s advisories name source packages, so administrators need to confirm the relevant installed binary packages built from that source have actually been updated.

Schedule a reboot into the newly patched kernel, since kernel updates don’t take effect for a running system until restart.

After rebooting, verify the active kernel version with uname -r and cross-check it against the fixed version named in the advisory — note that the running kernel’s release string and the source package version use different formats, so a direct string match isn’t always obvious.

Debian’s security documentation also recommends enabling unattended-upgrades for automatic security patching. Automating the download-and-install step reduces how long systems sit exposed, but administrators should still independently confirm that kernel updates have actually taken effect post-reboot rather than assuming automation handled everything end to end. Keeping a record of the installed kernel package version, the time the update was applied, and confirmation of a successful reboot makes it far easier later to distinguish machines that merely downloaded the fix from those genuinely running the corrected kernel — a distinction that matters a great deal if an incident investigation ever needs to rule systems in or out.

For this release, the reference points worth keeping on hand are advisory DSA-6528-1 and the fixed Trixie kernel package version, 6.12.111-1.