Automatic updater of WordPress always fails if FS_METHOD is ftpext since 6.6 with PHP 8.0+

[hideishi]

Since WordPress 6.6, enabling maintenance mode is introduced in automatic update.
The source code is wp-admin/includes/class-wp-automatic-updater.php in public function update().

<?php
if ( 'translation' !== $type ) {
        $upgrader->maintenance_mode( true );
}

The main problem is that in the called maintenance_mode(), WP_Filesystem() is called without any arguments.
When FS_METHOD is set to 'ftpext' (or non 'direct'), credentials are necessary to pass to WP_Filesystem() constructor.
Because no argument is passed, returned WP_Filesystem() has an empty $link.
Since PHP 8.0, ftp_nlist() does not accept null as first argument that results in PHP Fatal Error.

NOTICE: PHP message: PHP Fatal error:  Uncaught TypeError: ftp_nlist(): Argument #1 ($ftp) must be of type FTP\Connection, null given in /home/kusanagi/kusanagi9/DocumentRoot/wp-admin/includes/class-wp-filesystem-ftpext.php:438
Stack trace:
#0 /home/kusanagi/kusanagi9/DocumentRoot/wp-admin/includes/class-wp-filesystem-ftpext.php(438): ftp_nlist()
#1 /home/kusanagi/kusanagi9/DocumentRoot/wp-admin/includes/class-wp-filesystem-base.php(231): WP_Filesystem_FTPext->exists()
#2 /home/kusanagi/kusanagi9/DocumentRoot/wp-admin/includes/class-wp-filesystem-base.php(58): WP_Filesystem_Base->find_folder()
#3 /home/kusanagi/kusanagi9/DocumentRoot/wp-admin/includes/class-wp-upgrader.php(997): WP_Filesystem_Base->abspath()
#4 /home/kusanagi/kusanagi9/DocumentRoot/wp-admin/includes/class-wp-automatic-updater.php(474): WP_Upgrader->maintenance_mode()
#5 /home/kusanagi/kusanagi9/DocumentRoot/wp-admin/includes/class-wp-automatic-updater.php(676): WP_Automatic_Updater->update()
#6 /home/kusanagi/kusanagi9/DocumentRoot/wp-inc...

This causes the automatic updater to stop here, hence Automatic updater will never update WordPress core if the core is updated once to 6.6 or later (also updating plugins and themes fails!).
Prior to 6.6, maintenance_mode() was not enabled. Therefore, automati updater did not fail at this point end was eble to proceed to the later process where WP_Filesystem() was generated with proper credentials.

[hideishi]

I would like to highlight that WP_Filesystem() SHOULD NEVER BE CALLED WITHOUT CREDENTIALS unless you are 100% sure that FS_METHOD is 'direct' because since 8.0 PHP restriced type checks that throws fatal error if invalid type of argument is passed in ftpext and ftpsocket functions.
I haven't tried with ssh2 but I guess it is the same for it as well.

[dd32]

Hi @hideishi and welcome to Trac, thanks for reporting this.

Looking into it, it appears to have been introduced in [58128] / #58281.

You're correct, that WP_Filesystem() should not be called without the $args parameter, and that code similar to this should be employed:
​https://github.com/WordPress/wordpress-develop/blob/b8ecfbf9542198b1d88230221faeca6b71fa0ac7/src/wp-includes/update.php#L1114-L1121

ob_start();
$credentials = request_filesystem_credentials( '' );
ob_end_clean();

if ( ! WP_Filesystem( $credentials ) ) {
	wp_trigger_error( __FUNCTION__, __( 'Could not access filesystem.' ) );
	return;
}

Moving to 6.8 for resolution, but backporting should be considered. This isn't critical, as it only affects a subset of sites (Those using FTP/SSH with hard-coded credentials).

[hideishi]

Well, meny sites rely on automatic updates for keeping WordPress core, plugins and themes fresh and secure.
Sites configured with such credentials are jeopadized without backporting. In this sense, it is a security issue.

Because this affects not just for WordPress core, but automatic updates for plugins and themes in which tons of security issues may appear, I believe this causes a major threat on WordPress sites running 6.6 and 6.7 currently.
This will leave thet sites that uses FTP/SSH credentials vulnerable.

I would very much appreciate if you could consider to backport to 6.6 and 6.7 in which this issue occurs.

[SergeyBiryukov]

In 59981:

Upgrade/Install: Pass stored credentials to WP_Filesystem() in WP_Upgrader.

When using a non-direct filesystem, the call in WP_Upgrader::maintenance_mode() did not include the required credentials, leading to a fatal error as the connection was not initialized properly.

This commit attempts to use the stored credentials if available, and triggers a notice otherwise.

Follow-up to [56341], [58128].

Props hideishi, dd32, SergeyBiryukov.
Fixes #62718.

[SergeyBiryukov]

Thanks for the ticket! Reopening for 6.6.x and 6.7.x consideration.

[SergeyBiryukov]

In 59982:

Upgrade/Install: Revert [59981] pending test failure investigation.

See #62718.

@SergeyBiryukov judging by the patch commited that was failing tests
https://core.trac.wordpress.org/changeset/59981

I think that the only issue was a missing bracket by the end, in line 1021

Before adding that bracket 4 tests failed, after adding, they are all passing.

Anyway, later, I would post a testing report for this.

Trac ticket: https://core.trac.wordpress.org/ticket/62718

[SirLouen]

Also, I think some unit tests would be useful, to check for this specific scenario of using WP_Filesystem without credentials

[tusharaddweb]

Test Report: WordPress Automatic Updater Failure with FS_METHOD = 'ftpext'

Test Scenario:
The automatic updater in WordPress fails when FS_METHOD is set to 'ftpext' on WordPress 6.6+ with PHP 8.0 or higher.

Test Environment:
WordPress Version: 6.6+
PHP Version: 8.0+
FS_METHOD: ftpext
Server: Apache/Nginx
PHP FTP Extension: Enabled

Test Steps:
Set define('FS_METHOD', 'ftpext'); in wp-config.php.

Ensure valid FTP credentials are provided.
Attempt to update WordPress via the automatic updater.
Observe the update process and check for errors.

Test Result:
The update process starts but fails before completion.
WordPress prompts for FTP credentials even when defined in wp-config.php.

Error logs show permission issues or undefined FTP functions.

Conclusion:
The issue appears due to changes in how WordPress handles the ftpext method in version 6.6+, likely related to PHP 8.0+ compatibility. Further debugging or alternative FS_METHOD values (like direct) may be required.

[audrasjb]

Moving to 6.9 as 6.8 RC 1 is coming in a couple of hours.

[SirLouen]

@tusharaddweb could you provide logs with the issue?

[SirLouen]

Combined Patch and Bug Reproduction Report

Description

This report can't validate whether the issue can be replicated.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8579.diff

Environment

• WordPress: 6.8-beta3-60042-src
• PHP: 8.2.28
• Server: nginx/1.27.4
• Database: mysqli (Server: 8.4.4 / Client: mysqlnd 8.2.28)
• Browser: Chrome 134.0.0.0
• OS: Windows 10/11
• Theme: My Twenty Twenty Child Theme 1.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Bug Reproduction

1. First, we need to set up a FTP environment. Not an easy task, one of the most convoluted and worst documented topics in WP by far, personally I would choose this patch ​https://github.com/WordPress/wordpress-develop/pull/8589 that is the most straightforward way I've found to test this properly
2. We need to set in wp-config.php

   define( 'FS_METHOD', 'ftpext' );
   define( 'FTP_HOST', 'ftp' );
   define( 'FTP_SSL', false );
   

We are not setting any other credentials according to the report

Now we have a fully ftpext FTP working in ftp host

3. Now we execute a plugin update. I simply reduce the version of Hello Dolly.

4. System triggers for credentials: ​https://i.imgur.com/O1XfgH1.png

I can't see any errors in log

5. I put the credentials and finish the update

6. 🐞 Bug occurs. Several Warnings, update doesn't happen ❌ But it's not the same as the one in the report.

Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/src/wp-admin/includes/class-wp-filesystem-ftpext.php on line 404
Warning: ftp_rmdir(): Remove directory operation failed. in /var/www/src/wp-admin/includes/class-wp-filesystem-ftpext.php on line 415

Expected Results

• The update happens without any troubles since we are inputting the credentials manually.

Results after the patch

• ❌ Same errors as before the patch.

Additional Notes

1. One of the main hindrances I've found trying to debug this is testing towards a core update that has resulted in one even bigger bug that is completely blowing my mind: #63173
2. So I have to test this only with plugins like Hello Dolly.
3. Maybe I'm issing one step in the process. I ask reporter @hideishi to review this process.

