[jakejake]

I just commented it out myself but validating $shortcode might be a better solution.

[update] that wouldn't work either. it would still allow people to insert random shortcodes with whatever params they like. i'm not sure what the point of this function is, I don't think it should allow shortcodes to be passed in at all via _REQUEST

[golden_apples]

The php code would be inside a shortcode that looked like [php][/php], so no, that wouldn't protect you.

The smart fix is to check for user permissions and nonce before rendering the shortcode preview, which I hope is what the Woo patch does.

[jakejake]

cool thanks, yea i just looked at do_shortcode again. this woothemes function seems like a bad design.

Authentication would plug it from random attackers at least. But it seems to me it would still be ripe for a CSRF attack..? That might seem unlikely but I can imagine the attacker could post a comment with a link on the victims blog who had been identified as having a wootheme installed. If the victim clicked the link (likely while authenticated) the attacker's php code would execute.

[golden_apples]

Nonces, used properly, should be fairly decent protection against the kind of CSRF attack you're describing. They're not bulletproof, but, someone who knows enough about the internals of your site to generate a valid nonce probably has several other possible attack vectors...

I haven't looked at the actual theme in question, but I can imagine that a lot of Woo clientele want to be able to preview their posts with all the shortcodes intact, which is what this function does, and why it has to receive shortcode data through request parameter.

[jakejake]

I haven't seen their patch yet. I'd be surprised to see a nonce, my guess is they just call the standard Wordpress function to require auth.

There's surely a better way to do it without accepting code via the query string. Keep the code on the server and have that function only refer to an index or something perhaps?