DEV Community: MonsterMegs

What Web Hosting Consolidation Means for Site Owners

MonsterMegs — Fri, 11 Sep 2026 20:01:27 +0000

Originally published at https://monstermegs.com/blog/web-hosting-consolidation-2/

Four hundred and fifty jobs disappeared from one of Europe's largest hosting groups five weeks after that same company raised its revenue forecast. That contradiction is the clearest picture yet of what web hosting consolidation looks like in 2026, and it is not the story most people expect. Failing companies are not being swallowed by healthy ones. Profitable companies are deliberately shrinking themselves. On September 10, IONOS announced a strategic transformation program that removes 12 percent of its workforce while leaving its EUR 530 million adjusted EBITDA target for the year completely untouched.

IONOS Cuts 450 Jobs While Holding Its Forecast

IONOS will shrink from roughly 3,800 full time employees to about 3,350, a reduction the company says will run primarily through voluntary redundancy programs designed in partnership with employee representatives. Roughly half the affected roles sit outside Germany, spread across the group's international brands including STRATO, Fasthosts and home.pl. The restructuring carries a one time cost of around EUR 35 million, landing mostly in the fourth quarter of 2026, and is expected to deliver up to EUR 30 million in annual savings beginning in 2027.

The timing is what turns this into a web hosting consolidation story rather than a routine cost cut. Five weeks earlier, IONOS had raised its 2026 revenue growth forecast from roughly 7 percent to roughly 8 percent. First half results showed 280,000 net new customers and 6.9 percent revenue growth, with adjusted EBITDA margin slipping only slightly to 35.0 percent. As DataCenterDynamics reported, parent group United Internet is trimming across multiple subsidiaries at once. This is a business adding customers and cutting headcount in the same quarter.

What IONOS plans to do with the savings matters just as much as the cut itself. The company says the money goes into AI product development, further expansion of its cloud business, and what it describes as consistent use of artificial intelligence in internal workflows alongside platform consolidation. Fewer people, more platforms, software expected to absorb the difference.

Why Web Hosting Consolidation Now Favors the Biggest Deals

The other half of the story landed a day earlier, when fresh valuation data for privately held hosting businesses was published. It explains why web hosting consolidation keeps flowing upward. In the second quarter of 2026, deals below $500,000 traded at 2.0x seller's discretionary earnings, exactly where they have sat since 2023. Deals in the $5 million to $50 million band reached 5.8x adjusted EBITDA, the highest level since the first quarter of 2022. The distance between the smallest and largest hosting businesses is now the widest it has been in four years.

Advisor sentiment tracks those numbers closely. According to the Q2 2026 valuation data, 76 percent of advisors described the $5 million to $50 million segment as a seller's market, compared with only 22 percent for sub $500,000 deals. If you run a small hosting company, buyers are not competing for you. If you run a mid sized one, they are lining up. That single split drives most of the web hosting consolidation activity being announced right now.

The Multiples Are Not Measuring the Same Thing

One caveat gets lost every time these figures circulate. The lower tiers are measured on seller's discretionary earnings, which adds the owner's compensation back into the total. The upper tiers use adjusted EBITDA, which does not. Comparing 2.0x SDE against 5.8x EBITDA overstates the real spread, though not by enough to change the conclusion. Web hosting consolidation still rewards scale, and the size of that reward is growing each quarter.

Platform Consolidation Is Happening Inside Companies Too

Web hosting consolidation is normally reported as one company buying another. The IONOS announcement points at a quieter version happening inside a single group. IONOS runs a portfolio of brands that each carry their own control panels, billing systems, support queues and migration tooling. Collapsing those into shared platforms is where a large share of that EUR 30 million in savings is supposed to come from, and customers of every brand in the portfolio will feel it.

Support is the front line of any web hosting consolidation effort. On the same day the IONOS news broke, group.one published testing results showing its AI assistant, Ask Aida, completed 95 percent of tasks in customer testing, with authentication and abuse cases still requiring a human. That is a genuinely strong number and a revealing one. The remaining 5 percent covers precisely the moments when a site owner is most stressed: locked out of an account, compromised, or accused of abuse by an automated system.

Aruba Applies for 39 TLDs as Scale Cuts the Other Way

Not every large host is answering web hosting consolidation pressure by contracting. On September 10, Italian hosting company Aruba confirmed it had applied for 39 top level domain strings in ICANN's 2026 round, including .vps, .demo and .pec. That is a long horizon bet. A host that controls its own registry can bundle domains, hosting and email into packages that competitors cannot price against, because it sets the wholesale cost itself.

Both moves are web hosting consolidation wearing different clothes. IONOS is consolidating internally to defend margin. Aruba is consolidating vertically to own more of the customer relationship from registration through to the server. Site owners experience the first as fewer people on the support desk and the second as new domain extensions arriving with commercial strings attached. We looked at the wider application round when it opened in our coverage of the ICANN gTLD round.

What This Round of Web Hosting Consolidation Reveals

Set the two stories side by side and the pattern is hard to miss. IONOS is not cutting because customers left. It added 280,000 of them in six months. It is cutting because the cost of operating a hosting platform keeps climbing faster than what customers will pay to sit on one. Control panel licensing is the clearest illustration. cPanel shifted from flat per server fees to account based pricing in 2019, and every increase since has landed hardest on small hosts, because they hold the least negotiating leverage.

That cost curve is the real engine behind web hosting consolidation. Hardware, power and bandwidth all move in the same direction, rewarding volume over craftsmanship. Our earlier report on cloud infrastructure spending tracked the same pressure from the buying side of the market. An operator caught in the middle either grows fast enough to negotiate real discounts or sells to somebody who already has them.

What Buyers Actually Pay For

The same valuation research lists the traits that move a hosting business between 2.0x and 5.8x: the shape of recurring revenue and how renewals actually behave, control panel licensing costs, customer concentration, and owner dependence where critical knowledge sits in one person's head. Every one of those is a question a site owner can ask about their own provider, and the answers predict fairly well how the next wave of web hosting consolidation will treat them.

Web Hosting Consolidation Changes Who Answers Your Ticket

The practical effect of all this arrives through the support queue long before it shows up in a press release. When 450 roles come out of a group that operates half a dozen consumer brands, and AI is explicitly named as the mechanism for covering the gap, first response times may well improve while resolution quality on hard problems quietly degrades. Routine password resets and billing questions are exactly what an assistant like Ask Aida handles at 95 percent.

The problems that need a human are the ones that also need speed: a migration that silently dropped a database table, a mail queue blacklisted overnight, a compromised install spraying spam. Web hosting consolidation tends to optimize the common path and thin out the rare one. At MonsterMegs we have taken the opposite view, keeping engineers on the support desk precisely because the rare cases are where hosting earns its keep.

How to Respond to Web Hosting Consolidation on Your Own Site

Web hosting consolidation news of this kind does not call for panic, and switching hosts on the strength of a restructuring headline is an overreaction. It does call for a short audit. Confirm you hold your own off server backups rather than relying entirely on your provider's snapshots, and test a restore rather than assuming one works. Check who controls your domain registration and DNS, because during any consolidation event the registrar relationship is the piece you least want tangled up with the hosting account.

Then look at your renewal. Consolidated providers recover margin at renewal time far more often than at signup, so the number you originally paid is a poor guide to what comes next. Finally, note how portable your stack is. A standard cPanel account running current PHP on a LiteSpeed server can move in an afternoon. A setup wired into one provider's proprietary control panel and custom caching layer cannot, and that difference decides whether web hosting consolidation is an inconvenience or a crisis.

The Takeaway

Three things come out of this week clearly. IONOS cut 450 roles while growing revenue, which tells you the pressure is on operating costs rather than demand. Valuation data shows the gap between small and mid sized hosting businesses at its widest since 2022, which guarantees more deals. And both the internal restructuring at IONOS and Aruba's 39 TLD applications point the same way: web hosting consolidation rewards whoever owns more of the stack.

For site owners the sensible response is portability rather than loyalty, so keep your backups, your domain control and your stack standard enough to move. If you would rather sit on infrastructure built for speed instead of for the next earnings call, our LiteSpeed and NVMe web hosting is a straightforward place to land.

The SSL Certificate Lifetime Cut Is Now Hitting Sites

MonsterMegs — Mon, 07 Sep 2026 20:01:50 +0000

Originally published at https://monstermegs.com/blog/ssl-certificate-lifetime/

On March 15, 2026, the maximum SSL certificate lifetime dropped from 398 days to 200 days, and most of the web shrugged. Six months later, that shrug is turning into a scramble. Certificates issued in the first days of the new regime begin expiring in early October, which means a large slice of the internet is about to hit a renewal deadline it has never faced before, on a schedule that no longer lines up with anything annual. The renewal you booked for next spring is now due this autumn.

This is not a proposal or a draft standard. The new SSL certificate lifetime is already in force, enforced by browsers, and the next tightening is only eighteen months out. Here is what actually happened, what the first six months revealed, and what site owners need to change before the October wave lands.

What Changed on March 15 and Why It Bites Now

Every publicly trusted certificate issued on or after March 15, 2026 carries a maximum validity of 200 days. In practice, certificate authorities issue at 199 days to leave a safety margin. That halves the SSL certificate lifetime site owners had grown used to since 2020, and it quietly broke a habit that had been baked into operations for years: the annual certificate renewal, handled once, filed away, and forgotten until next year.

The SSL certificate lifetime math is what stings. A certificate issued on March 16 expires around October 1. Nobody who renewed in spring expects to renew again before winter. Teams that track expiry in a spreadsheet or a calendar reminder set the reminder for 2027, because that is what every previous cycle taught them to do.

The SSL Certificate Lifetime Math Nobody Ran

Cutting the SSL certificate lifetime in half does not double the workload. It more than doubles the number of opportunities to get it wrong. A single site now needs two renewals a year instead of one. An agency managing 200 client domains goes from 200 SSL certificate lifetime renewal events a year to roughly 400, and each one is a potential outage that presents visitors with a full page browser interstitial rather than a quiet warning.

The compression is not finished either. The SSL certificate lifetime cap falls to 100 days on March 15, 2027, and to 47 days on March 15, 2029. At 47 days, a site needs roughly eight certificate renewals per year. Any process that involves a human logging into a dashboard, downloading files, and pasting them into a server config is dead at that cadence.

Why the first cycle is the dangerous one

Second renewals are usually fine, because by then the shortened SSL certificate lifetime has trained everyone involved. The first one is where the failures cluster. Monitoring thresholds are still tuned to annual assumptions, alerting rules fire at 30 days when the buffer is proportionally smaller, and the person who handled last year's renewal may have changed roles entirely.

How Ballot SC-081v3 Set the SSL Certificate Lifetime Schedule

The change did not come from a browser vendor acting alone. In April 2025 the CA/Browser Forum unanimously approved Ballot SC-081v3, which amended the TLS Baseline Requirements to phase the SSL certificate lifetime down in three steps. Unanimous is worth pausing on: certificate authorities, who sell the certificates and stood to face significant operational cost, voted for it alongside the browser makers pushing it. DigiCert's breakdown of the ballot lays out the full schedule and the reasoning behind each step.

