Infosec News

[cyclone]

NOCIX Datacenter Outage

NOCIX is currently experiencing an ongoing service-impacting outage that started overnight. The outage appears to be affecting customer-hosted servers, and some customers are also reporting issues accessing the NOCIX customer portal. At this time, I have not found an official NOCIX incident report or public postmortem confirming the root cause, so the cause should be treated as unconfirmed.

NOCIX is a budget hosting provider based in Kansas City / North Kansas City, Missouri. The company was formerly known as DataShack and offers low-cost VPS hosting, dedicated servers, custom dedicated servers, gaming servers, and colocation-style services. NOCIX states that its dedicated servers are hosted in its Kansas City, Missouri data center, and that it operates from its own private data center in North Kansas City.

The immediate customer impact is loss of availability. Dedicated servers may be unreachable, hosted websites and services may be offline, and customers may be unable to access provider-side management through the portal. If the portal is unavailable, customers may also have limited ability to open tickets, request reboots, view billing, or use remote management features.

There are also active Reddit discussions from NOCIX customers reporting outages and sharing replies they say they have received from NOCIX support. These posts are useful for tracking customer impact and provider communication, but they should not be treated as confirmed root-cause information. Until NOCIX publishes an official incident notice, the safest technical summary is that a provider-side outage is affecting some NOCIX-hosted customer services and management access.

After services recover, customers should verify system health, review logs, check for unclean shutdowns or storage errors, confirm backups, and contact NOCIX support if servers remain offline. NOCIX’s Terms of Service mention prorated account credits for unplanned service disruptions, but customers must request credit through support.

---

Sources:

• NOCIX Contact: https://www.nocix.net/contact-us/
• Misaka Status (Uses Nocix hosting): https://misaka.fail/
• Reddit customer reports: https://www.reddit.com/search/?q=NOCIX outage

[cyclone]

Actively Exploited Chrome Zero-Day, CVE-2026-11645

Google has pushed an emergency Chrome desktop update for CVE-2026-11645, a high-severity zero-day in the V8 JavaScript engine that is already being exploited in the wild. The patched Stable channel versions are 149.0.7827.102 for Windows and Linux, and 149.0.7827.103 for macOS.

The bug is described as an out-of-bounds read/write issue in V8, Chrome’s JavaScript and WebAssembly engine. In practical terms, this is the type of browser memory corruption flaw that can be triggered through attacker-controlled web content, such as a crafted HTML page. Successful exploitation may allow arbitrary code execution inside Chrome’s browser sandbox, and memory corruption bugs like this can sometimes be chained with a second flaw to escape the sandbox or bypass mitigations such as ASLR.

Google has not released full technical details yet, which is normal for actively exploited Chrome bugs. Access to bug details is usually restricted until most users have received the fix, reducing the chance of rapid public weaponization. The advisory confirms that an exploit exists in the wild, but does not currently identify the threat actor, target set, exploit chain, or whether the activity is tied to spyware, cybercrime, or targeted intrusion operations.

This update is also notable because CVE-2026-11645 is reportedly the fifth Chrome zero-day patched so far in 2026. That continues the pattern of modern browser engines being high-value targets. Chrome, Chromium-based browsers, and embedded browser runtimes are frequently exposed to untrusted content, making V8 bugs especially attractive for initial access, credential/session theft, and targeted drive-by exploitation.

Admins should verify Chrome version compliance rather than assuming auto-update has completed. Chrome’s update mechanism usually handles this automatically, but browser restarts are still required. Enterprise fleets should confirm patched versions across Windows, macOS, and Linux endpoints, and should also check Chromium-based browser variants as vendor patches become available.

Recommended actions:

• Update Chrome desktop to 149.0.7827.102 or later on Windows/Linux, or 149.0.7827.103 or later on macOS.
• Force browser restarts where updates are pending.
• Review EDR/browser telemetry for unusual Chrome crashes, suspicious renderer behavior, and unexpected child process activity.
• Treat recent exposure to suspicious or compromised websites as higher risk until endpoints are confirmed patched.
• Watch for follow-up advisories as Google releases more technical detail after broad patch adoption.

---

Sources:

• Bleeping Computer: https://www.bleepingcomputer.com/news/security/google-patches-fifth-chrome-zero-day-bug-exploited-in-attacks-this-year/
• The Hacker News: https://thehackernews.com/2026/06/chrome-v8-zero-day-cve-2026-11645.html
• SOC Prime Team: https://socprime.com/blog/cve-2026-11645-chrome-zero-day-vulnerability-exploited-in-the-wild/

