{
"title": "CISA’s Emergency Alert: Actively Exploited SharePoint and FortiSandbox Bugs Require Immediate Remediation",
"content": "On July 16, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added three vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, confirming that threat actors are actively exploiting them in the wild. The additions include two command-injection bugs in Fortinet FortiSandbox (CVE-2026-25089 and CVE-2026-39808) and a deserialization flaw in Microsoft SharePoint (CVE-2026-58644). For any organization using these products, the KEV listing transforms the patch-management timeline from a monthly cycle into an incident-response deadline.

Three Actively Exploited Bugs Hit CISA's Radar

CISA’s July 16 alert is short on technical details—it doesn’t specify affected versions, attack vectors, or indicators of compromise. But the agency’s decision to list these CVEs on the KEV catalog carries a specific meaning: CISA has evidence that attackers are already using these flaws to break into networks. This is not a theoretical risk. The KEV catalog was created under Binding Operational Directive 22-01 to flag vulnerabilities that have crossed from “potential threat” to “observed reality,” and the latest additions are a clear warning.

The two FortiSandbox flaws (CVE-2026-25089 and CVE-2026-39808) are OS command injection vulnerabilities. In these attacks, an adversary crafts input—often through a web interface or API—that the application passes directly to the operating system shell, allowing arbitrary command execution. Because FortiSandbox is a security appliance designed to detonate and analyze potential malware, compromising it could give attackers a front-row seat to threat intelligence, network credentials, and integration pathways into other security tools.

The SharePoint vulnerability (CVE-2026-58644) is a deserialization of untrusted data flaw. In deserialization attacks, an application rebuilds objects from data supplied by a user or remote system without adequate validation. A malicious payload can manipulate the object structure to trigger code execution, file creation, or even full server takeover. SharePoint servers, which often act as central collaboration platforms for documents, workflows, and custom applications, become high-value targets if exposed.

SharePoint: A Deserialization Flaw with Enterprise-Wide Consequences

For Windows administrators, CVE-2026-58644 demands immediate attention—and a broader scope than a routine patch. SharePoint farms typically run under highly privileged service accounts and maintain trust relationships with Active Directory, SQL Server, Exchange, and even Microsoft 365. An attacker who successfully exploits this deserialization bug could gain access to sensitive files, extract credentials, or pivot laterally into more critical infrastructure.

Compounding the risk, many organizations underestimate SharePoint’s network exposure. While a central farm might be well-documented, shadow IT or forgotten deployments are common. Development, test, or disaster-recovery SharePoint servers may linger online behind lax firewall rules or be accessible through VPN portals. External collaboration features, such as those that allow partners to upload documents, can create indirect internet exposure. CISA’s KEV designation means you must find every SharePoint instance—not just the one you remember.

Beyond patching, the real scoping task is compromise assessment. Deserialization bugs are notoriously tricky to patch perfectly; incomplete fixes can leave systems vulnerable to variants. That’s why thorough logging review is essential—attackers may have already planted a web shell or created a secondary account before the patch was applied. Review SharePoint ULS logs, IIS logs, and Windows Event Logs for anomalies: new application pools, unexpected scheduled tasks, or suspicious logins. If you detect signs of tampering, assume the server has been breached and trigger your incident response plan. Patching a server that’s already under attacker control won’t stop data exfiltration or lateral movement.

FortiSandbox: When the Security Appliance Becomes the Attack Surface

The FortiSandbox vulnerabilities are equally alarming, not because FortiSandbox is as ubiquitous as SharePoint, but because its role makes a compromise especially dangerous. A sandboxing appliance is placed at a critical juncture in the security stack: it receives potentially malicious files from email gateways, endpoints, and web proxies, and it often has the authority to quarantine or block threats. An attacker who gains control can disable detection, white-list malware, or manipulate threat intelligence feeds.

Administrators should examine not only whether their FortiSandbox appliances are internet-facing, but also whether management interfaces are accessible from internal networks, jump boxes, or automated systems like SIEM and SOAR. Because these devices are considered trusted infrastructure, they often retain broad network permissions. An attacker with command injection on a FortiSandbox could potentially pivot to the rest of the Fortinet Security Fabric, including firewalls and switches. Additionally, review all integrations: if your FortiSandbox submits samples to a central threat intelligence platform, that pipeline could be poisoned. Validate the integrity of any data that has passed through the appliance since potential exploitation began.

Fortinet’s PSIRT team will have details on affected versions and patches, but the KEV addition means you should treat this as an emergency. If you can’t patch immediately, isolate the appliance from the network as much as possible, restrict access to a tightly controlled VLAN, and monitor all outbound traffic.

BOD 26-04: A New Mandate for Risk-Based Patching

The July 16 KEV additions fall under CISA’s Binding Operational Directive 26-04, which reshapes how federal civilian agencies manage vulnerabilities. Instead of chasing every CVE, agencies must prioritize vulnerabilities listed in the KEV catalog, especially those on public-facing assets that could give an attacker total control. The directive also mandates that agencies determine whether a system was compromised before the patch was applied—a shift from check-the-box compliance to active threat hunting.

Although BOD 26-04 applies directly to federal agencies, CISA explicitly encourages private sector organizations to adopt the same risk-based approach. In practice, the KEV catalog should answer the question, “Which of the thousands of new CVEs should I patch first?” by highlighting those with active exploitation. The three latest additions are a perfect case: if you’re running SharePoint or FortiSandbox, these patches jump to the top of your queue, ahead of even other critical-but-unexploited flaws.

Immediate Actions for IT Teams

Whether you answer to a government regulator or a private board of directors, the following steps are non-negotiable in light of CISA’s alert:

  1. Inventory all SharePoint and FortiSandbox deployments. Scan your networks for any instance, including development, staging, QA, and backup servers. Don’t rely on memory or outdated CMDB records—use network scans and configuration management tools.
  2. Identify external exposure. For each identified instance, determine if it’s reachable from the internet, directly or via a proxy, VPN, partner portal, or cloud connector. Internet-facing systems are the highest priority for remediation.
  3. Apply the vendor patches immediately. For CVE-2026-58644, review Microsoft’s Security Response Center for update availability. For the FortiSandbox CVEs, follow Fortinet’s PSIRT advisory. Ensure you have backups and understand any dependencies before patching; schedule downtime if needed.
  4. Conduct a compromise assessment before and after patching. Check for:
- Unusual network connections or outbound traffic. - New or modified local accounts and service credentials. - Unexpected processes, scheduled tasks, or application pools. - Anomalies in security logs, such as failed login spikes, privilege escalation, or unexpected configuration changes. For SharePoint, leverage the Unified Logging Service (ULS) and IIS logs. For FortiSandbox, review management access logs and alerting data.
  1. Preserve forensic evidence. Before making changes, take disk images or memory dumps if feasible, and store logs offline. This helps later if you need to understand the scope of an incident.
  2. Isolate or limit access if patching is delayed. If you absolutely cannot patch immediately, restrict access to the affected systems to a minimal set of IP addresses, enforce multi-factor authentication, and disable unnecessary services