Title: 1.5.1.3 – remote code execution 0-DDAAYY exploit Last modified: August 18, 2016 --- # 1.5.1.3 – remote code execution 0-DDAAYY exploit * [hevnsnt](https://wordpress.org/support/users/hevnsnt/) * (@hevnsnt) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/) * Any fixes for this yet? I am not posting the exploit here Viewing 14 replies - 1 through 14 (of 14 total) * [Mark Jaquith](https://wordpress.org/support/users/markjaquith/) * (@markjaquith) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246541) * A patch has been created and should be committed soon. Actually, the idea is to completely kill all register_globals type exploits. * [Lorelle](https://wordpress.org/support/users/lorelle/) * (@lorelle) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246722) * According to “experts” on the subject this is a PHP issue and not just related to WordPress and has been known for a while: * “The `register_globals` is evil. You shouldn’t have it turned on anyway. Turn it off. Now.” * This is also according to PHP and security expert, [Chris Shiflett](http://shiflett.org/talks/oscon2003/14). * To turn it off, add the following line to your `.htaccess` file in your WordPress root directory on your server, if your host server supports the use of php_flags: * `php_flag register_globals off` * And now it is fixed. * [absynth](https://wordpress.org/support/users/absynth/) * (@absynth) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246728) * Claiming that “register_globals is evil” is nothing but FUD. Not register_globals per se is evil, but lazy programmers that rely on it – or write flawed “deregistration layers”. * Contrary to self-proclaimed “security experts” claiming otherwise, there is a lot of PHP products that run very well with register_globals on or off, without having to resort to finger pointing at a language feature. * Do you “experts” also consider echo evil because it can be used to greatly faciliate XSS attacks by not filtering output? Or mysql_query() – because without it, SQL injection would not be possible? Your logic is seriously flawed. * [ionic](https://wordpress.org/support/users/ionic/) * (@ionic) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246730) * It is good that you have used quotes around “experts”. * Because according to experts this is an issue with poorly programmed PHP applications. A problem caused by lazy programmers that do not initialize their variables. * When you write C code you also have security problems if you do not initialize your variables. This is for sure not a PHP issue. * And as a sidenote: Chris Shiflett is not a security expert. I invite you to look into his very own software projects, that you can download from his website. In his wwwforum you will find nearly every possible security hole that one can construct within a PHP application. * Btw: turning of register_globals in your .htaccess will not work at all on non apache webservers. * Btw2: the WordPress team knows about other security holes in WordPress 1.5.1.3 for some time now, but they consider them not important enough to fix them. * [masquerade](https://wordpress.org/support/users/masquerade/) * (@masquerade) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246731) * That’s interesting, because at no point have the WP developers ever shown this type of characteristic. I’d like to see even one known exploit that the devs refuse to fix. * [ionic](https://wordpress.org/support/users/ionic/) * (@ionic) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246733) * Ask photomatt. * [skippy](https://wordpress.org/support/users/skippy/) * (@skippy) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246736) * For various reasons, the core WordPress developers (that is, Ryan and Matt) do not discuss WordPress exploits until a patch is available, and a release plan is in place. * The vitriol about unpatched vulnerabilities is mis-placed. Matt and Ryan have an obligation to make sure that the problems they fix do not cause more trouble. We experienced this with 1.5.1.2, which was released to fix a problem, and ended up introducing additional problems. * And as I said, it involves more than just patching. The patches need to be sufficiently tested. The upgrade process needs to be supported by the volunteers here. Simply releasing a new version, and saying “here you go!” would do more harm than good. * I’m not thrilled about the existence of security vulnerabilities; but it’s a fact of life that they’ll always be present. WordPress is an increasingly complex piece of software, and although Matt and Ryan make an effort to be security conscious in their coding, they are after all human beings. We all make mistakes; we all have bad days; we all overlook some things. * You can help, rather than complain. * Every single reader here is invited to participate in WordPress’ development. If you notice problems, please log them at [trac.wordpress.org](http://trac.wordpress.org/). If you discover a severe vulnerability, email [security@wordpress.org](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/security@wordpress.org?output_format=md). The Open Source mantra is “With many eyes, all bugs are small.” By working together, we can squash bugs and make sure that WordPress is as secure as it can be. * [Mark Jaquith](https://wordpress.org/support/users/markjaquith/) * (@markjaquith) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246760) * Code has been checked in to safely initialize all variables that could “leak” through on systems with register_globals on. Like you said, setting the phpflag isn’t possible on all systems. A universal solution is the goal. * By all means, look at the new code and utilize the Trac bug reporting system to contribute improvements. * [robfay](https://wordpress.org/support/users/robfay/) * (@robfay) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246790) * Will that line of code in the.htaccess file resolve the issue? I am thankful that you are aware of this issue and will quickly resolve it. * Let me provide you with some motivation – a nightmere result of this vulnerability hits a novice – me! I got hit within the last 24 hours through this exploit and an IRC bot got onto my server. My webhost suspended my account (thinking it was my maliciousness – later pointed me to this post and realized it wasn’t me) and I just about lost it! I have a big demo in less than two hours, so I had to explain that I’m no sysadmin or programmer – just know enough html and css to get by using wordpress. Thankfully, he appeared to resolve the issue and reinstated my account. Whew! Website back up! * Thanks for looking into and resolving this serious issue. * [masquerade](https://wordpress.org/support/users/masquerade/) * (@masquerade) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-246797) * The line should resolve the issue on apache servers. A better solution is to tell your host that register_globals should be off in php.ini, and it will greatly improve their security. * [robfay](https://wordpress.org/support/users/robfay/) * (@robfay) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-247031) * What other precautions might I try? Should I change webhost account passwords along with wordpress passwords? Are these vulnerable as a result? * It already appears that I might be getting a bit more comment spam than before, but that could be my imagination. * [shep](https://wordpress.org/support/users/shep/) * (@shep) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-247106) * for those in which the .htaccess solution doesn’t work, you might be able to do this, if your host allows you to have custom php.ini files. * [http://forums.site5.com/showthread.php?t=961&highlight=register_globals](http://forums.site5.com/showthread.php?t=961&highlight=register_globals) * [chrisgeleven](https://wordpress.org/support/users/chrisgeleven/) * (@chrisgeleven) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-247124) * Anyone know if DreamHost has globals turned on by default? * [ifelse](https://wordpress.org/support/users/ifelse/) * (@ifelse) * [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-247125) * By default, [register_globals is turned on with DH](https://panel.dreamhost.com/kbase/index.cgi?area=3070). * To turn it off, add `php_flag register_globals off` to your .htaccess file as Lorelle mentioned. Viewing 14 replies - 1 through 14 (of 14 total) The topic ‘1.5.1.3 – remote code execution 0-DDAAYY exploit’ is closed to new replies. * 14 replies * 11 participants * Last reply from: [ifelse](https://wordpress.org/support/users/ifelse/) * Last activity: [20 years, 10 months ago](https://wordpress.org/support/topic/1513-remote-code-execution-0-ddaayy-exploit/#post-247125) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics