CVE-2026-24858: A Stark Reminder to Always Test for Cross-Tenant Privilege Escalation

In the world of penetration testing and security assessments, clients often insist that their tenants or environments are fully isolated. "There is no shared architecture," they frequently say. "Our tenants run independently with zero cross-tenant access." This assumption can lead to narrowed scopes or overlooked test paths. However, the recently disclosed CVE-2026-24858 in Fortinet products demonstrates how even apparently isolated systems can contain critical shared dependencies. All it takes is one flawed trust model in a shared cloud service to enable widespread compromise.

The Vulnerability: Cross-Tenant Authentication Bypass via FortiCloud SSO

CVE-2026-24858 is a critical authentication bypass vulnerability (CVSS 9.4, classified under CWE-288: Authentication Bypass Using an Alternate Path or Channel). It affects multiple Fortinet products, including FortiOS (FortiGate firewalls), FortiManager, FortiAnalyzer, FortiProxy, and FortiWeb.

The flaw exists in the FortiCloud Single Sign-On (SSO) feature. When enabled on a device, an attacker with their own valid FortiCloud account and at least one registered device could authenticate to and gain administrative access on devices registered under entirely different customer accounts. This created a true cross-tenant privilege escalation path, allowing unauthorized logins across customer boundaries.

Fortinet observed active exploitation in the wild, including attackers creating local admin accounts for persistence, modifying firewall and VPN configurations, and exfiltrating sensitive data. To halt the attacks, Fortinet temporarily disabled FortiCloud SSO globally on January 26, 2026, before issuing patches and reinstating the service with fixes on January 27, 2026. The U.S. CISA added it to the Known Exploited Vulnerabilities catalog, requiring federal agencies to remediate by January 30, 2026.

This case highlights how a centralized identity and SSO service like FortiCloud can undermine tenant isolation if token validation or account scoping fails.

Why This Matters for Pentesting: Trust But Verify

Clients often push back on cross-tenant testing with claims of complete separation. Real-world incidents like this prove otherwise. Shared components, such as cloud identity providers, API gateways, or reused validation logic, frequently introduce hidden risks.

CVE-2026-24858 serves as a perfect example of why cross-tenant privilege escalation testing must remain standard practice, regardless of architectural assurances:

• Shared services are ubiquitous. Platforms like FortiCloud, Azure AD, or Okta centralize identity across customers, and a single flaw can enable broad access.
• Attackers exploit the weakest link. A valid account on the shared service becomes a skeleton key if scoping is inadequate.
• One misconfiguration or bug suffices. Here, the FortiCloud SSO mechanism trusted registrations without proper tenant isolation checks.

In pentests, we routinely probe these boundaries: enumerate shared endpoints, test token manipulation, check for Insecure Direct Object References (IDOR) across tenants, and validate isolation claims through evidence rather than documentation.

Lessons Learned and Recommendations

1. Always test cross-tenant paths. Include them in scope, even if clients resist. Use tools like Burp Suite for token analysis or custom scripts to probe shared services.
2. Verify isolation claims rigorously. Request diagrams, but confirm through testing rather than acceptance.
3. Minimize shared feature exposure. For Fortinet environments, disable FortiCloud SSO unless essential, apply patches urgently, and audit recent logins/config changes.
4. Embrace zero-trust design. Assume shared layers could fail and layer defenses accordingly.

CVE-2026-24858 is more than a Fortinet-specific issue. It is a clear warning: in security, the assumption that "it can't happen here" is often the most dangerous. Trust but verify. When pentesting, never accept "no shared architecture" at face value. Prove it through thorough, boundary-pushing testing.