The security case is straightforward. A shorter SSL certificate lifetime limits the blast radius of a stolen private key, a mis-issued certificate, or a certificate bound to cryptography that has since been deprecated. Revocation has never worked reliably at internet scale, since browsers cannot depend on revocation checks being available or honored. Expiry, by contrast, always works. Shrinking the window is the industry admitting that expiry is the only revocation mechanism it can actually trust.

Domain Validation Reuse Quietly Shrank Too

The part that catches people out is not the certificate at all. Ballot SC-081v3 also cut how long a certificate authority may reuse existing domain control validation data. That reuse window dropped to 200 days on March 15, 2026, and falls to 100 days in March 2027, tracking the SSL certificate lifetime itself.

In plain terms, proving you control the domain is no longer a once a year event either. If your validation relies on a DNS TXT record that someone deleted during a migration, or an HTTP file challenge sitting in a directory a redirect rule now swallows, renewal fails at validation rather than issuance. The error looks nothing like an SSL certificate lifetime warning, and teams lose hours chasing the wrong problem.

Microsoft's Azure Storage Cutoff Added Pressure

The SSL certificate lifetime change did not land in isolation. On February 3, 2026, Microsoft finally enforced its long delayed retirement of TLS 1.0 and 1.1 across Azure Storage, including Azure Files, Queue Storage, and Table Storage. The company had scheduled the cutoff for November 2024, postponed it, rescheduled for November 2025, and postponed again before pulling the trigger this year.

The wording left no room for interpretation. As The Register reported, all clients connecting to Azure Storage using a TLS version below 1.2 simply lose the ability to connect. Two enforcement events in six weeks, one on protocol versions and one on the SSL certificate lifetime, hit the same teams and the same aging integrations.

What the SSL Certificate Lifetime Squeeze Reveals

Both changes point at the same thing: the era of set and forget TLS is over, and the ecosystem has stopped pretending otherwise. The unanimous SC-081v3 vote and Microsoft's willingness to break old clients after two postponements are the same decision from different directions. Compatibility with manual, infrequent, human driven certificate handling is no longer something the web will preserve.

The evidence that this works is already visible. Let's Encrypt now accounts for over 60 percent of active TLS certificates, and the overwhelming majority of certificates issued today are domain validated and provisioned automatically. Those sites did not notice March 15 at all, because a 90 day renewal cycle makes a 200 day SSL certificate lifetime irrelevant. The disruption is concentrated entirely among the sites still renewing by hand.

The gap is operational, not technical

Nothing about a shorter SSL certificate lifetime is technically hard. ACME clients have been production ready for a decade, and most quality hosting control panels ship with automated issuance built in. The gap is that plenty of certificates live on load balancers, legacy appliances, mail servers, and internal services that were configured once, years ago, by someone who has since left. Those are the assets that will fail in October, not the WordPress sites on managed platforms.

Post Quantum Rollout Is Landing at the Same Time

Running alongside all of this is a cryptographic migration that the shorter SSL certificate lifetime is quietly designed to enable. Post quantum capable client traffic passed 60 percent in February 2026, up from under 3 percent at the start of 2024, using the X25519MLKEM768 hybrid key exchange in TLS 1.3. Origin side support crossed 10 percent in January after Akamai enabled it by default.

This is the strategic reason for the schedule. When publicly trusted post quantum certificates arrive, expected in late 2026 or 2027, the web needs to be able to rotate its entire certificate population in weeks rather than years. A 47 day SSL certificate lifetime makes that possible. A 398 day one does not. Server software is moving accordingly, as the recent post quantum support in LiteSpeed shows.

What Site Owners Should Do Before October

Start with an inventory, because the certificates that will fail are the ones nobody remembers owning. Every hostname, every subdomain, every internal service and appliance, with its real SSL certificate lifetime pulled from the certificate rather than from a spreadsheet. Anything issued between March 15 and April 2026 expires in the next several weeks.

Then automate everything you can, and put explicit monitoring on everything you cannot. Where a host offers automated issuance and renewal through the control panel, switch to it rather than uploading certificates manually, and verify that renewals are firing. Confirm your validation method still resolves, since a stale DNS record will break renewal long before expiry does. Finally, check that nothing in your stack still negotiates below TLS 1.2, because the Azure cutoff signals where every other major platform is heading. Sites hosted with automated SSL certificates handle most of this without intervention, but the verification step is still yours.

The Takeaway

Three things matter here. The 200 day SSL certificate lifetime cap is live and its first renewal wave arrives in October, catching anyone who set a 2027 reminder. Domain validation reuse shrank on the same schedule, so renewals can fail for reasons that look nothing like expiry. And with 100 day certificates arriving in March 2027, any manual process you patch together this autumn will break again in six months, so automating now is cheaper than automating twice.

The sites that sailed through March 15 were not better prepared than yours, they were just already automated, which is exactly the lesson worth taking from a compromised or expired certificate incident like those covered in our look at server compromise trends. If you would rather not track any of this by hand, MonsterMegs includes free SSL certificate installation with automatic renewal on every hosting plan.

What the NGINX Security Update Fixes for Site Owners

MonsterMegs — Fri, 04 Sep 2026 20:01:25 +0000

Originally published at https://monstermegs.com/blog/nginx-security-update/

Two days ago the NGINX project shipped a pair of releases at once, and the quieter half is the one worth your attention. Alongside nginx 1.31.5, the team published njs 1.0.1, which closes three separate vulnerabilities in the JavaScript engine that thousands of servers use to make routing and access decisions. One of them lets a request slip past an access rule an administrator believed was being enforced. If your site sits behind NGINX, or behind a CDN, load balancer, or reverse proxy that runs it, this NGINX security update is one to apply rather than queue.

What Shipped in the September NGINX Security Update

The release landed on September 2, 2026. On the mainline side, nginx 1.31.5 is a feature release: it introduces a Control API, predicate locations, and a new ngx_http_json_module. Those are meaningful additions for anyone building dynamic configuration or handling JSON at the edge, and they are the headline most coverage led with.

The njs 1.0.1 release published the same day is where the security content lives. It patches CVE-2026-18329, an access control bypass in js_access; CVE-2026-78222, a worker process crash triggered through ngx.fetch(); and CVE-2026-78689, a heap buffer overflow in xml.exclusiveC14n(). All three are documented in the project's own 2026 release notes. Bundling a feature release and a security release in the same announcement is normal practice for the project, but it does mean the NGINX security update can get lost behind the shinier feature list.

The Three njs Flaws Behind the NGINX Security Update

njs is NGINX's scripting engine. It is optional, but it is widely deployed in front of APIs and applications precisely because it lets operators write logic that plain configuration directives cannot express. That includes authorization checks, which is what makes the first flaw in this NGINX security update more serious than a version bump suggests.

The js_access bypass

js_access exists so operators can write their own access decisions in JavaScript and have NGINX enforce the verdict. CVE-2026-18329 is an access control bypass in that mechanism. The practical risk is straightforward: a check that returns “deny” in testing may not deny in every code path, and nothing in your logs necessarily screams that it failed. Configurations that use js_access as the only gate in front of an internal endpoint carry the most exposure here.

The ngx_fetch crash

CVE-2026-78222 crashes a worker process through ngx.fetch(), the function njs scripts use to call out to other services. A crashed worker is not a breach, but repeated crashes are a denial of service, and ngx.fetch() had already been hardened once this year in njs 1.0.0 back in June. Seeing it patched twice in three months is a signal about where the fragile surface sits.

The XML canonicalization overflow

CVE-2026-78689 is a heap buffer overflow in xml.exclusiveC14n(), the XML canonicalization helper used mostly in SAML and signed-document workflows. Heap overflows in a worker process are the category that occasionally graduates from crash to code execution, which is why this part of the NGINX security update deserves priority even though the affected function is niche.

The njs Engine Change That Set the Stage

These fixes did not appear in a vacuum. In June 2026, njs 1.0.0 marked a genuine turning point for the scripting layer: the project deprecated its original njs engine in favor of QuickJS, aligned exception classes across both engines, and hardened ngx.fetch() request validation. That was a major-version milestone, and major-version milestones move a lot of code at once.

Two of the three flaws in the September NGINX security update sit in areas that release touched. That is not a knock on the migration, which brings a faster and better-tested JavaScript engine to a component that badly needed one. It is a reminder of how transitions behave in practice: the months immediately after a large refactor are when researchers find the most, and when operators need to track releases most closely. Anyone who adopted njs 1.0.0 early should treat this NGINX security update as part of the same story rather than an isolated patch.

This NGINX Security Update Fits a Busy 2026 Pattern

Read the 2026 changelog end to end and a rhythm emerges. February closed an SSL upstream injection issue. March fixed buffer overflows in the DAV and MP4 modules plus two mail session authentication flaws. May brought a six-CVE release covering HTTP/2 request injection, HTTP/3 address spoofing, and a use-after-free in OCSP resolver requests. June and July each added three more. This NGINX security update is not an outlier; it is the eighth batch of fixes in nine months.

That cadence is not a sign of a project in trouble. It is what a mature, heavily audited codebase looks like when researchers are actively pointing tools at it. The problem is on the operator side: patch fatigue is real, and a server that is three NGINX security update cycles behind is running known, published, exploitable code.

The July Flaw That Should Change How You Read These Notes

The clearest argument for taking each NGINX security update seriously arrived in July. CVE-2026-42533, patched in nginx 1.30.4 and 1.31.3, is a heap buffer overflow in the map directive's regex handling that carries a CVSS v4.0 score of 9.2. It affects a range of versions stretching back to 0.9.6, and it is reachable pre-authentication through crafted HTTP requests.

What makes it instructive is that it is configuration-dependent. The dangerous pattern involves regex-based map directives using numbered captures such as $1 or $2, with a string expression referencing the map output after an earlier regex match. Plenty of servers running affected versions were never exploitable. Plenty of others were, and had no way to know without reading their own configuration line by line. That is the trap: version numbers alone do not tell you your exposure, and skipping an NGINX security update because “we probably do not use that module” is a guess dressed up as a decision.

Why This Reaches Far Beyond People Who Run NGINX

As of September 4, 2026, W3Techs measures NGINX at 31.3% of all websites whose web server is known, ahead of Cloudflare Server at 29.9%, Apache at 22.5%, and LiteSpeed at 14.7%. That makes it the single most common web server on the public internet.

More to the point, NGINX is rarely the only thing in the path. It sits inside CDN edge nodes, Kubernetes ingress controllers, API gateways, and the reverse proxy layer of hosting stacks that terminate on something else entirely. A site owner who has never typed an nginx command may still depend on half a dozen NGINX instances between a visitor and their content. When an NGINX security update ships, the relevant question is not “do I run NGINX” but “who in my delivery chain does, and have they patched?”

That question has teeth. We have already seen this year how quickly attackers industrialize access to compromised web servers, and unpatched proxy layers are exactly the kind of quiet foothold that gets recycled into larger campaigns.

What Site Owners Should Do After This NGINX Security Update

If you administer your own servers, the direct action is to move to njs 1.0.1 and, if you track mainline, nginx 1.31.5. Then audit specifically for the exposed surface: grep your configuration for js_access, ngx.fetch(), and any njs code touching XML canonicalization, and treat those blocks as suspect until the update is in place. While you are in there, check for the regex map pattern behind CVE-2026-42533 as well.