[cyclone]

FortiBleed: The ongoing Fortinet Compromise Campaign

Fortinet devices are once again in the spotlight, this time due to an ongoing large-scale compromise campaign being tracked as FortiBleed. This appears to be less of a single clean “one CVE explains everything” situation and more of a broader Fortinet edge-device compromise wave involving exposed management surfaces, credential theft, weak or reused passwords, and recently patched Fortinet issues.

The most relevant confirmed vulnerability tied to the current Fortinet activity is CVE-2026-24858, an authentication bypass issue involving FortiCloud SSO. Fortinet says the flaw could allow an attacker with a FortiCloud account and registered device to authenticate into devices registered to other accounts when FortiCloud SSO was enabled. Fortinet also stated that the issue was exploited in the wild and that server-side mitigations were applied in late January before fixed software versions were released.

For FortiGate/FortiOS, affected versions include:

• FortiOS 7.6.0 through 7.6.5
• FortiOS 7.4.0 through 7.4.10
• FortiOS 7.2.0 through 7.2.12
• FortiOS 7.0.0 through 7.0.18

Fixed versions are:

• FortiOS 7.6.6 or later
• FortiOS 7.4.11 or later
• FortiOS 7.2.13 or later
• FortiOS 7.0.19 or later

The broader FortiBleed campaign is being reported as active and large-scale, with researchers observing mass targeting of internet-facing Fortinet FortiGate devices across many countries. The activity reportedly includes extraction of FortiGate configuration files, credential reuse, brute forcing, and cracking of stored credential hashes from older or upgraded FortiOS deployments.

One important detail is that this campaign may not be driven by CVE-2026-24858 alone. Some reports suggest attackers are abusing a mix of stolen credentials, exposed admin portals, weak authentication practices, and possibly recently patched Fortinet vulnerabilities. Fortinet’s own analysis also points heavily toward post-auth activity, account creation, configuration theft, and abuse of valid or compromised credentials.

Observed post-compromise behavior includes:

• Successful FortiCloud SSO administrative logins
• Creation of local admin accounts such as audit, backup, itadmin, secadmin, or support
• Export or theft of FortiGate configuration files
• Reuse of credentials recovered from configs
• Brute-force attempts against exposed services
• Continued targeting of SSL VPN and management interfaces

The config theft angle is especially important. FortiGate configs can contain sensitive operational data, VPN details, user/account references, LDAP/RADIUS settings, local users, firewall objects, and other information useful for follow-on compromise. Even if passwords are hashed, older FortiOS deployments or upgraded systems may still contain weaker stored password hashes unless admins have logged in again or passwords have been rotated.

Admins should treat this as a compromise-assessment event, not just a normal patch cycle.

---

Sources:

• Fortinet PSIRT - CVE-2026-24858: https://fortiguard.fortinet.com/psirt/FG-IR-26-060
• Fortinet analysis of SSO abuse on FortiOS: https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios
• Arctic Wolf FortiBleed campaign writeup: https://arcticwolf.com/resources/blog/active-fortibleed-campaign-impacting-fortinet-devices-across-194-countries/
• Kudelski Security FortiBleed research: https://kudelskisecurity.com/research/fortinet-fortibleed-global-compromise-active-exploitation-of-fortinet-vulnerabilities

[cyclone]

Januscape: Linux KVM Guest-to-Host Vulnerability in x86 Shadow MMU

Januscape is a newly disclosed Linux KVM vulnerability affecting x86 virtualization hosts. Tracked as CVE-2026-53359, the issue is a use-after-free bug in the KVM/x86 shadow MMU code path. The bug is especially relevant for KVM environments that expose nested virtualization to untrusted guest VMs.

At a high level, this is a guest-to-host isolation issue. A malicious guest with kernel-level privileges inside the VM can trigger corruption in the host kernel’s KVM shadow page state. The public proof-of-concept is a host panic/DoS, but the researcher says the same bug has also been turned into a full guest-to-host escape in a controlled environment. That full exploit has not been publicly released.

The vulnerability was discovered and reported by Hyunwoo Kim, also known as @v4bel, and was reportedly used as a zero-day submission in Google’s kvmCTF program.

