Category: WordPress

WordPress 7.1.3 Security Release: What Changed and How to Confirm Your Site Has It

WordPress 7.1.3 Security Release: What Changed and Who Can Reach It
- WordPress 7.1.3 Security Release Facts From WordPress.org and Patchstack
Does the WordPress 7.1.3 Security Release Apply to Your Site?
Did the WordPress 7.1.3 Security Release Reach Your Site Automatically?
- What Blocks Automatic Updates in WordPress Core
Lab Results: WordPress 7.1.2 Against 7.1.3
The Comment Disclosure Fix in the WordPress 7.1.3 Security Release
The Sticky Post Fix and Who Holds Author Roles
The make_absolute_url() Loop That Never Ended
The Image Upload Bug in the WordPress 7.1.3 Security Release
Imgur Embeds After the WordPress 7.1.3 Security Release
What I Could Not Tie to Code
Who Applies the WordPress 7.1.3 Security Release: Shared Hosting, VPS or You?
- Shared Hosting: The Host Patches Packages, You Verify WordPress
- VPS and WooCommerce: You Verify Both Layers
Frequently Asked Questions: WordPress 7.1.3 Security Release

TL;DR

The WordPress 7.1.3 security release shipped on 6 October 2026 with seven security fixes and four bug fixes. Read your version under Tools, Site Health, Info, WordPress; 7.1.2 or any earlier 7.1 release needs the update. Minor releases install themselves by default, but a handful of switches stop that. In my lab, 7.1.2 handed an anonymous visitor the comments on a private post and a draft post and let an Author account make posts sticky; 7.1.3 refused both. WordPress published no CVE IDs, and none of the coverage I opened reports exploitation.

Listen: what the seven fixes change, what a lab run of 7.1.2 against 7.1.3 showed, and how to check your site. By Matt Chrust, Director of Business Development, AHosting.

WordPress 7.1.3 Security Release: What Changed and Who Can Reach It

The WordPress 7.1.3 security release shipped on 6 October 2026 with seven security fixes and four bug fixes. WordPress.org recommends updating immediately. This guide reads the release the way a host does. It checks whether the update reached your site, and it compares the real code of 7.1.2 and 7.1.3 file by file. Every fact below is dated 23 October 2026.

Seven fixes sounds like a lot of change, but the change is small. I downloaded both official archives and compared them: 15 files differ, and 9 of those are PHP. The rest are one admin script with its minified copy, four admin bar style sheets and the version number.

WordPress 7.1.3 Security Release Facts From WordPress.org and Patchstack

WordPress.org lists the seven fixes and credits each reporter in its version 7.1.3 notes.
The same notes say older branches get the fixes as a courtesy, and only the newest version is actively supported.
Patchstack, which wrote the most detailed analysis of the seven fixes, says only two of them can start from a visitor with no login.
WordPress assigned no CVE IDs and published no severity scores for these fixes, and SecurityOnline reports no confirmed exploitation and no public proof of concept.

Fix as WordPress lists it	Who can reach it (Patchstack)	Changed file in 7.1.3	What the diff shows
Stored XSS on the Comments admin screen	A visitor posts a pending comment; a moderator must click its link	Not found in the diff	I could not tie it to a changed line
Denial of service in WP_Http::make_absolute_url()	Contributor or higher	class-wp-http.php	A loop now stops when a pass removes nothing
Second-order SQL injection in the WXR export	An administrator running an export, plus a bad stored thumbnail value	export.php	IDs are cast to integers with absint() in three places
Author role can make posts sticky	Author or higher	class-wp-rest-posts-controller.php	An AND in the permission check became an OR
Comments on private and unpublished posts disclosed	Anyone, no login	class-wp-query.php	The comment feed query moves below the post status check
Imgur embeds vulnerable to XSS	Contributor or higher, plus a viewer	class-wp-oembed.php	Imgur is dropped from the trusted provider list
Hook name collision in the status and type hooks	Needs a plugin that passes raw values	post.php	The hooks fire only for registered statuses and types

AHosting WordPress 7.1.3 Fix-to-Code Map. Reach: Patchstack. Diff: my comparison of the official archives.

Does the WordPress 7.1.3 Security Release Apply to Your Site?

If your site reports 7.1.2 or any earlier 7.1 version, it needs 7.1.3. Patchstack says the Comments screen XSS affects 7.1.0 through 7.1.2, and SecurityOnline says every version before 7.1.3 is affected. The comment disclosure fix exists only from 7.1.3 on, as the lab results below show.

Older branches depend on backports. WordPress.org said they were still in progress when it published, and Patchstack reported fixes available through at least 6.6 on 6 October, with branches 4.7 through 6.5 not yet patched at that point. Check Dashboard, then Updates, for a patch release on your own branch.

Read your version in one of three places. Tools, then Site Health, then Info, then WordPress shows it. In cPanel File Manager, open wp-includes/version.php and read the wp_version line. With WP-CLI, the command wp core version prints it. The checker below turns that number into a next step.

WordPress 7.1.3 Security Release Update Check

Which WordPress version does your site report? How do core updates reach your site?

Choose your version and how updates run, then select the button.

See WordPress hosting plans

Did the WordPress 7.1.3 Security Release Reach Your Site Automatically?

Possibly, because WordPress installs minor releases by default. The WordPress upgrade documentation says existing installations receive minor core updates, such as maintenance and security releases, unless you change that.

I tested it. On 23 October 2026 I built a fresh WordPress 7.1.2 site on my workstation with default settings. Within a few minutes it had replaced its own core files and reported 7.1.3. That was one machine with outbound network access, not an AHosting server, so treat it as proof that the mechanism works, not as a promise about any particular site.

A second 7.1.2 site, built with automatic core updates switched off, stayed on 7.1.2 for the whole test. That is the state of any site where something blocks the updater, and it is the state in which this release never arrives.

What Blocks Automatic Updates in WordPress Core

I read the updater in the WordPress 7.1.3 source. The blockers are specific, and most of them are choices someone made once and forgot.

Blocker	Where WordPress checks it	How a site ends up with it
WP_AUTO_UPDATE_CORE set to false in wp-config.php	Documented core setting	Someone froze core after a bad update
AUTOMATIC_UPDATER_DISABLED set to true	class-wp-automatic-updater.php, is_disabled()	A hardening guide or a staging copy
The automatic_updater_disabled filter returns true	The same function, one line later	A plugin or a must-use plugin
DISALLOW_FILE_MODS set to true	wp_is_file_mod_allowed() in load.php	A locked-down production setup
A .git, .svn, .hg or .bzr folder in the site folder or above it	class-wp-automatic-updater.php, is_vcs_checkout()	A site deployed from a repository
WP-Cron never runs	wp-includes/update.php starts the update only during a cron run	DISABLE_WP_CRON with no system cron behind it

Update blockers read from the WordPress 7.1.3 source, 23 October 2026.

Plugin and theme updates follow their own switches, which our post on auto-updating plugins and themes walks through. If any row above matches your site, press Update Now under Dashboard, then Updates, and do not wait for the updater.

Lab Results: WordPress 7.1.2 Against 7.1.3

Reading a diff tells you what changed. Running both versions tells you what it meant. I installed WordPress 7.1.2 and 7.1.3 side by side with the SQLite integration plugin from WordPress.org, then repeated the same requests against each.

Setup: one workstation, PHP 8.5.10, one private post, one draft post and one public post, each with an approved comment, plus an Author account. This is not an AHosting server, and I did not test the SQL injection, the Comments screen XSS or the hook collision.

Request	WordPress 7.1.2	WordPress 7.1.3
Anonymous request for the comment feed of the private post	Returned the comment	Empty feed
Anonymous request for the comment feed of the draft post	Returned the comment	Empty feed
Anonymous request for the site-wide comment feed	Public post comment only	Public post comment only
Author creates a published post with sticky set to true through the REST API	201 Created, post made sticky	403 rest_cannot_assign_sticky
Author marks an existing post of their own sticky	200 OK, post made sticky	403 rest_cannot_assign_sticky
make_absolute_url() with a crafted relative path	Ran until PHP time limit hit at 3 seconds	Returned at once
oEmbed provider lookup for an imgur.com link	Mapped to the Imgur endpoint	No provider found

AHosting WordPress 7.1.2 vs 7.1.3 Lab Results, run 23 October 2026 on one workstation.

The Comment Disclosure Fix in the WordPress 7.1.3 Security Release

This is the fix that needs no login. In 7.1.2, an anonymous request for the comment feed of a single post returned the comments of a private post and of a draft post. WordPress had already built the comment list before it decided the visitor was not allowed to see the post.

The cause is an ordering problem in class-wp-query.php. In 7.1.2 the comment feed query runs first, and the post status check that empties the post list runs afterward, which is too late for the comments already loaded. The 7.1.3 diff moves the whole comment block below the status check, so a hidden post now produces an empty feed.

Two limits keep this in proportion. The comment must already be approved, which happens, for example, when it was approved before the post went private or when a logged-in editor replied. The visitor also needs the post ID, and those are sequential numbers. Neither limit makes the bug harmless on a site that keeps member-only or unreleased content.

The Sticky Post Fix and Who Holds Author Roles

The sticky bug is a one-operator logic error, and my lab reproduced it exactly. The REST posts controller refused the request only if the user lacked both the edit-others and the publish capability. An Author has the publish capability, so the check passed. 7.1.3 changed the AND to an OR.

The impact is modest: an Author could pin their own post to the top of the blog index. The lesson is wider. Patchstack warns that several of the seven fixes concern what Contributor and Author roles can reach, and recommends auditing who holds them. Our guide to open registration and the default role shows where a site quietly hands those roles out.

The update path changed too. 7.1.3 checks the sticky permission only when a request would change the sticky state, so an Author editing a post that is already sticky is not blocked.

The make_absolute_url() Loop That Never Ended

WordPress resolves relative redirect addresses with WP_Http::make_absolute_url(). It strips every segment-then-dot-dot pair with a regular expression, in a loop that runs while the path still contains the dot-dot sequence. In 7.1.2, if the expression matches nothing, the sequence never leaves and the loop never ends.

I tested a path of that shape against the real 7.1.2 function. It ran until PHP stopped it at my 3 second limit. The 7.1.3 version counts the replacements in each pass and exits the loop when the count is zero, and it answered at once. I am not printing the exact input.

The caller matters. In class-wp-http.php, redirect handling reads the Location header of a response and passes it to this function, so a site fetching a remote address that redirects can reach it. Patchstack says the attack needs a Contributor account or higher. A request stuck in that loop holds one PHP process until the time limit ends it, which is why the fix belongs in the update, not in a server setting.

The Image Upload Bug in the WordPress 7.1.3 Security Release

Four bug fixes ship beside the seven security fixes, and Search Engine Journal calls one of them critical, citing the WordPress ticket rating. Image uploads could fail with a fatal error on a server whose PHP lacks the DOM extension. It is not a security fix, but it breaks the Media Library.

The code explains it. The image helper wp_get_image_alttext() builds a DOMDocument to read the alternative text stored in a photo. In 7.1.2 it never checked that the class exists. The 7.1.3 diff adds that check at the top and returns an empty string instead. The function reaches the DOM code only when the file contains XMP metadata.

I did not reproduce the crash. The PHP on my machine has the extension built in, and the switch I tried to hide the class had no effect. Site Health lists the dom extension under PHP extensions as optional, so your own Info, Server tab shows whether your server has it. For the PHP side of the same server, see our guide to the best PHP version for WordPress in cPanel.

Imgur Embeds After the WordPress 7.1.3 Security Release

The Imgur fix removes the provider rather than patching it. In 7.1.2, WordPress mapped imgur.com links to the Imgur endpoint. In 7.1.3 my lookup found no provider for an imgur.com link. The class-wp-oembed.php docblock now lists Imgur, and two Someecards domains, among the providers no longer supported as of 7.1.3.

The oEmbed format works by asking a provider endpoint for HTML to place in your page, as the oEmbed specification describes. Patchstack explains that Imgur sat on the trusted list, so its output skipped the sandboxing filter.

Existing embeds are the catch. WordPress stores a fetched embed in post meta under keys that begin with _oembed_, and Patchstack warns the fix does not remove cached content already stored. Clear your page and object caches after updating, and search your posts for imgur.com links written by Contributor accounts.

What I Could Not Tie to Code

A guide that claims to have verified everything is lying. Here is what I could not verify. The stored XSS on the Comments admin screen, reported by Trail of Bits, has no changed line in the comments list table that I could find. The only admin script that changed is the help tab handler in common.js, and I will not call that the fix.

WordPress.org also lists two Customizer files among the revised files in its 7.1.3 notes. In the two archives I downloaded, both files are byte-identical. I cannot explain that difference, and I would rather say so than guess.

What I can say comes from Patchstack: the attack starts with a pending comment and needs a moderator to click a link in it. Until you update, moderators should not click links inside pending comments. The export SQL injection needs an administrator to run an export and a bad thumbnail value already stored, and the hook collision needs a plugin that passes raw values into post creation.

Who Applies the WordPress 7.1.3 Security Release: Shared Hosting, VPS or You?

WordPress core is your application, so the answer is mostly you on every kind of hosting. The host updates the server and the PHP packages. WordPress updates itself from inside your account, unless one of the blockers above stops it. Our PHP security update guide covers the server half of that split.

Shared Hosting: The Host Patches Packages, You Verify WordPress

On shared web hosting, your provider keeps the server software current, and you read the WordPress version. First-hand, the AHosting customer server we inspected runs CloudLinux 9 with CageFS and LVE, and its LiteSpeed PHP processes run as each site’s own cPanel user, 38 of them on 30 September 2026. That isolation keeps one account away from another. It does not stop a flaw inside a site from leaking that site’s own comments, which is why the update matters even with isolation in place.

VPS and WooCommerce: You Verify Both Layers

A WordPress VPS leaves package updates and WordPress updates to you, so check both versions. Stores deserve one extra step: update on staging, then run a test checkout on your WooCommerce hosting account before the live site. Agencies can read the version of every client site in one pass and update them together.

If the update does not appear, open a ticket with the WordPress version from Site Health and the PHP version from its Server tab, and we will look at it with you. Anyone on shared web hosting can open wp-includes/version.php in cPanel File Manager, the file this guide uses to read the version.

Frequently Asked Questions: WordPress 7.1.3 Security Release

Do I need the WordPress 7.1.3 security release on my site in 2026?

Specifically, yes if your site reports 7.1.2 or any earlier 7.1 version. WordPress.org recommends updating immediately because it is a security release. Patchstack says the update is not a drop-everything emergency, so schedule it today, not next month.

When was the WordPress 7.1.3 security release published and which fixes does it carry?

Specifically, WordPress.org published it on 6 October 2026 with seven security fixes and four bug fixes. The fixes cover a Comments screen XSS, a denial of service, an export SQL injection, sticky posts for Authors, comment disclosure, Imgur embeds and a hook name collision.

Does the WordPress 7.1.3 security release install itself on every WordPress site in 2026?

However, not on every site. WordPress installs minor releases by default, and a fresh 7.1.2 lab site replaced itself with 7.1.3 within minutes. A constant in wp-config.php, a plugin filter, a locked file system, a Git folder or a stalled WP-Cron can stop it.

What changed between WordPress 7.1.2 vs 7.1.3 in the WordPress 7.1.3 security release?

In practice, 15 files differ between the two official archives, and 9 of them are PHP. The changes sit in the HTTP class, the query class, the REST posts controller, the oEmbed class, the export tool, the post status code and the image helper.

How can I confirm the WordPress 7.1.3 security release reached my AHosting WordPress site?

Specifically, open Tools, then Site Health, then Info, then WordPress, and read the version. You can also open wp-includes/version.php in cPanel File Manager and read the wp_version line. Anything below 7.1.3 means the update did not arrive.

Shared hosting vs VPS: who installs the WordPress 7.1.3 security release for me?

Typically, WordPress core lives inside your own site and updates itself on both. On shared hosting your provider handles the server packages. On a VPS you handle the packages and the application, so you must also verify the core version yourself.

Is WordPress 7.1.2 vulnerable until the WordPress 7.1.3 security release is installed in 2026?

Specifically, yes, because 7.1.2 lacks the seven security fixes, and my lab showed it leaking private post comments and letting an Author make posts sticky. However, WordPress published no CVE IDs and the coverage I opened reports no confirmed exploitation, so update promptly without panic.

Which Imgur embeds need attention after the update, and does clearing the cache matter?

Notably, the fix removes Imgur from the trusted embed list but does not remove embeds already stored. Patchstack advises clearing your cache after updating. Review posts that contain Imgur links, especially ones written by Contributor accounts.

Does AHosting CageFS protect a site from a WordPress core flaw like the comment disclosure?

In practice, no, not from a flaw inside the site itself. CageFS keeps one account from reading another account, but a leaked comment feed is the content of the site itself, served by its own WordPress. Updating WordPress is what closes that kind of flaw.

How can AHosting help me when the WordPress 7.1.3 security release does not appear under Updates?

Specifically, open a ticket and include the WordPress version from Site Health and the PHP version shown under the Server tab. We will look at it with you. Meanwhile, check wp-config.php for a WP_AUTO_UPDATE_CORE or AUTOMATIC_UPDATER_DISABLED line.

October 23, 2026

PHP Security Update: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for WordPress

PHP Security Update: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Fix Two Critical Flaws
- PHP Security Update Facts Confirmed on php.net
- What the Two Critical PHP Flaws Do
Does the PHP Security Update Affect Your WordPress Site?
- Which Server Setups the PHP Security Update Covers
- Why a WordPress Update Does Not Replace the PHP Security Update
How to Check the PHP Security Update Reached Your Site
How to Install the PHP Security Update in cPanel MultiPHP Manager
Where AHosting Servers Stand on the PHP Security Update
- How We Install the PHP Security Update When It Arrives
- Why a Build Date of 21 October Is Not the Fix
PHP 8.1 and Older: No PHP Security Update Is Coming From PHP
- Why a Version Number Can Mislead on Old Branches
- Which Branch to Move To
If You Cannot Install the PHP Security Update Today
- Why Shared Hosting Customers Can Rarely Apply These Measures
- What a Low post_max_size Costs a WordPress Site
What to Check After the PHP Security Update
- Signs Worth Checking After a Critical PHP Flaw
- Keep the Version Check on a Calendar
Frequently Asked Questions About the PHP Security Update

TL;DR

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are the php security update for two critical remote code execution flaws, released on 21 October 2026. Read your full PHP version now, and update if it is lower than the fixed release for your branch. A green WordPress Site Health check does not prove you are patched, and PHP 8.1 and older get no fix from PHP.

