id summary reporter owner description type status priority milestone component version severity resolution keywords cc focuses 13827 Spam Vulnerabilities In wp-signup.php Breaking Plugins uglyrobot wpmuguru "I feel comfortable posting this here as the exploit is being observed in the wild already. We have a signup code plugin, i’ve seen about 3 users report spammers getting past the signup code without knowing it. I've also seen similar ineffectiveness with captchas and other antisplog plugins out there. Finally someone posted their logs (http://premium.wpmudev.org/forums/topic/spammer-bypassed-signup-code) so I could find the issue, and I think it could be classified as a security bug in MultiSite. The problem here is in the way the wp-signup.php handles stages. A plugin can either choose to add a check to the user part or blog part of signups. If you click the gimme a blog option it simply prints user info you entered in the screen before as hidden inputs, it's not saved in the db or anything until the blog form is completed: {{{ }}} So a bot can simply post those hidden variables and skip the user part of wp-signup.php completely, along with any protections a plugin has added to it. There are nonces that are supposed to help with that, but from the logs I think the bot is scraping it off the user page first, and since they never submit that part of the form the nonce is still valid on the blog part of the form as they are the same nonce id. Even if the nonce ids were changed though a bot could first submit invalid data to the blog part and collect the nonce there as well. This bug essentially breaks half of the anti-spam plugins out there as they add protection to the user part of the form, and bots can skip that completely! As it stands a plugin can only protect user or blog signups, not both without being annoying (2 captchas to signup, etc). The only solution I can see is a complete rewrite of wp-signup.php, probably to put user and blog fields on the same page maybe hidden with JS as BuddyPress does. Unfortunately that means likely needed rewrites to many signup protection plugins. While we're considering a rewrite of wp-signup.php, I would like to see it switched to a format more like BuddyPress uses, with it being a fake page slug that can be defined in wp-config.php and calls the default theme page template for display. Though that's more of a feature request for a future release." defect (bug) closed normal Multisite 3.0 normal wontfix needs-patch reporter-feedback