If someone else runs your stack, this NGINX security update turns into a support question rather than a shell session. Ask your host or CDN provider which nginx and njs builds they are running and when the September patches land. A provider who can answer that in one reply is telling you something useful about how they operate. On managed platforms the patching should already be handled for you, which is the practical case for LiteSpeed NVMe hosting where the server layer is somebody else's job. It is the same dynamic we covered when the LiteSpeed server update added post-quantum encryption earlier this year: the value of a managed stack is that these releases reach your sites without you scheduling a maintenance window.

Either way, do not treat “we are on a supported version” as the finish line. Supported and patched are different states, and the gap between them is where most real incidents start.

The Takeaway

Three things are worth carrying away from this release. First, the September NGINX security update patches a genuine access control bypass, not just crash bugs, so the js_access flaw deserves same-week attention. Second, 2026 has produced a steady stream of NGINX fixes, and falling behind by even a few cycles now means running publicly documented vulnerabilities. Third, because NGINX runs somewhere in almost every delivery chain, this NGINX security update is worth asking about even if you have never configured a web server yourself.

If keeping up with releases like this is not how you want to spend your week, MonsterMegs handles the server layer on every managed WordPress hosting plan so patches land without a ticket from you.

How an AI Domain Name Generator Finds Your Perfect Name

MonsterMegs — Wed, 02 Sep 2026 20:01:27 +0000

Originally published at https://monstermegs.com/blog/ai-domain-name-generator-2/

You have the business plan, the logo sketches, and maybe half a website already built. Then you type your first domain idea into a search box and get the same answer three times in a row: already registered. That wall is where most new projects stall, and it is exactly the problem an AI domain name generator was built to solve. Instead of guessing one name at a time and hitting a dead end, you describe what your business actually does and get back dozens of available options in seconds.

Why Good Domain Names Feel Impossible to Find

The math explains the frustration. Verisign's quarterly report recorded 401.6 million domain name registrations across all top level domains at the end of the second quarter of 2026, an increase of 8.1 percent year over year. Nearly every short, pronounceable English word in .com was claimed a decade ago, along with most two word combinations of them.

Manual brainstorming does not scale against that. You think of ten names, discover ten are taken, and start doubting the idea itself. An AI domain name generator flips the order of operations: rather than testing names one by one, it produces a large candidate pool filtered for availability first, so everything you look at is something you can register today.

How an AI Domain Name Generator Actually Works

Under the hood, an AI domain name generator is doing three jobs at once. First it reads your description and extracts the concepts that matter: the industry, the audience, the tone, the promise. Second it generates candidates using the patterns real brands use, including compound words, invented words, prefixes, suffixes, and clipped forms. Third it checks each candidate against live registry data and quietly discards anything already taken.

That third step is what separates a real tool from a thesaurus. A language model left to its own devices will happily hand you twenty gorgeous names that were all registered in 2004. Availability checking has to run inside the same loop, not as an afterthought, which is why a well built AI domain name generator returns fewer results but usable ones.

Why the results feel more human than older tools

Older generators glued your keyword onto a fixed word list. You typed “coffee” and got coffeehub, coffeezone, and coffeepro. An AI domain name generator understands that a specialty roaster and a drive through chain want completely different names even though both sell coffee. It works from meaning rather than string concatenation, and that single difference is why the output reads like names a person would actually pick.

Give the AI Domain Name Generator a Better Brief

Output quality tracks input quality almost perfectly. Type one word and you get generic results that could belong to anyone. The people who walk away from an AI domain name generator with a shortlist on the first try are the ones who write two or three sentences covering what the business does, who it serves, and how it should sound.

Compare the prompt “bakery” with “a small batch sourdough bakery in Portland that sells wholesale to restaurants and wants a warm, old world name.” The second gives the AI domain name generator a product, a market, a region, and a tone to work from. The suggestions that come back are not slightly better, they are a different category of result.

Details worth adding to your prompt

Say how long you want the name to be, because a five letter name and a fifteen letter name are different design problems. List words to avoid, especially competitor terms or anything you have already ruled out. State whether you want a real word, an invented word, or a compound. Every constraint you add narrows the search space and raises the hit rate.

Extensions Change What the Generator Can Find

If you lock an AI domain name generator to .com only, you are searching the most exhausted namespace on the internet. Opening the extension list is the fastest single improvement you can make. ICANN has delegated well over a thousand generic top level domains, and most of them are nowhere near as crowded as .com.

Extensions can also carry meaning instead of just filling space. A studio on .design, a product on .app, a tool on .ai: the extension becomes part of the name rather than a tax you pay at the end. Our roundup of new domain extensions covers which ones have genuine traction and which are novelty buys.

One caveat worth keeping in mind. If the .com of your chosen name belongs to an established business in a similar field, an AI domain name generator will still offer you the alternative extension, and you will spend years being confused with them. Check who holds the .com before you fall in love with the .co.

Turning Fifty Suggestions Into a Shortlist of Three

A productive session with an AI domain name generator ends with too many options, not too few. That is the right problem to have, but you still need a filter, and three quick tests do most of the work.

The radio test: say the name out loud and ask someone to type it without seeing it spelled. If they get it wrong, that name will leak traffic forever. The scan test: read it in lowercase with no spaces, the way it appears in a URL, and check for accidental words. The regret test: picture yourself saying it in a meeting three years from now.

Do not skip the trademark check

An AI domain name generator has no idea what is trademarked in your country or your category. A name can be perfectly available to register and still be legally unusable for your business. Search your national trademark database and run a plain web search before you commit. It takes five minutes and it occasionally saves an expensive rebrand.

Checks to Run Before You Register

Once you have a favorite, look at its past. A free WHOIS lookup shows whether the name was registered before and recently dropped, which can hint at abandoned spam history worth avoiding. A quick search for the name in quotes tells you whether an existing site, product, or social account already owns that word in people's minds.

If the name is for a real brand rather than a weekend project, secure the obvious variants while you are there. Agencies and anyone building a portfolio can register domains in bulk rather than coming back later to buy the misspelling someone else grabbed first.

Where an AI Domain Name Generator Leads People Astray

The first failure mode is cleverness over clarity. An AI domain name generator is very good at wordplay, and wordplay that needs explaining is a liability on a business card. If you have to say “it is like the word, but with a Z,” keep looking.

The second is chasing availability instead of fit. It is tempting to grab the first free name that is short and pronounceable, but short and free is not the same as right for your business. The third is registering too fast. Sit with your top three for a day. Names that feel brilliant at midnight often look thin by morning, and an AI domain name generator will still be there tomorrow with fifty more.

Line the Name Up With Where the Site Will Live

Naming and hosting are usually treated as separate errands, which creates avoidable friction. Once an AI domain name generator hands you a winner, register it and point it at your hosting account the same day, while DNS propagation has time to settle before launch. Setting up email on the domain at that point costs you a few minutes instead of a support ticket later.

It is also the moment to decide what the name has to carry. A personal blog and a store expecting seasonal traffic spikes go through the same naming process but have very different infrastructure needs, and matching a LiteSpeed and NVMe backed plan at MonsterMegs to that expectation up front is cheaper than migrating in a hurry.

Putting It All Together

Naming stopped being a scarcity problem and became a filtering problem. An AI domain name generator gives you volume and availability in one pass, so your job shifts from hunting for anything free to choosing well from a real shortlist. Write a specific brief, open up the extensions, and apply the radio, scan, and trademark checks before your card comes out.

The name you end up with matters less than whether people can hear it, spell it, and remember it. When you are ready to see what your idea sounds like as a domain, put your description into the AI domain name generator and see what comes back.

What the Latest Google Spam Update Means for Site Owners

MonsterMegs — Mon, 31 Aug 2026 20:01:31 +0000

Originally published at https://monstermegs.com/blog/google-spam-update-2/

Google shipped a ranking change in August, and it was finished before most site owners had time to open their analytics. The August 2026 Google spam update began rolling out on August 18 and completed on August 21, a total of two days and sixteen hours from announcement to close. That is fast even by recent standards. It is also easy to miss entirely, which is exactly why so many people spent the back half of August arguing about traffic drops without knowing whether the Google spam update had anything to do with them.

What Google Confirmed About the August Rollout

Google Search Central announced the release on August 18 at roughly 12:30 pm Eastern with a single short post stating that the August 2026 spam update had gone live and that the ranking release history page would be updated once the rollout finished. Three days later the entry appeared on the Google Search ranking updates dashboard with a completion timestamp of August 21 at around 4:50 am. No blog post, no fresh policy documentation, no accompanying core update. The Google spam update was announced, executed, and closed out inside seventy-two hours.

The scope was global. Google confirmed the rollout applied to all regions and all languages rather than targeting a single market. That is standard for spam releases, but it is worth stating plainly, because site owners outside English speaking markets routinely assume these enforcement passes skip their region. They do not. If your site is indexed, this Google spam update evaluated it.

The Google Spam Update Was Over Before Most Sites Noticed

Rollout speed has quietly become the story of 2026. The March 2026 spam update completed in nineteen hours and thirty minutes, the fastest confirmed ranking rollout ever recorded on Google's dashboard. The June 2026 spam update took two days and one hour. This August's Google spam update took two days and sixteen hours. Compare that with the broad releases from the same year: the March 2026 core update ran twelve days and four hours, and the May 2026 core update ran eleven days and twenty-one hours.

That gap matters for diagnosis. If your traffic slid gradually across two weeks, a Google spam update is an unlikely explanation, because these rollouts simply do not last two weeks. If your rankings moved sharply inside a two or three day window in the second half of August, the timing lines up. Rollout duration is one of the few free diagnostic signals Google hands you, and almost nobody uses it.

What the Google Spam Update Did Not Target

Google was unusually specific about exclusions this time. The company confirmed that this Google spam update did not target link spam, and that it did not target the site reputation abuse policy, the rule covering third party content published on an established domain to borrow its ranking strength. Both of those have separate enforcement tracks. Ruling them out narrows the field considerably for anyone trying to work out what happened to their rankings.

Google also introduced no new spam policy alongside the release. The existing published policies remain the complete list of what the systems look for. In practical terms, the Google spam update was an enforcement pass against rules that were already written down rather than a change to the rules themselves. If you want to know what was actually being measured, the official Google spam policies documentation is the reference to read, not the commentary written about it.

Why the August Volatility Story Got Complicated

August was noisy long before any of this. Rank trackers recorded a sharp burst of movement between August 1 and August 3 that Google never confirmed as an update at all, and we wrote about that early August ranking volatility while it was happening. Two unrelated events inside one month creates a genuine attribution problem. Plenty of sites that lost traffic on August 2 have spent the past two weeks blaming a Google spam update that did not begin until sixteen days afterward.

It got messier from there. Several SEO publications began reporting an “August 2026 core update,” some dating it to August 8 and others to August 26, complete with confident recovery advice. Google's ranking release history lists no such release. The only confirmed August entry is the Google spam update that ran from the 18th to the 21st. Before you act on somebody else's traffic analysis, check the status dashboard rather than the aggregators repeating each other.

The Policies That Actually Decided Outcomes

Since no new rules shipped, the useful question is which existing ones the Google spam update was enforcing. Reporting across the SEO community during the rollout pointed consistently at two policy areas that have absorbed the bulk of enforcement attention through 2026, and both are worth understanding whether or not your rankings moved.

Scaled content abuse

