InMotion Rolls Out Monarx ThreatShield Inside the PHP Engine Across Its Fleet

InMotion Hosting said on August 24 that it is deploying Monarx ThreatShield across its server fleet. The announcement gives few details about the scale or the commercial terms of the rollout, but its central technical claim is specific. According to Monarx, the protection does not sit in front of the servers reading traffic: it is built into the PHP engine, and judges a request by what the code does once it is already executing.

Earlier in August, the same company published something considerably more detailed: an account of two customer WordPress sites on its platform being taken over in under half a minute each.

Key facts

• Announced: August 24, 2026, by both companies on the same day.
• What it is: runtime application self-protection that Monarx says is built into the PHP engine, designed to detect and block cross-site scripting, SQL injection, remote code execution, bots and brute force, credential stuffing, and application abuse.
• How far back it goes: InMotion first installed Monarx on shared servers in May 2020, according to the InMotion and Monarx case study. Both 2026 releases date the partnership to 2021.
• The 40% figure: a 39.9% fall in security-related support cases in December 2021 against a January to May 2020 baseline, measured while earlier Monarx products ran on the shared fleet only. It is not a ThreatShield result.
• Not disclosed: the size of the fleet, which service tiers the rollout covers, and whether ThreatShield carries a charge.

Two Sites, Two Hours Apart, About 24 Seconds Each

In a report by Carrie Smaha, last updated on August 5, InMotion detailed two WordPress sites hosted on its platform that were compromised within a two-hour window in July 2026, from unrelated networks. Both were hit inside the first 48 hours after WordPress shipped emergency releases 6.9.5, 7.0.2, and 6.8.6 on July 17 and enabled forced automatic updates. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog four days later.

The three releases are not equivalent. InMotion’s report notes that the SQL injection primitive reaches back to 6.8, while the batch handler confusion that turns it into an unauthenticated, remotely reachable attack arrived only in 6.9. A site on the 6.8 branch carries the injection flaw but cannot be driven to full remote code execution through this path, so 6.8.6 closed the injection issue on that branch rather than the chain known as wp2shell.

On the first site, a batch route request, a new administrator account, a login, a plugin upload and its activation ran start to finish in about 24 seconds. Thirteen seconds later the attacker was executing shell commands as the cPanel account user. The second site followed the same shape in roughly 28 seconds.

One of the two was still running a vulnerable version 28 hours after WordPress enabled forced automatic updates. InMotion found an update management plugin on the account set to block core, plugin and theme updates, which it calls a plausible explanation while noting the logs were not conclusive enough to state it as fact. The site was then reinfected six days after cleanup, through a webshell the first pass had missed.

Neither announcement presents the rollout as a response to those incidents, and we do not claim it was. Neither company has said whether ThreatShield would have blocked the sequence those accounts document, and no test or analysis of the two incidents has been published. What the report does establish is InMotion’s own account of the problem: a compromise completing in 24 seconds is not something a support queue or a nightly scan can get in front of.

Why Inspecting the Request Is Not the Same as Watching the Code Run

A conventional web application firewall examines traffic before the application processes it, working from request content, signatures, rules and whatever other signals it is configured to use. Monarx describes ThreatShield as running inside the runtime instead, where it sees “each request and how it behaves” rather than “just how it looks.” The company says the approach is optimized for Linux PHP environments, and its product page puts the contrast bluntly, promising “context-aware ‘smart’ prevention, unlike traditional ‘dumb’ WAFs.”

Monarx illustrated the limitation with a case we also covered. On August 12 the company published a note on the remote code execution flaw fixed in WordPress 7.0.4, where a user with Author-level access or higher could upload a file named as a PDF or an image that is in fact a PostScript program. Two upload paths skipped WordPress’s content check, ImageMagick inspected the real format, and handed the file to GhostScript, which ran it.

As Monarx put it, this “is not a typical request-based web attack,” because the malicious behavior “can sit inside content that initially looks like a legitimate media upload and only becomes dangerous when the file is processed later.” The note stops short of saying a firewall cannot catch it, calling protection “more difficult for a conventional WAF and heavily dependent on its file inspection capabilities and configuration.” The behavior itself surfaces at execution, which is where ThreatShield claims to operate.

The 40% Came From the Shared Fleet, and From Products That Predate ThreatShield

Both releases repeat a 40% reduction in security-related support cases, attributed to the first year of the partnership. The InMotion and Monarx case study behind that number tells a more precise and, in one respect, more favorable story.

Each stage was measured against a baseline averaged over the five months before rollout:

• May 2020: the Monarx agent and its Protect RASP installed on about 25% of the active shared fleet, reaching most of the rest by early September.
• September 2020 to January 2021: support cases 22.2% below baseline after the initial full install.
• Late January 2021: Monarx switched off on half the servers for an A/B test, re-enabled everywhere in June.
• July to October 2021: 31.2% below baseline with Active Protection fully enabled.
• December 2021: 39.9% below baseline after a new version of the cloud analysis engine.

So the headline figure is the endpoint of a staged rollout across roughly nineteen months, and it measures the products of that period: the agent, Protect RASP and Active Protection. ThreatShield came later, and the current releases present it as a further layer on top.

The detail worth pulling out is the denominator. Monarx ran on the shared fleet only during that study, while support cases from VPS and dedicated customers, who did not have it, were counted in the data. The case study says the reduction for shared customers alone was therefore larger than 40%, “perhaps significantly larger.” That caveat cuts in the vendor’s favor.

InMotion Also Sells Monarx as a Paid Add-On

The add-on is called “Monarx Security.” Its page markets it with a purchase button that requires an account login, alongside links comparing VPS plans and dedicated servers, and lists “Protect RASP PHP Integration” and a “Smart Web Application Firewall” among the features. ThreatShield does not appear in that feature list.

So InMotion appears to have two separate Monarx arrangements: protection the host deploys at infrastructure level, and a purchasable Monarx Security bundle for VPS and dedicated accounts covering malware scanning, removal and Protect RASP. The public pages do not explain how the two feature sets overlap, and neither release says whether the fleet-wide ThreatShield deployment carries a charge or changes what the add-on covers.

Monarx advertises 20 times fewer false positives than “legacy signature-based scanners” and an efficacy rate above 99.99% for automated threat removal, neither with a published method. It also markets SmartWAF, a network and application layer filter labeled “Coming Soon” and not named as part of the InMotion deployment.

Hosting.com Announced a Fleet-Wide Monarx Deployment in January

InMotion is not the first large host to deploy Monarx technology fleet-wide. In January 2026, seven months earlier, Hosting.com announced that it had partnered to deploy Monarx’s AI-first server security across its entire global server fleet. That release describes real-time threat protection built into the platform, and Hosting.com, the new name of A2 Hosting, says it powers more than 3 million websites across more than 40 locations.

Which layer is a separate question. Monarx ships several, from malware detection and removal through Protect RASP and Active Protection to ThreatShield, and the January release names none of them, as is true of the other entries on the vendor’s announcement index: CloudAbove, Big Wet Fish, Libyan Spider, XXL Hosting and Hostinger.

That is the part worth watching, and it is the substance of this announcement. At InMotion, runtime protection at the PHP layer stops being something a customer buys and becomes something the platform has, installed across servers whose owners never make the decision.

InMotion says it serves more than 170,000 customers on hardware and a private network it owns and runs itself, having been independent since 2001. At that scale, one route reaches only the customers who decide to buy, and the other reaches every account on the platform.