Over the weekend, Fortinet released an emergency security update for a critical FortiClient Enterprise Management Server (EMS) vulnerability (CVSS 9.1), after confirming it is being actively exploited in the wild.
The flaw, CVE-2026-35616, is a pre-authentication access control issue that enables attackers to bypass authentication protections and gain elevated privileges on affected systems to execute code or commands via crafted requests.
The vulnerability impacts FortiClient EMS versions 7.4.5 and 7.4.6, and internet scans have identified more than 2,000 exposed instances that could be targeted. Exploitation activity was first observed on March 31, 2026, prior to public disclosure, giving attackers an early window to compromise vulnerable systems.
Fortinet issued hotfixes on Saturday and urged immediate patching, noting that the flaw has already been leveraged in attacks.
Jacob Warner, Director of IT, Xcape, Inc.:
“A compromised FortiClient EMS allows attackers to push malicious payloads to the entire managed fleet, turning a single exploit into a total enterprise breach. To stop the active exploitation of CVE-2026-35616 and CVE-2026-21643, organizations must immediately apply hotfixes for versions 7.4.5/7.4.6 or upgrade to 7.4.7.
“The most impactful action is removing EMS interfaces from the public Internet by placing them behind a VPN or Zero Trust gateway. Additionally, teams should audit logs for unauthorized API activity and implement strict network segmentation to isolate management traffic. Relying on a cycle of emergency patches for exposed edge tools is a failing strategy; eliminating the external attack surface for management infrastructure is the only way to break the pattern of constant exploitation.
“If your management console is still reachable from the public Internet, you are essentially crowdsourcing your admin privileges.”
Sunil Gottumukkala, CEO, Averlon:
“The running joke in the cybersecurity industry is that the nastiest bugs always show up on Friday evenings or on major holidays, but Fortinet appeared to be doing the right thing here by getting the patch out fast once it confirmed active exploitation. The bigger issue is that attackers keep targeting management infrastructure because it offers high leverage: if you own the control plane, you often own everything behind it. Teams should treat these platforms accordingly, with minimal exposure, emergency patching, continuous monitoring, and clear containment playbooks.”
Lydia Zhang, President & Co-Founder,Ridge Security Technology Inc.:
“Any vulnerability in a network management platform can lead to large-scale impact, as it often has access to many managed devices. This is why attackers frequently target management platforms.
“It is recommended to conduct thorough application security testing, including zero-day scenario testing, before releasing any management platform. During development, engineering efforts are often focused on the firewall itself, while the management platform may receive less attention and, as a result, be less hardened.”
Denis Calderone, CTO, Suzu Labs:
“Fortinet products, EMS specifically, have had some pretty big issues as of late. Admins have just finished patching FortiClient EMS to 7.4.5 to fix last week’s SQL injection and now there is this new zero-day, CVE-2026-35616. This one is a pre-auth API bypass in 7.4.5 and 7.4.6 that was being exploited before Fortinet even knew about it (exploitation started March 31, disclosure was April 4). So that’s now three critical pre-auth vulnerabilities patched in this same product in two years: CVE-2023-48788 patched in March of 2024, CVE-2026-21643 in February, and CVE-2026-35616 this week. At some point, patch and hope you’re done stops looking like a viable strategy.
“So, is Fortinet doing the right thing by pushing an emergency weekend patch? Yes of course, a Saturday hotfix when you confirm zero-day exploitation is the right response, and it’s better than Fortinet’s history of delayed disclosure. But still, you have to worry about the engineering process when you have 2 critical flaws like this in in back-to-back versions of the same product. The threat actors and researchers are finding these problems, and it would be nice to see the manufacturer chipping into that effort.
“Unfortunately, we don’t think this is isolated, and we expect the pace of discovery in products like these to accelerate. Products with deep vulnerability histories are giving researchers and attackers a roadmap, and AI-assisted code analysis has gotten very good at finding the same types of bugs. Fortinet, Ivanti, Citrix, the products with the longest track records in the CISA KEV catalog, are going to keep producing new critical CVEs at an increasing rate. Hopefully we’re wrong here, but that’s the trajectory we’re already seeing.
“Which brings us to the only practical strategy left, which is to stop exposing the management server UIs and APIs to the internet. The EMS admin interface is what’s being targeted here. If it’s reachable, you’re at risk. Restrict access to management networks, put it behind a VPN or conditional access, and monitor for anomalous API activity.
“You’re always going to be patching Fortinet, but you don’t have to make it easy for attackers to reach the thing you’re patching, and even in a good scenario, you will still end up being exposed for days before announcement and patching even happens, which is just way too long nowadays.”
The fact that I keep seeing Fortinet pop up in my inbox is a sign that I may want to reconsider my use of their products. But in the meantime, it’s once again time to patch all the (Fortinet) things.
Hardcoded API keys expose Google Gemini AI via apps with 500M+ installs: CloudSEK
Posted in Commentary with tags CloudSEK on April 7, 2026 by itnerdCloudSEK has published research showing that 22 popular Android applications, collectively installed on more than 500 million devices, contain hardcoded Google API keys that now provide full, unauthorized access to Google’s Gemini artificial intelligence platform.
The report, released today by CloudSEK’s BeVigil security search engine, reveals a structural flaw at the crossroads of decade-old developer practices and Google’s rapidly expanding AI infrastructure. It is available at:
Background: A Decade-Old Assumption, Quietly Broken
For more than a decade, Google told developers that API keys in the AIza… format were safe to embed in public-facing applications. They were treated as public identifiers, not secrets.
That changed with Gemini. When a developer enables the Gemini API on a Google Cloud project, every existing API key on that project silently inherits access to Gemini endpoints, with no warning, no notification, and no opt-in prompt.
Developers who embedded Maps or Firebase keys years ago, following Google’s own documentation, now unknowingly hold live credentials to one of the world’s most powerful AI systems.
BeVigil scanned the top 10,000 Android apps by install count and confirmed 32 such live keys across 22 applications.
The Affected Apps: Household Names, Global Reach
The 22 vulnerable applications span e-commerce, travel, finance, education, news, and productivity. They include:
CONFIRMED DATA EXPOSURE: Using the key found in ELSA Speak’s publicly downloadable app, CloudSEK researchers queried Google’s Gemini Files API and received a live response listing uploaded audio files. The files were likely speech recordings submitted by users for AI-powered pronunciation coaching.
What an Attacker Can Do With a Single Exposed Key
Any person who decompiles a vulnerable app and extracts its hardcoded key can:
Real Losses: Three Cases of Gemini API Key Abuse
The following highlights three publicly reported cases where stolen or exposed Google API keys led to severe financial harm:
Case 1: $15,400 overnight. A solo developer’s startup nearly collapsed after an attacker used his exposed key to flood Gemini with inference requests. The developer revoked the key within 10 minutes of a $40 billing alert. Due to a 30-hour reporting lag in Google Cloud’s billing system, the damage had already reached $15,400 by the time the dashboard updated.
Case 2: $128,000 and a company facing bankruptcy. A Japanese company using the Gemini API for internal tools saw approximately 20.36 million yen (around $128,000) in unauthorized charges accumulate after its key was compromised, even though firewall-level IP restrictions were in place. Google initially denied an adjustment request.
Case 3: $82,314 in 48 hours, a 455-times spike. A three-person development team in Mexico with a typical monthly cloud spend of $180 had their key stolen between February 11 and 12, 2025. Within 48 hours, attackers generated $82,314 in Gemini charges. Google’s representative initially held the company liable under the platform’s Shared Responsibility Model, citing an amount that exceeded the company’s total bank balance.
Full Report: https://www.cloudsek.com/blog/hardcoded-google-api-keys-in-top-android-apps-now-expose-gemini-ai
Leave a comment »