Infosec News

cyclone

Gemini Access to Unintended Public Google Cloud API Keys

Recent research by Truffle Security identified 2,863 publicly exposed Google Cloud API keys that can authenticate to Google Gemini endpoints following API enablement. These keys, commonly embedded in client-side JavaScript for benign services such as maps and analytics, were not originally intended for AI access.

When the Gemini (Generative Language) API is enabled within a Google Cloud project, all existing API keys in that project inherit access by default, including publicly exposed keys. This creates a significant risk of unauthorized data access and quota abuse.

Key Findings

API keys with the prefix AIza were found embedded in public-facing code
Enabling the Gemini API retroactively grants those keys access to AI endpoints
Newly created API keys default to “Unrestricted”, allowing access to all enabled APIs
Attackers can:
- Access /files and /cachedContents endpoints
- Execute Gemini API calls
- Generate excessive LLM usage charges
One reported case alleged $82,314.44 in unauthorized charges within 48 hours

A separate scan by Quokka identified over 35,000 Google API keys embedded across 250,000 Android applications, indicating broader ecosystem exposure.

Risk Impact

This issue transforms what were historically treated as low-risk billing identifiers into high-value AI credentials.

Potential consequences include:

Data exposure via AI-related endpoints
API quota theft and financial loss
Expanded blast radius through AI-integrated cloud services
Elevated abuse potential due to generative AI capabilities

The behavior was initially considered intended functionality. Google has since implemented proactive controls to detect and block leaked API keys attempting Gemini access. No confirmed exploitation campaigns have been publicly reported at this time.

Recommended Actions

Organizations using Google Cloud should:

Audit enabled APIs in all projects
Identify and rotate exposed API keys immediately
Prioritize older keys deployed under previous guidance
Restrict API keys to specific services and referrers
Remove API keys from client-side code where possible
Implement continuous API monitoring and anomaly detection

Sources:

cyclone

Active Exploitation of Cisco Catalyst SD-WAN CVSS 10.0 Zero-Day (CVE-2026-20127)

Overview

Security researchers and government agencies have confirmed active exploitation of a critical vulnerability affecting Cisco Catalyst SD-WAN infrastructure. The vulnerability, tracked as CVE-2026-20127, allows an unauthenticated remote attacker to bypass authentication on affected Cisco Catalyst SD-WAN Controller and Manager systems and gain administrative access.

The flaw carries a CVSS score of 10.0 (critical) and enables attackers to send crafted requests to the SD-WAN controller, resulting in login access as a high-privileged internal account. Once initial access is obtained, the attacker can manipulate SD-WAN network configuration and potentially gain full control of the platform.

Cisco Talos attributes the activity to a sophisticated threat cluster tracked as UAT-8616. Investigation indicates that exploitation activity has likely been occurring since at least 2023, meaning organizations may have been compromised for several years before disclosure.

Exploitation Chain

Observed attacks follow a multi-stage compromise process:

Initial Access
- Exploitation of CVE-2026-20127 allows authentication bypass on Cisco Catalyst SD-WAN controllers.
- Attackers gain administrative access as a privileged non-root user.
Privilege Escalation
- Attackers downgrade the SD-WAN software to reintroduce CVE-2022-20775, a CLI path traversal vulnerability.
- This allows escalation from administrative access to root privileges.
Persistence and Covering Tracks
- After obtaining root access, attackers restore the system to the original software version to conceal the downgrade.
- The actor establishes persistence through:
  - Unauthorized SSH keys
  - Creation and deletion of local user accounts
  - Modification of startup scripts
  - Rogue SD-WAN control connections
- Logs and command histories are frequently cleared or truncated to reduce forensic evidence.

Observed Post-Compromise Activity

Investigations identified several behaviors associated with successful compromise:

Addition of rogue SD-WAN control peers to the network fabric.
Creation of malicious or impersonated local user accounts.
Deployment of unauthorized SSH keys in:
- /home/root/.ssh/authorized_keys
- /home/vmanage-admin/.ssh/authorized_keys
Enabling root SSH login by modifying SSH configuration.
Clearing or truncating logs including:
- syslog
- wtmp
- lastlog
- cli-history
- bash_history
Unexplained software version downgrades followed by re-upgrades.
Unusual control-plane peering events originating from unknown IP addresses.

Threat actors also leveraged NETCONF (port 830) and SSH to move laterally between SD-WAN components within the management plane.

Impact

Cisco Catalyst SD-WAN components operate within the network control plane and manage connectivity between distributed sites and cloud environments. Compromise of these systems can allow attackers to:

Modify routing and network policies
Intercept or redirect traffic
Maintain persistent access to enterprise networks
Use the SD-WAN fabric as a foothold for broader compromise

Organizations operating internet-exposed SD-WAN management interfaces are considered at highest risk.

Government and Industry Response

Multiple government cybersecurity agencies issued joint advisories warning of ongoing exploitation. U.S. federal agencies were directed to immediately inventory and patch affected SD-WAN deployments due to the risk posed to critical infrastructure and government networks.

The vulnerability has been added to the Known Exploited Vulnerabilities (KEV) catalog, requiring rapid remediation within federal environments.

Detection and Threat Hunting Guidance

Defenders are advised to investigate:

Unexpected SD-WAN control-plane peering events
Unknown public IP addresses establishing controller connections
Root logins or SSH key changes on SD-WAN nodes
Missing or abnormally small log files
Evidence of temporary software downgrades followed by re-upgrades

Manual validation of control connection events in SD-WAN logs is considered a critical indicator of potential exploitation.

Mitigation

Recommended defensive actions include:

Immediately applying Cisco patches for affected SD-WAN components.
Reviewing controller logs for unauthorized peering connections.
Restricting access to management interfaces and SD-WAN control ports.
Blocking unnecessary internet exposure of SD-WAN controllers.
Implementing Cisco’s SD-WAN hardening guidance and continuous log monitoring.

Organizations are strongly advised to assume potential compromise if indicators described in the advisories are present.

Sources:

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/