Listen: which PHP releases carry the fix, why a green Site Health check proves nothing, and the steps to take. By Matt Chrust, Director of Business Development, AHosting.

PHP Security Update: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Fix Two Critical Flaws

The php security update shipped on Wednesday, 21 October 2026, and every WordPress site runs on the PHP it patches. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical remote code execution flaws. Specifically, php.net says the risk is highest for mod_php, where it describes a demonstrated exploit that needs no login. Therefore, the job is short: read your full PHP version, compare it with the fixed release for your branch, and update if you are behind.

Yesterday we published what was known before the release, in our pre-release guide to the PHP critical security release. The details are public now, so this guide replaces the waiting with steps. It also shows why WordPress cannot run the check for you.

PHP Security Update Facts Confirmed on php.net

Every fact in the table below comes from the PHP security advisory of 21 October 2026 and the PHP supported versions page. We read both directly on 22 October 2026. The last releases before this one came out on 24 September 2026, so any of those versions is behind.

PHP branch	Fixed release	Release before the fix	PHP support on 22 October 2026
PHP 8.5	8.5.12	8.5.11	Active support until 31 December 2027; security until 31 December 2029
PHP 8.4	8.4.27	8.4.26	Active support until 31 December 2026; security until 31 December 2028
PHP 8.3	8.3.36	8.3.35	Security fixes only, until 31 December 2027
PHP 8.2	8.2.35	8.2.34	Security fixes only, ending 31 December 2026
PHP 8.1 and older	None from PHP	Not applicable	No updates from the PHP project; source backports exist for 7.4, 8.0 and 8.1

AHosting PHP Security Update Fixed-Release Ledger: the fixed release for each branch, read from php.net on 22 October 2026.

What the Two Critical PHP Flaws Do

PHP names the first flaw CVE-2026-109618, “RCE via OOM corruption”. In plain terms, out-of-memory handling can interrupt PHP while internal request data is only partly set up. Request cleanup may then treat that invalid data as valid. The CVE record went public on the day of the release.

The second flaw is CVE-2026-109619, “RCE via stale global state”. Request-owned internal state can survive after its memory is freed. A later request handled by the same worker may then use that stale state before normal initialization resets it. Both flaws are rated CVSS v4.0 9.2, and the CVSS v4.0 specification puts every score from 9.0 to 10.0 in the Critical band.

Does the PHP Security Update Affect Your WordPress Site?

Yes, if your site runs one of the affected branches at a release older than the fixed one. WordPress is a PHP application, so each page request runs through the PHP interpreter on your server. A flaw in PHP therefore sits underneath your site whatever theme or plugins you use.

Which Server Setups the PHP Security Update Covers

PHP says the risk applies to all installations that serve web requests. Its list includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. In other words, no common setup is outside the notice. Our shared WordPress servers serve PHP through LiteSpeed, so a site that is not on mod_php is still inside the scope of the advisory.

PHP also says Linux distributions and LTS vendors received the patches in advance. That matters for any server you manage yourself, because your package source may already carry the fix.

Why a WordPress Update Does Not Replace the PHP Security Update

A flaw in the PHP engine is fixed in PHP, not in WordPress. Updating plugins and themes remains good practice, but it will not close this gap. For the wider picture of what a host adds at server level, see our guide to server-level WordPress hosting security.

Who installs the fixed release depends on how your site is hosted. On shared hosting the provider installs packages and you choose among them. On a managed server or a VPS hosting plan you or your administrator install the packages yourself, so nobody does it for you.

How to Check the PHP Security Update Reached Your Site

You need the full version, such as 8.4.26, not just 8.4. The branch tells you the family. The last number tells you whether you have the fix.

Read Your Full PHP Version in WordPress

Log in to the WordPress admin area.
Open Tools, then Site Health, then the Info tab.
Expand the Server section and read the PHP version line.
Write the full number down, including the last segment.

A second source is useful. In cPanel, MultiPHP Manager lists the PHP version each domain uses. If the two views disagree, a per-domain setting or a file in your document root is overriding one of them.

Why Site Health Stays Green Without the PHP Security Update

WordPress shows a PHP check in Site Health, and green looks like proof of a patch. It is not. We read the source of WordPress 7.1.2: the test is get_test_php_version in wp-admin/includes/class-wp-site-health.php, lines 736 to 860. It asks the WordPress.org Serve Happy service for a recommended version and three flags, then compares your PHP_VERSION with that one number.

At line 786 the test returns good when your version is equal to or higher than the recommended version. WordPress also caches the answer for a week. Nothing in the function holds a list of fixed releases, so it cannot tell a patched release from an unpatched one on the same branch.

What WordPress.org Returned for Affected and Fixed Releases

We tested that on 22 October 2026, about a day after the release. We asked the same WordPress.org endpoint that WordPress calls about nine version strings. The table shows what came back, and what the code at lines 786, 798, 813 and 829 does with it.

PHP version string	Where it stands	is_supported	is_secure	Site Health result
8.5.11	Affected, before the fix	true	true	Good (green)
8.5.12	Fixed	true	true	Good (green)
8.4.26	Affected, before the fix	true	true	Good (green)
8.4.27	Fixed	true	true	Good (green)
8.3.35	Affected, before the fix	true	true	Good (green)
8.3.36	Fixed	true	true	Good (green)
8.2.34	Affected, before the fix	false	true	Recommended (warning)
8.2.35	Fixed	false	true	Recommended (warning)
8.1.31	No fix from PHP	false	true	Recommended (warning)

AHosting Site Health Version Check Comparison: how WordPress.org answered for affected and fixed releases, queried on 22 October 2026.

The result runs backwards. A vulnerable 8.4.26 shows green, while a fixed 8.2.35 shows a warning. Even 8.1.31, which PHP no longer updates, still returns is_secure as true. A code comment in WordPress explains why: the key only means the branch receives security updates, not that your version is safe. The service may change its answers, so treat the table as a dated snapshot.

Site Health is still good for one thing. Its label prints your full version string. Use it to read the number, and ignore the color for patch status.

PHP Security Update Version Checker

The checker below compares the version you type with the fixed release for its branch. It uses only the four fixed releases PHP published. It runs in your browser and sends nothing anywhere.

PHP Security Update Version Checker

Your full PHP version, for example 8.4.26 Who manages the server your site runs on?

Type your full version, choose your server type, then select the button.

See WordPress hosting plans

How to Install the PHP Security Update in cPanel MultiPHP Manager

Here is what you can and cannot do, depending on your hosting. The cPanel MultiPHP Manager documentation says each domain can use any installed PHP version, and that only the system administrator can set the system PHP version. As a result, the interface lets you choose among installed versions. It does not install a newer release for you.

Shared Hosting: What You Can Change Yourself

If your branch is 8.2, 8.3, 8.4 or 8.5, the fixed release is installed by your provider. Your part is to confirm the version afterward. If your site is on PHP 8.1 or older, the fix is a real upgrade, and that is a change you can make yourself in MultiPHP Manager, once the site passes a test.

Back Up and Test Before the PHP Security Update

Take a full backup of files and database, and confirm you can restore it.
Record your current PHP version from Site Health and from cPanel, so you can switch back.
Test the site on a staging copy running the newer version. Our guide to pushing WordPress staging to live covers doing that safely.
Switch the live domain only after the staging copy passes: forms, login, checkout and cron jobs.

For the choice between branches, our guide to the best PHP version for WordPress in cPanel compares 8.3, 8.4 and 8.5. If WordPress shows a version warning after the switch, our post on the PHP version error WordPress shows walks through the usual causes.

Confirm the PHP Security Update Afterward

Reload Site Health and cPanel and confirm the full version string changed or already matched the fixed release. A branch name alone is not proof. On a provider you do not control, ask for the exact version in writing, then read the same number yourself. Our cPanel MultiPHP Manager lists PHP 8.5 among the selectable versions, but a listed branch shows a family and not a point release.

Where AHosting Servers Stand on the PHP Security Update

We checked our own servers on 22 October 2026. Across eleven of them, all four branches still run the release before the fix: 8.2.34, 8.3.35, 8.4.26 and 8.5.11. A second reading at 14:58 UTC the same day, on three of them, showed the same versions and no pending update. We are not telling you our servers are patched, because they are not yet.

The cause is not a missed update. Our servers already carry the newest PHP 8.4 build in the vendor repository they use, which was 8.4.26 when we looked. A package for 8.4.27 had not been published there yet, so there was nothing to install. That is no advantage: any host that takes its PHP packages from that repository is in the same position. We cannot give you a date, because publishing the package is the vendor step and not ours.

How We Install the PHP Security Update When It Arrives

On the servers we manage, we install PHP security releases ourselves, through the update path built into cPanel. On the server we examined in detail, that security check runs every hour. On a customer-owned server we install it too, with the customer approval.

Your settings stay as they are. The package is replaced under the PHP branch your domain already selects, so you remain on the same version choice, and PHP workers recycle. The full version string in Site Health then moves, for example from 8.4.26 to 8.4.27. Until it matches the fixed release for your branch, the table above is still true: a shared hosting customer cannot set most of those measures, so the useful step is to read your version and ask us to confirm it.

Why a Build Date of 21 October Is Not the Fix

Here is a trap worth knowing. Running php -v prints a line such as PHP 8.4.26 (cli) (built: Oct 21 2026). That build date is the day PHP published the advisory, so it reads like the fix. It is not. Version 8.4.26 is the release before 8.4.27. Compare the version number with the fixed release for your branch, and never compare the build date.

PHP 8.1 and Older: No PHP Security Update Is Coming From PHP

PHP states that PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so a vendor may still protect an old version. Otherwise, the way out is to upgrade to a supported branch.

The fix ships for 8.2 to 8.5 only. A site on PHP 8.1, 8.0, 7.4 or 5.6 will not receive it through a normal update, because PHP published no release for those branches. Our MultiPHP Manager still lists some of those older branches, so check which one your domain selects.

Why a Version Number Can Mislead on Old Branches

The version number alone cannot tell you whether a vendor backport is present. Only the vendor can say. For that reason the checker above tells you to ask, not to assume. PHP also gave the security team source backports for 7.4, 8.0 and 8.1, which helps people who build PHP from source.

Which Branch to Move To

The PHP supported versions page lists 8.3 with security support until 31 December 2027, 8.4 until 31 December 2028 and 8.5 until 31 December 2029. PHP 8.2 reaches end of life on 31 December 2026, so moving there only buys ten weeks. Test on staging, then move to 8.3, 8.4 or 8.5.

If You Cannot Install the PHP Security Update Today

PHP says only an update is a complete solution. It lists measures that reduce exposure to specific attack paths but, in its words, do not make an installation safe. The table shows each measure and where the advisory says to set it.

Flaw	Measure PHP lists	Where the advisory says to set it	What it does not do
CVE-2026-109618	Set memory_limit to -1	Preferably where applications cannot override it, such as php_admin_value in the FPM pool or Apache configuration	An underlying allocation failure can still reach the vulnerable path
CVE-2026-109618	Set a low post_max_size: 8M without uploads, 32M with uploads	PHP configuration, plus limits at the web server or proxy	Does not remove the flaw
CVE-2026-109619	Set session.upload_progress.enabled to 0 and restart every worker	php.ini, an FPM pool or server configuration; not ini_set() or .user.ini	Blocks the confirmed session paths, not other variants
CVE-2026-109619	On PHP 8.5, set fatal_error_backtraces to 0 and restart every worker	Server-level configuration	Blocks only the confirmed fatal backtrace path

AHosting PHP Security Update Mitigation Table: each stopgap PHP lists, where to set it, and what it leaves open.

Why Shared Hosting Customers Can Rarely Apply These Measures

Most measures belong in server or pool configuration. For the stale-state flaw, PHP says not to rely on ini_set() or .user.ini. A shared hosting customer normally edits neither the pool nor the server configuration. As a result, the practical step is to ask the host for the fixed release, not to tune settings yourself.

What a Low post_max_size Costs a WordPress Site

A low post_max_size also limits what WordPress accepts in one request. An 8M cap means a media upload above 8 MB fails. On a store or a membership site, that shows up as a broken upload, which is why this stopgap should be temporary and removed once the fixed release is installed.

What to Check After the PHP Security Update

Start with the pages that earn money. Submit a contact form, log in as a customer and run a test order. A PHP change touches payment and checkout plugins first, so a store needs this step more than a blog does. If you run a shop, our WooCommerce hosting page describes the plans built for that load.

Signs Worth Checking After a Critical PHP Flaw

The PHP notice we read does not report exploitation in the wild. The advisory does call the flaws critical and unauthenticated, though, so a short review is cheap. Check for administrator accounts you did not create, files changed since 21 October that you did not touch, and scheduled tasks you do not recognize. Finally, keep your backups from before and after the update.

Keep the Version Check on a Calendar

PHP 8.4 leaves active support on 31 December 2026, and PHP 8.2 reaches end of life the same day. Therefore, put one recurring reminder in your calendar to read the full PHP version after each PHP release. It takes two minutes, and it matches how the advisory defines the fix.

If the number does not match the fixed release for your branch and you cannot change it yourself, open a ticket with the PHP version shown under Tools, Site Health, Info, Server, and we will look at it with you.

Frequently Asked Questions About the PHP Security Update

Do I need to install the php security update on my WordPress site in 2026?

Specifically, yes: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical flaws that can allow unauthenticated remote code execution. Every WordPress site runs on PHP, so every site on an older release of those branches needs the fixed release. Check your full version string first.

Which PHP versions fix the php security update released on 21 October 2026?

Specifically, the fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older on those four branches is affected. PHP 8.1 and older get no update from the PHP project, so those sites need a vendor backport or an upgrade.

Why does WordPress Site Health stay green before and after the php security update?

In fact, Site Health compares your version with one number from WordPress.org, so a vulnerable 8.4.26 and a fixed 8.4.27 both pass. Therefore, read the full version string in the Info tab and compare it with the fixed release yourself.

PHP 8.4.27 vs PHP 8.3.36: which branch should a WordPress site run after the php security update?

Specifically, both branches carry the fix at their fixed releases. According to php.net, PHP 8.4 has security support until 31 December 2028 and PHP 8.3 until 31 December 2027. Therefore, choose 8.4 if your plugins support it, and test on a staging copy first.

Shared hosting vs VPS: which one leaves the php security update in your hands?

Typically, a shared host installs the patched PHP packages, and you can only choose among the versions it has installed. On a VPS, by contrast, you or your administrator update the packages. In practice, ask your provider which case applies and for the exact version it now runs.

What should I do if my WordPress site runs PHP 8.1 and no php security update exists for it?

Specifically, move to a supported branch, because the PHP project no longer updates PHP 8.1 and older. Some distributions and LTS vendors ship backported fixes, so ask yours. Otherwise, test on staging and upgrade to PHP 8.3, 8.4 or 8.5.

Can memory_limit or post_max_size changes replace the php security update on shared hosting in 2026?

In fact, they cannot. PHP states that only an update is a complete solution and that its listed measures do not make an installation safe. Moreover, several of them belong in server or pool configuration, which shared hosting customers usually cannot change.

How do I find which PHP version my AHosting WordPress site runs after the php security update?

Specifically, open WordPress Site Health, choose the Info tab and expand the Server section to read the full PHP version. Additionally, cPanel MultiPHP Manager shows the branch for each domain. Together, the two views should agree; if they do not, a per-domain setting is overriding one of them. Compare the version number, never the build date, because a build dated 21 October 2026 can still be 8.4.26.

Does AHosting list PHP 8.5 in cPanel MultiPHP Manager for WordPress hosting in 2026?

Specifically, our cPanel MultiPHP Manager lists PHP 8.5 among the versions you can select. However, a listed branch is not proof of a fixed release, because the list shows branches and not point releases. Therefore, always confirm the full version string in Site Health after any change.

Are AHosting servers on the fixed php security update release yet, and what should I do meanwhile?

Specifically, not yet as of 22 October 2026: our servers run the release before the fix, because the newest PHP 8.4 build in the vendor repository was still 8.4.26. However, we install the package ourselves once the vendor publishes it, and on a customer-owned server we do it with your approval. Meanwhile, read your full version in Site Health and open a ticket if you want it confirmed.

October 22, 2026

PHP Critical Security Release: What WordPress Site Owners Should Do Now

PHP Critical Security Release: What Was Announced and What Is Still Unknown
- PHP Critical Security Release Facts You Can Rely On
- Why PHP Critical Security Release Timing Is a Plan, Not a Promise
Does the PHP Critical Security Release Affect Your WordPress Site?
- What the Announcement Says About WordPress
- Why a WordPress Update Will Not Fix a PHP Flaw
Why a Green Site Health Check Does Not Mean the PHP Critical Security Release Reached You
- What the PHP Version Test Actually Compares
- What Site Health Is Still Good For
How to Find Your PHP Version Before the PHP Critical Security Release
PHP Critical Security Release Readiness: Check Your Next Steps
- Before the PHP Critical Security Release: Four Steps
- After the PHP Critical Security Release: Four Steps
Which PHP Branches Still Receive Security Fixes After the Release
What to Do if the PHP Critical Security Release Skips Your End-of-Life PHP Version
- End-of-Life PHP Is Still Selectable on Many Hosts
- A Safe Move Off an Old PHP Branch
Who Applies the PHP Critical Security Release: Shared Hosting, VPS or You?
Frequently Asked Questions: PHP Critical Security Release

TL;DR

The PHP critical security release is due on 21 October 2026 at 14:00 UTC and fixes two flaws rated CVSS 9.2. PHP has not named the affected versions yet, so treat every WordPress site as exposed until it does. Check your full PHP version now, back up, and update as soon as the fixed version for your branch is published. A green Site Health PHP check does not prove you are patched.

Listen: what PHP has confirmed about the release, how to read your full PHP version, and the steps to take before and after it lands. By Matt Chrust, Director of Business Development, AHosting.

The PHP critical security release is scheduled for Wednesday, 21 October 2026 at 14:00 UTC, and every WordPress site runs on the software it patches. Specifically, the PHP security team announced two vulnerabilities, both rated CVSS v4.0 9.2, and asked all users to prepare now. However, the notice does not yet say which PHP versions are affected or which versions fix them. Therefore, this guide sticks to what is confirmed, shows how to check your site in two minutes, and explains why WordPress itself cannot tell you whether you are patched.

PHP Critical Security Release: What Was Announced and What Is Still Unknown

