- The critical vulnerability CVE-2026-21643 in FortiClientEMS 7.4.4 allows SQL injection and possible remote code execution without authentication.
- The vulnerability is related to the insecure handling of the HTTP Site header in the middleware, exploitable through the public endpoint /api/v1/init_consts.
- The exploitation can result in total compromise of the management database, theft of credentials, and modification of policies distributed to all endpoints.
- Mitigation involves upgrading to FortiClientEMS 7.4.5 or higher, disabling multi-tenant mode if it cannot be patched immediately, and restricting access to the administration console.
The security of endpoint management platforms has become a critical issue for many companies, and the latest clear example is Fortinet and its FortiClient Endpoint Management Server (EMS) solution. In recent months, a critical SQL injection vulnerability has been discovered affecting a very specific version of the product, generating considerable buzz in the cybersecurity community.
In this article, we'll calmly break down what's happening with the critical SQL injection vulnerability in Fortinet , how the CVE-2026-21643 vulnerability works, what real impact it has on organizations, how it's being exploited in practice, and, above all, what urgent and medium-term measures you should implement if you manage infrastructures based on FortiClientEMS or similar products.
Context of the CVE-2026-21643 vulnerability in FortiClientEMS
The vulnerability CVE-2026-21643 has been classified as critical , with a CVSS score ranging from 9.1 to 9.8 according to various sources, placing it practically at the highest severity level. The flaw resides in FortiClient Endpoint Management Server (EMS), the platform that companies use to deploy and manage FortiClient agents on their fleets of user devices.
Specifically, the issue affects FortiClientEMS version 7.4.4 of the 7.4 branch when multi-tenant mode (the "Sites" functionality) is enabled. Versions 8.0 and 7.2, as well as FortiEMS Cloud instances, are not affected by this bug, so Fortinet has focused all mitigation recommendations on environments still using version 7.4.4 on-premises.
This SQL injection occurs due to improper neutralization of special elements in SQL statements , classified under CWE-89. In practice, it allows an unauthenticated remote attacker to send specially crafted HTTP requests and cause the server to execute arbitrary SQL commands, which can result in remote code execution (RCE) with the privileges of the database user.
Fortinet's security advisories indicate that the vulnerability lies in the FortiClientEMS GUI component , specifically the web interface that administrators use to manage and monitor endpoints. This means that any instance with an internet-accessible interface becomes a prime target for attackers.
How critical SQL injection originates in Fortinet
The root of the problem is linked to a major middleware refactoring in FortiClientEMS 7.4.4 . During this code revision, the developers changed how the application handles connections to the PostgreSQL database and tenant routing, inadvertently introducing a bug in the connection file.
In this new logic, the server directly passes the HTTP header Site to a consultation search_path by PostgreSQLThe goal was to select the schema corresponding to each tenant based on this header, but the big problem is that the middleware does not perform proper validation or sanitization of that value.
As a result, an attacker can break the intended string format and slip their own malicious payload into the SQL statement, injecting arbitrary commands that the database will execute with the high privileges that the service user has configured within the Fortinet virtual machine.
The risk is further amplified because this vulnerable middleware executes before any authentication checks . In other words, there's no need to log in or have credentials: simply sending a manipulated HTTPS request with a modified Site header is enough to attempt to exploit the vulnerability.
This pattern perfectly fits a CVSS 3.1 scenario of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H , where the attack arrives via network, has low complexity, does not require prior privileges or user interaction, and completely compromises the confidentiality, integrity, and availability of the affected system.
Attack vector: endpoint /api/v1/init_consts and Site header
Security researchers, such as Bishop Fox's team, have explained that the most practical attack vector is found at the endpoint. publicly accessible /api/v1/init_consts, a FortiClientEMS API route used during interface initialization.
Attackers can first use this endpoint to Check if multi-tenant mode is enabledIf they discover that the Sites functionality is enabled, they proceed to inject SQL payloads through the HTTP header. Site, taking advantage of the fact that the value is passed without cleaning to the sentence search_path.
This endpoint has several design flaws: firstly, it lacks rate limiting mechanisms and specific brute-force defenses; secondly, it directly returns error messages generated by PostgreSQL in the response body. This makes life much easier for an attacker.
By receiving these errors so explicitly, a malicious actor can perform error-based extraction techniques in a single request , without needing to resort to the much slower, time-based injections. This allows for the enumeration of sensitive tables, columns, and data to be extremely fast.
If the exploit is successful, the attacker achieves a scenario of complete compromise of the endpoint management database . Since the database user runs with PostgreSQL superuser privileges, they can not only exfiltrate information but also escalate to remote code execution on the underlying operating system.
Real impact on the organization and managed endpoints
The impact of this vulnerability goes far beyond a simple data leak. The ability to execute arbitrary SQL on the FortiClientEMS database allows attackers to steal administrator passwords, digital certificates, and complete inventories of devices connected to the platform.
With that level of access, a threat actor can modify security policies and distribute malicious configurations to all managed endpoints. This opens the door to complex scenarios in which the organization's own security agents become an attack vector into the internal network.
Furthermore, the compromise of the management database also affects the confidentiality of the stored data (e.g., information about users, equipment, policies and certificates), the integrity (alteration of rules, templates and assignments) and the availability (possible data deletion or sabotage of the administration server).
This threat fits with the increasingly common trend of attacks against edge devices and management systems , highly valued by cybercriminals because they function as information concentrators and control over large volumes of endpoints.
For all the above reasons, Fortinet has classified this vulnerability as critical, and security agencies and firms recommend treating any exposed FortiClientEMS 7.4.4 instance as a maximum risk asset until proven otherwise.
Active exploitation and exposure area
Although some initial reports indicated that no active exploitation had been detected, researchers from the firm Defused confirmed actual attacks taking advantage of CVE-2026-21643 just four days before the vulnerability was made public.
Data collected by organizations like Shadowserver shows that approximately 2.000 FortiClientEMS instances were directly exposed to the internet at the time of monitoring. The United States led the statistics with around 756 vulnerable servers, followed by Europe with over 680. Shodan also detected more than 1.000 publicly accessible FortiClientEMS web interfaces, many likely unpatched.
The official NIST registry entry for CVE-2026-21643 supports this extreme severity, showing an AV:N/AC:L/PR:N/UI:N vector with high impact on C, I, and A. This implies that any FortiClientEMS 7.4.4 server with an open web interface can be completely compromised without the attacker needing credentials or having to convince any user to click anything.
Defused reported these exploits on March 28, also noting that, despite this, the vulnerability was not yet listed in CISA's KEV (Known Exploited Vulnerabilities) catalog or other public lists of actively exploited flaws, something that usually happens in these initial exploitation windows.
On the other hand, Fortinet had already released the corrective patch in February with version 7.4.5, which makes clear the recurring pattern in cybersecurity: there is a significant time gap between the availability of the fix and its actual deployment in production, a period during which attackers take advantage to compromise systems that are still not updated.
Indicators of compromise and signs of attack
For administrators managing FortiClientEMS, it's crucial to understand the clues left by a potential exploitation attempt. Key indicators of compromise (IoCs) include the following:
First, they highlight the unusually long response times, ranging from 5 to over 20 seconds, on the endpoints /api/v1/auth/signin o /api/v1/init_consts, as seen in the access logs of Apache or another web server that is in front.
It is also a warning sign to see Repeated HTTP 500 responses from the same IP address against the endpoint /api/v1/init_constsThis pattern may indicate that an attacker is fine-tuning their SQL injection payloads through trial and error until they find one that works and does not generate errors.
Additionally, it's worth looking in the PostgreSQL error logs. consultations search_path with single quotes, semicolons, or SQL keywords , the SELECT, INSERT o UPDATE outside the expected context. This type of trace usually points directly to an attempt to manipulate the Site header.
As a response measure, any FortiClientEMS 7.4.4 server that has been exposed to the internet without proper updates should be treated as potentially compromised . This involves isolating it from the network, performing a detailed forensic analysis (database, operating system, and logs), and planning a controlled reconstruction of the environment if evidence of intrusion is found.
Immediate mitigation and official solution from Fortinet
The primary mitigation measure is clear: update FortiClientEMS 7.4.4 to version 7.4.5 or higher as soon as possible. Fortinet fixed the vulnerability by replacing string interpolation in the query with proper handling of parameterized identifiers and securely escaping input from the Site header.
Versions 8.0 and 7.2, as well as FortiEMS Cloud, do not require additional action , as they are not affected by this specific vulnerability. Even so, it's still a good idea to review your internet exposure and access configurations, because the attack surface of management consoles should always be minimized.
For teams that, due to operational reasons, cannot apply the patch immediately, some researchers recommend a temporary mitigation: disabling the multi-tenant "Sites" functionality . This action prevents the execution of the vulnerable code path linked to the Site header, significantly reducing the exploitable options.
Similarly, it is essential to restrict web access to the EMS management interface to trusted internal networks only . Ideally, the console should be placed behind a VPN or a zero-trust access mechanism, and never left directly exposed to the internet except in very exceptional and properly secured cases.
Additionally, it is advisable to review and strengthen firewall rules and any WAFs in front of FortiClientEMS , applying filters that block typical SQL injection patterns in HTTP headers, especially in the Site header, and closely monitoring any anomalous API requests.
Good security practices beyond the patch
Beyond simply applying patches and specific mitigations, this incident makes it clear that vulnerability management must be an ongoing process , not just a one-off reaction to a vendor advisory. Organizations that rely on endpoint management platforms and network security solutions should strengthen their strategy on several fronts.
On the one hand, it is essential to have an up-to-date inventory of assets and versions , so that when a critical CVE is published it is possible to identify in minutes which systems are vulnerable and prioritize their update according to the level of exposure and criticality.
On the other hand, it is advisable to opt for periodic penetration tests and architecture reviews that validate not only the robustness of the product itself, but also how it is deployed: network segmentation, separation of management planes, access restrictions, centralized log monitoring and detection of anomalous behavior.
From a development perspective, this case again demonstrates the importance of applying secure development practices and regression testing whenever a deep refactoring of middleware or critical components is performed. Performance or scalability improvements cannot be accompanied by a step backward in such basic mechanisms as input sanitization.
Companies specializing in cybersecurity and secure development offer code auditing, penetration testing, and consulting services specifically designed to detect these vulnerabilities before they reach production. In environments that combine on-premises infrastructure, cloud, and edge devices, relying on external experts often makes all the difference.
Finally, at the governance and business levels, it is very useful to have dashboards and business intelligence that allow visualization of the state of vulnerabilities, the exposure of management interfaces, and the potential impact of a critical failure on the organization's processes. This approach facilitates prioritizing investments and justifying preventive measures that, at first glance, may seem costly, but which save many problems in the medium term.
The combination of a serious design flaw, a large attack surface, and the usual delay in patching makes CVE-2026-21643 a textbook case of why management console security should never be underestimated. Any organization using FortiClientEMS or similar solutions should take this incident as a wake-up call to review its security posture, accelerate its update cycles, and strengthen the defenses around its management platforms before another zero-day vulnerability or SQL injection puts them at a disadvantage again.