This policy covers generating large volumes of pages primarily to manipulate rankings rather than to help people, regardless of whether a human, a model, or a template produced them. The distinction Google draws is intent and value, not authorship method. A thousand AI assisted pages built on genuine firsthand expertise sit differently from a thousand pages spun from a keyword list, and enforcement passes like this Google spam update are where that difference gets priced in.

Expired domain abuse

Buying a lapsed domain to repurpose its accumulated authority for unrelated content has been an explicit violation for a while now, and it keeps resurfacing in spam enforcement discussion. If you acquired an aged domain and pointed it at a completely different topic, this is the policy that governs the outcome. Checking a domain's history before purchase is a five minute job with a free WHOIS lookup and it prevents an expensive mistake.

Where Server Health Enters the Picture

There is an angle to spam enforcement that rarely gets discussed, and it has nothing to do with your content strategy. Google's spam policies include hacked content and cloaking, and neither requires you to have done anything deliberately. A compromised installation quietly serving injected pages to Googlebot is spam by the policy's definition even though the site owner never wrote a word of it.

That is not a hypothetical risk. Compromised hosting accounts are actively used to publish spam at scale, a pattern we covered when looking at how compromised web servers get folded into larger attack infrastructure. If a Google spam update coincided with a ranking loss you cannot otherwise explain, run a fresh crawl of your own site and check what is actually indexed under your domain before you start rewriting content that was never the problem.

How to Respond to the Google Spam Update

The first step is confirming the timing actually matches. Pull your Search Console performance data, set the comparison window around August 18 to August 21, and look for a step change rather than a slope. A Google spam update that completed in under three days produces a sharp edge in the data. If your decline started earlier or arrived gradually, you are chasing the wrong cause and any fix you apply will be aimed at the wrong target.

If the timing does match, work the published policies in order rather than guessing. Audit anything mass produced, anything published on a domain you acquired for its history, and anything appearing in your index that you did not create. Spam enforcement recoveries are not quick, and there is no reconsideration request for algorithmic spam actions, so the honest expectation is months rather than weeks once the underlying issue is genuinely resolved. Resist the urge to make sweeping changes in the first two weeks after any Google spam update while the data is still settling.

One thing worth ruling out early is infrastructure. Slow response times and unpatched software will not trigger a spam action on their own, but they make a site easier to compromise, and a compromised site can absolutely earn one. Keeping software current on hosting that stays patched and monitored, which is a baseline we consider non negotiable at MonsterMegs, removes an entire category of problem from the investigation before you start.

Where to Go From Here

Three things are worth carrying away from this one. The August 2026 Google spam update was real, confirmed, global, and finished in two days and sixteen hours, which makes the timing easy to check against your own data. The widely reported “August core update” was not real, and Google's ranking release history is the only source that settles that question. And because no new policies shipped, the published spam documentation you could have read in July is still the complete answer to what was being enforced in August.

The practical takeaway is unglamorous but reliable: verify the timing before you diagnose, read the primary source before you act, and make sure the site itself is not quietly publishing something you never approved. If server level security and patching are part of what you want handled for you, our LiteSpeed powered web hosting is a sensible place to start.

What the New WordPress Core Update Changes for Sites

MonsterMegs — Fri, 28 Aug 2026 20:01:22 +0000

Originally published at https://monstermegs.com/blog/wordpress-core-update/

WordPress just shipped its most disruptive editor release in years, and it went out live from a conference stage. Version 7.1 “Mary Lou” was published on August 19, 2026, on the closing day of WordCamp US in Phoenix. If you run sites on the platform, this WordPress core update is not the kind of point release you click through without reading. It changes how block themes render, how media is organized, and how much tolerance the editor has for aging plugins.

The release is named for jazz pianist, composer and arranger Mary Lou Williams, a nod to what the core team described as a spirit of reinvention and collaboration. That framing turned out to be accurate. Collaboration tooling is one of the headline additions, and reinvention is exactly what a lot of theme and plugin developers are doing right now under deadline pressure.

The WordPress Core Update That Shipped From WordCamp US

Timing a major version to a live event is unusual. The core team scheduled publication for 23:10 UTC on August 19, the final day of WordCamp US, so contributors gathered in Phoenix could ship it together. It worked as theater and as project management. It also means the WordPress core update reached millions of installs during a week when a large slice of the developer community was traveling or standing on a conference floor.

The run up was not quiet either. The third release candidate landed on August 12 carrying more than 90 updates and fixes since RC1, split into 37 in the editor and 57 in core. Ninety changes in the last week before a major version is a signal rather than noise. It tells you the surface area of this WordPress core update was wide enough that the team was still catching regressions days before launch.

The core team was blunt about why that mattered, writing that testing for issues is crucial to the development of any software and one of the most meaningful ways anyone can contribute. RC3 was also the hard string freeze point, which locked translations in place and gave polyglot teams a stable target for launch day.

What the WordPress Core Update Actually Changes

Four areas carry most of the weight in 7.1, and none of them are cosmetic. Responsive styling, collaboration, media handling and AI controls all moved at once, which is why the compatibility conversation around this WordPress core update has been louder than usual.

Responsive Styling Lands in the Site Editor

The Site Editor now offers native responsive styling controls alongside pseudo state controls for hover, focus and active states. That is a genuine milestone. Until now, styling a block differently on mobile or giving a button a hover color meant custom CSS, a page builder, or a theme that shipped its own controls. Moving those into core removes a long standing reason to reach for third party tooling, and it quietly overlaps with features commercial builders have sold for years.

Notes Becomes a Real Collaboration Tool

Notes picked up suggestion mode, rich text, emoji reactions and, most usefully, at mentions. Typing an at sign inside a note opens a searchable list of collaborators you can tag directly. For editorial teams that have been running feedback through chat threads and shared documents, this WordPress core update pulls that conversation back into the editor where the content actually lives.

A Redesigned Media Editor and Two New Blocks

Media handling got the overhaul it has needed since the Media Library first shipped. The official release announcement highlights native media organization, a new media editor modal and improved image processing. Alongside that, two new core blocks arrived: Tabs and Playlist. Automated migration assistance for classic themes rounds out the list, aimed at the enormous population of sites still running pre block themes.

Tabs in particular is worth noting. It is one of the most commonly requested layout patterns and one of the most common reasons site owners install a block plugin. Every time core absorbs a pattern like this, a handful of plugins lose their reason to exist and site owners get one less dependency to maintain.

Iframe Mode and the React Upgrade Are the Real Story

The features get the headlines. The plumbing is what will break sites. WordPress 7.1 enforces iframe mode for block themes and lays the groundwork for the move from React 18 to React 19. Both changes are the right call architecturally. Both also mean that older plugins and custom blocks which reached outside their sandbox, assumed direct access to the editor document, or leaned on React internals now have a materially higher chance of failing.

Enforced iframe mode is the sharper edge. Custom blocks that injected styles or scripts into the editor without registering them properly have been living on borrowed time for several versions. This WordPress core update ends that grace period. If a block renders correctly on the front end but looks broken inside the editor after upgrading, iframe enforcement is the first thing to check.

The Compatibility Risk Inside This WordPress Core Update

Here is the practical read. Sites running a modern block theme with a short, well maintained plugin list will almost certainly sail through. Sites running a classic theme with a decade of accumulated plugins, a custom block library built by a contractor who has since moved on, or a page builder that has not shipped a compatibility release yet are the ones that need a staging environment before this WordPress core update goes anywhere near production.

The pattern is familiar. Major WordPress releases rarely break well built code. They break abandoned code. The 37 editor fixes in RC3 alone suggest how many edge cases surfaced during the beta cycle, and those were the ones testers found. Every release ships with a tail of issues that only appear once real sites with real plugin stacks upgrade.

This is also where the wider maintenance picture matters. The same neglect that turns a WordPress core update into a broken layout is what turns an unpatched plugin into a breach, a point the recent WordPress plugin security incidents made clearly.

A Security Release Set the Stage

Worth noting in the timeline: WordPress 7.0.4, a security release, went out shortly before RC3. That sequencing is a reminder that the branch you are on still receives fixes while the next major version is in flight, and that sitting on an old version to avoid a WordPress core update is not a neutral choice. It is a decision to skip security patches too.

If you have automatic minor updates disabled, that 7.0.4 release is a good prompt to check what version your sites are actually on. Plenty of installs are running further behind than their owners believe, and the gap only widens each time a WordPress core update is postponed.

Guidelines Gives Site Owners a Say Over AI

The most forward looking addition in this WordPress core update is Guidelines, a new feature for AI control. Core is starting to give site owners a structured way to express how AI tooling should behave in the context of their content. It is early, and the practical impact will depend entirely on what plugin and platform developers build on top of it, but the direction is significant.

WordPress adding native AI controls at the core level rather than leaving it to plugins signals that the project sees this as infrastructure. For anyone who has watched search engines reshape how content gets surfaced over the past year, having a first party place to declare AI preferences is a foundation worth paying attention to.

How to Roll Out the WordPress Core Update Safely

Take a full backup first, files and database both, and confirm you can actually restore it. A backup you have never tested is a hope, not a plan, and the backup routine you rely on should be verified before a major version, not after. Then clone to staging and upgrade there.

On staging, open the Site Editor and check every custom block you depend on. Iframe enforcement is the likeliest failure point, so look at editor rendering specifically rather than just the front end. Check your page builder vendor's changelog for a 7.1 compatibility note, and if they have not published one, wait. Update plugins and themes before core, not after, since most vendors shipped compatibility releases during the RC cycle. Only once staging is clean should the WordPress core update go to production, ideally on a low traffic day when you have time to watch it.

Hosting matters more than people expect during a cycle like this. On a LiteSpeed and NVMe stack like the one MonsterMegs runs, staging clones and restores finish in minutes rather than swallowing an afternoon, which is the difference between actually testing a WordPress core update and gambling on it.

The Takeaway

WordPress 7.1 “Mary Lou” is a genuinely useful release. Responsive styling and pseudo state controls in the Site Editor close a real gap, Notes turns the editor into a workable collaboration space, and Guidelines stakes out core territory on AI. Those are wins worth having.

The caution is equally real. Enforced iframe mode and the React groundwork mean this WordPress core update carries more compatibility risk than a typical major version, especially for classic themes and custom block libraries. Stage it, test the editor and not just the front end, and confirm your backups restore before you touch production.

If your current setup makes that testing cycle painful enough that you skip it, moving to fast WordPress hosting with staging is a sensible step to take before the next WordPress core update lands.

How to Set Up Business Email Hosting on Your Own Domain

MonsterMegs — Wed, 26 Aug 2026 20:01:19 +0000

Originally published at https://monstermegs.com/blog/business-email-hosting/

Would you buy from a company that emails you from a free webmail address? Most people quietly decide the answer is no. A message from hello@yourbrand.com carries weight that yourbrand2019@gmail.com never will, and setting up business email hosting on a domain you own takes an afternoon rather than a week. The trouble is that almost nobody explains the parts that actually break, which is why so many small companies end up in the spam folder wondering what went wrong.

Why Your Domain Should Handle Your Email

Email on your own domain does three things a free account cannot. It reinforces your brand on every message you send, it keeps your address portable if you ever change providers, and it keeps ownership of the mailbox with the company rather than with whoever created the account. That last point catches people out constantly when a freelancer or former employee walks away holding the only login.