[hideishi]

@SirLouen

Since automatic update occurs in an unattended way, it is necessary to set the credential (i.e. FTP password) in wp-config.php rather than waiting the popup for it.

Following is the snipet of wp-config.php.

define('FS_METHOD', 'ftpext');
define('FTP_HOST', 'localhost');
define('FTP_USER', 'your user');
define('FTP_PASS', 'your secret password');

I would recommend to focus on core updates rather than plugin/theme updates due to following reason although it is harder to setup the environment.

The error you saw happend from a different path than this issue (perhaps related).

Recent WordPress incorporated the feature to "rollback" the update if something happens during the automatic plugin update.
The error you saw is a part of the result of the "rollback" that failed to remove the backup (or perhaps origina?) plugin.

I assume that the original issue as I mentioned in this topic, caused the original Exception, and the "rollback" feature caught the Excecption and decided to "rollback".

Because it is hard to distinguish which Exception was caused by what feature, I would recommend to focus on core updates which currently doesn't have "rollback" so that it makes the test simpler.

[SirLouen]

@hideishi

Problem with core updates is this new bug #63173.
That is literally blowing my mind.

I need to keep debugging into this, for some reason ftpext has always been my nightmare. I used to use this method long way in the past and I always had zillions of issues depending on the setup.

Now that we have env and a new issue regarding ftpext has returned, I have more opportunities to test this more thoroughly.

By the way, I don't understand your snippet

Following is the snipet of wp-config.php.

define('FS_METHOD', 'ftpext');
define('FTP_HOST', 'localhost');
define('FTP_USER', 'your user');
define('FTP_PASS', 'your secret password');

The main problem is that in the called maintenance_mode(), WP_Filesystem() is called without any arguments. When FS_METHOD is set to 'ftpext' (or non 'direct'), credentials are necessary to pass to WP_Filesystem() constructor.

You said that the bug occur when no credentials are placed. Or I did understand it wrongly?

[hideishi]

@SirLouen

You said that the bug occur when no credentials are placed. Or I did understand it wrongly?

Yes, you are misunderstanding the issue.

The issue is that the WordPress function WP_filesystem() is called without any crendentials as an argument to the function. I really mean from PHP coding perspective, calling WP_filesystem() rather than calling WP_filesystem( $crendentials ).

You need to supply the "default" credential (as I wrote in wp-config.php) somewhere anyway.

The code submitted in comment:2 provides the workaround that internally parses wp-config.php or any other options to load defined credentials, and preloads to $credential so that it can be supplied to WP_filesystem() programatically without any manual interaction.

If FS_METHOD is ftpext (or anything that requires actual credentials), you need the credential.
If no credential is set in wp-config.php, accessing to the filesystem will fail because the WordPress can't access to the filesystem via FTP.
Therefore, it is always necessay to set the credential in wp-config.php in order to work the automatic updates correctly.

Let me clarify the procedures.

1. Setup ftp environment (localhost is just fine)
2. Install older WordPress for which updates are available, but 6.6 or later.
3. Write the credentials to wp-config.php including FTP_USER and FTP_PASS as well as setting FS_METHOD to ftpext.
4. Wait for automatic updates to happen.
5. You will see the PHP Exception and automatic updates fails.

If you setup WordPress prior to 6.6 (in which PHP code calling WP_filesystem() without any credential as an argument was not present), automatic updates will succeed.

[hideishi]

By the way, let me also explain why there is a use case of using ftpext rather than direct for automatic updates.

In shared hosting, it is common that PHP runs as your UID and GID. Therefore, FS_METHOD direct works fine since file/directory owner is the same as PHP user.

In typical enterpise servers (Linux, AIX, whatever you want), it is common that PHP (and Apache) runs as www user. However, this www user is acutally not allowed to login directly from security policy.
In this scenario, you will have a separate account (say myuser). So, actual contents such as HTML contents as well as PHP codes (WordPress) is stored on the location where myuser is uploadable. Since the file/directory is owned by myuser, it is different from the user that runs PHP (www).
Here, we use FSMETHOD=ftpext to force PHP to also access the file/directory via FTP so that the file/directory owners will be kept as myuser and not be overwritten (or probably forbidden) by accessing by www user.

[SirLouen]