In its news entry of 20 October 2026, PHP confirmed the date, the count and the severity. Notably, the same text went to the developer list, where the PHP security team posted it for php.internals. Consequently, there is one primary source for every confirmed fact below.

PHP Critical Security Release Facts You Can Rely On

The table separates what PHP confirmed from what press coverage claims. In particular, two CVE identifiers are circulating, but Qualys reports that PHP has not confirmed them.

Item	Status as of 21 October 2026	Source
Release date and time	Confirmed: Wednesday 21 October 2026, 14:00 UTC	php.net news entry
Number of vulnerabilities	Confirmed: two	php.net news entry
Severity	Confirmed: CVSS v4.0 9.2 for each (critical)	php.net news entry
Earlier release	Possible if details become public or exploitation appears	php.net news entry
CVE identifiers	Unconfirmed: public reports link CVE-2026-109618 and CVE-2026-109619	Qualys blog
Affected PHP versions	Not published yet	php.net, Qualys
Fixed PHP versions	Not published yet	php.net, Qualys
Type of flaw	Not stated in the notice	php.net news entry
Exploitation in the wild	None reported in the coverage we read	Help Net Security
WordPress-specific impact	Not stated by PHP	php.net news entry

AHosting PHP Security Release Fact Ledger: confirmed against unconfirmed, written before the 14:00 UTC release.

Why PHP Critical Security Release Timing Is a Plan, Not a Promise

PHP reserved the right to ship earlier. As a result, the 14:00 UTC time is the latest you should expect, not the earliest. Indeed, preparing before the release costs you ten minutes, while preparing after it costs you a rushed afternoon.

Does the PHP Critical Security Release Affect Your WordPress Site?

WordPress is a PHP application, so every page request runs through the PHP interpreter on your server. Therefore, a flaw in PHP sits underneath your site whatever theme or plugins you use. However, whether a given flaw is reachable from a WordPress page depends on details nobody has published yet.

What the Announcement Says About WordPress

In fact, it says nothing. PHP does not mention WordPress, and the Help Net Security report only tells WordPress owners where to find their PHP version. Likewise, Qualys advises organizations to prepare for expedited patching and to inventory every PHP system. In other words, the safe reading is that every PHP installation could be affected until the advisory says otherwise.

Why a WordPress Update Will Not Fix a PHP Flaw

Typically, a flaw in the PHP engine is fixed in PHP, not in WordPress. As such, updating plugins and themes remains good practice but will not close this gap. For the wider picture of what a host can add at server level, see our guide to server-level WordPress hosting security.

Why a Green Site Health Check Does Not Mean the PHP Critical Security Release Reached You

WordPress ships a PHP check in Site Health, and it is tempting to treat green as patched. Specifically, we read its source in WordPress 7.1.2: the test is get_test_php_version in wp-admin/includes/class-wp-site-health.php, lines 736 to 860. In short, it measures branch support, not patch level.

What the PHP Version Test Actually Compares

First, the test asks the WordPress.org Serve Happy service for a recommended version and three flags. Next, it compares your PHP_VERSION with the recommended version. If yours is equal or higher, the result is good and the label reads that you run a recommended version of PHP. Only below that line does it look at whether the branch is still supported.

Consequently, a site on any point release of a current branch shows green, including one that has not received a fix. Nothing in that function checks your exact release against a list of fixed releases. That is a design choice, not a bug, but it matters on the day a critical fix ships.

What Site Health Is Still Good For

That said, the label prints your full version, for example the text Your site is running PHP followed by the exact number. In addition, WordPress marks a branch with no security updates as critical. Therefore, use Site Health to read the version string and the end-of-life warning, and ignore the color for patch status.

How to Find Your PHP Version Before the PHP Critical Security Release

You need the full version, such as 8.4.26, not just 8.4. Specifically, there are three places to read it, and the first two take under two minutes.

Read the PHP Version Inside WordPress

Log in to the WordPress admin area.
Open Tools, then Site Health, then the Info tab.
Expand the Server section and read the PHP version line.
Write the full number down, including the last segment.

Read the PHP Version in cPanel MultiPHP Manager

Alternatively, cPanel lists the version for each domain. According to the cPanel MultiPHP Manager documentation, each domain can use any installed PHP version, and an Inherited label means it follows the system version. Notably, only the system administrator can change that system default, and a provider can switch the interface off.

In practice, the two views should agree. If they do not, a per-domain setting or a file in your document root is overriding one of them. For that case, our post on the PHP version error WordPress shows walks through the usual causes.

Read the PHP Version on a VPS

On a server you manage, run php -v over SSH. However, the command line can use a different PHP than the web server, so confirm the web version in Site Health as well.

PHP Critical Security Release Readiness: Check Your Next Steps

The checker below turns your branch and server type into next steps. It uses only facts confirmed on php.net, and it will not guess a fixed version.

PHP Critical Security Release Readiness Checker

Which PHP branch does your site run? Who manages the server your site runs on?

Choose your branch and server type, then select the button.

See WordPress hosting plans

Before the PHP Critical Security Release: Four Steps

Take a full backup of files and database, and confirm you can restore it.
Record your exact PHP version from Site Health or cPanel.
Test your site on a staging copy running a newer branch. Our guide to pushing WordPress staging to live covers doing that safely.
Check your host for any notice about the maintenance window.

After the PHP Critical Security Release: Four Steps

Read the advisory and find the fixed version for your branch.
Update, or confirm your host has updated, to that version or later.
Reload Site Health and cPanel and confirm the full version string changed.
Test the pages that earn money, such as forms and checkout.

For stores, the last step matters most. For example, a WooCommerce store should place a test order, because a PHP change touches payment plugins first.

Which PHP Branches Still Receive Security Fixes After the Release

Importantly, a fix only reaches branches that PHP still supports. The table below is taken from the PHP supported versions page, read on 21 October 2026.

PHP branch	Active support until	Security support until	Status on 21 October 2026
8.2	31 December 2024	31 December 2026	Security fixes only, ending in about ten weeks
8.3	31 December 2025	31 December 2027	Security fixes only
8.4	31 December 2026	31 December 2028	Active support, ending in about ten weeks
8.5	31 December 2027	31 December 2029	Active support
8.1 and older	Not listed	Not listed	Not supported by PHP
8.6	Not listed	Not listed	Release candidate, not for production

AHosting PHP Branch Support Table: dates as listed on php.net, with the 8.6 status from the 8 October 2026 RC3 notice.

Therefore, a branch outside the first four rows will not get a patch from PHP. Overall, the choice between current branches is covered in our PHP version guide for WordPress in cPanel.

What to Do if the PHP Critical Security Release Skips Your End-of-Life PHP Version

PHP has not said which branches the fixes cover. Even so, a branch missing from the supported list gets nothing from this release or the next one. In fact, WordPress already treats that case as critical and labels the version as one that does not receive security updates.

End-of-Life PHP Is Still Selectable on Many Hosts

Notably, being able to choose an old branch does not make it safe. On our customer servers, the cPanel list of installed PHP versions runs from old branches up to PHP 8.5, so an old branch is one click away. As a result, check what you selected, not what is on offer.

A Safe Move Off an Old PHP Branch

First, back up. Second, change the version for one domain in MultiPHP Manager or on staging. Third, load the site, the admin area and every form. Finally, switch back at once if a plugin fails, then update or replace that plugin before trying again.

Who Applies the PHP Critical Security Release: Shared Hosting, VPS or You?

The answer depends on where the PHP packages live. Typically, on shared hosting the provider installs them and you pick the branch. On a VPS or dedicated server, by contrast, you own that job.

Shared Hosting: The Host Patches, You Verify

In practice, a shared host updates the PHP packages for all accounts, and your task is to confirm the result. First-hand, the AHosting customer server we inspected runs CloudLinux 9 with CageFS and LVE. Its LiteSpeed PHP processes run as each site’s own cPanel user, and 38 of them were observed that way on 30 September 2026.

As a result, an exploited site is confined to what its own account can reach, which is how that isolation is designed to work. However, nobody has published the flaws, so we cannot say whether an exploit would respect that boundary.

VPS and Dedicated Servers: You Patch

By contrast, a WordPress VPS leaves package updates to you. Therefore, schedule the update for the hour after the fixed version appears, and keep a snapshot ready.

Agencies: Many Sites, One Version Check

For agencies, the work is a list, not a single check. Specifically, record the PHP version of every client site today. Agencies hosting many client sites on a reseller hosting account can then update them in one pass instead of site by site.

Finally, once you have confirmed the full version, open a ticket with the PHP version shown under Tools, Site Health, Info, Server and we will look at it with you.

Frequently Asked Questions: PHP Critical Security Release

Does the PHP critical security release put my WordPress site at risk in 2026?

Specifically, any WordPress site runs on PHP, so a critical PHP flaw can reach it whatever plugins it uses. However, PHP has not published the affected versions yet. Therefore, treat every site as exposed until the advisory names fixed versions.

When is the PHP critical security release and could it arrive earlier than planned?

Specifically, PHP scheduled the release for Wednesday 21 October 2026 at 14:00 UTC. However, the security team reserved the right to ship earlier if details become public or exploitation appears. As a result, prepare before the stated time, not at it.

Does a green PHP check in WordPress Site Health prove the PHP critical security release reached my site?

In fact, it does not. The check compares your PHP version with a recommended version from WordPress.org and shows green at or above it. Therefore, a site on an unpatched point release of a current branch still shows green. Read the full version string instead.

PHP 8.4 vs PHP 8.5: which branch should a WordPress site be on for security support in 2026?

Specifically, php.net lists security support for 8.4 until 31 December 2028 and for 8.5 until 31 December 2029. Both receive fixes today. However, WordPress plugin compatibility is the practical limit, so test on staging before moving a live site.

Who applies the PHP critical security release on shared hosting vs a VPS?

Typically, a shared host installs the patched PHP packages and you choose the branch your site uses. On a VPS, by contrast, you or your administrator must update the packages yourself. In practice, ask your provider which of the two applies to your plan.

My WordPress site runs PHP 8.2 in 2026, so should I wait for the PHP critical security release patch or upgrade now?

Notably, php.net lists 8.2 with security support only until 31 December 2026. A fix for 8.2 is not confirmed for this release. Therefore, back up, test on staging, and plan the move to 8.3 or later instead of waiting.

What should I do if my WordPress site runs PHP 8.0 or an older end-of-life branch?

First and foremost, move to a supported branch, because php.net no longer lists the older ones. WordPress Site Health already flags such versions as critical because they receive no security updates. Consequently, a patch is unlikely to reach them.

How do I check which PHP version my AHosting WordPress site uses in cPanel?

Specifically, open MultiPHP Manager in cPanel and read the PHP version listed beside each domain. Alternatively, open Tools, Site Health, Info, Server inside WordPress. In other words, the two views should agree, and a mismatch points to a per-domain override.

Does AHosting CageFS limit the damage if a PHP flaw is exploited on one site?

Specifically, AHosting customer servers run CloudLinux with CageFS and LVE, and each PHP process runs as the cPanel user that owns the site. As a result, an exploited site is confined to what that account can reach. However, nobody has published the flaws yet, so this is design intent, not a guarantee.

How can AHosting help me confirm my PHP version after the PHP critical security release?

In practice, open a ticket with the PHP version shown under Tools, Site Health, Info, Server and we will look at it with you. Additionally, mention your domain so we can compare it with the version cPanel lists for that site.

October 21, 2026

Headers Already Sent in WordPress: Find the Byte | AHosting

Headers Already Sent in WordPress: What PHP Is Refusing to Do
- Headers Already Sent: The Second Path Names the Victim
How to Read Output Started At When Headers Already Sent Appears
Headers Already Sent After a BOM or a Stray Space
- Check the First Three Bytes for Headers Already Sent
Headers Already Sent Because of Text After the Closing Tag
- Remove the Closing Tag to Stop Headers Already Sent
Headers Already Sent Because Something Printed a Notice
- When the Named File Is a Core File
Paste Your Headers Already Sent Warning Into the Decoder
Why Headers Already Sent Works on One Host and Fails on Another
- Headers Already Sent After You Move Hosts
What Headers Already Sent Breaks: Login, Redirects and the REST API
Find the Stray Byte That Causes Headers Already Sent Across a Site
- A Scanner for BOMs and Text After the Closing Tag
- A Fix Order for Headers Already Sent
What the Headers Already Sent Lab Did Not Cover
Frequently Asked Questions About Headers Already Sent in WordPress

TL;DR

The headers already sent warning means PHP had already sent a byte of page output when WordPress tried to send a header or a cookie. Read the path after "output started at" first, because it names the file and line where that byte left. A line number of 1 points to a BOM, a line near the end points to text after a closing tag, and a core file points to a notice printed above it. In our lab a 3 byte BOM produced six warnings and no login.

Listen: the first path in the warning is the cause, and the line number says whether it is a BOM, a closing tag or a printed notice. By Matt Chrust, Director of Business Development, AHosting.

Headers Already Sent in WordPress: What PHP Is Refusing to Do

The headers already sent warning is PHP refusing to change an HTTP header after the page has started. A web response has two parts, the headers first and the body second. Once a single byte of body leaves PHP, the headers are locked, and a later call to header() or setcookie() fails. The PHP manual for header() says why: output can come from “blank lines in a file”, not only from HTML.

Here is the full message, with a made-up path:

Warning: Cannot modify header information - headers already sent by (output started at /home/user/public_html/wp-config.php:1) in /home/user/public_html/wp-login.php on line 525

Headers Already Sent: The Second Path Names the Victim

The message has two halves, and only one of them helps. The first half, output started at, names the file and line where the first byte left PHP. That is the cause. The second half, in ... on line, names the code that tried to send a header and was too late. Core files appear there constantly, and editing them is the wrong move.

To check this, I installed WordPress 7.1.3 on a local PHP 8.5.10 server and caused each problem on purpose. Every row of the tables below comes from one of those runs. The setup is a single workstation, not an AHosting server, and the last section lists what it did not cover.

How to Read Output Started At When Headers Already Sent Appears

Start with the file and the line number. Together they sort the problem into one of five cases, and each case has a different fix.

What output started at names	Most likely cause	What to check	Reproduced in the lab
A plugin, theme or `wp-config.php` file, line 1	A BOM, or a space or line break before the PHP opening tag	The first three bytes of that file	Yes. A BOM in `wp-config.php` gave six warnings and no login cookie
A plugin or theme file, a line near the end	Text after the closing tag: a second newline or a space	The last lines of that file	Yes. A closing tag plus two newlines was reported at line 5
A plugin or theme file, a line in the middle	The code printed something: an echo, or a notice PHP displayed	The named line, then any message printed above the warning	Yes. A notice raised on line 2 was reported at line 2
A core file such as `wp-includes/functions.php`	A Notice or Deprecated message printed by core for another plugin	The first message above the first warning; it names the real file	Yes. A deprecated call was reported at `functions.php` line 6260
Nothing is shown at all	display_errors is off, so the warning is hidden but the problem remains	The PHP error log, and the login page error text	Yes. Login returned 200 with no cookie and an unexpected output error

Headers Already Sent Decoder Table: five readings of the output started at path, each tied to a run on WordPress 7.1.3.

Headers Already Sent After a BOM or a Stray Space

A byte order mark, or BOM, is the character U+FEFF placed at the start of a file. In UTF-8 it is the three bytes EF BB BF, and the W3C article on the byte-order mark warns that a BOM at the start of a PHP file begins output before a header call runs. Some editors add it on save, and none shows it. PHP treats any bytes before the opening tag as output. The PSR-1 standard therefore requires PHP code to use UTF-8 without BOM.

In the lab I put those three bytes before the opening tag of wp-config.php and submitted the login form with the right password. WordPress answered 200 and set no login cookie. It printed six warnings, all saying output started at wp-config.php:1. One invisible mark produced six messages, because each header and cookie call in the login request failed on its own.

Check the First Three Bytes for Headers Already Sent

A line number of 1 is the tell, but check before you edit. In a shell, head -c 3 wp-config.php | od -An -tx1 prints ef bb bf when the BOM is there. I ran that on macOS only. A space or tab before the opening tag shows up as 20 or 09 in the same output.

To fix it, save the file again as UTF-8 without BOM. In VS Code, the encoding button in the status bar lets you save the file with a different encoding. Then request the page again and confirm that the first byte is the opening tag.

Headers Already Sent Because of Text After the Closing Tag

The closing tag is the second classic source. PHP swallows one newline that comes right after the closing tag, and anything beyond that newline is output. The lab shows the edge exactly: a must-use plugin ending in a closing tag plus one newline worked, and the same file with two newlines broke login.

In that run the report said output started at the plugin file, line 5, although the file had four lines. Notably, the second newline sits on a fifth line that looks empty in an editor, which is why this one is hard to see.

Remove the Closing Tag to Stop Headers Already Sent

Because the closing tag at the end of a file is optional, leaving it off removes this whole class of error. The WordPress PHP coding standards say that omitting the closing tag at the end of a file is preferred. For a file you own, such as a custom plugin or a functions.php, delete the final closing tag and any lines below it.

Do not edit a core file or a vendor plugin this way. Replace it with a clean copy from its author instead, because your change disappears at the next update anyway.

Headers Already Sent Because Something Printed a Notice

Whitespace is only one kind of output. A PHP notice, warning or deprecation message is output as well, and WordPress shows them in the page when debugging is on. The WordPress debugging handbook says the WP_DEBUG_DISPLAY default is true, which “shows errors and warnings as they are generated”. A site that shows one notice then shows a headers already sent warning right behind it.

In the lab, a must-use plugin raised a notice on init with debugging on. Login returned 200 with no cookie, and the warning said output started at that plugin, line 2, the very line that raised the notice. So far the file named is the culprit.

When the Named File Is a Core File

The next run is the one that misleads people. A plugin called a deprecated function on init. WordPress printed the Deprecated message itself, so the warning said output started at wp-includes/functions.php:6260. Core is named, and core is innocent. The real file is in the message printed above the first warning.

Read that first message, then rename the plugin folder it names and test again. To stop the display while you fix the cause, set WP_DEBUG_DISPLAY to false and WP_DEBUG_LOG to true. If a debug log stays on, read what a public debug log exposes so that you do not trade one problem for another.

Paste Your Headers Already Sent Warning Into the Decoder

The decoder below applies the table to your own warning. It reads the line number and the path, then names the likely cause and the section to read next. It reports what the table says and nothing more, so a plugin with unusual output still needs a person to read the file.

Warning Line Decoder

Paste the whole warning. The text stays in your browser and is not sent anywhere.

Your warning line

Why Headers Already Sent Works on One Host and Fails on Another

The same files can pass on one server and fail on another. The reason is output_buffering. The PHP output control settings list its default as “0” and give 4096 as an example value. With a buffer, PHP holds early output in memory, so headers can still go out first.

I ran the same broken files with and without a 4096 byte buffer. The result is Table 2.

Stray output	output_buffering	Login result
3 byte BOM in `wp-config.php`	0	200, no login cookie, six warnings
3 byte BOM in `wp-config.php`	4096	302 redirect, login cookie set, no warning
20 byte echo from a plugin	4096	302 redirect, login cookie set
5000 byte echo from a plugin	4096	200, no login cookie, warning at the echo line
3 byte BOM, display_errors off	0	200, no login cookie, no warning shown

Same Files, Different PHP Settings: how output_buffering changes the login result in the lab.

Headers Already Sent After You Move Hosts

Because the setting belongs to the server, a migration can start this warning without anyone touching a file. A BOM that a lenient buffer hid for years surfaces the day the new server has none. If the warning appears right after a move, the migration walkthrough covers the checks around it, and the stray byte is still the thing to find.

Raising the buffer would hide the symptom in the lab, and I would not ship it. The 5000 byte row shows the hiding stops working as soon as the output grows. I did not read this setting on any AHosting server, so this post makes no claim about its value there. Ask your host, or look at it in phpinfo().

What Headers Already Sent Breaks: Login, Redirects and the REST API

The warning is the visible part. The damage is what failed to send. In login, wp_set_auth_cookie() makes three setcookie() calls at pluggable.php:1193 to 1195, and all three failed in the lab. Redirects use header( "Location: ..." ) at pluggable.php:1542, and the admin sends a Referrer-Policy header at functions.php:7310. None of these has a guard.

The Cookies Are Blocked Due to Unexpected Output Error

Hiding the warning does not hide the failure. With display_errors off, the lab login page came back with “Cookies are blocked due to unexpected output.” These lines of wp-login.php print it when the login cookie is missing and headers_sent() is true. The error is the same problem seen from the login form.

Headers Already Sent in the REST API Response

REST responses need clean JSON. With a BOM in a must-use plugin, a REST request returned a body that began with the bytes ef bb bf, then warning markup, and a JSON parser rejected it. The editor shows that as a bad response, so the not a valid JSON response guide is the next place to look.

Why the Front Page Looks Fine

The front end is quieter. WordPress tests headers_sent() before it sends most front-end headers, at class-wp.php:573 to 581, and nocache_headers() returns early the same way. In the lab, the front page returned 200 and printed no warning, yet the stray byte still sat ahead of the doctype. A clean front page therefore does not clear a file.

Redirect and login problems from cookies deserve their own check, and the too many redirects guide covers the cookie and redirect side separately.

Find the Stray Byte That Causes Headers Already Sent Across a Site

Usually the warning names the file, and you are done. Sometimes you migrate a site or inherit one, and you want every file checked at once. On a shared web hosting plan that lists SSH access, a short PHP script can do it. I wrote one and tested it on seven sample files.

A Scanner for BOMs and Text After the Closing Tag

It reads every .php file under a folder and prints two kinds of finding. A first token made only of a BOM or whitespace is reported with its bytes, and so is whitespace after a final closing tag. It left alone a closing tag followed by one newline, a file with no closing tag, and a template with real markup.

<?php
// Usage: php find-stray-output.php /path/to/wp-content
$it = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($argv[1], FilesystemIterator::SKIP_DOTS));
foreach ($it as $f) {
    if (substr($f, -4) !== '.php') { continue; }
    $t = token_get_all(file_get_contents($f));
    $first = $t[0];
    if (is_array($first) && $first[0] === T_INLINE_HTML && trim($first[1], "\xEF\xBB\xBF \t\r\n") === '') {
        echo $f . ':1 starts with ' . bin2hex(substr($first[1], 0, 6)) . "\n";
    }
    $last = end($t);
    $prev = prev($t);
    if (is_array($last) && $last[0] === T_INLINE_HTML && is_array($prev) && $prev[0] === T_CLOSE_TAG && trim($last[1]) === '') {
        echo $f . ' ends with ' . bin2hex(substr($last[1], 0, 6)) . " after the closing tag\n";
    }
}

The script is read-only. It cannot find an echo or a notice, so the decoder above still comes first. If you run many client sites, run it once per account, because a reseller hosting account keeps a separate cPanel account for each client.

A Fix Order for Headers Already Sent

Read the first warning, and ignore the repeats. They share one cause.
On line 1, check the first three bytes and save the file as UTF-8 without BOM.
Near the end of a file, delete the closing tag and any lines under it.
With a core file, read the message printed above the first warning and fix the file it names.
Test login in a private window, because a cached admin session hides the cookie failure.

What the Headers Already Sent Lab Did Not Cover

The lab used WordPress 7.1.3 with SQLite instead of MySQL, PHP 8.5.10 and the built-in web server, on one workstation. I did not test LiteSpeed, LSAPI or php-fpm, multisite, a cPanel editor, or any browser. The scanner ran on seven sample files, not on a real site, and the shell commands ran on macOS only. Every number in this guide comes from that setup, so treat the line numbers as WordPress 7.1.3 line numbers.

Finally, if your warning fits none of the five rows, the file is not the problem and the next step is a person. If your site runs on our WordPress hosting plans, open a ticket with the full warning line, from the word Warning to the last line number, and we will look at it with you.

Frequently Asked Questions About Headers Already Sent in WordPress

What does the headers already sent warning mean in WordPress in 2026?

Specifically, PHP had already sent page output when WordPress tried to send a header or a cookie, so PHP refused. The path after output started at names the file and line where the first byte left, and that is the place to look. The second path in the message only names the code that was too late.

Why does headers already sent appear in wp-admin and login but not on the front page?

In practice, WordPress core tests headers_sent before it sends most front-end headers, so the front end stays quiet. Login, admin screens and redirects call setcookie or header without that test, so they print the warning. The stray output can still be on the front page, ahead of the doctype.

Headers already sent: BOM vs closing tag whitespace, which one does the line number reveal?

Specifically, a line number of 1 points to a BOM or to text before the PHP opening tag. A line number near the end of a file points to text after the closing tag. In our lab a closing tag followed by two newlines was reported at line 5 of a file with four lines.

Output buffering vs fixing the file: which is the right fix for headers already sent in 2026?

Specifically, fixing the file is the right fix. Output buffering only holds early output in memory, and it stops helping once the output outgrows the buffer. In our lab a 20 byte echo passed with a 4096 byte buffer, and a 5000 byte echo failed with the same setting.

How do I find which plugin causes headers already sent when the path names a core file?

Specifically, scroll up to the first message printed above the first warning, because a Notice or Deprecated line names the real file. In our lab a deprecated call from a must-use plugin was reported at wp-includes functions.php line 6260, while the message above it named the plugin. Then rename that plugin folder and test again.

Why can’t I edit the header in WordPress when the headers already sent warning shows?

Indeed, this warning is about HTTP headers, the lines a server sends before the page, and not the header area you edit in the Customizer or the Site Editor. No theme setting changes it. The fix is in a PHP file that printed something too early, so use the path after output started at.

Which AHosting plans list SSH access or WP-CLI for headers already sent troubleshooting?

Specifically, the AHosting WordPress Hosting page lists WP-CLI access and SSH access (jailed shell), and the Web Hosting page lists SSH access (jailed shell), as read on October 20, 2026. Neither page says which tools exist inside the shell, so check that PHP runs there before you rely on a scanner.

What should I send AHosting support about a headers already sent warning in 2026?

Specifically, send the full warning line, from the word Warning to the last line number, including both paths. The line holds file paths for your account and nothing secret. If a notice printed above it, add that line too, and say which file you already checked.

Can I hide the headers already sent warning with a .user.ini file on AHosting shared hosting?

However, hiding the message does not fix the cause. Our servers read .user.ini files, so display_errors can be set there, but in our lab login still failed with display_errors off and WordPress printed that cookies are blocked due to unexpected output. Fix the file that printed the byte.

Is headers already sent a security problem or only a coding mistake in 2026?

Typically it is an editor or coding mistake, and a BOM does not prove a hack. That said, if the output at the named line is text you did not write, treat the file as suspect and compare it with a clean copy from the plugin or theme author.

October 21, 2026

Sorry, You Are Not Allowed to Access This Page in WordPress: Find the Cause

Not Allowed to Access This Page: What WordPress Actually Checks
- The Two Questions Behind the Message
- The Three Causes at a Glance
Cause 1: Not Allowed to Access This Page Because the Page Is Not Registered
- How to Confirm Cause 1 in Under a Minute
Cause 2: Not Allowed to Access This Page Because the Account Lost Its Role
Cause 3: Not Allowed to Access This Page Because the Role Is Too Low
- Why the Exact Sentence Matters
- Give the Smallest Role That Works
Which Cause Do You Have? Check Your Symptoms
What the Lab Measured About Not Allowed to Access This Page
What Your Host Can and Cannot Change
Frequently Asked Questions: Not Allowed to Access This Page

TL;DR

WordPress prints "Sorry, you are not allowed to access this page." from one line in core, after one function answers no. That function refuses for three reasons: the page is not registered, your account has no role, or your role is too low. Open the Dashboard first. If it loads, check the plugin behind the address. If it fails too, the role records carry the wrong prefix.

Not allowed to access this page: one function says no, for one of three reasons. By Matt Chrust, Director of Business Development, AHosting.

Not Allowed to Access This Page: What WordPress Actually Checks

When WordPress says you are not allowed to access this page, it has already decided, and it decided before the screen you asked for ran any code. The full sentence is “Sorry, you are not allowed to access this page.” It arrives with an HTTP 403 status and a plain error page.

In WordPress 7.1.3, which I read and ran for this guide, one line in menu.php prints it. That line sits right after an if test. Therefore the real question is never why WordPress printed the message. It is why the function in that test returned false.

The Two Questions Behind the Message

The function is user_can_access_admin_page(), and its source in plugin.php asks two things. First, is the page registered? Second, does your account hold the capability that the menu entry demands?

A page counts as registered when a plugin or core added it to the admin menu during that request. If the lookup finds no match, the function returns false at once. Otherwise it returns the result of current_user_can() for the capability stored on the menu entry. As a result, a stale bookmark and a low role end in the same sentence even though they have nothing in common.

The Three Causes at a Glance

Every case I reproduced falls into one of three rows. Match your symptom in the first column, then jump to the section that carries the fix.

What you see	What core checked	Cause	Where the fix is
One plugin screen fails; the Dashboard opens	Is the page in the registered list?	The plugin is deactivated, removed or renamed, or the address is wrong	Cause 1: plugins screen or menu
Every screen fails, Dashboard included	Does the account hold the read capability?	The account has no role: capabilities or roles records carry the wrong prefix	Cause 2: two database records
Settings or Tools fails; Posts opens	Does the role hold manage_options?	The role is real but too low for that menu entry	Cause 3: role change by an Administrator

WordPress Admin Page Denial Decision Table: three causes of the message, from WordPress 7.1.3 source and the lab runs

Cause 1: Not Allowed to Access This Page Because the Page Is Not Registered

This is the cheapest cause to check, so check it first. A plugin adds its screen to the menu only while it is active. Deactivate the plugin, and the screen vanishes from the registered list on the next request.

In the lab, an Administrator opened a test plugin page and got a normal 200. After I deactivated the plugin, the same address returned a 403 with the exact message. The Dashboard still returned 200 in the same session. An address that never existed, such as page=does-not-exist, produced the identical result.

How to Confirm Cause 1 in Under a Minute

Open the Dashboard at /wp-admin/. If it loads, your account still has a role, so cause 2 is unlikely.
Open the Plugins screen and look for the plugin that owns the address. Compare the page name in the URL, after page=, with the plugin you expect.
Reactivate the plugin, or reinstall it if an update removed it, then open its screen from the left menu instead of the saved bookmark.
If the plugin is active and the screen is still refused, read cause 3. A plugin can register a page and still demand a capability you lack.

Notably, a plugin update can rename its menu slug. Old emails and bookmarks then point at a slug that no longer exists. The message looks like a permissions problem, but nothing about your account changed.

Cause 2: Not Allowed to Access This Page Because the Account Lost Its Role

The second cause is the one that locks out an owner, and it can follow a migration. WordPress stores your role in the database, under a key that begins with the table prefix. If the prefix changes and the key does not, WordPress looks for your role under the new name and finds nothing.

Where WordPress Stores Your Role

Two records matter. The user meta table holds one row per user whose key is the prefix plus capabilities, and core builds that key at class-wp-user.php line 488. The options table holds one row whose name is the prefix plus user_roles, built at line 342 of class-wp-roles.php.

With the default prefix those names are wp_capabilities and wp_user_roles. After a move to a site whose prefix is different, WordPress reads the new names. Specifically, the old rows stay in the tables under the old names, and nothing reads them.

I tested all three combinations in the lab, after rewriting the stored keys from wp_ to xy_ while the tables kept wp_. An Administrator got a 403 with the exact message on the Dashboard, on Settings and on Plugins whether the old prefix sat on the user meta rows only, on the roles option only, or on both. In other words, either record alone is enough to lock you out.

Repair the Prefix in phpMyAdmin

The AHosting shared hosting plan page lists phpMyAdmin, and cPanel opens it from the Databases section. Work through these steps in order, and stop after the export if anything looks unfamiliar.

Export the whole database from the Export tab. The UPDATE statements below cannot be undone.
Read $table_prefix in wp-config.php. That is the prefix your tables use, and it is the one the keys must carry. Call it NEWPREFIX.
In the users meta table, find a row whose key ends in _capabilities and read its prefix. That is your old prefix. Call it OLDPREFIX.
Open the SQL tab, paste the two statements below with both prefixes replaced, and run them one at a time.
Reload /wp-admin/. The Dashboard should open at once, because the rows are read on every request.

UPDATE NEWPREFIX_usermeta
SET meta_key = REPLACE(meta_key, 'OLDPREFIX_', 'NEWPREFIX_')
WHERE meta_key LIKE 'OLDPREFIX\_%';

UPDATE NEWPREFIX_options
SET option_name = 'NEWPREFIX_user_roles'
WHERE option_name = 'OLDPREFIX_user_roles';

The first statement renames every user meta key that starts with the old prefix, which includes the capabilities and user level rows. The second renames the roles option. In the lab, the same two statements, written for SQLite and with the prefixes swapped, returned the Dashboard and Settings to 200 after the break. SQLite’s replace() function works the way the MySQL one does here, but I did not run the statements on MySQL itself.

Or Use WP-CLI Where the Plan Lists It

The AHosting WordPress hosting page lists WP-CLI access and a jailed SSH shell. The documented command is wp user set-role, which sets the role of one user. It repairs that user only. It does not touch the roles option, and the lab showed that a stale roles option alone locks everyone out.

Therefore, use WP-CLI for a single account whose own row is wrong, and use the SQL for a whole site that moved. If you are unsure which describes you, the Dashboard test in the widget below usually decides it. For the move itself, the migration walkthrough compares four ways to migrate WordPress to a new host. For a first look at phpMyAdmin queries, the autoloaded options guide shows the tool in use.

Cause 3: Not Allowed to Access This Page Because the Role Is Too Low

The third cause is the least dramatic. Your account has a role, and the role is simply too low for that menu entry. WordPress is doing exactly what it should.

In core, Settings requires manage_options (wp-admin/menu.php line 405), while the Dashboard needs only read (line 29). In the lab, an Editor opened Posts with a 200 and was refused on Settings with a 403 and the exact message. The same Editor was refused on a test plugin page registered with manage_options.

Why the Exact Sentence Matters

Other refusals use other words. For example, the Editor who asked for the Users screen got a 403 with “Sorry, you are not allowed to list users.” from a different line of core. The sentence you read therefore points at a mechanism, so copy it exactly when you search or write to anyone.

Give the Smallest Role That Works

Raising everyone to Administrator makes the message disappear, and it is the wrong fix. NIST defines least privilege as granting each user the minimum authorizations needed for the job. An Editor who needs one plugin screen should get that capability through a role plugin or a custom role, not the keys to the whole site.

Agencies meet this case directly when a client holds an Editor account and asks for Settings. If you manage many client sites, the reseller hosting page describes the account structure, and the open registration guide explains why the default role for new users must stay low.

Which Cause Do You Have? Check Your Symptoms

The four questions below follow the decision table. The result names the likeliest cause and points at the section with the fix. It reads nothing from your site, so every answer comes from you.

Find Your Cause in Four Questions

Which screens show the message? Was that plugin recently deactivated, deleted or replaced? Did you recently move the site, restore a backup or change the table prefix? What role does the Users screen show for your account?

Answer the questions above and the likely cause appears here.

Read the matching fix

What the Lab Measured About Not Allowed to Access This Page

The numbers below come from a lab on one workstation, not from an AHosting server. I installed WordPress 7.1.3 on PHP 8.5.10 with the SQLite database plugin from WordPress.org, created an Administrator, an Editor and a user with no role, and requested each page with curl. The results are about how core behaves, and they say nothing about our hosting accounts.

State	Request	Status	Exact message
Administrator	Settings screen	200	No
Editor	Settings screen	403	Yes
User with no role	Dashboard	403	Yes
Editor	Dashboard	200	No
Editor	Plugin page needing manage_options	403	Yes
Administrator, plugin active	That plugin page	200	No
Administrator, plugin deactivated	That plugin page	403	Yes
Administrator	Address that never existed	403	Yes
Administrator, old prefix on either or both records	Dashboard, Settings, Plugins	403	Yes
Editor	Users screen	403	No: a different sentence

WordPress 7.1.3 lab results: ten states, with the status code and whether the exact message appeared

Two limits apply. I did not test multisite, a real migration plugin, or MySQL, and I did not test an HTTPS or domain change. Therefore this guide makes no claim about those cases.

What Your Host Can and Cannot Change

No host can change which roles may open which screens, because that logic lives in WordPress. A host can give you the tools to repair the records, and it can read the evidence with you. That is the useful boundary.

If the login itself loops instead of refusing you, that is a different failure. In that case read the redirect loop guide, because the fix lives in a redirect rule, not in a role.

If the fix above did not work, open a ticket with the exact address you were opening and the role your account shows on the Users screen, and we will look at it with you. Please leave out passwords and database exports. Neither is needed to read the cause.

