'str' object has no attribute 'type' about wordfence-cli

[Sloppyedwards]

Yes, looks to be the same issue. Towards the end of my wp-config.php file are the following lines:

define('WP_TEMP_DIR',ABSPATH.'tmp');

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
        define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

I didn't put them there, so I'm not sure if they are standard or were standard under some past version. Thanks for the update! I'll watch for the next release and try again.

[akenion]

This is an issue with how CLI parses WordPress' wp-config.php file to identify any non-standard path configurations. I was able to trigger the same trace using a construct like this in the wp-config file:

define('SOME_CONSTANT', ANOTHER_CONSTANT . '/some-string');

I assume you have something similar (a constant concatenated with a string) in your wp-config file. If that is the case, I have a fix ready (#120) and will include it in the next CLI release.

[davidnuzik]

v2.1.0.-rc2 11/27/23

SUMMARY:
QA validation PASSED. I was able to successfully reproduce the issue, then validate it is fixed on 2.1.0-rc2.

VALIDATION STEPS

1. With v2.0.3, alter wp-config.php by adding this line:
   define('TEST_CONSTANT', TEST2_CONSTANT . '/test-string');
   Save the file to disk.
2. Now, with wordfence, run wordfence vuln-scan <path to wp install> -d
3. The reported issue is observed including the traceback.
4. Now, test again, but use v2.1.0-rc2 this time. The issue no longer appears and the scan works as expected. When done testing, remove the line we added to wp-config.php and save again to restore the wordpress install back to normal.