500 Errors with new Filesystem Class

  • synapseresults

    (@synapseresults)


    11 months ago

    We utilize a multi-user filesystem in our managed hosting to ensure that plugin changes cannot be made without approval. The webserver runs as a user that has write permissions to only specific folders including the upload directory, and the new wpcf7_uploads folder. Outside of these folders the webserver user has only read permissions.

    With the upgrade to 6.1 we are now seeing 500 errors on file uploads associated with the new file handling through the WPCF7_Filesystem class. Rolling the plugin back to 6.0.6 resolves the error. We are seeing the same error with Contact Form 7 on other hosting providers.

    This issue was discovered with WP 6.8.2 running on PHP 8.2 and was isolated to Contact Form 7.

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Takayuki Miyoshi

    (@takayukister)

    11 months ago

    Why not give the web server user the appropriate permissions?

    Thread Starter synapseresults

    (@synapseresults)

    11 months ago

    Because we have a hardened WordPress to minimize the damage that can be done with a wp-admin compromise. We are following the permissions hardening outlined here: https://developer.ww.wp.xz.cn/advanced-administration/security/hardening/#file-permissions

    We manage updates from the command line via wp-cli and review error logs and adjust permissions as needed, giving full recursive ownership of the uploads folder to the web server user did not resolve the issue.

    The web server user does have full permissions to write and read to the uploads area and owns the majority of child folders within uploads. We have also confirmed that user can write temporary files in the system temp folder. The WordPress media library and version 6.0.6 of the plugin have no issues with this permission setup. We are seeing errors from the chmod and rm methods. It looks like the filesystem API is falling back on the FTP extension, despite having write permissions to the folders in question.

    Error Logs for context (We did add some debugging to the unship_unloaded_files to better understand what was happening before we reverted the plugin):

    [Thu Jul 24 15:03:05.729342 2025] [proxy_fcgi:error] [pid 22641:tid 140208615294720] [client 127.0.0.1:53106] [10.81.234.218] AH01071: Got error ‘PHP message: File test.png uploaded to /www/synapseresults.com/htdocs/wp-content/uploads/wpcf7_uploads/2495563086/test.png; PHP message: PHP Fatal error:  Uncaught TypeError: ftp_chmod(): Argument #1 ($ftp) must be of type FTP\\Connection, null given in /www/synapseresults.com/htdocs/wp-admin/includes/class-wp-filesystem-ftpext.php:288\nStack trace:\n#0 /www/synapseresults.com/htdocs/wp-admin/includes/class-wp-filesystem-ftpext.php(288): ftp_chmod()\n#1 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/filesystem.php(96): WP_Filesystem_FTPext->chmod()\n#2 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/file.php(91): WPCF7_Filesystem->chmod()\n#3 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/submission.php(847): wpcf7_unship_uploaded_file()\n#4 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/submission.php(105): WPCF7_Submission->unship_uploaded_files()\n#5 [internal function]: WPCF7_Submission->{closure}()\n#6 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/l10n.php(147): call_user_func()\n#7 /www/synapseresults.com/htdocs/wp-content/plugin…’

    [Thu Jul 24 14:54:09.010779 2025] [proxy_fcgi:error] [pid 22641:tid 140208623687424] [client 127.0.0.1:50974] [10.81.234.218] AH01071: Got error ‘PHP message: PHP Fatal error:  Uncaught TypeError: ftp_nlist(): Argument #1 ($ftp) must be of type FTP\\Connection, null given in /www/synapseresults.com/htdocs/wp-admin/includes/class-wp-filesystem-ftpext.php:438\nStack trace:\n#0 /www/synapseresults.com/htdocs/wp-admin/includes/class-wp-filesystem-ftpext.php(438): ftp_nlist()\n#1 /www/synapseresults.com/htdocs/wp-admin/includes/class-wp-filesystem-ftpext.php(456): WP_Filesystem_FTPext->exists()\n#2 /www/synapseresults.com/htdocs/wp-admin/includes/class-wp-filesystem-ftpext.php(399): WP_Filesystem_FTPext->is_file()\n#3 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/filesystem.php(111): WP_Filesystem_FTPext->delete()\n#4 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/functions.php(384): WPCF7_Filesystem->delete()\n#5 /www/synapseresults.com/htdocs/wp-content/plugins/contact-form-7/includes/file.php(384): wpcf7_rmdir_p()\n#6 /www/synapseresults.com/htdocs/wp-includes/class-wp-hook.php(322): wpcf7_cleanup_upload_files()\n#7 /www/synapseresults.com/ht…’

    Plugin Author Takayuki Miyoshi

    (@takayukister)

    11 months ago

    Do you use a shared hosting server? Who is the host?

    You appear to pay great attention to security risks, but if so, why don’t you consider managing your sites on a dedicated server?

    Thread Starter synapseresults

    (@synapseresults)

    10 months, 4 weeks ago

    We value security so that we can provided secured hosting to our clients and for ourselves. We are our own host and we provide managed hosting to our clients. The locked down file permissions are part of our security scoping and are non-negotiable.

    Since the plugin rollback resolved our problem we are not looking for any kind of specific support on this issue, this is more of a bug submission than anything, especially since the integration with the WP Core Filesystem API is a new feature.

    We have a lot of experience with Contact Form 7 and ship it standard with all of our website builds, and until 6.1 have had no issues with the plugin. It’s been solid work, very extensible, and reliable for years (congrats on that). The only resolution we’re hoping for is that you might review, see if you can duplicate our issue under similar circumstances, and if so potentially address it in a future release.

    Plugin Author Takayuki Miyoshi

    (@takayukister)

    10 months, 4 weeks ago

    Chances are that you have improper constants in the wp-config.php file, but if that is done by intention, I have nothing to say on the matter.

    ag1233

    (@ag1233)

    10 months, 3 weeks ago

    if this is in Linux (possibly Windows as well), I think adding in wp-config.php:
    define( ‘FS_METHOD’, ‘direct’ );
    helps in that it uses form upload to upload files directly on the web.
    But that is not all, normally in apache, the web server run under a user / group : apache / www-data etc.
    This particular user / group needs to have write access in the wp-content/uploads folder.
    allowing uploads is always a risk, there are no reasonable mitigation other than to perhaps scan the uploaded fiiles to identify threats if possible. denying uploads would likely mean preventing images etc from being uploaded.

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘500 Errors with new Filesystem Class’ is closed to new replies.