Frequently Asked Questions: Not Allowed to Access This Page

What does the 403 error mean in WordPress when you are not allowed to access this page?

Specifically, the 403 is the HTTP status WordPress sends with the message after it checks your account against the admin menu. It means WordPress ran, found the page, and refused you, so the cause sits in your plugins, your role or your database, not in the web server. The decision table in this guide matches each symptom to its fix.

Why does WordPress 7.1 say you are not allowed to access this page after a plugin is deactivated in 2026?

In practice, a deactivated plugin stops registering its menu page, so the saved bookmark points at a page WordPress no longer knows. In the lab, an administrator got a 403 with the exact message on that URL and a normal 200 on the Dashboard. Reactivate the plugin, or open the screen from the menu instead of the bookmark.

Is a missing role vs a missing plugin page the reason you are not allowed to access this page in 2026?

Specifically, you can tell them apart with one request. A missing role fails every wp-admin screen including the Dashboard, while a missing plugin page fails only that one address and the Dashboard still opens. Open the Dashboard first, then read the rest of the guide for the matching fix.

Editor vs Administrator: which WordPress screens say you are not allowed to access this page?

For example, an Editor can open Posts but gets the message on Settings, because the Settings menu entry requires the manage_options capability and the Editor role does not carry it. An Administrator opens both. The lab table in this guide lists the exact requests and the results.

Can I fix not allowed to access this page errors in phpMyAdmin on an AHosting cPanel account?

Specifically, yes, when the cause is a prefix mismatch. The AHosting plan pages list phpMyAdmin, so two UPDATE statements can rewrite the old prefix in the user meta table and in the roles option. Export the database first, because an UPDATE cannot be undone, and replace the example prefixes with your own.

Does AHosting WordPress hosting include WP-CLI access to change a user role in 2026?

Specifically, the AHosting WordPress hosting page lists WP-CLI access and a jailed SSH shell, so the documented command wp user set-role can change one account. It writes only that user, though, and the lab showed a stale roles option alone is enough to lock out every user. Check the plan page for your own account before relying on it.

Which two database records decide whether WordPress 7.1.3 treats a user as an administrator?

Specifically, one is the user meta row named after the table prefix plus capabilities, and the other is the options row named after the prefix plus user_roles. The first says which role the user holds, and the second says what that role may do. If either row carries the wrong prefix, WordPress finds no capabilities and refuses every admin screen.

Why does every wp-admin screen say you are not allowed to access this page after a migration to a new cPanel host?

Specifically, the likely cause is a table prefix that changed in the move, or tables imported under a different one, while the stored keys still carry the old prefix. WordPress builds the capabilities key from the current prefix, finds nothing, and treats your account as having no role. All three prefix cases in the lab returned the message on the Dashboard, the Settings screen and the Plugins screen.

Will AHosting support look at a not allowed to access this page error with me if I open a ticket?

Specifically, yes. Open a ticket with the exact address you were opening and the role your account shows on the Users screen, and we will look at it with you. Please leave out passwords and database exports, because neither is needed to read the cause.

How can I tell a WordPress 403 vs a web server 403 when I am not allowed to access this page?

In practice, read the page itself. The WordPress version carries the sentence Sorry, you are not allowed to access this page and the browser title WordPress Error, because WordPress printed it. A 403 page without that sentence was produced before WordPress ran, so changing roles or prefixes will not help.

October 20, 2026

ERR_TOO_MANY_REDIRECTS in WordPress: Find the Looping Rule With curl

What ERR_TOO_MANY_REDIRECTS Means in WordPress
- Why the ERR_TOO_MANY_REDIRECTS Loop Is Rarely a WordPress Bug
Read the ERR_TOO_MANY_REDIRECTS Chain With curl Before You Change Anything
- The Redirect Loop Signature Table for ERR_TOO_MANY_REDIRECTS
Cause 1: A Force-HTTPS Rule Behind a Proxy Causes ERR_TOO_MANY_REDIRECTS
Cause 2: FORCE_SSL_ADMIN Produces an ERR_TOO_MANY_REDIRECTS Loop on wp-admin Only
Cause 3: A www and Non-www Fight Creates an ERR_TOO_MANY_REDIRECTS Loop
- Why the Scheme Alone Rarely Triggers This One
Cause 4: Two HTTPS Rules Cause the Last ERR_TOO_MANY_REDIRECTS Pattern
What Our ERR_TOO_MANY_REDIRECTS Lab Measured
A Five-Step ERR_TOO_MANY_REDIRECTS Fix Order That Avoids Guessing
What to Record Before You Ask for Help With ERR_TOO_MANY_REDIRECTS
When ERR_TOO_MANY_REDIRECTS Points at Something You Cannot Edit
Frequently Asked Questions: ERR_TOO_MANY_REDIRECTS in WordPress

TL;DR

ERR_TOO_MANY_REDIRECTS means two layers keep sending the browser to each other. Run curl -sIL once, read the Location headers, and the repeating pair names the layer to fix.

isten: an ERR_TOO_MANY_REDIRECTS loop is two rules disagreeing, and the redirect chain shows which two. By Matt Chrust, Director of Business Development, AHosting.

What ERR_TOO_MANY_REDIRECTS Means in WordPress

ERR_TOO_MANY_REDIRECTS is the browser telling you that a request was redirected, and the redirect was redirected, and so on until it gave up. The message is not a WordPress error. WordPress is one of the two parties in the argument, and finding the other party is the whole job.

The give-up point is a published number. The Fetch standard says that when a request’s redirect count reaches 20 the browser returns a network error (Fetch standard, HTTP-redirect fetch), and Chromium sets its own limit to 20 (Chromium url_request.h).

Why the ERR_TOO_MANY_REDIRECTS Loop Is Rarely a WordPress Bug

A loop needs two rules that each think they are right. One says the canonical address is HTTPS, the other cannot tell that the visitor already arrived over HTTPS. Or one says www, and another says non-www. WordPress ships with parts of both rules, which is why the loop looks like a WordPress problem, but the second rule is almost always something you or a layer in front of the site added.

Read the ERR_TOO_MANY_REDIRECTS Chain With curl Before You Change Anything

Do not start by disabling plugins. Start by looking at the chain, because the chain tells you which of four causes you have. In a terminal, run curl -sIL --max-redirs 5 https://example.com/wp-admin/, replacing the address with the failing one. The -I flag asks for headers only, -L follows redirects, and --max-redirs 5 stops the output after five hops so you can read it.

curl keeps no cache, so it shows what the server sends today, not what your browser remembers from an hour ago. Read only the Location lines. A loop is any URL that shows up twice.

The Redirect Loop Signature Table for ERR_TOO_MANY_REDIRECTS

We reproduced the first three loops below in a lab and recorded the Location pattern each one prints. The fourth row is the pattern expected when two rules point opposite ways, and we did not reproduce it. Match your curl output to a row, then jump to the section named in the last column.

What repeats in the Location lines	Where the loop appears	Likely cause	Section
The same `https://` URL, forever	Every page	A force-HTTPS rule that cannot see HTTPS behind a proxy	Cause 1
The same `https://` URL for `/wp-admin/` only	Login and dashboard	`FORCE_SSL_ADMIN` with `is_ssl()` false	Cause 2
`https://www.` then `https://` then `https://www.`	Front-end pages	Home URL host and a second rule disagree about www	Cause 3
`http://` to `https://` to `http://`	Every page	Two HTTPS rules in different layers pointing opposite ways	Cause 4

The Redirect Loop Signature Table: four ERR_TOO_MANY_REDIRECTS loop patterns and where to look first.

Cause 1: A Force-HTTPS Rule Behind a Proxy Causes ERR_TOO_MANY_REDIRECTS

This is the loop to rule out first whenever a CDN or reverse proxy sits in front of the site, and it is the one the diagram below shows. A CDN or reverse proxy accepts the visitor over HTTPS, then talks to your server over plain HTTP. A force-HTTPS rule at the origin sees an HTTP request, answers with a 301 to the HTTPS address, and the visitor comes straight back to the proxy. The origin never learns the visitor was already secure.

How WordPress Decides a Request Is HTTPS

WordPress reads two server variables. The function is_ssl() returns true when $_SERVER['HTTPS'] is on or 1, or when no HTTPS variable exists and the port is 443 (WordPress 7.1.3, load.php lines 1659 to 1673). It does not read the X-Forwarded-Proto header a proxy adds. Behind a proxy that ends TLS, both variables describe the plain HTTP leg, so is_ssl() is false on every request.

The wp-config.php Fix for This ERR_TOO_MANY_REDIRECTS Loop

The WordPress developer documentation describes exactly this case: a site behind a reverse proxy that provides SSL, itself hosted without SSL, sends requests into an infinite redirect loop, and the remedy is to configure WordPress to recognize HTTP_X_FORWARDED_PROTO (Administration Over SSL). In practice that means a few lines in wp-config.php, above the require_once for wp-settings.php: if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) { $_SERVER['HTTPS'] = 'on'; }. Our lab used the same logic and it turned 51 requests into one (results below). Only use it when every request really arrives through your proxy, because a client that reaches the origin directly could send that header itself. Some proxies send a comma-separated list such as http,https, which the same page warns about, so test the value you actually receive.

The Second Way Out of This ERR_TOO_MANY_REDIRECTS Loop

The header trick is one fix, and changing the connection is the other. If the proxy connects to your server over HTTPS instead of plain HTTP, the web server itself reports a secure request, so is_ssl() is true with no code change at all. Which of the two you choose depends on whether the origin has a valid certificate for the proxy to connect to, and on who controls the proxy settings. Either way the goal is identical: the layer that decides to redirect must be told what the visitor actually used.

On Cloudflare this choice has a name: the SSL/TLS encryption mode. Flexible is the mode that produces this loop, because Cloudflare serves the visitor over HTTPS and then fetches from your origin over plain HTTP, which is exactly the arrangement the diagram above shows. In the Cloudflare dashboard, select the site, open SSL/TLS, then Overview, and change the mode from Flexible to Full (strict). Full (strict) requires a valid certificate on the origin, while Full accepts a self-signed one and still encrypts the leg to your server. Change the mode first and retest with curl before you edit wp-config.php, because the header fix ends the loop while leaving the connection to your server unencrypted.

Cause 2: FORCE_SSL_ADMIN Produces an ERR_TOO_MANY_REDIRECTS Loop on wp-admin Only

If the public pages load and only /wp-admin/ or wp-login.php loops, suspect this cause first. Two places in core redirect to HTTPS when FORCE_SSL_ADMIN is on and is_ssl() is false. The login file does it at line 15 of wp-login.php, and auth_redirect() does it for dashboard URLs at lines 1281 and 1293 of pluggable.php (WordPress 7.1.3).

The front end is untouched because neither code path runs there. That asymmetry is the clue, and it is why people lose an afternoon editing public-page rules that were never involved. The fix is the same as Cause 1, since both come from is_ssl() being false behind a TLS-terminating layer: make the HTTPS variable reflect the real request before wp-settings.php loads.

Cause 3: A www and Non-www Fight Creates an ERR_TOO_MANY_REDIRECTS Loop

WordPress sends the browser to the host in its Home URL setting. The canonical redirect takes its target host from home_url() (canonical.php lines 602 to 605), and it only acts when the difference is no-www versus yes-www (lines 731 to 738). If your Home URL says www and another layer sends www traffic to the bare domain, the two bounce between hosts.

The second rule can be a redirect in a DNS or proxy panel that was set up before the WordPress address changed, or the reverse. The signature is easy to spot in curl: the Location lines alternate between two hostnames. Pick one host, then set that host in the Home URL setting and in every rule that mentions it.

Why the Scheme Alone Rarely Triggers This One

The canonical comparison arrays hold host, path, port and query, and no scheme (canonical.php lines 740 to 750). So a scheme mismatch by itself does not make redirect_canonical() loop. It also runs only on the front end, because the function returns early when is_admin() is true (line 63), which matches the pattern that a www loop breaks public pages while the dashboard keeps working.

Cause 4: Two HTTPS Rules Cause the Last ERR_TOO_MANY_REDIRECTS Pattern

A site can end up with a force-HTTPS rule in .htaccess, another from a security or SSL plugin, and a third in the proxy panel. When they all agree, nobody notices. When one of them uses a different host or a different port, the browser alternates between two targets.

Apache’s own documentation says a redirect in a dedicated HTTP virtual host is the cleanest approach to forcing HTTPS, with a mod_rewrite alternative for .htaccess use (Apache mod_rewrite: when not to use it). The practical rule that follows is simple: one force-HTTPS rule, in one place. Where you cannot edit the virtual host, the single rule lives in .htaccess or in the plugin, never both. Our guide to free SSL and domain management covers where certificates and domain redirects normally sit.

What Our ERR_TOO_MANY_REDIRECTS Lab Measured

We reproduced three of the loops on 19 October 2026 so the numbers in this guide are first-hand. The setup was a PHP 8.5.10 origin that uses WordPress 7.1.3’s own is_ssl() and the redirect branches quoted above, a small TLS edge that ends HTTPS and forwards plain HTTP with X-Forwarded-Proto: https, and curl following redirects. It is a lab on one machine, not a customer site, and it is labeled that way so nobody reads it as production data.

Lab case	Redirects followed	Requests the origin logged	Outcome
Force-HTTPS rule behind the edge	50	51	curl stopped: Maximum (50) redirects followed
FORCE_SSL_ADMIN branch on /wp-admin/	50	51	Same stop, only on the dashboard path
www to non-www edge rule vs canonical host	50	51 (26 non-www, 25 www)	Hosts alternated on every hop
Same rule with X-Forwarded-Proto trusted first	0	1	HTTP 200 on the first request

Lab results, 19 October 2026: three loops reproduced and one fixed with the X-Forwarded-Proto line.

Two things stand out. Each loop costs the origin one request per hop, so a browser that stops at 20 redirects will have cost the origin about 21 requests, which is a quiet source of server load on a busy site. And the fix for the proxy case changed the result from 51 requests to one.

A Five-Step ERR_TOO_MANY_REDIRECTS Fix Order That Avoids Guessing

Run curl -sIL --max-redirs 5 on the failing URL and write down the repeating Location values.
Match them to the signature table, then change one rule only.
Retest with curl, then in a private window, so a remembered redirect or an HSTS upgrade does not hide your fix (how HSTS works).
If the loop only appears after a move, compare the redirect rules on the old and new site, starting with our WordPress migration steps.
Only now disable plugins one at a time, because a plugin that adds a redirect will show up as a rule in the chain.

If you run a CDN in front of the site, our guide to LiteSpeed Cache and a CDN together lists the settings that tend to collide with an HTTPS redirect.

ERR_TOO_MANY_REDIRECTS Loop Diagnoser

Where does the loop appear? What sits in front of WordPress?

Show the likely cause

Pick both answers, then press the button.

What to Record Before You Ask for Help With ERR_TOO_MANY_REDIRECTS

A loop report is only as useful as the evidence attached to it. Collect four things first, because each one rules out a cause in seconds. The exact URL that loops, copied from the address bar. The full output of curl -sIL --max-redirs 5 for that URL. Whether a CDN, proxy or DNS-level redirect service sits in front of the site. And the last change made before it started, whether that was a migration, a new SSL plugin, or an edit to the WordPress Address or Site Address fields.

That last item matters more than it looks. A loop that begins right after a change was almost certainly caused by that change, and reversing it is faster than any diagnosis. The signature table then tells you what you reversed, which is how you avoid repeating it.

When ERR_TOO_MANY_REDIRECTS Points at Something You Cannot Edit

Some loops live in a layer you do not control: a proxy panel, a reseller’s DNS service or a managed-hosting rule. When the curl output names a hostname that your account does not manage, you are done diagnosing and the next step is a ticket with that output attached. If your hosting and TLS arrangement is the open question, our SSL certificate options page and the shared hosting plans list what each plan includes.

For the hosting side of a WordPress setup, see our WordPress hosting plans. If the loop is already live and the curl output is in front of you, open a ticket with that output, with any Set-Cookie lines removed, and we will look at it with you.

Frequently Asked Questions: ERR_TOO_MANY_REDIRECTS in WordPress

How do I fix ERR_TOO_MANY_REDIRECTS on a WordPress site?

Specifically, run curl -sIL on the failing URL and read the Location headers. The two URLs that repeat name the two layers fighting, and the fix is to make one layer stop redirecting.

Why does ERR_TOO_MANY_REDIRECTS appear only on wp-admin and the login page in 2026?

Typically because FORCE_SSL_ADMIN is on while WordPress cannot see that the request arrived over HTTPS. The login code redirects to HTTPS, the proxy forwards plain HTTP again, and the loop never ends. The signature table above shows the curl output to expect.

Does a 301 vs 302 status matter when debugging an ERR_TOO_MANY_REDIRECTS loop?

In practice, it matters for the browser, not for the cause. A browser may remember a permanent redirect, so test with curl or a private window, because curl keeps no cache and shows every hop as the server sends it.

Should an .htaccess rule vs the WordPress address setting force HTTPS in 2026 without an ERR_TOO_MANY_REDIRECTS loop?

Ultimately, use one place only. Apache documents a redirect in a dedicated HTTP virtual host as the cleanest approach, with mod_rewrite as the .htaccess alternative, and a second HTTPS rule in a plugin or proxy is how the loops start.

Will moving to AHosting stop an ERR_TOO_MANY_REDIRECTS loop that started on my old host?

In fact, not by itself, because the loop comes from redirect rules that travel with the site files and database. Instead, compare the curl chain before and after the move, and check the migration steps in our migration guide before changing any rule.

What should I send AHosting support for an ERR_TOO_MANY_REDIRECTS loop in 2026?

In particular, send the output of curl -sIL –max-redirs 5 on the failing URL with any Set-Cookie lines removed, plus whether a CDN or proxy sits in front of the site. That output shows which hostnames and schemes repeat, so nobody has to guess the cause.

Can page caching on AHosting hide or cause an ERR_TOO_MANY_REDIRECTS loop in wp-admin?

In contrast to public pages, a logged-in admin session is uncacheable, so every wp-admin request reaches PHP and the redirect code runs each time. Caching therefore neither causes nor cures that loop, and the fix lives in the redirect rules.

How many redirects does a browser follow before showing ERR_TOO_MANY_REDIRECTS?

Specifically, the Fetch standard stops at 20 redirects and Chromium sets its limit to 20. Command-line curl follows up to 50 by default when you ask it to follow redirects, which is why a loop shows a count of 50 there.

Why does ERR_TOO_MANY_REDIRECTS appear after I set www as the preferred domain?