In typical enterpise servers (Linux, AIX, whatever you want), it is common that PHP (and Apache) runs as www user. However, this www user is acutally not allowed to login directly from security policy. In this scenario, you will have a separate account (say myuser). So, actual contents such as HTML contents as well as PHP codes (WordPress) is stored on the location where myuser is uploadable. Since the file/directory is owned by myuser, it is different from the user that runs PHP (www). Here, we use FSMETHOD=ftpext to force PHP to also access the file/directory via FTP so that the file/directory owners will be kept as myuser and not be overwritten (or probably forbidden) by accessing by www user.

Sure, makes a lot of sense. Now I'm going to explain to you my testing protocol:

For testing purposes, we use ​https://github.com/wordpress/wordpress-develop/

Here I prepared an FTP patch ​https://github.com/WordPress/wordpress-develop/pull/8589 to test this
To configure it with an FTP running in container ftp
The sequence of commands would be:

> git clone https://github.com/wordpress/wordpress-develop/
> cd wordpress-develop
> git fetch origin pull/8589/head:ftp-docker-support
> git checkout ftp-docker-support
> npm install
> npm run build:dev
> cp .env.example .env
> sed -i 's/LOCAL_FTP=false/LOCAL_FTP=true/' .env.example
> npm run env:start
> npm run env:install

And then you can add to wp-config.php

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_USER', 'admin' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'ftp' );
define( 'FTP_SSL', false );

WP admin and password are, admin and password respectively also.

Now you can use in an easily reproducible environment by anyone on your computer and get to see the errors I'm commenting

The problem is that with such errors, I cannot exactly reproduce your bug report🤦‍♂️. So I'm trying to see if I can create the environment first. Anyway, now I got everything I need to keep it up.

[takuword]

@SirLouen Hi,

• Could you explain why are you editing .env.example, not .env?

I think editing that file would not trigger your test.

• Could you explain why are you editing wp-config.php, not wp-tests-config.php?

When I followed your instruction, FS_METHOD constant in the wp-tests-config.php had the value of direct by default. ​In the handbook, they are suggesting edit wp-tests-config.php instead of wp-config.php.

After I followed your instruction with the modification shown above, I've successfully observed Argument #1 ($ftp) must be of type FTP\Connection, null given error.

If my understanding is incorrect, let me know so I can learn something from that.

Thank you!

[SirLouen]

@takuword theoretically when you run it for first time, it will convert the .env.example into .env. But I'm not sure if this is done in the build:dev step or in the env:start, so maybe I put it too late in the instructions, feel free to check it. If you already have the .env file, feel also free to edit this manually because its not going to be edited otherwise.

wp-config.php is the config it takes for regular testing with env. Contrarily to ​`wp-env` I've noticed that this docker environment, only creates a single instance using the regular parameters (wp-config.php and wordpress_develop database). Check the docker-compose.yml file for reference.

But maybe, for PHPUnit, the container is based on wordpress_develop_tests and wp-tests-config.php, I'm not sure, but to test this, I'm not using the automated unit testing suite, just a manual inspection.

But what its interesting that using my steps, and modifying wp-tests-config.php you were able to reproduce it.

By checking the docker-compose.yml, there are 0 references to the tests environment:
​https://github.com/WordPress/wordpress-develop/blob/trunk/docker-compose.yml

How can it be possible?

If you have the time to do a screen recording with the process, you would do my week, because I'm spending countless hour with this issue.

[SirLouen]

Combined Reproduction Report & Patch Testing

Description

This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/8579.diff

Environment

• WordPress: 6.7.1-src
• PHP: 8.2.28
• Server: nginx/1.27.4
• Database: mysqli (Server: 8.0.41 / Client: mysqlnd 8.2.28)
• Browser: Chrome 134.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.0
• MU Plugins:
  • Auto Updates Enforcer 1.0.0
• Plugins:
  • Test Reports 1.2.0

Steps to Reproduce

1. Get on 6.7.1 branch git checkout tags/6.7.1, we need to trigger an automatic update, and it will be done from 6.7.1 to 6.7.2
2. Get FTP patch npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/8589

The original patch doesn't patch cleanly because there are some minor differences among branches, so I needed to apply some changes manually in tools/local-env/scripts/start.js

3. Get the exists method patch npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/8599
4. Get the sanitizes patch npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/8618

Alternatively, I've created this branch with all this in place: ​https://github.com/SirLouen/wordpress-develop/tree/patch/6.7.1/62718 to fast-forward all the 4 first steps