There is a control argument too. With business email hosting you decide how many mailboxes exist, what happens to a departing employee, where mail is archived, and which addresses forward where. You can add sales@, support@, and billing@ in seconds. None of that flexibility exists when your correspondence lives in a personal account that belongs to someone else.

Trust is the quiet benefit. Spam filters and recipients alike treat a domain backed address more favorably than a free one, and proposals, invoices, and password resets all land better when they come from the same domain as your website. Good business email hosting simply makes your company look like a company, which matters most at the exact moment a new customer is deciding whether to reply.

The Three Business Email Hosting Options Explained

Broadly speaking there are three routes, and the right one depends on team size and how much administration you want to own. Picking the wrong one is rarely fatal, but switching later means moving mailboxes and re-cutting DNS, so it pays to think for ten minutes first.

Mail Included With Your Hosting Account

Most cPanel hosting plans include full mail service at no extra cost, which makes this the default starting point for small teams. You create mailboxes in the control panel, set quotas, add forwarders and autoresponders, and use webmail or any standard client. For a business running a handful of addresses, this form of business email hosting covers everything needed without another monthly bill.

Dedicated Mail Providers and Relays

Larger teams that live inside shared calendars and collaborative documents often prefer a dedicated provider. The tradeoff is cost per user per month, which adds up quickly across a growing team. A middle path is keeping your mailboxes with your host while routing outbound transactional mail, such as order confirmations, through a specialist relay that handles reputation for you. Plenty of businesses run a hybrid setup like this for years without issue, keeping day to day business email hosting on the same account as their website while offloading only the high volume automated messages.

Getting MX Records Right Before Anything Else

Everything in business email hosting starts with MX records. These DNS entries tell the rest of the internet which server accepts mail for your domain, and if they point somewhere stale, nothing else you configure matters. Check them before you create a single mailbox, because a domain that recently moved registrars or hosts often carries records nobody has looked at in years.

Two rules save most of the pain. First, never run two sets of MX records for the same domain at different priorities hoping mail lands in both places, because it will not work the way you expect. Second, allow for propagation. Changes usually settle within an hour but the published TTL governs how long old servers keep the previous answer, so lower your TTL a day before you plan to cut over. Treat that cutover as the riskiest moment in any business email hosting migration and schedule it for a quiet evening rather than a Monday morning.

SPF DKIM and DMARC in Plain English

These three records are what separate mail that lands in the inbox from mail that quietly disappears. They are also the step most people skip, and skipping them is the single most common reason a new business email hosting setup delivers straight to junk. Since February 2024, Google has required that bulk senders authenticate with SPF, DKIM, and DMARC and keep spam complaint rates below 0.3 percent, according to its email sender guidelines. Yahoo introduced matching rules on the same timeline.

SPF Lists Who Can Send

An SPF record is a single DNS entry naming the servers permitted to send mail for your domain. If you send from your host and a newsletter tool, both must appear in that one record. You are allowed exactly one SPF record per domain, and publishing two is a classic mistake that invalidates both and undoes your business email hosting setup in one move.

DKIM Signs and DMARC Enforces

DKIM adds a cryptographic signature to outgoing messages so receivers can confirm nothing was altered in transit. DMARC then tells those receivers what to do when a message fails, and where to send reports. Start at a monitoring policy, read the reports for a fortnight, and only then tighten to quarantine or reject. The DMARC project documentation covers the syntax in detail.

Connecting Devices Without Losing Mail

Use IMAP, not POP3. IMAP keeps messages on the server and syncs state across every device, so an email read on your phone shows as read on your laptop. POP3 downloads and often deletes, which is how people end up with three years of correspondence trapped on a laptop that later dies. Any modern business email hosting setup should be IMAP by default, with SSL or TLS enabled on both incoming and outgoing connections.

Ports trip people up more than anything else. Incoming IMAP over SSL uses 993, and outgoing SMTP over TLS normally uses 465 or 587. If mail arrives but will not send, the culprit is nearly always the outgoing port, an unticked authentication box, or an internet provider blocking port 25 on residential connections. Most business email hosting control panels publish the exact settings on a single page, so copy them from there rather than guessing.

Business Email Hosting and Inbox Deliverability

Authentication gets you through the door; behavior keeps you there. Sending patterns matter, so a brand new domain that suddenly blasts 5,000 messages looks exactly like a spammer to a filter. Warm up gradually, keep your lists clean, and remove addresses that bounce rather than retrying them indefinitely. Business email hosting reputation is built slowly and lost in a single careless send.

Content matters too. Avoid link shorteners, keep a plain text alternative alongside HTML messages, and make unsubscribing genuinely easy on anything resembling marketing. Reliable business email hosting also depends on the server itself having a clean sending reputation, which is one practical reason to care about how carefully your host manages outbound mail and abuse handling across its network.

Quotas Archiving and Backups

Mailboxes grow faster than anyone predicts, mostly through attachments nobody ever deletes. Set per mailbox quotas at the start and add a warning threshold, because a full mailbox silently rejects incoming mail and the sender may never tell you. Reviewing quotas once a quarter takes five minutes and prevents an awkward conversation about a lost order.

Do not assume your host backs up mail the way it backs up files, and check the retention window before you need it. Mail deleted from an IMAP account is gone from every device at once, which is exactly the scenario a proper backup routine is meant to cover. Export archives for departed staff before you delete their accounts. At MonsterMegs, mail lives on the same NVMe backed servers as your site, so searching a large mailbox stays quick even after a few years of archives pile up.

Common Business Email Hosting Mistakes to Avoid

The most frequent error is changing MX records before mailboxes exist on the new server, which bounces every message sent during the gap. Create the accounts first, verify you can send and receive, then move the records. The second is forgetting a forwarding address set up years ago that quietly copies company mail somewhere nobody remembers.

Weak passwords on shared mailboxes come third, and a compromised sales@ address gets a domain blacklisted within hours. Use unique passwords, enable two factor authentication where offered, and audit the mailbox list twice a year. Finally, do not overlook the domain itself, since business email hosting depends entirely on a registration that has not lapsed, and choosing a domain name you will keep long term saves migrating twice.

Where to Go From Here

Three takeaways carry most of the value here. MX records decide whether mail reaches you at all, SPF, DKIM, and DMARC decide whether it reaches the inbox rather than the spam folder, and IMAP with sensible quotas keeps your archive safe across devices. Get those right and business email hosting becomes something you stop thinking about entirely.

If you are still running your company on a free webmail address, our cPanel web hosting plans include mailboxes on your own domain, which makes this a straightforward afternoon project rather than a migration.

Why Compromised Web Servers Now Power Global Attacks

MonsterMegs — Mon, 24 Aug 2026 20:01:16 +0000

Originally published at https://monstermegs.com/blog/compromised-web-servers/

Your website might already be working for someone else. In August 2026, Check Point Research disclosed that a North Korean espionage crew had stopped hosting its own command and control infrastructure and was instead routing operator traffic through compromised web servers owned by ordinary businesses. The relay points were not underground bulletproof hosts. They were compromised web servers running everyday software. They were webmail installs, WordPress sites and PrestaShop stores whose owners had no idea their hosting accounts had been folded into a state sponsored spy campaign aimed at defense and aerospace firms in Europe and India.

The Campaign That Turned Compromised Web Servers Into Infrastructure

The activity is a revival of Operation Dream Job, the long running Lazarus Group campaign that approaches engineers on LinkedIn with fake recruiter messages and elaborate fake hiring portals. What changed in 2026 is the back end. Check Point observed successful exploitation beginning in June 2026, and reported the underlying Windows privilege escalation flaw, CVE-2026-68820 in the AFD.sys WinSock driver, to Microsoft in late July. Microsoft shipped the fix in its August 2026 Patch Tuesday. The zero day got the headlines, but the quieter detail for anyone who runs a website was where the stolen data went: out through compromised web servers that belonged to unrelated third parties.

Sergey Shykevich, director of threat intelligence at Check Point Software, summarized the wider problem bluntly. “When the website, the download and the recruiter all appear authentic, the old advice to ‘spot the phishing link' is no longer easily applicable.” The same logic applies at the network layer. When callback traffic terminates at a legitimate small business domain with clean reputation history, the old advice to block known bad infrastructure stops working too.

RelayShell and the Roundcube Flaw That Opened the Door

The tool that made this possible is a previously undocumented PHP web shell that Check Point named RelayShell. It does not behave like the noisy web shells most administrators have seen. RelayShell does not execute operator commands on the host it sits on. It acts as a mailbox, writing commands and responses into plain text files that the real victim machines poll and answer. The compromised web servers in the chain are couriers, not endpoints, which is exactly why nobody noticed them.

Access to those compromised web servers came from two directions. Many of the affected Roundcube webmail servers were still vulnerable to CVE-2025-49113, a flaw disclosed more than a year earlier and long since patched upstream. Others appear to have been entered with valid credentials bought from dark web markets, which is a reminder that a fully patched control panel is still only as strong as the password behind it. Researchers identified at least 17 compromised web servers carrying RelayShell, a small number that hides a much larger structural problem.

Why File Based Relaying Is So Hard to Spot

Traditional detection looks for outbound connections to strange IP addresses, beaconing intervals, or PHP processes spawning shells. RelayShell generates none of that on the relay host. From the outside, the compromised web servers are just serving HTTP requests and writing files, which is what web servers do all day. Host based scanners tuned to catch reverse shells and cryptominers can walk straight past compromised web servers in this configuration, and traffic analysis at the victim end sees a request to a normal looking website rather than a suspicious foreign endpoint.

The Credential Failure Behind Many Compromised Web Servers

Stolen credentials keep showing up as the entry point, and separate research published the same month explains why the supply never dries up. Truffle Security spent four years cataloging exposed Amazon Web Services credentials and, on 10 August 2026, re-tested 10,616 complete key pairs that had been leaked publicly between August 2022 and August 2026. As BleepingComputer reported, 9,308 of them, roughly 88 percent, still authenticated successfully. Among those, 242 belonged to IAM users holding the AdministratorAccess policy and 526 were root keys.

That is the same failure mode that produces compromised web servers, scaled up to cloud accounts. Secrets get published, nobody rotates them, and years later they still open the door. A hosting control panel password reused on a breached forum in 2023 works exactly the same way in 2026 unless somebody changes it. Attackers do not need a zero day to build a network of compromised web servers when 88 percent of the old keys still work.

Why Attackers Now Prefer Compromised Web Servers

Renting infrastructure is a liability for a threat actor, and compromised web servers remove almost every drawback. Domains get registered, paid for and eventually attributed. Hosting providers respond to abuse reports and pull accounts. Reputation systems flag freshly registered domains within hours. Compromised web servers solve all of those problems at once, because the domain is years old, the certificate is valid, the WHOIS record points at a real company, and the abuse desk has no complaints on file.

There is a second advantage that matters more in targeted espionage than in commodity crime. Defense contractors and aerospace suppliers run outbound filtering. Traffic to an anonymous VPS in an unusual jurisdiction gets questioned. Traffic to a European retailer running PrestaShop does not. The compromised web servers in this campaign were chosen precisely because they look boring, and boring is the most valuable property attacker infrastructure can have.

What It Costs the Site Owner

Site owners caught in this rarely see data theft on their own systems. What they get instead is blocklisting, deliverability collapse when their sending domain lands on a threat feed, and in the worst cases a law enforcement request pointing at their hosting account. Cleanup on compromised web servers means finding a web shell that was designed not to look like one, which is considerably harder than removing a defacement.

