⚠️ Make sure your Podlove Publisher is updated to v4.2.7 (published September 20). It fixes an exploit (published September 22) that is actively being used to upload malicious code to WordPress instances.
⚠️ Make sure your Podlove Publisher is updated to v4.2.7 (published September 20). It fixes an exploit (published September 22) that is actively being used to upload malicious code to WordPress instances.
Shout out to @ubernauten who went the extra mile to help detect and mitigate attacks for their users.
This post may help you find out if you were affected: https://uberspace.social/@ubernauten/115264495468009257
I can now confirm this as I have seen infected instances where wp-admin contained files like `3wF3e0.php` and a `.htaccess` that should not be there.
In http logs, you might see `GET /index.php?podlove_image_cache_url=...`, followed by a call of the exploit file in the cache directory.
–Eric
@adlerweb See https://github.com/podlove/podlove-publisher/blob/67f7a6577bc27dd0d0bf11c7ae715ea6c0d9dfc3/lib/model/image.php#L434-L446
The move_as_original_file from the initial report comes after an \Podlove\is_image check. I decided to implement the fix there.
Here's the commit that hardens the is_image check: https://github.com/podlove/podlove-publisher/commit/68d99dadeb5ab4c1353a70f0abe7cc66822713d9
– Eric
Some signs for contamination:
- Your main index.php includes stuff behind `<?php` in line 1, something like `goto ...` (same may be true for other WordPress default files):
- You find cache.php files that contain `error_reporting(0)` followed by obfuscated code
- You find files containing `error_reporting(0); set_time_limit(0);` - even though they may not be php files - followed by all kinds of access permission changes to files