Two unauthenticated root RCEs hit FatPipe’s end-of-life appliances
FatPipe MPVPN, WARP and IPVPN appliances on the end-of-life 10.1.2r60p100 firmware expose an OS command injection and a stack buffer overflow that both yield an unauthenticated root shell. Move to a supported release and lock down the management interface, which ships disabled by default.
September 17, 2026. Two advisories published in the NVD document an OS command injection and a stack-based buffer overflow in FatPipe MPVPN, WARP and IPVPN appliances running the 10.1.2r60p100 firmware. September 17, 2026. Both flaws, CVE-2026-90822 and CVE-2026-90823, lead to unauthenticated remote code execution as root, each scored CVSS 9.8. September 17, 2026. The affected firmware is end-of-life — no patch is coming, and only an upgrade to a supported release fixes the problem. Why it matters: an end-of-life VPN or SD-WAN appliance sitting at the network edge is already a risk on principle — here it adds two direct paths to root.
Two paths to root in an end-of-life appliance
The first flaw, CVE-2026-90822, is an OS command injection (CWE-78) in the xtremed daemon. An unauthenticated remote attacker who can reach the management interface can submit crafted input to the AuthFormServlet endpoint, causing authentication data to be processed by a shell and allowing arbitrary commands to execute as root.
The second, CVE-2026-90823, is a stack-based buffer overflow (CWE-121) in the /usr/sbin/auth_user_pass binary. A crafted authentication request reaches an unchecked copy into a fixed-size stack buffer, opening the way to arbitrary code execution as root.
The score is identical and unambiguous: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Network reachable, low complexity, no privileges required, no user interaction, high impact on confidentiality, integrity and availability. The only difference between the two is the mechanism — a shell invoked by uncleaned input on one side, a stack overwritten by an unbounded copy on the other — but the outcome is the same: root on the appliance.
The disabled-by-default management interface changes the calculus
The detail that tempers the picture is in the advisory itself. The affected management interface is disabled by default: it must be affirmatively enabled by the customer before the endpoint becomes reachable. A device straight out of the box, in its factory configuration, does not expose these flaws until someone has opened the administration path.
That is a useful nuance, not an excuse. Management consoles on network gear are enabled precisely because someone needs to administer them remotely — and that is where they get forgotten. FatPipe concedes as much in its own guidance: restrict management access to trusted administrative networks and use WAN access control lists to limit authorized sources. When a vendor tells you to close its own interface, the interface was never designed to face the internet.
The real fix no longer exists
The core of the problem is not the severity of the flaws — 9.8 is routine for this class of vector — but the status of the firmware. Version 10.1.2r60p100 is end-of-life, so FatPipe will not ship a patch for it. The only software fix is a migration to a currently supported release, which turns a routine update into a migration project to plan, test and deploy.
This is the worst of both worlds. An end-of-life VPN or SD-WAN appliance concentrates three liabilities: it is no longer patched, it holds an edge function that puts it in the front line, and it is the entry point to the internal network it protects. Every month without a migration adds a layer of risk — not because the appliance gets more vulnerable, but because the gap between its state and the patched state of the world keeps widening.
The FatPipe case is not isolated. VPN and remote-access appliances — SonicWall, Citrix, Fortinet, Ivanti, Pulse Secure — have all seen mass-exploited zero-days in recent years, often precisely because the remote-access console was reachable from the internet. The lesson is structural: an edge appliance’s management interface has no business being exposed, whether the box is still supported or not.
What to do
Remediation breaks down into three actions, in this order.
- 1. Confirm the version. Check the firmware on every MPVPN, WARP and IPVPN appliance. Any box on 10.1.2r60p100 is affected — FatPipe asks customers to contact its support to confirm the version and plan the move to a supported release.
- 2. Lock down the management interface. Until the migration is done, leave the interface disabled if it still is, or restrict it to trusted administrative networks only through WAN ACLs. That is the measure that genuinely shrinks the attack surface in the meantime.
- 3. Schedule the migration. End-of-life firmware makes any workaround temporary. The durable fix is a supported release — to be planned as a migration, not treated as a simple download.
For teams that do not know whether the interface is exposed, the reflex is the same as for any edge appliance: a surface scan of administration ports, a review of the firewall rules that filter them, and monitoring of authentication logs for abnormal attempts. An end-of-life appliance is not discovered at the moment of the incident, but at the moment of the inventory.
Why these appliances drift into end-of-life without anyone noticing
The real question is not technical but organizational. An edge VPN or SD-WAN appliance has every reason to stay in place: it works without visible maintenance, migrating it is disruptive because it touches the link for every branch or remote worker, and no one is explicitly in charge of its lifecycle. The result: the firmware drifts quietly into end-of-life with no alert ever firing — a device that never fails never climbs back up the priority list.
Yet end-of-life firmware is a dated, public fact. FatPipe documents version 10.1.2r60p100 as obsolete, and the NVD indexes the flaws that affect it. The gap between the publication of that information and its adoption across fleets is the real risk — not the flaw itself, but the time during which an exposed box keeps running firmware the vendor will no longer maintain.
This is where a monitoring write-up should turn into a governance action: assign an owner to every edge appliance, record its end-of-support date in the inventory, and make EOL a replacement criterion on par with a hardware failure. An end-of-life appliance is not an aging asset — it is debt compounding over time.
Verdict
If you run FatPipe appliances on the 10.1.2r60p100 firmware, do not treat these two CVEs as a patch to apply — there is none. Your only exit is a migration to a supported release; meanwhile, disable or immediately restrict the management interface to trusted administrative networks, because it is the surface that makes both flaws exploitable. If the appliance is still in service at the network edge, weigh the cost of the migration against the cost of an attacker holding root on your VPN entry point — and plan the end-of-life exit as a project, not a wish.