Advisories That Landed in the Same Window

The Lazarus disclosure did not arrive in isolation. WordPress published a core security release on 7 August 2026 covering a chain nicknamed XSS2Shell that takes an unauthenticated attacker from a reflected cross site scripting flaw on the login screen to remote code execution, then shipped a second core security release just five days later on 12 August. Around the same date, the Apache Software Foundation released apr-util 1.6.4 to fix two heap buffer overflows, CVE-2026-34501 in the Redis client and CVE-2026-34502 in the memcached client, both of which sit under a great deal of shared hosting.

Read together with the Check Point findings, the pattern behind compromised web servers is clear enough. Remote code execution paths into public facing PHP applications keep appearing, patched credentials keep circulating, and the population of reachable compromised web servers keeps replenishing itself. Our earlier coverage of plugin vulnerability disclosures traced the same cycle through the plugin ecosystem, where the gap between a published fix and an applied one is where most breaches actually live.

How to Tell Whether Your Site Is Being Used

Because RelayShell hides in normal web activity, the checks that separate healthy sites from compromised web servers are unglamorous. Compare your document root against a known good copy or a recent backup and look for PHP files that were modified outside your deployment window, especially in uploads, cache and vendor directories where nobody looks. Watch for unfamiliar plain text files with random names sitting next to legitimate scripts, since the file based messaging pattern leaves them behind. Review access logs for repeated POST requests to a single obscure path from a narrow set of addresses.

Then close the doors that turned the earlier victims into compromised web servers. Patch Roundcube, WordPress core and PrestaShop to current versions rather than to the version that was current when you launched. Rotate every credential attached to the account, including control panel, FTP, database and any API keys stored in configuration files, and treat any secret that ever touched a public repository as burned. The same server security hardening steps that stop opportunistic scanning also remove the easiest paths into compromised web servers.

Detail from the original research is worth reading directly if you administer public facing PHP applications, and The Hacker News writeup covers the full exploitation chain including the Windows side.

What Your Host Should Be Doing About It

Server level defense against compromised web servers is not something a site owner can install as a plugin. Account isolation stops one hijacked site on a shared machine from reaching its neighbors, which matters enormously when compromised web servers are being harvested at scale. Modern PHP versions with current security patches close whole families of exploitation paths. Outbound connection controls, mod_security rules and automatic malware scanning at the server layer catch the kind of shells that turn hosting accounts into compromised web servers, shells that a site owner would never notice. At MonsterMegs those protections run by default across our LiteSpeed powered web hosting plans, because the alternative is asking every customer to become a security analyst.

Ask your current provider three direct questions: how are accounts isolated from each other, what happens when malware is detected in an account, and how quickly do server side packages get patched after a CVE lands. Vague answers are an answer.

The Takeaway

Three things are worth carrying out of this story. Attackers have shifted from renting infrastructure to harvesting compromised web servers, which makes ordinary business websites strategically useful rather than merely opportunistic targets. The entry points remain mundane, with a year old unpatched CVE and purchased credentials doing the work that a zero day gets credit for. And the 88 percent figure on those leaked AWS keys shows that unrotated secrets stay dangerous for years, not weeks.

If you are not confident your current setup would catch a quiet PHP web shell, moving to a platform with account isolation and server level malware scanning built in is a reasonable next step, and our managed WordPress hosting handles the patching and monitoring side for you.

Cloud Infrastructure Spending Hits a New Eight Year High

MonsterMegs — Fri, 21 Aug 2026 20:01:19 +0000

Originally published at https://monstermegs.com/blog/cloud-infrastructure-spending/

Cloud infrastructure spending hit $143 billion in a single quarter, and almost none of that money went toward making your website load faster. Synergy Research Group published its Q2 2026 figures on August 3, showing the eleventh consecutive quarter of growth in cloud infrastructure spending, with artificial intelligence workloads absorbing the overwhelming share of the increase. If you run a WordPress site, an online store, or a portfolio of client websites, that number matters more than it first appears, because the capacity race behind it is quietly reshaping which hardware reaches ordinary hosting servers and how quickly it gets there.

Why Cloud Infrastructure Spending Just Broke Records

The standout figure is a $43 billion year over year jump, the largest single increase Synergy has recorded in this market. Across those eleven quarters, the cloud market has doubled in size. Generative AI cloud services grew 165 percent year over year, a pace nothing else in the sector approaches. John Dinsdale, chief analyst at Synergy Research Group, summarized it plainly: “AI technology has lit a fire under the cloud market and is now driving unprecedented growth.”

The geographic split is just as lopsided. Cloud infrastructure spending in the United States grew 49 percent in Q2, comfortably ahead of the worldwide average, while India, Ireland, Indonesia and Thailand posted the fastest national growth rates. ITPro's breakdown of the Synergy data covers the regional detail. The through line is that cloud infrastructure spending is now concentrated in a handful of countries with the power grids and permitting speed to support it.

How the big three actually fared

AWS held 28 percent of the market in the quarter, Microsoft 20 percent and Google Cloud 15 percent. Amazon retains a clear lead, but its share has drifted down for several quarters even as absolute revenue climbs, because a growing slice of cloud infrastructure spending is landing with providers that barely registered two years ago. Share is being diluted by new entrants rather than lost to established rivals, which is an unusual pattern in a maturing market and one worth watching closely.

Nine Neoclouds Now Sit in the Global Top Forty

Synergy's most interesting finding is not about the leaders at all. Nine neocloud companies, GPU first providers built specifically for AI training and inference, now rank among the world's forty largest cloud providers. These are firms with narrow product lines, aggressive leasing strategies and almost no presence in the general purpose hosting market that most website owners actually rely on day to day.

Nebius Group illustrates the trend. In August it launched a European AI infrastructure company headquartered in Amsterdam, focused on full stack GPU clusters and developer tooling rather than the storage, databases and virtual machines traditional providers sell. Every dollar of cloud infrastructure spending routed to a specialist like that is a dollar not buying commodity compute for everyone else. That redirection is the quiet story inside the cloud infrastructure spending numbers.

The August Buildout Behind the Numbers

Quarterly figures stay abstract until you look at what is being poured. Data Center Knowledge's August roundup lists Meta breaking ground on a one gigawatt AI campus in Sturgeon County, Alberta, backed by more than $9 billion, alongside an expansion of its five gigawatt Hyperion supercluster in northeast Louisiana. OpenAI disclosed Project Camellia in Effingham County, Georgia, at 3,210 megawatts. Google's Project Tembo in Cheyenne, Wyoming, is planned at 2.7 gigawatts.

The international entries are no smaller. ByteDance committed $38.4 billion to a campus at Brazil's Pecem port complex, starting at 200 megawatts with room to reach roughly one gigawatt. Mitsubishi Estate announced $9.3 billion for 2.5 gigawatts of Japanese capacity. The full August project list at Data Center Knowledge runs far longer. Together these projects show where record cloud infrastructure spending physically ends up.

Europe and Asia are scaling too

This is not a North American story alone. Pure Data Centres Group is building in Seinajoki, Finland, with a 110 megawatt first phase worth 1.5 billion euros and headroom to pass 550 megawatts. EdgeMode announced a 3 billion euro, 300 megawatt project in Mora, central Spain. AWS confirmed a Hyderabad expansion inside a $48 billion India commitment, of which $21 billion is earmarked for cloud and AI infrastructure between 2026 and 2030. DayOne and Firmus are developing a 360 megawatt campus on Indonesia's Batam Island. Those four announcements alone represent a meaningful slice of forward cloud infrastructure spending.

What Cloud Infrastructure Spending Does Not Buy Website Owners

Here is the part that gets lost in the headlines. A gigawatt of GPU capacity does nothing for a WooCommerce checkout. The workloads driving cloud infrastructure spending are training runs and inference endpoints, and they run on hardware profiles with very little overlap with what a busy PHP application needs. Your site wants fast single thread CPU, low latency NVMe storage, generous memory and a web server that handles concurrency efficiently.

GPU capacity is not web capacity

None of this record cloud infrastructure spending changes the physics of a slow database query or an unoptimized theme. It does, however, compete for the same supply chain: memory, power distribution, cooling, skilled data center staff and construction timelines. When AI campuses absorb that supply, refresh cycles for conventional hosting fleets can stretch, which is exactly why NVMe storage performance and efficient server software matter more now, not less.

Power Has Become the Real Constraint

Read the August announcements closely and the pattern is unmistakable. Brookfield and NextEra are building a 1.2 gigawatt campus on the former Department of Energy site in Paducah, Kentucky, with dedicated on site generation. Firmus signed a 600 megawatt, twelve year energy agreement with Gunvor Group for its Southgate project in Australia. Developers are no longer simply leasing space, they are procuring electricity years in advance.

Notice what those deals share: dedicated generation, decade long energy agreements, and sites chosen for grid access rather than proximity to users. Crusoe leased another 100 megawatts across three sites in Israel this month as part of a $10 billion plan spanning ten to fifteen years. When capital commits on that timescale, it is not chasing a temporary spike, it is betting the demand is structural. That assumption is what current cloud infrastructure spending forecasts rest on.

That shift has a knock on effect for everyone else. Grid capacity in established hosting regions is finite, and when hyperscale cloud infrastructure spending locks up interconnection queues, smaller operators wait longer to expand. It is one reason efficiency at the software layer, rather than simply racking more servers, has become the practical route to better performance for normal websites.

Concentration Risk Is Growing With the Spend

The other consequence of record cloud infrastructure spending is concentration. AWS, Microsoft and Google now account for 63 percent of the market between them, so a single control plane failure carries an outsized blast radius. Site owners watched that dynamic play out during July's cloud outages, when dependent services failed in sequence across completely unrelated businesses.

More money in the system does not automatically mean more resilience. It often means more shared dependencies: the same DNS providers, the same identity services, the same handful of regions. Diversifying where your DNS, backups and email live remains a cheap hedge against a failure you have no ability to control or even see coming.

What Site Owners Should Do About Cloud Infrastructure Spending

Do not chase the trend. Almost nothing in this quarter's cloud infrastructure spending report suggests a typical business site, blog or store should move to a hyperscaler. Respond instead to what the data reveals. Assume hardware refreshes may run slower industry wide, so choose a host already running current generation NVMe and a performance web server such as LiteSpeed, rather than one promising an upgrade sometime next year.

Then treat concentration risk seriously. Keep off site backups with a provider that is not your primary host, and know your DNS failover plan before you need it. Finally, spend your own optimization budget where it returns most: caching, image handling, database cleanup and PHP version currency. Those changes routinely deliver more measurable speed than any migration prompted by cloud infrastructure spending headlines.

None of that requires reacting to a quarterly report. The useful posture toward cloud infrastructure spending news is to read it as a supply signal, not a shopping list. Check which generation of storage and CPU your current plan actually runs on, confirm your backups restore cleanly, and measure your real world load times before and after any change you make.

The Takeaway

Three things stand out. Cloud infrastructure spending reached $143 billion in Q2 2026 because of AI, not because general web hosting demand exploded. That buildout competes for the power, hardware and skilled labor ordinary hosting depends on. And the more the market concentrates, the more valuable independent, well tuned infrastructure and a real support team become.

