Under Attack Mode (UAM) is available now in WebShield, the Imunify360 layer that filters traffic in front of your web server. It is a switch you throw when one domain comes under an automated flood. The domain, or just the paths you choose, goes behind a lightweight JavaScript challenge. Real browsers solve the challenge in the background and carry on. Bots that cannot run JavaScript never reach the site.

Keyed on the domain, not the IP

Imunify360 already makes most of its traffic decisions automatically. The network firewall blocks known attackers using attack data from more than 65 million protected domains, and WebShield’s GreyList / Anti-bot Challenge, its per-IP reputation check, challenges visitors that look suspicious. Both work one visitor at a time, judged on reputation and behavior, across the whole server.

UAM is a different kind of control. A rule exists because you created it, covers one domain and the paths you set, and applies to every visitor regardless of source address. And that is the point. When a scripted flood hits a site’s checkout from thousands of addresses at once, you would rather gate that whole domain briefly than chase IPs one by one.

Floods, tickets, and churn

The Web Hosting Trends Report 2026, our survey of 446 hosting providers, sizes the problem accurately. Among them, 40% name DDoS as a major security challenge, and 36% point to resource-eating bots. The costs are concrete. Security incidents eat a large portion of support time, and 19% of providers have lost customers over one.

Providers say their customers choose a host mostly on speed, price, and support. A flood degrades two of the three at once. The site slows down, and the ticket queue fills up.

For targeted floods, UAM is the right tool. Today we are shipping that switch: you enable it when needed, and turning it off is just as easy.

What visitors experience

A real visitor sees a brief pause while the browser solves the challenge, not a CAPTCHA. A clearance cookie then keeps them moving for the lifetime you set on the rule.

Every request on the covered paths is challenged, and clients that cannot run JavaScript will not get through. That includes machine clients you want to keep: uptime monitors and payment or webhook callbacks on a covered path are challenged like any other visitor. So scope rules rather than blanketing a domain.

include mode challenges only the paths you list, such as /checkout or /api.

exclude mode challenges everything except what you list, which keeps payment callbacks, health checks, and uptime monitors reachable.

Getting started

UAM ships off by default, and every rule and counter command fails until the service is on, so enabling it comes first. Then add a rule for the domain under pressure and check your work:

imunify360-wsctl uam settings service enable
imunify360-wsctl uam add '{"domain":"shop.example.com","cookie_ttl":"1h","label":"Black Friday","paths":{"mode":"include","matchers":[{"value":"/checkout","condition":"prefix"}]}}'
imunify360-wsctl uam test shop.example.com/checkout

A new rule is live immediately. The required cookie_ttl field sets how long a solved challenge stays valid. The paths block scopes the rule to the checkout paths under pressure. Leave it out and the rule covers the whole domain, including any payment callbacks and webhooks it serves.

uam test tells you whether a URL would be challenged, with the same matching as live traffic, so you can confirm the rule covers what you meant before any flood arrives.

Once traffic flows, imunify360-wsctl uam counters shows which rules are challenging, busiest first.

UAM only sees requests that reach WebShield. Static files your web server delivers directly never get there, so they are never challenged.

And a reassurance for the cautious: UAM fails open. If no active rule matches, or the rules cannot be read, traffic proceeds through the normal WebShield flow. UAM never blocks a request outright. It only inserts a challenge.

Path matchers, rule editing, and counter windows are covered in the Under Attack Mode documentation.

Availability

UAM requires WebShield 1.45.0 or later and root access, and it is managed from the command line today. It is not available on every environment WebShield supports, so check each server:

imunify360-wsctl filters

If uam appears in the list, the server has it. Where it does not, WebShield’s GreyList / Anti-bot Challenge still applies.

What’s next

Next steps include UI controls, starting with cPanel, so managing rules will not require a terminal. After that comes self-service: a server administrator will be able to open UAM to individual hosting accounts, so account owners can put their own domains behind the challenge from the control panel or the WordPress plugin. Later, engagement itself becomes automatic: Imunify360 will detect a flood and throw the switch on its own, with the administrator still in control.

Try the switch before you need it

Enable the service, add a rule for one low-stakes domain, and run uam test against it this week, while nothing is on fire. The day a flood picks a high-value site, you will already know where the switch is.