I wrote about an influx of <a href="https:\/\/pagely.com\/blog\/tracking-wp-php-object-injection-attackers-in-november\/" target="_blank" rel="noopener noreferrer">PHP Object Injection attacks<\/a> previously, warning about a trend of attacks targeting a known but somewhat under-reported PHP vulnerability. Looking back since that time, I get the odd feeling that <em>object injection<\/em> (or as they're sometimes called <em>unserialize)<\/em> vulnerabilities keep cropping up. Wondering if this is just a frequency illusion (once you notice something like a certain make\/model of a car, you notice it everywhere!) or actually a trend; I dug into the numbers.\r\n<h3>Confirming Growth:<\/h3>\r\nThese type of attacks are in fact becoming more popular. Using <a href="https:\/\/wpvulndb.com\/" target="_blank" rel="noopener noreferrer">WPVulnDB.com<\/a> (a website which keeps tracks of WordPress core, theme and plugin vulnerabilities) I found that object injection vulnerabilities had 1 report in 2014, 4 in 2015, then doubled to 8 in 2016 and so far in 2017 there have been 13 reports (not bad for half way through the year)\r\n\r\n \r\n\r\n<img class="size-medium wp-image-9401 aligncenter" src="https:\/\/pagely.com\/wp-content\/uploads\/2017\/05\/Screen-Shot-2017-05-22-at-9.08.14-AM-1-600x471.png" alt="" width="600" height="471" \/>\r\n\r\nBack in November, I reported seeing a spike in attacks targeting insecure objects, and looking historically at reported vulnerabilities, we're seeing these numbers going up each year. It's not a stretch that these two facts lead me to suspect the WordPress and plugin developer communities may have had no (or bad) knowledge of the risks behind insecurely trusting serialized objects, while attackers have been weaponizing and targeting vulnerable sites.\r\n\r\nFull disclosure: I am the reporting party for some of the above vulnerabilities. One in 2016, and so far in 2017, seven. I took a weekend to see how many insecure usages of unserialize() I could find in the plugin code base and within hours had handfuls of working vulnerabilities; I stopped only so I could start triaging and notifying plugin authors regarding how to enact fixes. Many of which were appreciative for the help.\r\n<h3>About the Vulnerability:<\/h3>\r\nIf you want to learn more about how the exploit works, read here:\r\n<ul>\r\n \t<li><a href="https:\/\/www.owasp.org\/index.php\/PHP_Object_Injection" target="_blank" rel="noopener noreferrer">https:\/\/www.owasp.org\/index.php\/PHP_Object_Injection<\/a><\/li>\r\n \t<li><a href="https:\/\/www.notsosecure.com\/remote-code-execution-via-php-unserialize\/" target="_blank" rel="noopener noreferrer">https:\/\/www.notsosecure.com\/remote-code-execution-via-php-unserialize\/<\/a><\/li>\r\n<\/ul>\r\nIt is a well known high risk action to accept user input into the unserialize function. PHP.net even publishes a very large and mostly red warning on the usage page for <a href="https:\/\/php.net\/manual\/en\/function.unserialize.php" target="_blank" rel="noopener noreferrer">unserialize()<\/a>:\r\n\r\n<img class="aligncenter" style="width: 600px; height: 143px;" src="https:\/\/pagely.com\/wp-content\/uploads\/2017\/05\/Screen-Shot-2017-05-09-at-7.17.05-PM-600x143.png" alt="PHP.net Warning" \/>\r\n<h3>Addressing the threat:<\/h3>\r\nEvery WordPress developer (plugin or otherwise), nay everyone who writes PHP code, should take the above warning to not insecurely use unserialize() to heart. We (as in the WordPress community) could use some help with spreading knowledge about this vulnerability around.\r\n\r\nIf you are already using unserialize insecurely, you're in luck as patching may be easy to address:\r\n\r\nThe majority of code we have seen insecurely using unserialize could just as easily patch their code by changing how they hand off the data from a serialized object to a JSON representation of the values. In some cases simply replace <a href="https:\/\/php.net\/manual\/en\/function.serialize.php" target="_blank" rel="noopener noreferrer">serialize()<\/a> with <a href="https:\/\/php.net\/manual\/en\/function.json-encode.php" target="_blank" rel="noopener noreferrer">json_encode()<\/a> and <a href="https:\/\/php.net\/manual\/en\/function.unserialize.php" target="_blank" rel="noopener noreferrer">unserialize()<\/a> with <a href="https:\/\/php.net\/manual\/en\/function.json-decode.php" target="_blank" rel="noopener noreferrer">json_decode()<\/a> is the only change that needs to be made.\r\n<h4>For developers:<\/h4>\r\nPlease, if you are a developer, double check that you're not trusting serialized data sent from user input and passing it directly back to unserialize().\r\n<h4>For security researchers:<\/h4>\r\nThere are a lot of plugins out there, and a lot of vulnerabilities - I had to cut my research short just due to time constraints. If you're a researcher interested in picking up or helping out with this issue (hunting vulns, writing PoCs and recommending patches), <a href="https:\/\/pagely.com\/contact\/" target="_blank" rel="noopener noreferrer">get in touch.<\/a>\r\n<h4>For everyone else:<\/h4>\r\nIf you're not a developer or a researcher but worried about this threat, you can still help. Share this post with your friends and others who have WordPress sites, ideally developers. Together we can stop these Object Injection attacks from continuing to be a problem.