Infosec News

cyclone

Update: Details of the Solflare “xpass” Exploit

March 13, 2026

In Feb 2025, I reported an exploit vulnerability in the Solflare Chrome wallet which allowed the wallet vault (solflaredata) to be decrypted without the user's password.

Original post from Feb 2025:
https://forum.hashpwn.net/post/416

Turns out, this was a backdoor, not a bug.

Today, I am releasing the full details of the xpass exploit, aka the "backdoor master key".
https://forum.hashpwn.net/post/11116

cyclone

Storm-1175: Rapid Zero-Day Ransomware Campaign

Recent reporting highlights a fast-moving ransomware operation linked to a Chinese threat group tracked as Storm-1175.

According to Microsoft, the group can move from initial access to data exfiltration and Medusa ransomware deployment in under 24 hours in some cases.

Overview

Storm-1175 is actively exploiting both zero-day and n-day vulnerabilities, often chaining multiple flaws across exposed edge services to gain access. Affected platforms include:

Microsoft Exchange
Ivanti Connect Secure / Policy Secure
JetBrains TeamCity
ConnectWise ScreenConnect
PaperCut
Additional services such as CrushFTP and SmarterMail

More than a dozen vulnerabilities across multiple enterprise products have been observed in active exploitation.

Attribution & Targeting

Microsoft assesses the group as financially motivated, not state-sponsored. Targeted sectors include:

Healthcare
Finance
Education
Professional services

Primary victims are located in the US, UK, and Australia.

Tradecraft

Observed tactics include:

Rapid exploitation of newly disclosed or even pre-disclosure vulnerabilities
Chaining multiple CVEs for initial access
Targeting exposed perimeter services
Disabling endpoint protection before payload execution
Fast data exfiltration prior to encryption

The defining factor is operational speed, significantly reducing defender response time.

Mitigation

Patch internet-facing systems immediately
Reduce exposed attack surface (VPNs, mail, RMM tools)
Enforce MFA on all external access
Monitor lateral movement and privilege escalation
Protect EDR from tampering
Segment networks to limit impact
Track actively exploited vulnerabilities, not just published advisories

Sources

cyclone

MD6 - The Failed SHA-3 Hash You Likely Never Heard Of

While MD6 never made it into NIST as SHA-3 back in 2008, it has resurfaced recently in several hash cracking challenges.

Originally designed by Ronald L. Rivest (RSA) and submitted to the NIST SHA-3 competition, MD6 was eventually withdrawn due to concerns around reduced-round security vs. performance tradeoffs.

After a suggestion from @Vavaldi (HashMob) to add MD6 support to hashgen, I ported MD6 from C to pure Go, optimized the algorithm for better performance and reduced RAM/GC usage in Go, then added support for 5x common MD6 digest sizes to hashgen (128, 224, 256, 384, 512).

The MD6 Go port has a bit-identical hex output to the original C reference implementation, follows the specifications from the docs submitted to NIST, while also closely following Go’s stdlib crypto/sha API for ease of use in your next CTC Go project.

MD6 - Pure Go port
https://github.com/cyclone-github/md6

hashgen v1.3.1 (source code) - w/ MD6 support
https://github.com/cyclone-github/hashgen

Sources:

cyclone

Copy Fail - Root Any Linux Distro

Copy Fail (CVE-2026-31431) is a logic bug in the Linux kernel's authencesn cryptographic template. It lets an unprivileged local user trigger a deterministic, controlled 4-byte write into the page cache of any readable file on the system. A single 732-byte Python script can edit a setuid binary and obtain root on essentially all Linux distributions shipped since 2017.

Container impact is also significant. Since the page cache is shared at the host-kernel level, this is not just a local privilege escalation primitive. In affected environments, it may also become a container escape or Kubernetes node compromise path if the required kernel interfaces are reachable.

Read the full write up from the sources below.

Sources:

cyclone

Global Crypto Scam Crackdown Leads to 276 Arrests

A coordinated international law enforcement operation has led to at least 276 arrests and the shutdown of nine cryptocurrency investment scam centers.

According to the U.S. Department of Justice, the operation involved the FBI, Dubai Police, the Chinese Ministry of Public Security, and other international partners. The scam centers targeted victims in the United States and caused millions of dollars in losses.

The schemes used fake crypto investment platforms and social engineering tactics, including romance-style approaches often associated with pig-butchering scams. Victims were guided into sending funds to fraudulent platforms that appeared legitimate.

Several alleged managers and recruiters now face U.S. federal charges in San Diego, including charges related to wire fraud and money laundering.

Sources:

cyclone

YellowKey: BitLocker Bypass or Backdoor?

ChatGPT Image May 23, 2026, 11_25_25 AM.png

YellowKey is a public BitLocker bypass disclosed by Nightmare-Eclipse. Microsoft is tracking it as CVE-2026-45585. NVD lists it as a Windows security feature bypass with physical attack requirements, low attack complexity, no privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. In plain English: if the attacker has the machine, this can bypass the protection BitLocker users think they have.

From a hacker’s perspective, this is not just a minor recovery bug. This compromises BitLocker-protected drives in the real-world threat model BitLocker is supposed to defend against. The attacker does not need the Windows password. They do not need the BitLocker recovery key. They do not need to crack AES. The PoC abuses Windows Recovery Environment and causes a shell to spawn with access to the protected volume. Once that happens, the disk is effectively decrypted from the attacker’s point of view. The crypto may still be sound, but the platform hands over the unlocked volume.

The suspected attack path involves WinRE and filesystem transaction recovery behavior under System Volume Information\FsTx. Microsoft’s mitigation guidance lines up with this. Public reporting says the mitigation removes autofstx.exe from WinRE’s BootExecute processing and recommends moving affected BitLocker systems away from TPM-only unlock. NVD also records Microsoft’s statement that systems using TPM+PIN are not exploitable by this issue.

The backdoor angle is why this is getting so much attention. Nightmare-Eclipse claims the responsible component exists inside the WinRE image and that a same-named component exists in normal Windows without the dangerous behavior. That does not prove intent. Microsoft calls it a security feature bypass, not a backdoor. But from the offensive security side, this looks bad. A Microsoft-controlled recovery path can expose a BitLocker volume without user authentication. That is exactly the kind of behavior people expect full disk encryption to prevent.

Recommendations are simple: Do not trust TPM-only BitLocker on high-value systems. If you must continue using BitLocker, use TPM+PIN where possible, apply Microsoft’s WinRE mitigation, lock firmware settings, disable external boot, and consider disabling WinRE on hardened machines. Better yet, ditch BitLocker and use VeraCrypt full system encryption if possible.

At the time of this writing, the author’s GitHub appears to have been taken down, along with the original YellowKey exploit repo.

Sources:

Nightmare-Eclipse - YellowKey GitHub (offline)
NIST CVE-2026-45585
Tech Radar
Windows Central

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