3 ms·
This is almost always at the core of WP exploits. Sure, there have been some SQL injection and XSS, but almost every WP exploit I've seen in person has been re
by mgkimsal 9y ago
This is almost always at the core of WP exploits. Sure, there have been some SQL injection and XSS, but almost every WP exploit I've seen in person has been related to files being able to be written to the filesystem and become a publicly accessible URL immediately.
I don't do as much with WP these days, but have worked with it some over the years, and work with multiple folks in the geographic area who primarily do WP work (friends with folks who run WP meetings and do all-WP work, etc).
I've seen dozens of exploited systems in the last 2-3 years, and been asked to help 'clean them up'. Every single one of those was some variation on some bot exploiting some code (in core or in a plugin) that allowed for some obfuscated code to be written to a publicly accessible directory, with names like "includes.php" or "sys.php" (things like that) - common words that no one who is not a WP expert would even think to question in the first place (no one leaves BACKDOOR_EXPLOIT.php as a file name, for example).
Yes, you can install stuff like wordfence and similar tools to continually scan your disk to look for 'infections', but... why allow those to be written to the drive in the first place? I know the answer is "convenience", but it's been a huge community price to pay.