Forum Replies Created

Viewing 15 replies - 1 through 15 (of 18 total)
  • I’m also missing the comments on the list ips. I was about to ask the same thing, and I will appreciate an answer.

    BTW: you can safely specify ranges like this:
    3.4.5.[0-24] or 3.4.5.0-3.4.5.24

    Thanks, it works well. Let’s hope the original developer updates de plugin ASAP and fixes this issue and the security issue urgently.

    • This reply was modified 5 months, 3 weeks ago by clip1492.
    clip1492

    (@clip1492)

    Hi everyone,

    While waiting for an official fix, I’ve implemented a temporary MU-plugin to mitigate the reported Local File Inclusion (LFI) vulnerability in Favorites 2.3.6.
    https://gist.github.com/clip1492/4a4f8f757b8fcb3c0e26326108cb44e6
    Place it inside /wp-content/mu-plugins/ as favorites-hardening.php)

    What this MU-plugin does

    • Clamps the ?tab parameter in the Favorites settings page. → Prevents arbitrary file includes such as ../../wp-config.php.
    • Hardens public AJAX endpoints used by the plugin (favorites_favorite, favorites_list, favorites_clear, favorites_array, favorites_cookie_consent).
    • Blocks traversal attempts (../, %2e%2e, %5c, %2f, etc.) at request level.
    • Sanitizes input parameters (forces numeric IDs and booleans).
    • Returns 403 Forbidden for any suspicious input, while keeping legitimate functionality intact.

    ⚠️ Disclaimer

    This patch is unofficial and provided as-is.

    Use it at your own risk — it has been tested on WordPress 6.7 / PHP 8.3 but there is no warranty and it may not cover every possible scenario or future plugin version.

    It doesn’t modify the plugin itself, so it can be safely removed once an official fix is released.

    🧪 Testing summary

    1. Attempted LFI via admin tab

    Request: /wp-admin/options-general.php?page=simple-favorites&tab=../../wp-config

    → Result: 403 Forbidden or silently redirected to “General” tab (✔️ blocked)

    2. Traversal attempt via AJAX

    Request: action=favorites_favorite&postid=../../wp-config

    → Result: 403 Forbidden (✔️ blocked)

    3. Traversal attempt in other parameters

    Request: action=favorites_list&include_links=../..

    → Result: 403 Forbidden (✔️ blocked)

    4. Normal AJAX request (valid post ID)

    Request: action=favorites_favorite&postid=123

    → Result: JSON { "status":"error","message":"Invalid post." } (✔️ normal behavior)

    5. Normal list request

    Request: action=favorites_list&include_links=true&include_buttons=false

    → Result: JSON favorites list returned (✔️ normal behavior)

    ✅ Result

    All traversal and inclusion attempts are blocked (HTTP 403).

    Normal Favorites operations continue to function normally.

    Hope this helps other users to stay safe until the plugin developer releases an official update.

    Feedback and code review are always welcome.

    Thread Starter clip1492

    (@clip1492)

    Apologies for so many posts.. After testing using Twenty theme with YITH plugin deactivated, product reviews are marked as spam.

    You can close this support thread. Thanks

    Thread Starter clip1492

    (@clip1492)

    if ( $commentdata['comment_type'] === 'review' && get_post_type( $commentdata['comment_post_ID'] ) === 'product' ) {
    do_action( 'spam_comment', $comment_ID );
    }

    Thread Starter clip1492

    (@clip1492)

    After another look, I realized that the spam product review was indeed detected by the plugin, since the Spam counter on the Dashboard increased — that’s when I quickly wrote my previous reply, without further testing.

    However, it turns out that the product review remains published and is not actually marked as spam. Only the Dashboard counter seems to update.

    So my question is: have you tested whether WooCommerce reviews are effectively marked as spam? I can confirm they’re detected by the counter, but the actual spam management on the comment itself fails with WooCommerce reviews — possibly because they use slightly different metadata, which should be easy to support.

    Best,

    Fran

    • This reply was modified 7 months, 1 week ago by clip1492.
    Thread Starter clip1492

    (@clip1492)

    Wait, yess!!! It works, on the comment before I was testing while logged as admin, and with “Trust aproved commenters” enabled, so the spam test comment passed.

    Now I’ve retested it while unlogged and from a private browser window, and the comment was efectively filtered.

    Thanks, everything is clear now and I can confirm that the plugin filters Woocommerce Reviews, even with plugins like YITH advanced reviews.

    • This reply was modified 7 months, 1 week ago by clip1492.
    • This reply was modified 7 months, 1 week ago by clip1492.
    • This reply was modified 7 months, 1 week ago by clip1492.
    Thread Starter clip1492

    (@clip1492)

    **** READ THE SECOND TEST ON THE NEXT COMMENT BELOW, THE PLUGIN EFECTIVELY WORKS ON WOO REVIEWS ***

    Sadly it was not filtered and the comment with the wikipedia links was passed as valid through the woocommerce reviews form. “BBCode links are spam” was checked in.

    I guess nothing I can do except enable Google captcha on the form.

    • This reply was modified 7 months, 1 week ago by clip1492.
    • This reply was modified 7 months, 1 week ago by clip1492.
    Thread Starter clip1492

    (@clip1492)

    Hi Torsten,

    You can test it here: https://www.temporary-url.com/6984 (this is a masked URL since the site in question contains 18+ content)

    Please note that YITH Advanced Reviews is also installed, and the theme is Bricks Builder.

    I checked and WooCommerce product reviews are stored as regular comments (comment_type = ‘review’, linked to post_type = ‘product’).

    So yes, they’re technically normal comments — I’ll wait for your test results to see if Antispam Bee filters them correctly. This could also help other Woo store owners, and maybe you could mention WooCommerce reviews compatibility in the plugin features.

    Best,

    Fran

    • This reply was modified 7 months, 1 week ago by clip1492.
    Thread Starter clip1492

    (@clip1492)

    Thanks for the clarification — that helps a lot.

    It seems clear now that the reported privilege escalation vulnerability applied to Dokan Pro <= 4.0.8 , not Dokan Lite, which explains the confusion caused by some tools like WP Toolkit that don’t distinguish between Lite and Pro versions and clearly was sending a false positive alert.

    • This reply was modified 7 months, 3 weeks ago by clip1492.
    Thread Starter clip1492

    (@clip1492)

    Could you confirm if the results displayed in the thread were compressed by our plugin?

    I used “Quick Actions – Image Kit” macOS app to calculate the compression values that worked well on my previous workflow before I discovered CompressX.

    Conversion had to be run in batches manually on local computer and then had to FTP transfer the resulting files to the server, which is a pain in the ass, but better than running compression on 3th party remote servers from paid services.


    The site I’m working with, needs critical image quality due to the nature of its contents. As I will contiue testing the settings of CompressX, if any question arises about this topic, I will write it on this thread again. Thanks for your answer and i keep investigating.

    Thread Starter clip1492

    (@clip1492)

    Changing ‘Save Unauthenticated Favorites as’ from ‘session’ to ‘cookie’ on Settings-> Favorites->Users, seems to solve the issue.

    Thread Starter clip1492

    (@clip1492)

    I’ve enabled WP_DEBUG and the 503 doesn’t returns any error debug.log. I already checked this, and i would be more than happy if the system returns a clue about what is happening. Also no errors stated on redis.log.

    To recover the site, deleting object-cache-php is not enough, nor restarting redis service from terminal, but I must restart Apache and then things get back to normal.

    • This reply was modified 1 year, 7 months ago by clip1492.
    • This reply was modified 1 year, 7 months ago by clip1492.
    • This reply was modified 1 year, 7 months ago by clip1492.
    Thread Starter clip1492

    (@clip1492)

    Today I discovered that the unsolicited install of WPforms even bloated the WP database with 4 tables on my production site, which have not been removed after uninstalling WPforms:

    _wpforms_payment
    _wpforms_payment_meta
    _wpforms_tasks
    _wpforms_tasks_meta

    Maybe this is useful for other folks who had the same issue and like to have their database tidy. I hope this chapter ends here.

    • This reply was modified 1 year, 7 months ago by clip1492.
    • This reply was modified 1 year, 7 months ago by clip1492.
    • This reply was modified 1 year, 7 months ago by clip1492.
    Thread Starter clip1492

    (@clip1492)

    As Total Server Memory is 16GB, Swap: 4Gb, Free: 2.6 Gb , Buffer/Cache: 7Gb (this can be liberated)

    Then I’ve edited redis.config with:

    maxmemory 1024mb
    maxmemory-policy allkeys-lru

    then sudo systemctl restart redis which shows status active.

    Issued: redis-cli FLUSHALL again, just in case.
    Updated the plugin to the latest version released hours ago.

    Website works well, plugin shows: Status: Not enabled Filesystem: Writeable Redis: Reachable

    Clicking on “Enable Object Cache” issues again “Service Unavailable – 503” on all website pages (Admin and frontend).

    Deleting the object-cache.php on wp-contents this time doesn’t removes the 503, so I reboot the server, and everything goes back to normal, but without object cache.

    While wp error.log doens’t whows errors at the time of the 503, logs on redis.log show this:





    26313:M 16 Oct 2024 13:23:09.643 * DB loaded from disk: 0.002 seconds

    26313:M 16 Oct 2024 13:23:09.643 * Ready to accept connections tcp

    26313:M 16 Oct 2024 13:23:09.643 * Ready to accept connections unix

    26313:M 16 Oct 2024 13:24:26.072 * DB saved on disk

    26313:signal-handler (1729078073) Received SIGTERM scheduling shutdown...

    26313:M 16 Oct 2024 13:27:53.601 * User requested shutdown...

    26313:M 16 Oct 2024 13:27:53.601 * Saving the final RDB snapshot before exiting.

    26313:M 16 Oct 2024 13:27:55.104 * DB saved on disk

    26313:M 16 Oct 2024 13:27:55.104 * Removing the pid file.

    26313:M 16 Oct 2024 13:27:55.104 * Removing the unix socket file.

    26313:M 16 Oct 2024 13:27:55.104 # Redis is now ready to exit, bye bye...

    1333:C 16 Oct 2024 13:28:56.280 * Supervised by systemd. Please make sure you set appropriate values for TimeoutStartSec and TimeoutStopSec in your service unit.

    1333:C 16 Oct 2024 13:28:56.281 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

    1333:C 16 Oct 2024 13:28:56.281 * Redis version=7.2.5, bits=64, commit=00000000, modified=0, pid=1333, just started

    1333:C 16 Oct 2024 13:28:56.281 * Configuration loaded

    1333:M 16 Oct 2024 13:28:56.282 * monotonic clock: POSIX clock_gettime

    1333:M 16 Oct 2024 13:28:56.283 # Failed to write PID file: Permission denied

    1333:M 16 Oct 2024 13:28:56.283 * Running mode=standalone, port=6379.

    1333:M 16 Oct 2024 13:28:56.284 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

    1333:M 16 Oct 2024 13:28:56.284 * Server initialized

    1333:M 16 Oct 2024 13:28:56.285 * Loading RDB produced by version 7.2.5

    1333:M 16 Oct 2024 13:28:56.285 * RDB age 63 seconds

    1333:M 16 Oct 2024 13:28:56.285 * RDB memory usage when created 1.43 Mb

    1333:M 16 Oct 2024 13:28:56.288 * Done loading RDB, keys loaded: 2, keys expired: 0.

    1333:M 16 Oct 2024 13:28:56.288 * DB loaded from disk: 0.004 seconds

    1333:M 16 Oct 2024 13:28:56.289 * Ready to accept connections tcp

    1333:M 16 Oct 2024 13:28:56.289 * Ready to accept connections unix

    Any clue about how to solve it? Much appreciated in advance.

    • This reply was modified 1 year, 7 months ago by clip1492.
    • This reply was modified 1 year, 7 months ago by clip1492.
Viewing 15 replies - 1 through 15 (of 18 total)