> Rails looks for files in specific locations to execute code, not arbitrary encoded strings.

The examples from this article are all essentially malicious third-party code. No language will save you from that.

That is why WordPress should save you from that. The WordPress team has had an awful attitude about security. They encourage a culture of free templates shared widely, without much regard for warning users of the dangers. Most users of WordPress are non-technical, the WordPress team knows this and shows no particular concern about it. WordPress needs to get serious about offering some security checks.

Start checking templates and plugins for `base64_decode` and they'll just start using a new technique to hide these things. The solution is one they've already implemented - a trusted source for templates and plugins on WordPress.org, and the WordPress.com site for folks who really shouldn't be administrating a LAMP environment anyways.

There are several solutions that can be tried, and most of them have been mentioned in this thread already. There is whitelisting, various automated checks, trusted sources, encryption, warnings, attempts at education, etc.

None of these suggestions are worth a damn until the WordPress team acknowledges that WordPress security is a major problem, one that should be a top priority for them.

Security is a major issue and it is a top priority for us.

The examples from this article also obfuscate the malicious third-party code and execute it. Yes, the WordPress team should do more to prevent this sort of nonsense.