5. Run all the initialization commands (build:dev, env:start, env:install)
6. Adding this to wp-config.php:

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_USER', 'admin' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'ftp' );
define( 'FTP_SSL', false );

7. Now I can wait for the automatic update to take place or, we can accelerate this by adding this simple plugin or just the function to functions.php:

<?php
/*
Plugin Name: Auto Updates Enforcer
Description: Ultra-Fast Auto Updates
Version: 1.0.0
Author: SirLouen
*/

function trigger_auto_update_debug() {
    if (isset($_GET['trigger_auto_update']) && current_user_can('update_core')) {
        do_action('wp_maybe_auto_update');
        echo "Auto-update check triggered";
        exit;
    }
}
add_action('admin_init', 'trigger_auto_update_debug');

8. We can trigger the auto-update with this URL: ​http://localhost:8889/wp-admin/?trigger_auto_update=1
9. 🐞 Bug occurs.

Little extra note: To keep reproducing this, you might need to remove the auto_updater lock is a record in wp_options table.

Expected Results

• System autoupdating without any troubles

Actual Results after Patch

1. ✅ Patch solves the issue.

Additional Notes

After several days of research, I've discovered that some FTP clients are very delicate to commands, and for example, ftp_nlist fails with core updates because of very long paths. This added up to the fact that some ftpext filesystem methods had some minor bugs, it was impossible to reproduce it under certain conditions.

For this reason, this Report, is strongly dependent on these two reports: #63173 #63197
Also, I encourage pinging the main Build Tool maintainers: @desrosj or @SergeyBiryukov to take control over this report #63172 and consider implementation, which has made my life better for debugging all this and probably will make future devs to debug anything FTP.

[SergeyBiryukov]

Replying to SirLouen:

judging by the patch commited that was failing tests [59981]

I think that the only issue was a missing bracket by the end, in line 1021

Before adding that bracket 4 tests failed, after adding, they are all passing.

Good catch, thanks! I think it might be not the bracket (they appear to be balanced in that commit), but the fact that I removed the if ( ! $wp_filesystem ) { ... } conditional which should have been kept to avoid unnecessarily recreating $wp_filesystem on each call.

[SergeyBiryukov]

In 60107:

Upgrade/Install: Pass stored credentials to WP_Filesystem() in WP_Upgrader.

When using a non-direct filesystem, the call in WP_Upgrader::maintenance_mode() did not include the required credentials, leading to a fatal error as the connection was not initialized properly.

This commit attempts to use the stored credentials if available, and triggers a notice otherwise.

Follow-up to [56341], [58128].

Props SirLouen, hideishi, dd32, tusharaddweb, takuword, SergeyBiryukov.
Fixes #62718.

[SergeyBiryukov]

Reopening for 6.8 RC2 or 6.8.x consideration after a second committer's review.

[desrosj]

Since this is not a regression specifically in 6.8, I don't think this is something we should add to the release.

Leaving for now to receive more feedback, but I suggest punting to 6.8.1.

[takuword]

@SirLouen Apologies for the delay — I was off over the weekend. Glad to hear the bug has been reproduced and a patch is submitted. Let me know if a screen recording is still needed.

[SirLouen]

@takuword not gonna lie you: I'm super intrigued on how you did it. I had to edit a couple functions in FTPext to make it work with my setup and you said you were able to make it run without any changes, which blows my mind.

If you can do the recording, it will be remarkable.

[SirLouen]

I have created this follow-up ticket #63206

As I suggested @audrasjb I think that it's totally safe and sound to merge this into 6.8 (as is replicating the exact same behavior of other calls to this function), and we can continue towards 6.9 with the new major revamp I'm proposing in #63206 as a more solid solution.

[takuword]

@SirLouen Here we go. This is the screen capture (30 minutes long, be careful. If you are just curious the result, skip to the very end):
​https://youtu.be/4sVAa4YVS28
Updated: ​https://youtu.be/GMXMfvJiU5Q
fyi: I've just uploaded the video so it might take some time to process it on the server side.

[audrasjb]

As this is not a regression found on 6.8, let's move this ticket to milestone 6.9, it shouldn't even be in our ticket list past 6.8 RC 1 :)

[SirLouen]

Replying to takuword:

Here we go. This is the screen capture (30 minutes long, be careful. If you are just curious the result, skip to the very end):
​https://youtu.be/4sVAa4YVS28
Updated: ​https://youtu.be/GMXMfvJiU5Q
fyi: I've just uploaded the video so it might take some time to process it on the server side.

Ok, you are not testing what I was expecting you to test.

Thanks for the video, now everything makes sense.

First, I understand that you had to copy my old Dockerfile and the old docker-compose.yml because with my last update, I had to remove them for acceptance.

You must know, that when you execute npm run env:start the .env.example file moves into .env automatically, you don't need to copy it manually.

Also, the wp-tests-config.php is just for the test:php suite. But here we are not testing against the suite, but manually in the web interface. What I was asking, for testing purposes, was to simply do a Core upgrade from the WordPress Updates menu (inside the WP web interface).

So now everything makes sense on what you were explaining. It was really strange that using a docker system, it worked for you and did not work for me.

About the failing tests you see, I don't think you can simply switch the FS_METHOD to ftpext in the wp-tests-config.php and still make them pass. But I really think they still should be passing. Definitely something to look further into. The test suite is fragile for certain edge cases, like this particular one (anything FTP). Maybe you could open a new ticket with this casuistry.

[SergeyBiryukov]

Replying to desrosj:

Leaving for now to receive more feedback, but I suggest punting to 6.8.1.

Thanks, 6.8.1 sounds good :)

[takuword]

Yes I saw the console messages. No need to copy .env.example :)
OK, I understand your context as well ( = not doing the test against the test suite) now.

Replying to SirLouen:

Replying to takuword:

Here we go. This is the screen capture (30 minutes long, be careful. If you are just curious the result, skip to the very end):
​https://youtu.be/4sVAa4YVS28
Updated: ​https://youtu.be/GMXMfvJiU5Q
fyi: I've just uploaded the video so it might take some time to process it on the server side.

Ok, you are not testing what I was expecting you to test.

Thanks for the video, now everything makes sense.

First, I understand that you had to copy my old Dockerfile and the old docker-compose.yml because with my last update, I had to remove them for acceptance.

You must know, that when you execute npm run env:start the .env.example file moves into .env automatically, you don't need to copy it manually.

Also, the wp-tests-config.php is just for the test:php suite. But here we are not testing against the suite, but manually in the web interface. What I was asking, for testing purposes, was to simply do a Core upgrade from the WordPress Updates menu (inside the WP web interface).

So now everything makes sense on what you were explaining. It was really strange that using a docker system, it worked for you and did not work for me.

About the failing tests you see, I don't think you can simply switch the FS_METHOD to ftpext in the wp-tests-config.php and still make them pass. But I really think they still should be passing. Definitely something to look further into. The test suite is fragile for certain edge cases, like this particular one (anything FTP). Maybe you could open a new ticket with this casuistry.

[jorbin]

As this has an imparct on upgrades, I think we need to be a bit extra risk adverse. I would love to see some additional reports that confirm this has fixed the issue and also that there aren't any knockon issues with upgrades.

[takuword]

I followed the instructions from SirLouen by setting LOCAL_FTP=true in the .env file and temporarily moving the .git directory to .git.bak to avoid triggering the WP_Automatic_Updater::is_vcs_checkout() check, which would prevent automatic updates in my environment. I have confirmed that the patch is working and has fixed the issue.

I used the same environment as mentioned in the comment above.

As I'm going to test in other environments as well, I will let you all know if any problems arise.

Edit: I've also tested on the non-Docker environment as well, and it also worked as intended:
WordPress: 6.8
PHP: 8.4.6
Server: nginx 1.26.3
Database: MariaDB 10.11
Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
OS: AlmaLinux OS 8
Theme: Twenty Twenty-Five 1.2
MU Plugins:
Auto Updates Enforcer 1.0.0

[jorbin]

In 60184:

Upgrade/Install: Pass stored credentials to WP_Filesystem() in WP_Upgrader.

When using a non-direct filesystem, the call in WP_Upgrader::maintenance_mode() did not include the required credentials, leading to a fatal error as the connection was not initialized properly.

This commit attempts to use the stored credentials if available, and triggers a notice otherwise.

Follow-up to [56341], [58128].

Reviewed by jorbin.
Merges [60107] to the 6.8 branch.

Props SirLouen, hideishi, dd32, tusharaddweb, takuword, SergeyBiryukov.
Fixes #62718.