The root cause is in how KVM reuses shadow MMU pages. KVM keeps shadow page tables that mirror guest-controlled paging structures in certain modes. When nested virtualization is enabled, KVM may need to shadow the nested EPT/NPT structures built by the guest hypervisor. This forces execution through the legacy shadow MMU path, even on modern systems that normally use hardware-assisted two-stage paging such as Intel EPT or AMD NPT.

The vulnerable function, kvm_mmu_get_child_sp(), reused an existing child shadow page based on a matching guest frame number, but did not also verify that the shadow page role matched. In practice, two shadow pages can refer to the same GFN while serving different purposes. One may be a direct split page derived from a large mapping, while another may be an indirect shadow page for a guest page table. Reusing the wrong one breaks KVM’s internal reverse-map accounting.

Once that accounting is wrong, KVM may fail to remove the correct reverse-map entry when tearing down shadow pages. Later, when the relevant memslot or shadow page is freed, stale pointers can remain. When KVM later walks or cleans up those structures, it can dereference or write through memory that has already been freed. The public PoC drives this into a host kernel panic through KVM’s own corruption detection path.

This is not a QEMU bug. The vulnerable logic is in the in-kernel KVM implementation. That distinction matters because mitigations focused only on QEMU device emulation do not address this issue.

The practical risk depends heavily on the environment. The most concerning targets are:

• x86 KVM hosts
• Multi-tenant virtualization platforms
• Cloud, hosting, CI, lab, or VPS environments
• Systems where guests are untrusted
• Hosts exposing nested virtualization to guests

The attack requires root or equivalent kernel-level control inside the guest VM, because the published trigger is implemented as a guest kernel module. In many cloud or VPS scenarios, that is not a strong limitation, since customers commonly have root inside their own guest. The more important exposure condition is whether nested virtualization is available to the guest.

The issue affects both Intel and AMD x86 systems because the vulnerable shadow MMU logic is shared across the KVM/x86 implementation. ARM64 KVM hosts are not affected by Januscape, although they have had separate KVM escape-class issues such as ITScape.

The vulnerable code dates back to commit 2032a93d66fa from the Linux 2.6.36 era, around 2010. The mainline fix is commit 81ccda30b4e8, which updates the reuse check so KVM compares the shadow page role along with the GFN. In simple terms, KVM now only reuses a shadow page when both the frame number and the role match.

Fixed stable kernel versions reported include:

• 7.1.3
• 6.18.38
• 6.12.95
• 6.6.144
• 6.1.177
• 5.15.211
• 5.10.260

Distribution backports may not line up cleanly with upstream version numbers, so admins should check vendor advisories and package changelogs rather than relying only on uname -r.

For operators, this should be treated as a high-priority patching issue if nested virtualization is exposed to untrusted guests. The safest remediation is to update the host kernel to a vendor-patched build and reboot into the fixed kernel.

If patching cannot be done immediately, disabling nested virtualization is the main mitigation for the guest-to-host path:

• kvm_intel.nested=0
• kvm_amd.nested=0

After applying that mitigation, reboot the host or reload the KVM modules only if no guests are running. On production systems, rebooting into a known-good configuration is usually the cleaner approach.

Useful checks on a KVM host include:

uname -r
lsmod | grep '^kvm'
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null

Inside a guest, nested virtualization exposure commonly shows up as vmx or svm CPU flags:

grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u

For Proxmox, OpenStack, VPS, and general KVM operators, the key question is not simply “am I running KVM?” The better question is: “Can an untrusted guest reach nested virtualization on an unpatched x86 KVM host?”

If yes, this deserves immediate attention.

The public PoC is intended to demonstrate a host panic and should not be run on production infrastructure. A successful crash can take down all VMs sharing the same physical host. A failed crash also does not prove that the host is safe.

This is one of those bugs where the operational risk is narrower than a generic remote kernel RCE, but severe in the right environment. For single-user local KVM labs, the impact may be limited. For multi-tenant x86 KVM infrastructure with nested virtualization enabled, it is a serious guest isolation failure.

---

Sources:

• Januscape researcher repository: https://github.com/V4bel/Januscape
• Openwall oss-security disclosure: https://www.openwall.com/lists/oss-security/2026/07/06/7
• NVD - CVE-2026-53359: https://nvd.nist.gov/vuln/detail/CVE-2026-53359
• The Hacker News: https://thehackernews.com/2026/07/16-year-old-linux-kvm-flaw-lets-guest.html