Some taxonomy names should be disallowed

[Denis-de-Bernardy]

I haven't tested, but can't we can get all sorts of weird bugs (some of which could have potential side effects in the security department) if a term taxonomy is called users, userlogins, posts, etc.?

the reason are lines such as:

wp_cache_add($term->term_id, $term, $term->taxonomy);

Rather than being dis-allowed, The group should be prefixed with something, such as tax-$taxonomy

Milestone: In my opinion, This is not a "high-risk" security issue. My reasoning for this, is due to that it takes a malicious plugin or theme running on your blog in order for an issue to arrise. Due to it having little impact upon end users (Rather, The onus falls on Developers right now to use a non-conflicting taxonomy name, And any malicious plugin could access/overwrite users directly) and not being a regression from a previous version, It belongs in the next major release.

outch, as what i've seen today, this will allow to overwrite posts in cache. I'll raise the severity and priority one step in the hope that we can improve things before we fall over our own feets.

BUT: I can not find that line in core: wp_cache_add($term->term_id, $term, $term->taxonomy); please reference at least one location for this to be reviewed.

BUT: I can not find that line in core: wp_cache_add($term->term_id, $term, $term->taxonomy); please reference at least one location for this to be reviewed.

FWIW there's an equivalent call in the update_term_cache function of wp-includes/taxonomy.php (line 2167 of revision 14032): wp_cache_add($term->term_id, $term, $term_taxonomy);

I agree with dd32, a theme or plugin would need to create a taxonomy with a conflicting name.

That has no security severity, since we already rely on theme/plugin being trusted. If we'd consider this issue a security flaw, then what about theme/plugin being able to edit global $post from any action and filter, or add filters to get_option()? With these 2 little features anything in a site can be changed from a code running in modules.

Only security risk I see here is if a theme/plugin is installed, hides data in cache using this method, and then it's found as risky and removed from wp-content, but its altered data remains in cache until cache becomes outdated and forced to be updated from database. But if that's the case, whoever removes it will know about cache and a simple wp_cache_flush() will solve the rest.

The real problem here is if a theme designer that knows little about Core and never saw cache in his life decides to create a taxonomy "users". But terms have different fields than other objects, so the whole site would probably break still during development, just with pageload-living cache, still during development. He would find it out easily and learn about cache or much probably just try giving his taxonomy another name and see everything go back to normal. "Well, IDK why that happened, but it seems a taxonomy named 'users' breaks everything, I'll just use a less common name and move on".

using a prefix like "tax-".$term->taxonomy in every cache code solves it all.

Replying to hakre:

BUT: I can not find that line in core: wp_cache_add($term->term_id, $term, $term->taxonomy); please reference at least one location for this to be reviewed.

In 3.0.* it's wp_cache_add($term->term_id, $term, $term_taxonomy).