Notably, WordPress sends non-www requests to the host in its Home URL setting, so a second rule that sends www back to non-www at the DNS panel, proxy or .htaccess makes the two bounce forever. Keep one preferred host in both places.

Can HSTS keep an ERR_TOO_MANY_REDIRECTS loop alive after I fix the server in 2026?

Indeed, a site that sent an HSTS header makes the browser upgrade http:// URLs for that domain to HTTPS on its own, so an HTTP-based test can behave differently in the browser than in curl. Retest with curl and a fresh private window before changing rules again.

October 19, 2026

Open Registration With Privileged Default Role? What Site Health Is Telling You

Open Registration With Privileged Default Role: What It Means in Site Health
How Open Registration With Privileged Default Role Gets Set Without the Settings Screen
How to Fix Open Registration With Privileged Default Role in Two Minutes
- Change the two options in Settings, General
- Read the open registration options directly in the database
Check Whether Anyone Used Your Open Registration
- What to do about an account you did not create
Which Default Roles Trigger the Open Registration With Privileged Default Role Warning
Why Author and Contributor Pass the Open Registration With Privileged Default Role Check
What Site Health Cannot Tell You About Open Registration
When Open Registration Is Intentional: Choosing a Safe Default
Check Your Settings for Open Registration With Privileged Default Role
Keep Registration Closed Without Another Plugin
Frequently Asked Questions About Open Registration With Privileged Default Role

TL;DR

Open registration with privileged default role means anyone can sign up and become an Editor or Administrator. Set New User Default Role to Subscriber in Settings, General, then check Users for accounts you did not create.

Listen: the Site Health registration warning compares two role names, and the Settings screen cannot have set it. By Matt Chrust, Director of Business Development, AHosting.

Open Registration With Privileged Default Role: What It Means in Site Health

Open registration with privileged default role is a critical Security item that WordPress 7.0 added to Tools, Site Health. It appears when two options in your database agree on something dangerous: anyone may register, and every new account lands as an Editor or an Administrator. We read the check in WordPress 7.1.3 to see exactly what it compares, and what we found changes what you should do first.

The short version is a two-minute fix followed by a check you should not skip. This guide covers both, plus a gap in the test itself: it flags two roles and quietly passes three that can still hurt you.

Here is the mechanism. The option users_can_register controls the Anyone can register box, and default_role controls New User Default Role. The registration form never asks a visitor which role they want. It calls wp_create_user() with a name, a password and an email, and wp_insert_user() then fills in the role from default_role. Combine a public form with a powerful default, and a stranger gets a privileged account in one submission.

Site Health runs the check as a direct test when the screen loads. It reads both options with get_option(), and the item turns critical only when users_can_register is truthy and default_role is exactly editor or administrator, per the check in WordPress 7.1.3. The description it prints reads: Registration is open to anyone, and the default role is set to a privileged role.

How Open Registration With Privileged Default Role Gets Set Without the Settings Screen

Because the Settings screen no longer lets you choose a privileged default, a site that shows this item had its options written some other way. WordPress 7.0 added a filter named default_role_dropdown_excluded_roles and set it to exclude administrator and editor from the dropdown, according to the General Settings source. The one exception is a role that is already saved: it stays in the list so you can see it and change it.

That leaves a short list of ways the combination appears:

The site chose Editor before the exclusion arrived in WordPress 7.0, and nobody has revisited the value since.
A plugin, theme or code snippet wrote the option with update_option(), or a migration or staging copy carried an old value over.
Someone with Administrator or database access edited the row directly.
A snippet emptied the exclusion filter, so the dropdown offers Editor again and an Administrator picked it.

The check cannot tell you which of these happened. It reads two values and has no history. Treat it as a configuration error until the Users screen says otherwise, and read the account check below before you close the item.

How to Fix Open Registration With Privileged Default Role in Two Minutes

Change the two options in Settings, General

Log in as an Administrator and open Settings, then General.
Find the Membership row. If you do not need public sign-ups, untick Anyone can register.
If you do need sign-ups, set New User Default Role to Subscriber.
Click Save Changes, then reload Tools, Site Health and open the Status tab to run the check again.

On a Multisite network the Membership row does not appear on the single-site General screen, because the source only renders it when is_multisite() is false. The test still reads the site-level options on a network, and its Change these settings link points to that same screen, so network owners will need the database method below.

Read the open registration options directly in the database

If the Settings screen will not load or will not save, read the values where they live. In phpMyAdmin or any database tool your plan gives you, open the options table and run SELECT option_name, option_value FROM wp_options WHERE option_name IN ('users_can_register', 'default_role');. Your table prefix may differ from wp_, but the two option names are the same on every site.

A value of 1 in users_can_register means the form is open, and subscriber is the safe default. If a value flips back after you change it, something writes it on every request. A plugin or must-use plugin is the usual suspect, so deactivate plugins one at a time until the value stays put.

Check Whether Anyone Used Your Open Registration

Fixing the settings closes the door. It does not tell you who already walked through, so check the accounts before you move on. Open Users, then All Users, and use the Administrator and Editor links above the list. Open every account you do not recognize and read its role on the profile screen.

The database gives a faster view of the newest accounts. Run SELECT ID, user_login, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20; to list the twenty most recent sign-ups with their registration time. The user_registered column exists in the core schema, so the query works on every install.

What to do about an account you did not create

If an unknown Administrator or Editor exists, treat the site as exposed and work through these steps in order:

Write down the unknown account’s username and registration time before you touch anything.
Change the password of every real Administrator, and use Log Out Everywhere Else on each profile.
Reassign any content the unknown account owns, then delete the account.
Open Plugins and Appearance, Themes and look for anything you did not install, because an Administrator can add both.
Restore from a clean backup if you have one that predates the account.

Then fix the two options so the same thing cannot happen again. CWE-269, Improper Privilege Management, is the name security teams give to handing an account more access than it needs, and this check is a small, specific guard against it.

Which Default Roles Trigger the Open Registration With Privileged Default Role Warning

The role you pick decides what a stranger can do in the first minute. The table below turns the capability grants in WordPress 7.1.3 into plain terms and shows which rows the check flags. It is our reading of the core role definitions for a single-site install.

Default role	Site Health result	What a stranger can do on day one	Capabilities granted by core
Administrator	Critical	Take over the site: activate and edit plugins, edit themes, change settings, edit other users	`activate_plugins`, `edit_plugins`, `edit_themes`, `edit_users`, `manage_options`
Editor	Critical	Publish and edit any post, upload files, save raw HTML	`edit_others_posts`, `publish_posts`, `upload_files`, `unfiltered_html`
Author	Good (not flagged)	Publish and edit their own posts and upload files	`publish_posts`, `edit_published_posts`, `upload_files`
Contributor	Good (not flagged)	Write posts and submit them, but not publish	`edit_posts`
Subscriber	Good (not flagged)	Read only, and manage their own profile	`read`

AHosting Default Role Risk Table: which WordPress 7.1.3 default roles the open registration check flags, and what each grants. Source: wp-admin/includes/schema.php, populate_roles_160().

Read the table from the bottom up. Each step adds a power, and the check draws its line above Author. The line is reasonable for a quick warning, but it is not the line a careful site owner would draw. The role definitions are also documented in the WordPress roles and capabilities guide, which lists the full capability set for every role.

Why Author and Contributor Pass the Open Registration With Privileged Default Role Check

The test is a strict comparison against two role names. In code terms it asks whether default_role is in the list editor, administrator, and nothing else. That has two consequences you should know about.

First, Author passes. A site with Anyone can register on and Author as the default shows a green item, yet every stranger who signs up can publish posts and upload files. Green here does not mean safe.

Second, custom roles pass. Membership and course plugins create their own role slugs, and the test compares the slug, not the capabilities behind it. A role named member that carries every Editor capability looks identical to a harmless one. Open the plugin that created the role and read what it grants.

The principle behind both cases is least privilege: give an account only what its job needs. The OWASP Authorization Cheat Sheet puts it as a design rule, and for open sign-ups it reduces to one line. Choose Subscriber unless you have a written reason for anything else.

What Site Health Cannot Tell You About Open Registration

The item is a two-value comparison, so it misses several things a careful owner would want to know. It does not look at your existing accounts, so a site that was already abused still shows green once the options are fixed. It does not check whether new sign-ups must confirm an email address or pass any approval step.

The test also reads only the site-level users_can_register option. On a Multisite network, new-site registration is controlled by a separate network setting that the source reads with get_site_option() in a different file, and this test never looks at it. Treat the item as a prompt to review your sign-up setup, not as a verdict on it.

Finally, a passed check says nothing about plugins that run their own registration forms. A form from a plugin can create accounts with any role the plugin chooses, whatever your General settings say. If you use such a plugin, read its role setting in the plugin itself.

When Open Registration Is Intentional: Choosing a Safe Default

Some sites need public sign-ups: communities, course sites, member areas and shops. The check is not telling you to close registration. It is telling you not to hand out Editor or Administrator while registration is open. For an intentional sign-up form, the safe pattern is short.

Leave New User Default Role on Subscriber, so a new account can do nothing but read.
Grant any higher role by hand or through a plugin rule you have read, never through the default.
Review the newest accounts on a schedule, using the database query above or the Users screen.
Read the capabilities of any custom role before you accept it as a default, because the test will not.

If a membership plugin insists on its own default role, that is a decision about what a stranger should be allowed to do in the first minute. Make it deliberately, with the role table above beside you.

Check Your Settings for Open Registration With Privileged Default Role

Pick your two settings below. The checker applies the same logic as the WordPress 7.1.3 test, then adds the verdict the test leaves out for Author, Contributor and custom roles.

Registration and Default Role Checker

Anyone can register New User Default Role

See AHosting WordPress hosting

Keep Registration Closed Without Another Plugin

A fresh WordPress install is safe on both options. The core install defaults set users_can_register to 0 and default_role to subscriber, so every dangerous combination is something that was changed afterward. That is why this item deserves attention even though it takes two minutes to fix.

If you do run public sign-ups, keep Subscriber as the default and promote people by hand. Our guide to keeping a WordPress site spam-free covers registration controls and server-level blocking.

Account isolation limits the damage if one site is compromised, as we explain in WordPress hosting security beyond plugins. Two other Site Health items have their own guides: the potentially public log file warning and the auto-update problem check.

If the Site Health line or the account list still does not make sense, open a ticket with the exact line Site Health printed and the usernames and roles of your Administrator and Editor accounts, with no passwords or email addresses, and we will look at it with you. The WordPress default of Subscriber applies on every plan, from web hosting to a shop on WooCommerce hosting.

Frequently Asked Questions About Open Registration With Privileged Default Role

What does open registration with privileged default role mean in WordPress 2026?

Specifically, it means Anyone can register is switched on while New User Default Role is Editor or Administrator, so every new sign-up becomes a privileged user. WordPress added the check in version 7.0, and the role table above shows exactly which values trip it.

Is open registration with privileged default role a real risk when Anyone can register is checked?

Indeed, it is a real risk. The registration form never asks which role a visitor wants, so anyone who can submit it receives the saved default role, unless a plugin adds an approval step of its own. Fixing the default role closes the door, and checking the Users screen shows whether anyone already walked through.

How do I fix open registration with privileged default role in 2026 if Settings will not save?

Typically, something rewrites the option on every request, such as a plugin or a must-use plugin. Set default_role to subscriber in the options table, reload Site Health, and if the value flips back, deactivate plugins one at a time until it stays. The code that writes the option is the real problem to remove.

What are the default user roles in WordPress for new registrations?

Specifically, a fresh WordPress install leaves Anyone can register off and sets New User Default Role to Subscriber, as the install defaults in core 7.1.3 show. The five built-in roles are Administrator, Editor, Author, Contributor and Subscriber, and only Subscriber is read-only.

Editor vs Administrator as the default role: which one triggers open registration with privileged default role?

In fact, both do. The test compares default_role to the two strings editor and administrator and turns critical on either match. Administrator is worse, because that role can edit plugins and themes, while Editor can publish any post and save raw HTML.

Subscriber vs Contributor in 2026: which default role is safer after open registration with privileged default role is fixed?

Overall, Subscriber is safer. It holds only the read capability, while Contributor adds edit_posts, which lets every stranger create draft posts inside your admin. Choose Contributor only when you want public submissions and will review each one.

Who can change the options behind open registration with privileged default role on an AHosting account?

Notably, only your site’s Administrators, code running inside your site, and anyone with access to your account’s database. The two options live in your own WordPress database, so the warning is a question about your site’s configuration and access, not about the server.

Can I open a ticket with AHosting about open registration with privileged default role on my site?

Specifically, yes: send the exact line Site Health printed plus the usernames and roles of your Administrator and Editor accounts, with no passwords or email addresses. We will look at it with you. Fix the two options first if you can, because that takes about two minutes.

Do AHosting accounts see the same open registration with privileged default role check as any other host?

Indeed, because the check lives in WordPress core, not in the server. It behaves the same on any host running WordPress 7.0 or later, and the options it reads are stored in your site’s own database wherever it is hosted.

Why does Site Health 7.1.3 pass an Author default role under open registration with privileged default role?

In fact, the test only lists editor and administrator, so Author, Contributor and every custom role slug pass. An Author can publish posts and upload files, which makes Author a poor default for open sign-ups even though the item stays green.

October 16, 2026

PHP Default Timezone Is Invalid? What WordPress Is Really Checking

PHP Default Timezone Is Invalid: What the Site Health Check Tests
- The one-line test behind the critical label
- What goes wrong when PHP default timezone is invalid
Why Server Settings Cannot Cause or Clear PHP Default Timezone Is Invalid
Why Changing the WordPress Timezone Does Not Clear PHP Default Timezone Is Invalid
- Region names beat fixed offsets
- Store UTC, convert only for display
How to Find What Triggers PHP Default Timezone Is Invalid
How to Fix PHP Default Timezone Is Invalid Without Shifting Dates
Where Hosting Matters for PHP Default Timezone Is Invalid
- Related Site Health checks worth reading next
Frequently Asked Questions: PHP Default Timezone Is Invalid

Listen: the Site Health timezone warning is a check on code that runs after WordPress loads, not a server setting. By Matt Chrust, Director of Business Development, AHosting.

TL;DR

PHP default timezone is invalid means a plugin, theme or custom file changed PHP timezone after WordPress set it to UTC. Your server settings did not cause it and cannot clear it. Search wp-content for date_default_timezone_set(), update or remove whatever calls it, and use wp_date() when you need local times.

PHP Default Timezone Is Invalid: What the Site Health Check Tests

If Tools > Site Health lists a critical issue called PHP default timezone is invalid, your hosting did not break anything. Something running inside WordPress changed the PHP timezone after WordPress had already set it. That is all the check detects. It is also why the usual advice to edit php.ini does nothing. This guide shows what the test compares, how to find the code that trips it, and how to fix it without shifting your dates.

First, the exact wording. The critical label reads PHP default timezone is invalid. Its description says PHP default timezone was changed after WordPress loading by a date_default_timezone_set() function call. It adds that this interferes with correct calculations of dates and times.

The one-line test behind the critical label

In the WordPress 7.1.3 source, the test is get_test_php_default_timezone(), and it is short enough to read in one sitting. Its logic is a single comparison. If date_default_timezone_get() returns anything other than UTC, the status becomes critical. Specifically, the comparison sits at line 1168 of class-wp-site-health.php.

There is no warning tier and no list of acceptable zones. Moreover, the message never names the plugin responsible. Europe/Malta, America/Chicago and a typo all fail in exactly the same way, because the test only asks whether the answer is UTC.

What goes wrong when PHP default timezone is invalid

Core code assumes PHP is running on UTC and applies the site’s own offset when it formats a date. When a plugin moves PHP to another zone, code that calls PHP’s plain date() and code that calls wp_date() start giving different answers for the same timestamp. The mismatch equals the gap between the two zones.

The vendor of one popular booking plugin documents this exact error. They note that most plugins should not modify the PHP timezone, and that when one does, dates and times shift even when the correct timezone is configured in the plugin. In practice, a booking page that shows 9:00 for a visitor while the confirmation email says another hour is the usual symptom.

Therefore the label is a symptom, and the damage is whatever the changed zone does to your dates. A site with no date-sensitive plugins may never notice. A site with bookings, events, scheduled posts or order cutoffs will.

Why Server Settings Cannot Cause or Clear PHP Default Timezone Is Invalid

WordPress overwrites the server timezone at load

Here is the part most guides skip. Early in wp-settings.php, WordPress runs date_default_timezone_set( 'UTC' ), on line 73 of the 7.1.3 tag. The comment above it reads that WordPress calculates offsets from UTC. Whatever PHP was told before that line is discarded for the rest of the request.

That includes the date.timezone value in php.ini, a .user.ini file, and any timezone field in a cPanel PHP editor. The PHP manual describes the INI setting as the alternative to calling date_default_timezone_set() in a script, and the function simply wins because it runs later.

We checked the behavior with a three-line script on PHP 8.5.10 on a workstation, not a server. With date.timezone set to America/Chicago, the default read back as America/Chicago. After one call with UTC it read UTC. After a second call with Europe/Malta it read Europe/Malta. In short, the last call always wins, and WordPress makes the first call, so only code that runs after it can leave the zone changed.

What our shared servers do with php.ini and .user.ini

On our shared WordPress servers, PHP runs as each site’s own cPanel user under CloudLinux. A php.ini file inside the document root is never read, while a .user.ini file is read and refreshed on a cache of about five minutes. As a result, you can set date.timezone per site, and it will still be overwritten the moment WordPress loads.

The order in wp-settings.php matters too. After line 73, core loads must-use plugins at line 506 and regular plugins at line 582. Every one of those files runs after the reset, so any of them can change the zone, and the active theme does the same later still.

The Timezone Layer Table

Use this table to rule layers in or out before you touch anything. It is the same logic the infographic below draws as a request timeline.

Layer	Where it lives	Who sets it	Can it trigger the Site Health check?
Server default	php.ini or a cPanel PHP setting, `date.timezone`	You or your host	No. WordPress overwrites it with UTC at wp-settings.php line 73
Per-site file	`.user.ini` in the document root	You	No. The same overwrite applies
Site timezone	Settings, General, Timezone (options `timezone_string` and `gmt_offset`)	You	No. It is read for display by `wp_timezone()` and never sets PHP
Must-use plugin	`wp-content/mu-plugins`, loaded at line 506	A developer	Yes, if it calls `date_default_timezone_set()` and leaves the zone changed
Plugin or theme	`wp-content/plugins` and `wp-content/themes`, loaded after line 582	A developer	Yes, with the same condition