If you would rather run on current generation hardware than wait for the industry to finish chasing gigawatts, MonsterMegs builds its LiteSpeed NVMe hosting plans around exactly that idea.

How Reseller Hosting for Agencies Builds Recurring Revenue

MonsterMegs — Wed, 19 Aug 2026 20:01:23 +0000

Originally published at https://monstermegs.com/blog/reseller-hosting-for-agencies-3/

An agency that launches ten client sites a year and hands each one off to a random host is walking away from thousands of dollars in recurring revenue every single year. Reseller hosting for agencies closes that gap. Instead of pointing clients toward whoever ran the cheapest ad that week, you buy server resources once, carve them into individual client accounts, and bill for hosting under your own brand. The setup work happens once. The revenue arrives every month, whether or not you shipped a new design that quarter.

This guide covers what reseller hosting for agencies actually includes, how to size your first plan, how to price it, and where the model stops making sense. No fluff, no theory, just the decisions you will face in your first ninety days.

Why Reseller Hosting for Agencies Beats Referral Commissions

Most agencies start with referrals. You send a client to a host, collect a one-time commission of maybe forty dollars, and never think about it again. Then the client calls you anyway when their contact form breaks, because you built the site and you are the only technical person they know. You end up doing the support work without any of the revenue.

Reseller hosting for agencies inverts that arrangement. You own the billing relationship, so the twenty dollars a month a client would have paid elsewhere lands in your account instead. Ten clients at that rate is $2,400 a year from work you were already doing for free. Thirty clients is real money, and it arrives on the first of the month regardless of whether your project pipeline is full.

There is a retention argument for reseller hosting for agencies too. Clients who host with you rarely leave quietly. Moving away means moving their site, their email, and their DNS, which is friction that keeps relationships alive through slow quarters.

What a Reseller Account Actually Includes

Reseller hosting for agencies gives you a WHM control panel sitting above a set of individual cPanel accounts. WHM is where you create accounts, set resource limits, suspend nonpayers, and manage DNS. Each client gets their own cPanel login, their own file space, and their own databases, fully isolated from every other account you host.

You also get white label control. Nameservers run on your own domain, cPanel branding can carry your logo, and client-facing emails come from your address. Most clients never learn who runs the underlying hardware, which is exactly the point of reseller hosting for agencies.

The resources that actually matter

Storage and bandwidth are the numbers hosts advertise, but they are almost never the constraint. What limits a reseller account in practice is CPU, memory, and the number of simultaneous PHP processes each site can use. A single badly built WooCommerce store can consume more server capacity than twenty brochure sites combined. When comparing reseller hosting plans, read the resource limits before you read the storage figures.

Sizing Your First Reseller Plan

Start smaller than you think. The instinct is to buy capacity for the agency you want to be in three years, but reseller plans upgrade in minutes and hosts prorate the difference. Paying for headroom you will not touch for eighteen months is just a slow leak.

A practical rule: budget roughly one gigabyte of storage per small business site, then double it if the client uploads video or runs a photo-heavy portfolio. For a first plan, capacity for fifteen to twenty-five accounts covers most agencies through their first full year of reseller hosting for agencies work.

Server location matters more than most people expect when you start reseller hosting for agencies. Pick a data center near the majority of your clients' visitors, because every hundred milliseconds of latency shows up in Core Web Vitals scores that your clients will eventually ask you about.

How to Price Reseller Hosting for Agencies

Pricing is where most agencies undercharge badly. They look at their reseller plan cost, divide it by the number of clients, add a small margin, and land somewhere around eight dollars a month. That price signals “commodity” and buys you a support obligation with no cushion.

Price on value instead. Your clients are not buying disk space, they are buying the confidence that their site stays online and someone competent answers when it does not. A reasonable structure for reseller hosting for agencies looks like three tiers: a basic plan around twenty dollars a month for brochure sites, a business plan near forty for sites with email and light e-commerce, and a managed tier at eighty or more that bundles updates, backups, and monitoring.

The margin math on reseller hosting for agencies works out well. A reseller plan costing thirty dollars a month spread across twenty accounts at twenty-five dollars each produces roughly $470 in monthly profit, and that number climbs every time you add a client without adding server cost.

Bill annually where you can

Annual billing cuts your churn, eliminates eleven failed-payment emails a year, and gets cash in the door up front. Offer two months free for annual prepayment and most small business clients take it without negotiating.

Building Packages in WHM Before Your First Client

Create your hosting packages in WHM before you sell anything. A package is a saved template of limits, so provisioning a new client becomes a thirty-second task rather than a form full of decisions. Build one package per pricing tier and name them to match what clients see on your invoice.

Set realistic limits rather than unlimited ones. Capping databases, email accounts, and subdomains protects the whole account from one client's runaway plugin, and it gives you an obvious, non-awkward reason to move a growing client up a tier. The official cPanel package documentation walks through each field if you are setting up reseller hosting for agencies for the first time.

Decide your DNS approach early too. Running your own branded nameservers looks more professional and makes future host changes invisible to clients, which is worth the ten minutes of setup.

Moving Existing Client Sites Onto Your Account

Most agencies already have a backlog of client sites scattered across four or five different hosts. Consolidating them is the fastest way to make reseller hosting for agencies pay for itself, and it is usually less painful than it sounds because most quality hosts migrate cPanel accounts for free.

Work through the list oldest and simplest first so you build a repeatable routine before you touch anything fragile. Always lower the DNS TTL a day ahead, verify the site on a temporary URL before switching, and keep the old account alive for a week. Our guide to migrating client sites covers the full sequence step by step.

This is also a natural moment to consolidate client domains under one registrar account. If you manage names for a dozen clients, a bulk domain search makes registering and renewing them far less tedious than logging into six different panels.

Setting Support Expectations That You Can Keep

The fear that stops agencies from reselling is support. What if a client calls at midnight? In practice, the support load splits cleanly into two categories. Server-level problems go to your host, and any host worth using handles those around the clock without involving you. Everything else is application-level: a broken plugin, a full mailbox, a forgotten password.

Write your support boundaries into the hosting agreement before the first invoice. Define what is included, define what is billable, and give clients a single channel to reach you. Agencies that run reseller hosting for agencies profitably are almost always the ones who set those boundaries in writing on day one.

Lean on your upstream host for the hard parts. Fast, knowledgeable support from your provider is the single feature that determines whether reseller hosting for agencies feels like a revenue stream or a second job. At MonsterMegs, that means LiteSpeed and NVMe infrastructure with a team that answers server questions directly, so you are never the only person awake when something breaks.

Where Reseller Hosting for Agencies Hits Its Limits

The model is not universal. Reseller accounts share a server, so a single high-traffic store doing serious volume belongs on a semi-dedicated plan of its own rather than inside your shared pool. Clients with custom server software, unusual PHP extensions, or strict compliance requirements also fall outside what reseller hosting for agencies can offer.

Scale changes the math as well. Past roughly a hundred accounts, most agencies find that dedicated infrastructure costs less per site and gives them room to tune the stack. That is a good problem, and it typically arrives years after your first reseller plan.

One more consideration: platform concentration. WordPress powers 41.2% of all websites according to W3Techs, so most agency portfolios are heavily WordPress-weighted. That makes server-level caching and PHP tuning worth checking carefully before you commit to reseller hosting for agencies, because those settings affect every client site you host at once.

Where to Go From Here

Three things matter most if you take this on. Size your first plan for the next year rather than the next decade, because upgrades are easy and wasted capacity is not. Price on value instead of dividing your costs, since a twenty-five dollar plan with clear boundaries beats an eight dollar plan that quietly buys unlimited support. And put your support terms in writing before the first client account exists.

Reseller hosting for agencies rewards preparation more than scale. Get the packages, pricing, and boundaries right with your first three clients, and the next thirty are mostly repetition. When you are ready to start, MonsterMegs offers reseller hosting built on LiteSpeed and NVMe so your clients' sites stay fast while you focus on the work you were hired to do.

PHP Stack Hardening Lands in New Release Candidates

MonsterMegs — Mon, 17 Aug 2026 20:01:17 +0000

Originally published at https://monstermegs.com/blog/php-stack-hardening/

Seven out of every ten websites whose server language we can identify are running PHP, which means a stack overflow bug in the interpreter is never just a PHP problem. On August 11, 2026, the PHP project shipped release candidates for PHP 8.4.25 and 8.5.10, and the headline change in both is PHP stack hardening: real recursion depth limits inside functions that could previously chew through an entire thread stack and take the process down with them. For anyone running a site on shared, reseller, or semi-dedicated hosting, this is the quiet kind of fix that decides whether a malformed request returns a clean error or knocks your whole PHP worker pool offline.

Inside the August Release Candidates

Both actively supported branches got the same treatment on the same day. PHP 8.4.25 RC1 and PHP 8.5.10 RC1 landed together on August 11, carrying a patch set that reads less like a feature drop and more like a structural audit. The PHP stack hardening work is the centerpiece, but it arrives bundled with a run of memory safety corrections across core extensions.

The timing follows a busy summer. On July 30, the project pushed security releases across four branches at once: PHP 8.5.9, 8.4.24, 8.3.33, and 8.2.33. Those builds closed CVE level holes including an out of bounds write in BCMath, a backslash breakout in the PGSQL extension, and a signed integer overflow in the standard extension. You can walk the full sequence in the official PHP news archive for 2026.

What PHP Stack Hardening Actually Changes

Stack overflows in a scripting engine are an awkward class of bug. They are rarely exploitable in the classic sense, but they are trivially reachable, and the result is a hard process crash rather than a caught exception. That is why PHP stack hardening matters more than its low profile suggests: it converts an uncontrolled crash into a controlled error the runtime can report.

The functions that got recursion limits

The RC patch sets add explicit recursion depth limits to the usual suspects. That list includes array_walk_recursive(), array_replace_recursive(), compact(), and a set of DOM operations that could previously recurse without a ceiling. Each of these can be handed a deeply nested or self referencing structure, and until now the only thing stopping the descent was the size of the stack itself.

From segfault to catchable error

The practical effect of PHP stack hardening is a change in failure mode. Instead of a segmentation fault that kills the worker and shows up in your error log as an abrupt termination, the engine now raises a proper error at a defined depth. Your monitoring sees something actionable. Your other requests keep serving. On a busy server, that difference is the difference between one failed request and a cascade.

The Memory Safety Fixes Riding Along

PHP stack hardening is the story, but it is not the whole patch set. The release candidates also resolve use after free issues in implode(), the XSL extension, user stream filters, and the sockets extension. Use after free bugs are the more serious category here, because they touch memory that has already been released and can produce genuinely unpredictable behavior under the right conditions.

Further down the changelog sit fixes that matter to anyone running PHP at scale: a JIT deoptimizer register preservation bug, session heap corruption in mod_mm, a PCRE UTF-8 handling problem with the \C token, infinite loops in PDO_PGSQL during COPY cleanup, null byte truncation in Reflection exception messages, and incorrect MBString position calculations for negative offsets. Individually these are edge cases. Collectively they are the reason release candidates exist.

Why PHP Stack Hardening Matters on Shared Servers

On a single tenant box, a crashed PHP worker is your problem alone. On a shared or reseller server, process level crashes are noisier neighbors than most people realize. A request that reliably kills a worker becomes a cheap denial of service primitive: no exploit chain required, just a nested payload and a loop. PHP stack hardening removes that primitive from the shelf.

