A single Tuesday brought critical patches from three major enterprise vendors, including a maximum-severity command injection bug in Ivanti Sentry that hands attackers root access without authentication. Here's what each flaw does and which versions you need to be on.
Three of the biggest names in enterprise software, Fortinet, Ivanti, and SAP, pushed out fixes on the same day for a batch of vulnerabilities that range from serious to about as bad as a CVSS score can get. Several allow unauthenticated remote code execution, which is the category that turns an internet-facing appliance into an open door. None of the flaws have been seen exploited in the wild yet, but with public technical write-ups already circulating for at least one of them, the window between disclosure and weaponization tends to close fast.

Ivanti Sentry: the perfect 10 you don't want
The headline item is Ivanti Sentry, the product formerly known as MobileIron Sentry, which gatekeeps mobile device traffic into corporate systems. Ivanti patched two critical flaws here, and both are the kind that security teams drop everything for.
CVE-2026-10520 carries a CVSS score of 10.0, the maximum. It's an OS command injection bug that lets a remote, unauthenticated attacker reach root-level code execution. CVE-2026-10523, scored 9.9, is an authentication bypass that lets an attacker create arbitrary administrative accounts and walk away with full admin control. Either one is enough to fully compromise the appliance. Both are fixed in versions R10.5.2, R10.6.2, and R10.7.1.
watchTowr Labs published the technical details on the command injection issue, and the mechanics are worth understanding because they illustrate a common pattern in appliance security. An attacker sends a specially crafted HTTP request to the /mics/api/v2/sentry/mics-config/handleMessage endpoint. That request gets interpreted as a MICS configuration command and handed off to a backend function named handleExecute(), which runs it. No credentials required.
What's interesting is how Ivanti chose to fix it. According to security researcher Sonny Macdonald, the patch does two things at once. "Ivanti did not just remove attacker control over the vulnerable execution path," Macdonald said. "They also added a layer of protection in front of it to make reaching the endpoint significantly more difficult. In other words: they added authentication." Unauthenticated requests to the vulnerable endpoint now get redirected to the login page. That defense-in-depth approach, fixing the root cause and gating access to the code path, is the kind of thing defenders should look for when evaluating whether a vendor patch is solid or just papering over the symptom.
Fortinet: command injection in FortiSandbox
Fortinet's patch addresses CVE-2026-25089, a command injection flaw scoring 9.1 that affects the FortiSandbox web UI across its on-premises, Cloud, and PaaS variants. In Fortinet's own words, "an improper neutralization of special elements used in an OS command vulnerability [CWE-78] in FortiSandbox, FortiSandbox Cloud and FortiSandbox PaaS WEB UI may allow an unauthenticated attacker to execute unauthorized commands via specifically crafted HTTP requests."
CWE-78 is the same underlying weakness class as the Ivanti bug: untrusted input flowing into a system command without proper sanitization. FortiSandbox is a malware analysis platform, which makes it an especially attractive target, since compromising the thing that inspects suspicious files gives an attacker a useful blind spot.
The affected versions and their fixes:
- FortiSandbox 5.0.0 through 5.0.5: upgrade to 5.0.6 or above
- FortiSandbox 4.4.0 through 4.4.8: upgrade to 4.4.9 or above
- FortiSandbox Cloud 5.0.4 through 5.0.5: upgrade to 5.0.6 or above
- FortiSandbox PaaS 5.0.4 through 5.0.5: upgrade to 5.0.6 or above
Fortinet's advisories are published through its PSIRT page, which is the authoritative source for affected builds and remediation steps.
SAP: four critical bugs across NetWeaver, Commerce Cloud, and Data Hub
SAP's monthly patch batch included four critical fixes spanning NetWeaver AS ABAP, the ABAP Platform, SAP Commerce Cloud, and SAP Data Hub. These systems sit at the financial and operational core of a huge number of large enterprises, so SAP flaws tend to carry outsized business risk even when the CVSS numbers look comparable to other vendors.
The four issues:
- CVE-2026-44748 (CVSS 9.9): An XML signature wrapping vulnerability in SAML authentication in NetWeaver AS ABAP and ABAP Platform.
- CVE-2026-27671 (CVSS 9.8): A memory corruption vulnerability in Application Server ABAP.
- CVE-2026-22732 (CVSS 9.1): A Spring security vulnerability in SAP Commerce Cloud and SAP Data Hub.
- CVE-2026-40128 (CVSS 9.0): A directory traversal vulnerability in NetWeaver Application Server Java.
SAP security firm Onapsis explained the SAML flaw in concrete terms. "The application allows an authenticated attacker with normal privileges to obtain a valid signed message and send modified signed XML documents with tampered identity information to the verifier," the company said. "Due to an improper XML signature verification, the manipulated identity information is accepted, leading to unauthorized access to sensitive user data and potential disruption of normal system usage." XML signature wrapping is a long-standing class of attack against SAML, where the structure of a signed XML document is rearranged so that the signature validates against one element while the application reads identity claims from a different, attacker-controlled one. It's a reminder that signature verification and the parsing logic that consumes the data have to agree on exactly what was signed.
The memory corruption bug, CVE-2026-27671, is the one that worries low-level defenders. It lets an unauthenticated attacker send a crafted RFC request that abuses how the SAP kernel validates the RFC protocol, corrupting memory in the process. RFC is SAP's remote function call mechanism, often reachable inside corporate networks even when systems aren't directly internet-facing, so flat network architectures make this kind of bug more dangerous than its scope might suggest. SAP's fixes are distributed through the SAP Support Portal security notes.
What to actually do about it
The practical takeaways here are not complicated, but they're the difference between patched and breached.
Prioritize by exposure, not just by score. An internet-facing Ivanti Sentry or FortiSandbox appliance with an unauthenticated RCE path should be at the top of the list ahead of an internal SAP system that requires authentication, even when the SAP CVSS number is similar. Map which of these products you run, confirm the running versions, and check whether they're reachable from outside your network.
For the appliance bugs, segmentation buys time but isn't a fix. If you can't patch FortiSandbox or Ivanti Sentry immediately, restrict access to the management interfaces to known administrative networks. That said, patch as soon as you can, because public exploit details for the Ivanti flaw mean proof-of-concept code is likely to follow.
For SAP, don't treat RFC-reachable systems as safe just because they aren't on the public internet. Lateral movement is the whole point of most intrusions, and an unauthenticated memory corruption bug reachable over an internal protocol is a gift to an attacker who already has a foothold.
There's no evidence any of these flaws are being exploited right now, which is the good news. The honest read is that this is a maintenance-window opportunity rather than a fire drill, but it's a maintenance window you want to use before that status changes. Pull the affected versions from each vendor's advisory, confirm your inventory against them, and schedule the upgrades while the pressure is still low.

Comments
Please log in or register to join the discussion