AHosting Timezone Layer Table: which timezone setting can trigger the PHP default timezone is invalid check

Why Changing the WordPress Timezone Does Not Clear PHP Default Timezone Is Invalid

Settings > General has its own timezone field, and many site owners change it hoping the critical label will clear. It will not. That setting is stored in the timezone_string and gmt_offset options, and wp_timezone() builds a date object from them whenever WordPress needs the site’s local time.

Specifically, wp_timezone_string() returns the saved zone name if there is one. Otherwise it builds a fixed offset such as +08:45 from gmt_offset. Neither path calls date_default_timezone_set(), so the PHP default stays on UTC unless other code moves it.

Region names beat fixed offsets

For the site setting, choose a named zone such as Europe/Malta over a manual offset. Named zones come from the tz database, which records that governments change daylight saving rules sometimes with little notice. A fixed offset cannot follow those changes, so the clock drifts twice a year.

Store UTC, convert only for display

The same idea appears in W3C guidance. An instant in time can be converted for display in any timezone, as the W3C working note on time and timezones explains. In other words, keep timestamps neutral and convert at the last step. That is exactly the job wp_date() does, and it is why changing PHP’s own zone is the wrong tool.

How to Find What Triggers PHP Default Timezone Is Invalid

The label gives you no file name, so the search is yours. Work from cheapest to most disruptive, and do all of it on a staging copy if you have one. Furthermore, take a backup before deactivating anything on a live site.

First Step: Search the files for date_default_timezone_set

With SSH or a terminal on your plan, run grep -rn date_default_timezone_set wp-content from the WordPress root. Without a terminal, use the cPanel File Manager to compress wp-content, download the archive, and run Find in Files in any code editor. The File Manager search box only matches file names, so it cannot find a function call. Check the plugins, themes and mu-plugins folders in the results.

Read each match before blaming it. A function that sets the zone, does its work, and then restores the previous zone is harmless, because the test only sees the final state. Similarly, a match inside a comment or a bundled date library that never runs on your site is noise. Only a call that leaves the zone changed matters.

Second Step: Ask WordPress what PHP is using

With WP-CLI, run wp eval 'echo date_default_timezone_get();'. It loads WordPress fully, so the answer includes whatever plugins and the theme did. UTC means the cause is not loading on that path. Anything else confirms the zone really is being changed.

Next, repeat the command with --skip-plugins, then with --skip-themes. If the answer flips back to UTC when plugins are skipped, the cause is a plugin. If it flips when the theme is skipped, look at functions.php and the theme’s included files.

Third Step: Bisect by deactivating plugins in batches

Without WP-CLI, deactivate half of your plugins and reload Tools > Site Health. Wait for the tests to finish. If the label clears, the culprit is in that half, so reactivate it in smaller groups. If it stays, the culprit is in the other half.

In practice, six to eight rounds find a single plugin among a hundred, and far fewer on a normal site. Avoid deactivating anything that handles payments or order processing on a live store during business hours, and test those on staging instead.

Fourth Step: Check the theme and must-use plugins

Plugins are the usual suspect, but a theme can do the same thing. Open the active theme’s functions.php and any child theme files. Moreover, look in wp-content/mu-plugins, because must-use plugins cannot be deactivated from the Plugins screen and are easy to forget.

Snippets pasted from old tutorials are a common source. A line added years ago to make a date display in a local zone often survives theme changes inside a code-snippets plugin. Search that plugin’s stored snippets too.

How to Fix PHP Default Timezone Is Invalid Without Shifting Dates

Update or replace the plugin that changes the zone

Start with an update, because vendors fix this once reported. If the current version still calls the function, send the developer the file name, the line number and one sentence: the PHP default timezone is invalid check fails because the plugin changes PHP’s zone after WordPress sets UTC. Developers respond to that, as the SSA guide above shows, because the fix is usually a small change to wp_date().

If the plugin is abandoned, replace it. Nothing about this warning justifies keeping code that changes global PHP state for every other plugin on the request.

Replace the call in your own code with wp_date()

If the call is your own snippet, delete the date_default_timezone_set() line. Then format times with wp_date( 'Y-m-d H:i', $timestamp ), which uses the site timezone automatically. For date objects, wp_timezone() or current_datetime() gives you the site zone without touching PHP.

Core’s own wp_date() accepts a true Unix timestamp and an optional timezone argument. As a result, one function covers both display in the site zone and display in any other named zone, with no global state involved.

Why forcing UTC back is the wrong fix

It is tempting to reset the zone from a later hook so the label turns green. However, that hides the symptom while the plugin keeps working from a different assumption, so its dates can stay wrong. Fix the code that changes the zone rather than the check that reports it.

Confirm that PHP default timezone is valid again

Reload Tools > Site Health after each change and wait for the tests to complete. The critical item moves to the passed list with the label PHP default timezone is valid once the zone reads UTC at test time. Then spot-check a scheduled post, a booking page and any date shown in an email.

PHP Default Timezone Is Invalid Layer Checker

Where did you set a timezone before the critical label appeared?

Your result appears here.

Still hunting through plugin folders? See AHosting WordPress hosting with cPanel

Where Hosting Matters for PHP Default Timezone Is Invalid

Hosting cannot clear this label, but it decides how easily you can run the search above. On a cPanel web hosting plan, File Manager and the PHP version selector cover every step in this guide that does not need a terminal. Our walkthrough of choosing a PHP version in cPanel covers the second one.

When you want to run grep and WP-CLI against many sites at once, a VPS with root access is the easier place to do it. For a single WordPress site, our WordPress hosting plans run on cPanel with File Manager and PHP version selection, which is all this hunt needs.

If you have followed every step and still cannot find the cause, open a ticket with the exact Site Health line and the list of plugins and must-use plugins in your account, and we will look at it with you.

Timezone problems rarely travel alone. If the same screen also shows a failed cron event, read what a failed scheduled event really means, because scheduled jobs depend on correct timestamps. For another PHP-side warning, see an active PHP session was detected. Finally, the auto-updates check matters here, because the plugin you need to update may be blocked from updating itself.

Frequently Asked Questions: PHP Default Timezone Is Invalid

How do I set the default timezone in PHP for WordPress in 2026?

In practice, you do not set it at all. WordPress forces PHP to UTC every time it loads, so the correct place for your local zone is Settings, General, Timezone. Use date.timezone in php.ini only for scripts that run outside WordPress.

Does the PHP default timezone is invalid warning mean my WordPress site is broken in 2026?

Specifically, no. The label only says some code changed PHP timezone after WordPress set it to UTC. Pages still load, but dates, schedules and booking times produced by that code can be off by the gap between the two zones.

Can AHosting change a server setting to clear PHP default timezone is invalid?

However, no server setting can clear it, because WordPress overwrites the server timezone with UTC at load. The check only fails when a plugin, theme or must-use file calls date_default_timezone_set() later, so the fix lives in that code.

Why does PHP default timezone is invalid appear after I install a booking or events plugin?

Typically, the plugin calls date_default_timezone_set() so its own date functions match the zone it expects. That works inside the plugin but leaves PHP changed for the rest of the request, which is exactly what the Site Health test compares against UTC.

WordPress timezone setting vs PHP date.timezone: which one controls my post dates in 2026?

In fact, the WordPress setting controls what visitors see, because wp_date() reads it through wp_timezone(). PHP date.timezone is replaced with UTC at load, so changing it never moves a post date on a WordPress site.

Editing the plugin file vs asking the developer to fix PHP default timezone is invalid: which is safer?

Therefore, ask the developer first. A hand edit disappears at the next plugin update and can change how that plugin formats dates. If you must edit, do it on a staging copy and send the vendor the file and line number.

How can I find which plugin triggers PHP default timezone is invalid without SSH access?

For example, deactivate plugins in small batches and reload Site Health after each one. The batch whose removal turns the label green contains the culprit. You can also download wp-content and search it on your computer for date_default_timezone_set.

Can I use AHosting cPanel to download plugin files and test PHP versions while tracking this down in 2026?

Overall, yes. AHosting WordPress hosting runs on cPanel, so File Manager can compress and download wp-content, and the PHP version selector lets you test another version. The file search itself happens on your computer.

Will a staging copy help me test fixes for PHP default timezone is invalid safely?

Indeed, a staging copy is the safest place to deactivate plugins in batches. The Site Health result is the same on staging, and you can watch dates and schedules for a day before touching the live site.

As a result of how core works, wp_date() formats any timestamp in the site timezone without touching PHP global state. Changing the PHP default affects every other plugin on the request, while wp_date() affects only the string you ask for.

October 15, 2026

Problems Auto-Updating Plugins and Themes? It Is a Filter Test, Not a Server Fault

Problems Auto-Updating Plugins and Themes: What the Warning Actually Tests
The Three Results of the Problems Auto-Updating Plugins and Themes Check
Why Site Health Reports Problems Auto-Updating Plugins and Themes as Critical
Finding the Code Behind Your Problems Auto-Updating Plugins and Themes Warning
- Constants that change what the dashboard shows
What the Problems Auto-Updating Plugins and Themes Check Cannot See
- Why the filter matters for security
Fixing Problems Auto-Updating Plugins and Themes on AHosting
- Replay the result before you change anything
- When to open a ticket
Frequently Asked Questions: Problems Auto-Updating Plugins and Themes

TL;DR

Your site may have problems auto-updating plugins and themes means one thing: code on your site is returning false from the auto_update_plugin or auto_update_theme filter for a made-up test plugin. It is not a cron fault, a permissions fault or a full disk. Critical means the dashboard still offers auto-updates that the filter overrides. Recommended means the filter and the dashboard agree that updates are off. Search your files for the filter, then reload Site Health.

Problems Auto-Updating Plugins and Themes: What the Warning Actually Tests

Site Health says Your site may have problems auto-updating plugins and themes, and the natural reaction is to hunt for a broken cron job, a permissions fault or a full disk. None of those is what this check looks at. The test never touches a file, never reads the cron schedule and never contacts WordPress.org. It asks a narrower question: has some code told WordPress to refuse plugin or theme updates while the dashboard still offers the switch? When the answer is yes, you get problems auto-updating plugins and themes in your Site Health list.

Listen: the Site Health auto-update warning is a filter test against a made-up plugin, not a cron, permissions or disk fault. By Matt Chrust, Director of Business Development, AHosting.

We read the source instead of the forum threads. This guide follows the WordPress 7.1.3 source tag, which we opened on October 14, 2026. The test is get_test_plugin_theme_auto_updates() at line 1815 of class-wp-site-health.php, and the warning label is set at line 1836. The actual decision is made further down in detect_plugin_theme_auto_update_issues(), which you can read on GitHub at lines 3192 to 3267. Core’s own comment on that function admits it is making educated guesses, because nobody can prove auto-updates are configured correctly from inside a request.

The short answer: the warning means a filter named auto_update_plugin or auto_update_theme returned false for a made-up plugin, so the per-plugin switches on your Plugins screen are probably being overridden. Here is the whole test in one diagram.

The Three Results of the Problems Auto-Updating Plugins and Themes Check

The function can return only three statuses, and Site Health changes its label only when the status is not good. Good keeps the calm label that says auto-updates appear to be configured correctly. Critical and recommended both swap in the warning you are reading about, and the sentence under it is the only clue to which one you have.

Result	Condition in the code	What the message says	Lines
Critical	The filter returns false for the fake plugin or theme AND the dashboard still shows the switches	Auto-updates appear disabled, yet the settings are still displayed, which could stop them working	3231 to 3238
Recommended	The filter returns false, a filter is hooked, and the dashboard switches are already hidden	Auto-updates for plugins, themes or both appear disabled, so new versions will not arrive on their own	3240 to 3260
Good	Anything else, including no filter at all	There appear to be no issues with plugin and theme auto-updates	3263 to 3266

AHosting Auto-Update Check Outcome Table: the three results of the WordPress 7.1.3 plugin and theme auto-update test, with the condition and line numbers in class-wp-site-health.php.

Notice the order. Critical is tested first, so it wins whenever the dashboard and the filter disagree. Recommended is the quieter state: someone turned auto-updates off on purpose and made the screen match. The label is identical for both, which is why people assume the worst.

Why Site Health Reports Problems Auto-Updating Plugins and Themes as Critical

What the test sends through the filter

WordPress builds a fake plugin with the slug a-fake-plugin and version 9.9, and a fake theme called a-fake-theme (lines 3194 to 3216). It then calls the same hook a real update would use, passing true as the starting answer (lines 3223 and 3224, through wp_is_auto_update_forced_for_item() at line 1085 of update.php). The hook is documented as the auto_update_{$type} filter. If nothing is hooked, true comes back unchanged and the result is good.

Why the dashboard switch stops meaning anything

The real updater starts from your own choice. The per-plugin switch is stored in a site option, read at line 227 of class-wp-automatic-updater.php, and the result is then passed through the same filter at line 268. Whatever the filter returns replaces your choice. A blanket false therefore turns every plugin switch into decoration: you can click Enable auto-updates on all of them and none will update.

Filter patterns that trip the check, and ones that do not

Because the test uses a fake slug, the shape of your filter decides the result. We worked these out from the source, and have not yet confirmed each one on a clean install.

Filter pattern	Answer for the fake plugin	Result
Return false for every plugin	false	Trips the check
Allowlist: true only for named slugs	false, because a-fake-plugin is not on the list	Trips the check
Denylist: false only for named slugs	true, because a-fake-plugin is not on the list	Passes, even though real plugins are blocked
Return true for every plugin	true	Passes
No filter hooked anywhere	true, unchanged	Passes

How common auto_update_plugin filter shapes behave against the fake plugin used by the WordPress 7.1.3 Site Health test, derived from reading the source.

The denylist row matters most. A green result does not prove your plugins update, because the check cannot see a filter aimed at specific slugs. The allowlist row is the surprise: a careful setup that updates only approved plugins looks identical to a blanket block.

Finding the Code Behind Your Problems Auto-Updating Plugins and Themes Warning

The filter is ordinary PHP that something on your site registers. You are looking for four strings: auto_update_plugin, auto_update_theme, plugins_auto_update_enabled and themes_auto_update_enabled. Search for them in this order, which runs from the most likely culprit to the least:

The wp-content/mu-plugins folder. Must-use plugins load on every request and cannot be switched off from the Plugins screen, so a forgotten snippet can sit there for years.
Active plugins. Anything that manages updates, maintenance mode, staging or client handover may register the filter. Search the plugin folders rather than guessing from names.
The active theme’s functions.php and any child theme. Snippets pasted here vanish and reappear with theme changes.
wp-config.php. It can hold add_filter lines as well as constants, and it is the file people forget to read.

If you have terminal access, a recursive search for those strings finds them quickly. Without it, open each file in the order above and read it. Do the bisecting on a copy, not the live site: our WordPress staging guide covers setting one up, and renaming a plugin folder on production switches that plugin off for every visitor.

If the search finds nothing, the filter may be registered from code that builds the hook name dynamically, or from a plugin that is only active for some users. In that case switch the suspects off one at a time on the staging copy and reload Site Health after each change. The plugin whose removal turns the warning to good is the one holding the filter.

Constants that change what the dashboard shows

Two constants affect the interface side of the test rather than the filter side. AUTOMATIC_UPDATER_DISABLED and DISALLOW_FILE_MODS both make the updater report itself as disabled (is_disabled(), lines 33 to 59 of the updater class, and wp_is_file_mod_allowed() at line 1829 of load.php). Both are documented on the wp-config reference. On their own they hide the switches and still leave the result good, because nothing has filtered the starting true. Together with a false filter they give you recommended.

The hide-the-interface filters work the same way. The WordPress 5.5 developer note says returning false from plugins_auto_update_enabled or themes_auto_update_enabled only removes the interface, and does not turn auto-updates on or off. That is exactly why a site can end up critical: the filter blocks updates and nothing hides the switch.

What the Problems Auto-Updating Plugins and Themes Check Cannot See

Equally important is what this test ignores. It does not check that the server can write files, that cron fires, that the disk has room or that WordPress.org is reachable. Core runs a different item for those: Background updates, which is get_test_background_updates() at line 1740 and hands off to a separate class of tests. A site can pass this check and still fail to update, and fail this check while every other part of the update path is healthy.

So match the symptom to the right guide. Should WordPress ask for FTP details when you click Update, read why it is a file-owner check, not a password problem. If updates are scheduled but never run, what the scheduled event check actually tests explains the cron side, and core’s own auto-update message at line 1096 of update.php blames WP-Cron when the update event is missing. When an install fails midway, finding the folder before the cause covers it.

Why the filter matters for security

The reason to care is the gap between a fix being published and installed. The US government publishes a catalog of vulnerabilities known to be exploited, the National Vulnerability Database records them, and WPScan lists WordPress plugin vulnerabilities specifically. A filter that silently blocks auto-updates removes the one mechanism that closes that gap without your attention, and the critical result is the one where nothing on screen tells you so.

Fixing Problems Auto-Updating Plugins and Themes on AHosting

The fix is a decision followed by a small change. Decide first whether you want auto-updates at all, because the answer sets which Site Health result is acceptable.

You want auto-updates. Remove the filter that returns false, or replace a blanket false with a denylist of the few plugins you must pin. Reload Site Health: the result should return to good.
You want an allowlist. The check cannot see through it, so you will get critical while the switches show. Hide them with plugins_auto_update_enabled and themes_auto_update_enabled and you will get recommended, which is accurate and honest.
You want no auto-updates. Return false from the two interface filters as well, so the screen matches the code. The result becomes recommended, and you take on every update yourself.

Whichever you pick, put the filter in a single must-use plugin file with a clear name, so the next person can find it. The same filters work identically on our AHosting shared web hosting and AHosting VPS hosting plans, because the filter lives in your WordPress files and not in the server. After the change, reload Site Health to confirm the result.

Check the cron side separately. The Plugins screen has an auto-updates column, and the WordPress 5.5 developer note says it carries the toggle links and the time until the next update attempt. That time is built from the shared wp_version_check event (line 1096 of update.php), so it shows that cron is alive, not that your filter is clear. Site Health answers the filter question, and the column answers the cron question.

Replay the result before you change anything

The reader tool below runs the same two questions as core, so you can check which result you should expect before and after the change.

Replay the Auto-Update Check

Answer the two questions the test asks, and see which Site Health result core would print.

Does your Plugins screen still show the auto-update switches? Does anything hooked to auto_update_plugin return false for every plugin?