Scale explains the urgency. According to W3Techs, PHP powers 70.3 percent of websites with a known server side language as of August 2026. Of those, 63.1 percent run PHP 8, 28.9 percent are still on PHP 7, and 7.9 percent are sitting on PHP 5. That last figure is the uncomfortable one, because PHP stack hardening and every other fix in this cycle only reach servers that are actually on a supported branch.

PHP 8.6 Beta 1 Lands Two Days Later

Two days after the release candidates, on August 13, the project shipped PHP 8.6.0 Beta 1, with Beta 2 scheduled for August 27. That follows an alpha cadence that ran through July with Alpha 1 on July 2, Alpha 2 on July 16, and Alpha 3 on July 30. None of these are production builds, and the project is explicit about that.

The overlap is worth noticing. The same engineering effort that produced PHP stack hardening in the stable branches is being carried forward into 8.6 rather than left as a backport. Hardening work that only lands in maintenance releases tends to erode; hardening that ships in the development branch tends to stay.

How Hosts Actually Roll Out PHP Stack Hardening

There is a gap between a release candidate on php.net and the binary answering requests on your server, and it is worth understanding who closes it. Most cPanel and CloudLinux environments distribute PHP through packaged builds rather than compiling from source, so PHP stack hardening reaches customers when the packager cuts a build against the new stable tag. That usually happens within days of the final release, not the release candidate.

What that means in practice is that you rarely install this yourself. You select a branch, and your host supplies the patched build for it. The catch is that selection is sticky. A domain pinned to PHP 8.1 in 2023 stays pinned until somebody changes it, and no amount of PHP stack hardening upstream will help a site parked on a branch that stopped receiving builds.

This is also why per domain version switching matters more than raw version availability. If a single legacy application forces an old branch, you want the ability to isolate that one site rather than hold every other account back with it. Check your control panel now rather than the next time an advisory lands.

Support Windows Are the Real Deadline

PHP 8.4 has active support running through August 2027 and security fixes through August 2029. PHP 8.5 extends further, with support into 2028 and security patches expected through 2030. PHP 8.2 has already dropped into maintenance status, meaning security fixes only. PHP 8.3 remains actively supported and received its own security build on July 30.

If your site sits on PHP 8.2 or older, you are outside the group that receives improvements like PHP stack hardening. Security backports are narrower than general hardening by design. The branch you run determines which class of protection you get, and that is a hosting decision as much as a development one. Our earlier writeup on why PHP security updates matter covers the upgrade mechanics in more detail.

Responding to the PHP Stack Hardening Release

Nothing here demands a panicked overnight deployment. Release candidates are for testing, not production, and the stable builds carrying PHP stack hardening should follow within days to a week once the test matrix clears. What this news does justify is a short, specific set of checks this week.

Open your control panel and confirm which PHP version each domain is actually running. Sites migrated years ago frequently sit on a branch nobody has revisited. If anything is on 8.2 or below, plan the move to 8.4 or 8.5 now, while the jump is small. If you run recursive array helpers or DOM parsing against user supplied data, add a test with a deeply nested payload and see what your current build does with it. That single test tells you whether PHP stack hardening changes anything for your code.

Reseller and agency operators should extend the check across every account they manage, not just their own. The same discipline that applies to locking down a cPanel server applies here: the weakest branch on the box sets the floor. Managed platforms handle most of this for you, which is why LiteSpeed powered hosting plans at MonsterMegs keep current PHP branches available and switchable per domain from cPanel.

The Takeaway

Three things are worth carrying away from this cycle. First, PHP stack hardening turns a whole class of crash bugs into reportable errors, which is a meaningful reliability gain on any multi tenant server. Second, the memory safety fixes shipping alongside it are the more traditional security story, and they reached stable users at the end of July. Third, none of this protection reaches you if you are running an unsupported branch, and roughly a third of PHP sites still are.

If you want PHP stack hardening and every future fix to reach your site by default, running on a platform that keeps supported PHP branches one click away is the simplest place to start, and MonsterMegs semi dedicated hosting gives busy sites the isolated resources to absorb a bad request without taking neighbors down with it.

What the ICANN New gTLD Round Means for Site Owners

MonsterMegs — Fri, 14 Aug 2026 20:01:17 +0000

Originally published at https://monstermegs.com/blog/icann-new-gtld-round/

The window is shut. At 23:59 UTC on August 12, 2026, ICANN stopped accepting applications for only the second expansion of the internet's top-level domain space in its history, ending a filing period that had been open for just 15 weeks. The ICANN new gTLD round has now moved into evaluation, and whatever was submitted before that cutoff is the entire pool of candidate extensions the web will get for years to come. If your organization was still weighing whether to apply, that decision has been made for you.

How the ICANN New gTLD Round Reached Its Deadline

Applications opened on April 30, 2026 and ran a little over three months. ICANN treated the closing date as immovable and said so publicly, issuing a formal reminder on July 13 that the window would shut on August 12 with no planned extension. Applicants who filed in time still had one obligation left: evaluation fees were due by August 19, a full week after submissions closed. Missing that payment does the same damage as missing the application deadline itself.

The timing matters because the ICANN new gTLD round is only the second of its kind. The first opened in 2012 and has never been repeated. Fourteen years passed between the two, and nothing in ICANN's published planning suggests a third round is anywhere close.

Who Applied and What It Cost Them

The base evaluation fee was $227,000 per application, according to reporting from CircleID. That number filters the applicant pool before a single string gets reviewed, and it only buys standard evaluation. Applications that draw formal objections, require extended technical review, or land in a contention set against rival applicants will run considerably higher, with no refund path once evaluation has begun.

The applicants that price attracts

At that cost, the ICANN new gTLD round is not a market for casual speculators. It is a market for brands that want a closed extension they alone control, for cities and regions, for communities with a shared identity, and for registry operators building portfolios they intend to sell into. Governments, corporations, nonprofits and community groups were all eligible, provided they could demonstrate sustained technical and financial capacity and survive a rigorous evaluation.

ICANN has publicly projected roughly 2,000 applications and built its schedule around that figure, estimating program completion somewhere near June 2030. Official statistics for the ICANN new gTLD round are still listed as coming soon on the program's own site, so the real submission count remains unpublished as of this week.

Twenty Seven Scripts and a Less Latin Internet

The most consequential change in this expansion has little to do with brands. ICANN accepted applications in 27 different scripts, including Arabic, Chinese, Devanagari and Thai, representing hundreds of languages. ICANN's own announcement framed this internationalized domain name expansion as the central purpose of the round rather than a secondary feature.

The practical result is that a user in Cairo, Delhi or Bangkok may soon reach a website without typing a single Latin character. That is a real shift for a naming system that has been overwhelmingly Latin since the day it was built, and it is the part of the ICANN new gTLD round most likely to change how the web looks outside English-speaking markets.

There is a technical footnote for site owners here. Internationalized domains are handled behind the scenes through punycode conversion, and modern hosting stacks, including the cPanel environment MonsterMegs runs, deal with that translation automatically. Older self-managed mail servers and legacy scripts are where the rough edges usually show up.

The Applicant Support Program Was an Early Signal

Before the main window opened, ICANN ran an Applicant Support Program offering heavy fee reductions to applicants from underserved regions, and its final numbers are worth reading closely. The program closed with 72 submitted applications, up from just 19 a month earlier. Asia Pacific accounted for 36 of them, North America 20, Africa 10, Europe 5, and Latin America and the Caribbean 1.

Two shifts stand out. Nonprofit applicants jumped from 9 to 33, and micro and small businesses in less developed economies climbed from 6 to 28. ICANN had capacity for roughly 40 to 45 supported applicants on a first come basis, so demand clearly outran the support available. Read across to the ICANN new gTLD round as a whole, the pattern points to a late surge of filings from applicants already in the pipeline rather than a wave of brand new entrants.

That distinction is worth holding onto. A round driven by applicants who were already committed looks very different from one driven by fresh demand, and it tempers expectations for how many genuinely novel extensions the ICANN new gTLD round will ultimately produce.

What Happens Next in the ICANN New gTLD Round

Evaluation starts now. ICANN will assess every application for technical, financial and operational readiness, and will run a parallel evaluation track for Registry Service Providers, the backend operators that actually keep a registry's infrastructure online. Applications that pass move toward contracting and delegation. Applications that stumble can enter extended evaluation rather than being rejected outright, which is one reason the ICANN new gTLD round is measured in years rather than months.

Contention sets and auctions

Where two or more applicants requested the same string, ICANN routes the conflict into a contention set. Applicants are encouraged to resolve it privately, and sets that stay deadlocked can end at auction. The 2012 round produced some eye-watering results through that mechanism, and it is live again in the ICANN new gTLD round. With ICANN's completion estimate sitting near 2030, the first delegations from this round are unlikely to reach registrars for a long while.

Why the 2012 Round Still Shapes This One

The first expansion delegated more than 1,200 new extensions, running from .app and .blog through to .pharmacy and .cologne. A handful became genuinely mainstream. Others were delegated and then went essentially nowhere, and a number of brand extensions were quietly handed back to ICANN once their owners lost interest in operating a registry.

That track record is the best available guide to the ICANN new gTLD round. Registering under a brand new extension is a bet that the registry operator stays invested for a decade. The 2012 extensions that worked were the ones with a clear audience, sane pricing and a registry that kept promoting them long after launch day. For a read on which have actually stuck, our roundup of new domain extensions covers the endings seeing real registration volume today.

What the ICANN New gTLD Round Means for Your Website

If you already own a domain, nothing breaks. Your site keeps resolving, your email keeps flowing, your SSL certificate stays valid. The ICANN new gTLD round adds capacity to the naming system without disturbing anything already registered inside it. Google has said repeatedly that the extension itself is not a ranking factor, so a .com does not quietly lose ground because a new string gets delegated in 2029.

The real effects arrive slowly. Over the next several years the extension you register under will carry more signal than it does today, simply because visitors will be reading a wider range of endings without blinking. Brand owners with recognizable names also gain more surface area to monitor, since every delegated extension is another namespace where somebody can register a string that looks like yours.

What Site Owners Should Do Right Now

Nothing is urgent, but two tasks are worth an hour. First, watch for ICANN to publish the applied-for strings list, which will be the first genuine disclosure of what the ICANN new gTLD round actually contains and whether anything in your industry was requested. Second, audit which extensions currently carry your brand. Agencies and businesses protecting a name across several endings usually find a bulk domain search far quicker than checking one registration at a time.

Watch renewal pricing, not launch hype

New extensions frequently launch with promotional first-year pricing and much steeper renewals from year two onward. Read the renewal rate before you attach a brand to a string. That rule held right through the 2012 wave and it will hold through everything the ICANN new gTLD round eventually delivers.

Where to Go From Here

Three things to carry away. The ICANN new gTLD round closed on August 12 and will not reopen, with evaluation now stretching toward the end of the decade. The 27-script internationalized expansion is the genuinely important story here, not the brand extensions that draw the headlines. And for existing site owners, the right posture is patience plus a quick brand audit, not panic.

When new strings finally start landing, the practical question becomes which ones deserve your money, and browsing the newest TLDs already live at MonsterMegs is a sensible place to start while the 2026 applications work through evaluation.