Pick your answers, then replay the check.

AHosting WordPress hosting plans

When to open a ticket

If you have searched every file above and the warning remains, open a ticket with the exact Site Health line and the list of must-use plugins in your account, and we will look at it with you.

Frequently Asked Questions: Problems Auto-Updating Plugins and Themes

Why won’t my WordPress plugins update in 2026 when Site Health reports problems auto-updating plugins and themes?

Specifically, this warning does not explain a failed manual update. It says a filter named auto_update_plugin or auto_update_theme returned false for a made-up test plugin, so the per-plugin auto-update switches are probably being overridden. If a click on Update now also fails, that is a separate problem: check file ownership, disk quota and the Background updates item in Site Health.

Is it safe to ignore the problems auto-updating plugins and themes warning if I update plugins by hand?

In practice, yes for the moment, because the filter governs automatic updates, not the Update now button. The risk is the gap between releases: if you rely on auto-updates for a security fix and a filter blocks them, nothing installs until you notice. Either remove the filter or accept that you own every update.

Does the problems auto-updating plugins and themes warning mean my cron or file permissions are broken?

However, nothing in this test reads cron or permissions. It builds a fake plugin and theme, asks the auto_update filters what they would do, and compares that with whether the dashboard shows the toggles. Broken cron and wrong file ownership produce other Site Health items, not this one.

Critical vs recommended in 2026: which problems auto-updating plugins and themes result is worse?

Notably, critical is the contradictory one. It means a filter refuses updates while the dashboard still offers the switch, so the screen is lying to you. Recommended means the filter and the dashboard agree that updates are off, which is a deliberate state that only needs a decision.

Can AHosting support help me find which plugin is behind the problems auto-updating plugins and themes warning?

In practice, yes. Open a ticket with the exact Site Health line and the list of must-use plugins in your account, and we will look at it with you. The filter lives in your own files, so the quickest route is usually a search for auto_update_plugin across wp-content.

On AHosting WordPress hosting, auto_update_plugin filter vs plugins_auto_update_enabled filter in 2026: which switches updates off?

Specifically, the auto_update_plugin filter decides whether a given update runs, and returning false there blocks it. The plugins_auto_update_enabled filter only decides whether the dashboard shows the switches. Returning false from it hides the interface without turning anything on or off, which is why the two together can produce either Site Health result.

How do I clear the problems auto-updating plugins and themes warning on an AHosting WordPress plan without editing core files?

In other words, find the code that returns false and change that, never WordPress itself. Search mu-plugins, active plugins, the theme functions file and wp-config for auto_update_plugin and auto_update_theme, then remove the blanket false or narrow it to named plugins. Reload Site Health afterward to confirm.

What does DISALLOW_FILE_MODS do to the problems auto-updating plugins and themes check on a WordPress site?

Indeed, on its own it does not trigger this warning. The constant makes the updater report itself as disabled, which hides the dashboard switches, but the test still starts from true and nothing has filtered it, so the result stays good. Pair the constant with a filter that returns false and you get the recommended result instead.

Will fixing problems auto-updating plugins and themes make my WordPress site safer in 2026?

Consequently, only if the filter was blocking updates you wanted. Auto-updates close the gap between a plugin vulnerability being published and your site receiving the fixed version, but they do nothing about plugins that are abandoned or themes that no longer receive releases. Treat the fix as one control among several.

Must-use plugins vs wp-config: where should an auto-update filter live to avoid problems auto-updating plugins and themes?

For example, a must-use plugin is the safer home because it is a single named file that does not depend on the active theme, so you can find it again. Filters pasted into wp-config or a theme functions file get lost in upgrades, which is how they end up blocking updates years later.

October 14, 2026

Available Disk Space Is Critically Low? What WordPress Is Really Measuring

What “Available Disk Space Is Critically Low” Actually Checks
- One PHP Call Behind the Warning
- The Heading That Never Changes
Why Available Disk Space Is Critically Low Ignores Your Quota
- Green With a Full Account
“Could Not Determine Available Disk Space for Updates”
- When a Disabled Function Reads as Critically Low
- The Old Advice About wp-content/upgrade
Which Number to Trust When Available Disk Space Is Critically Low
- Read Both Meters in cPanel
Check Available Disk Space Is Critically Low Yourself in Two Minutes
- What the Value Means
- Read Your Available Disk Space Is Critically Low Result
How to Fix Available Disk Space Is Critically Low, in Order
- Where the Space Usually Goes
Available Disk Space Is Critically Low on AHosting Servers
A Practical Checklist for Available Disk Space Is Critically Low
Frequently Asked Questions: Available Disk Space Is Critically Low

TL;DR

Available disk space is critically low means PHP reported under 20 MB free on the filesystem that holds wp-content. On shared hosting that filesystem belongs to the whole server, not to your plan, so the warning can be wrong in either direction. Read the Disk Usage meter in cPanel instead. Near its limit: clear old backups, logs and unused plugins before updating. Plenty of room: the warning is a measuring problem, not a full site.

What “Available Disk Space Is Critically Low” Actually Checks

Available disk space is critically low, less than 20 MB available. Proceed with caution, updates may fail. That is the full line WordPress Site Health prints, and it reads as if the site were about to run out of room. On shared hosting it often has nothing to do with your account. Read against the WordPress 7.1.3 code that writes it, the warning measures one thing, and that thing is not your hosting plan.

Listen: the WordPress disk space warning reads the free space of the whole server, so on shared hosting it can be wrong in either direction. By Matt Chrust, Director of Business Development, AHosting.

One PHP Call Behind the Warning

The test has been part of Site Health since WordPress 6.3 and runs every time the screen loads. It calls PHP’s disk_free_space() on WP_CONTENT_DIR, the folder holding your plugins, themes and uploads, and sorts the answer into three bands. Under 20 MB is critical. Under 100 MB is low, graded recommended. Anything above that passes. If PHP returns no number at all, a fourth message appears instead, covered further down.

The Heading That Never Changes

One detail confuses almost everyone who meets this warning. In every state, including critical, the row in Site Health is titled Disk space available to safely perform updates. Only the text underneath changes. So a reassuring heading sits in the Critical issues list, and you have to expand it to read that available disk space is critically low. The badge beside it says Security.

Why Available Disk Space Is Critically Low Ignores Your Quota

PHP documents disk_free_space() as the bytes available on the corresponding filesystem or disk partition. Its source code asks the operating system through statvfs and multiplies the free blocks available to ordinary users, f_bavail, by the block size. That is a property of the disk, not of the customer asking.

Shared hosting limits each customer a different way. As the Linux Quota mini-HOWTO explains, a quota caps the disk blocks and the number of files one user may own, per filesystem. Many accounts share one filesystem, each with its own ceiling. The free space of the filesystem and the room left under your ceiling are two separate numbers, and Site Health only reads the first.

Site Health shows	Status	What PHP returned	Does it describe your account?	Next step
[Size] available disk space was detected, update routines can be performed safely	Good	Free space on the server filesystem	No, it can stay green with your quota full	Check cPanel Disk Usage anyway
Available disk space is low, less than 100 MB available	Recommended	Under 100 MB free on the filesystem	Only if the filesystem is yours, as on a VPS	Compare with Disk Usage
Available disk space is critically low, less than 20 MB available	Critical	Under 20 MB, or a non-number a host substituted	Rarely on shared hosting	Compare with Disk Usage; free space only if it is near the limit
Could not determine available disk space for updates	Recommended	False: the function is disabled or failed	No number at all	Watch Disk Usage before large updates

What each disk space result in Site Health means — the exact message, its status, what disk_free_space() returned, and whether it describes your account, read from WordPress 7.1.3 and PHP source.

Green With a Full Account

The quiet failure is the green one. Your account can sit at its limit while the server filesystem has plenty left, and Site Health reports space detected. The next plugin update then fails with a refusal to create a folder or copy a file. WordPress does have a clearer message, Could not copy files. You may have run out of disk space, but it measures the same filesystem and only runs during scheduled background updates.

“Could Not Determine Available Disk Space for Updates”

This is the same test reporting that PHP returned false. Some hosts add disk_free_space to their list of disabled PHP functions. WordPress then has no number and says so, graded recommended rather than critical. It is the honest version of the warning.

When a Disabled Function Reads as Critically Low

Trouble starts when a host replaces the function instead of disabling it. WordPress Trac ticket #59687 describes a managed host whose replacement returned null. WordPress only catches false, and in PHP null < 20 MB is true, so the test fell straight into the critical branch on sites with gigabytes free. Core developers closed it as a host issue. Ticket #59251, titled as Site Health incorrectly reporting low disk space, collected the same symptom from other sites before it was closed as fixed.

The Old Advice About wp-content/upgrade

Older forum threads tell you to create wp-content/upgrade. That worked once. WordPress 6.3.1 measured that folder, which a fresh install does not have yet, and a missing folder gave no number. In August 2024 a core commit pointed the test at WP_CONTENT_DIR itself, matching the unzip checks, and the change shipped in WordPress 6.7. Creating the folder today changes nothing.

Which Number to Trust When Available Disk Space Is Critically Low

Four places report disk space, and they answer four different questions. On shared hosting only one of them describes the limit your updates will run into.

Where you read it	What it measures	Trust it on shared hosting?	On a VPS
Site Health, Status tab	Free space on the filesystem holding wp-content	No	Yes
cPanel Disk Usage	Space your account uses against its own quota	Yes, this is the limit	Not shown without cPanel
cPanel File Usage	Files your account owns against its file-count limit	Yes, the second limit	Rarely limited
Site Health, Info, Directories and Sizes	How big WordPress folders are	Yes, for finding what grew	Yes
df -h over SSH	Free space on the filesystem	No, same as Site Health	Yes
quota -s over SSH	Your usage and limits	Yes, where the command is available	Only if quotas are set

Which number answers which question — every place a WordPress site owner can read disk space, what it measures, and whether it reflects a shared-hosting quota.

Read Both Meters in cPanel

The cPanel sidebar shows Disk Usage and File Usage side by side, and either one at its limit stops a write. A site can have gigabytes to spare and still be blocked because it owns too many small files, which our guide to the WordPress inode limit on shared hosting covers in detail. The quota command shows the same two limits from a terminal, where your host provides one.

Check Available Disk Space Is Critically Low Yourself in Two Minutes

Start with the cPanel meters. If Disk Usage shows plenty of room, the warning is a measuring problem, and you can stop here. If you want to see the number Site Health sees, a one-line test file shows it. Create a file with a random name, such as ds-check-4b9e.php, in the folder your domain serves, containing <?php var_dump(function_exists('disk_free_space') ? disk_free_space(__DIR__) : 'disabled');. Load it in a browser, note the value, and delete it straight away.

What the Value Means

A large float: free bytes on the server filesystem. Divide by 1,048,576 for megabytes. If it dwarfs the room left in Disk Usage, you are reading the shared disk.
A float under 20,971,520: the filesystem really is under 20 MB. On shared hosting that is a server problem, not yours to solve.
bool(false) or the word disabled: the function is unavailable, which is why Site Health could not determine a number.
NULL: the host replaced the function. This is the false critical from ticket 59687.

Read Your Available Disk Space Is Critically Low Result

The same logic as a tool: enter the Site Health line and the cPanel meter, and it tells you whether the warning describes your account or the server, and the one step to take next.

Disk Space Warning Reader

Enter what Site Health and cPanel show. The answer is whether the warning describes your account or the server, which number to trust, and the one thing to do next.

Site Health, expanded disk space line

cPanel Disk Usage: used against your limit

Did an update or install just fail?

—

What the warning describes:

Number to trust:

Do this next:

Read from the WordPress 7.1.3 and PHP source. It cannot see your server, so cPanel Disk Usage is what settles it.

How to Fix Available Disk Space Is Critically Low, in Order

Work through these in sequence and stop at the first one that applies. Most shared-hosting sites stop at the first or second step.

If cPanel Disk Usage shows plenty of room, leave the warning. Nothing you delete will change what PHP reports about a disk the whole server shares, and your updates have space.
If Disk Usage is near its limit, free space before the next update. Old backup archives, leftover folders in wp-content/upgrade and wp-content/upgrade-temp-backup, cache folders, a grown debug.log, and plugins or themes you no longer use are the usual weight. Mailboxes on the same account count too.
If Site Health says it could not determine the space, nothing is broken. WordPress just cannot pre-check for you, so glance at Disk Usage before a large update.
If an update failed while Site Health was green, read both meters at once. A full quota and a full file count produce the same refusal.
If both meters show room and the warning still says critical, the measurement is the host’s. Ask, and send the exact Site Health line with the Disk Usage figure.

Where the Space Usually Goes

A failed install leaves its download behind, and our guide to installation failed: could not create directory shows what a full quota does to the next one. Temporary files count as well: PHP’s own temporary folder can sit inside your account, as our post on the missing a temporary folder error explains. And a debug log left switched on grows without limit, which is one more reason to follow our advice on logging errors to a potentially public file.

Available Disk Space Is Critically Low on AHosting Servers

On our shared servers, customer home folders sit on a filesystem that enforces a separate quota for every cPanel account, and each account’s PHP temporary folder lives inside that same quota. So the rule in this guide applies directly: Site Health reads the shared filesystem, and the Disk Usage meter in your cPanel is the number that decides whether a plugin, theme or core update can be written.

What We Measured in October 2026

We ran the same PHP call as a customer account on one of our shared servers in October 2026. It returned about 2,385 GB, the free space of the shared filesystem, while that account had 4.73 GB left of its 5 GB quota. Against thresholds of 20 MB and 100 MB, the test therefore reports good for every account on that server, including one with no room left at all. The function is not disabled on any PHP version we offer, so the could-not-determine message does not appear either. In twelve months of support tickets, no customer has reported this warning to us. We send our own high disk usage notices instead, because the per-account number is the one that matters and WordPress cannot see it.

What the Plans Include

Our WordPress hosting plans include 10 GB, 20 GB and 50 GB of storage, and the standard web hosting plans carry the same three figures. A routine update needs only a fraction of that, but it needs the space at the moment it runs: the download and its unpacked copy exist side by side until the copy finishes. Keeping Disk Usage comfortably below its limit is what makes updates boring.

When to Open a Ticket

Clearing space is the fix in most cases, and it is yours to make. If cPanel shows room to spare and Site Health still says critically low, open a ticket with the exact Site Health line and the Disk Usage figure, and we will look at it with you. If you would rather the Site Health number be your number, a VPS with full root access puts the whole disk in your hands. The warning alone is not a reason to move.

A Practical Checklist for Available Disk Space Is Critically Low

Expand the Site Health row; the heading reads the same in every state.
Read cPanel Disk Usage before deleting anything.
Read File Usage too; a file-count limit blocks writes just as a full disk does.
Treat a critical warning with plenty of room in Disk Usage as a measuring problem.
Ignore advice to create wp-content/upgrade; it stopped mattering in WordPress 6.7.
Clear old backups, leftover upgrade folders, caches and logs when Disk Usage is near its limit.
Keep room for the download and its unpacked copy before a large update.
Delete any test file as soon as you have its value.
Send the Site Health line and the Disk Usage figure with any question to your host.

Frequently Asked Questions: Available Disk Space Is Critically Low

Why does WordPress say available disk space is critically low when I have enough?

Typically because the number is not about your account. Site Health asks PHP how much space is free on the filesystem that holds wp-content, and PHP has no idea what your plan allows. A critical result with room to spare usually means the host replaced that PHP function with one that returns no number, or the shared server disk itself is nearly full. Check the Disk Usage meter in cPanel: if it shows room, nothing on your site needs deleting.

What does available disk space is critically low mean in WordPress Site Health in 2026?

In other words, PHP reported less than 20 MB free where WordPress keeps plugins, themes and uploads. WordPress 7.1 runs the check every time Site Health loads and grades it critical under the Security badge, because an update needs room to download, unpack and copy files. Between 20 MB and 100 MB the same test says low instead, graded recommended.

Critically low vs low vs could not determine: what is the difference in Site Health?

Specifically, all three come from one test. Critically low means PHP returned under 20 MB and is graded critical. Low means under 100 MB and is graded recommended. Could not determine means PHP returned no number at all, usually because the host disabled the function, and is also graded recommended. The heading above all three reads the same, so expand it to see which one you have.

Does the available disk space is critically low warning read my hosting quota?

In fact, no. PHP asks the operating system for the free space of the whole filesystem, and a hosting quota is a separate per-account limit kept on top of it. On a shared server the two numbers can be gigabytes apart in either direction. Your quota is the Disk Usage figure in cPanel, and that is the one your updates actually run into.

Can I safely ignore available disk space is critically low in Site Health?

Above all, make one check first. If cPanel Disk Usage shows plenty of room, the warning is a measuring problem and your updates will have space, so it is safe to leave. If Disk Usage is close to its limit, the warning is right for the wrong reason, and the next plugin or core update may fail halfway. Free space first, then update.

Will creating a wp-content/upgrade folder fix the disk space warning in 2026?

Ultimately, no. WordPress 6.3.1 measured the upgrade folder, which a fresh install does not have yet, so creating it changed the result. Since WordPress 6.7 the test measures wp-content itself, so the folder makes no difference in 2026. Old forum threads that recommend it describe a version you are no longer running.

Site Health vs cPanel Disk Usage: which disk space number should I trust?

In practice, trust cPanel on shared hosting. Disk Usage shows what your account has used against its own limit, which is what decides whether a file can be written. Site Health shows the free space of a disk the whole server shares. On a VPS the two describe the same disk, so either one will do.

How much disk space do AHosting WordPress hosting plans include in 2026?

Overall, as published on the plan pages in October 2026, the three WordPress plans include 10 GB, 20 GB and 50 GB of storage, and the standard web hosting plans carry the same three figures. Your own limit and how much of it is used appear in the Disk Usage meter in cPanel, which is the number to watch before a large update.

Can AHosting support check an available disk space is critically low warning?

Notably, on our shared servers the test reads a filesystem with terabytes free, so it reports good even for a full account, which is why Disk Usage is the meter to watch. If cPanel shows room to spare and Site Health still says critically low, open a ticket with the exact Site Health line and the Disk Usage figure, and we will look at it with you.

Does an AHosting VPS give an accurate Site Health disk space reading in 2026?

Fortunately yes, because on a VPS the filesystem belongs to your server alone, so the free space PHP reports is the free space you have. A warning there is real and worth acting on: clear old backups and logs first. A VPS is not needed just to clear this warning on a shared plan, though.

October 9, 2026