3.0.2 and 3.0.3: You do not have sufficient permissions to access this page.

I get the same thing whenever I have a plugin with it’s own top level menu. It appears when I try to access it’s second level menu.

I am having the same issue that you both are describing in addition to others.

When I wish to access edit.php, I am greeted with the message “no posts found”, even though the same page displays that there are 500+ posts.

Lastly, the categories page is empty, though I have hundreds of categories. Interestingly enough, the pagination still exists, showing the correct number of pages for the categories I have, only no categories are listed.

Yes, I discovered that I am having the problems @stevesearer describes on:
/wp-admin/edit.php
/wp-admin/edit-tags.php
All three are showing blank tables of posts/categories/tags.

Steve — did this start happening to you when you upgraded to 3.0.2?

I’m having similar issues. I have two different blogs on my server, one has 3.0.2 and one has 3.0.3 on it, both are having the same issue. I don’t blog a lot, so I’m just now noticing this. I’m not sure how long it’s been this way.

??wp-admin/edit.php —?says no posts found, while also showcasing that there are “All (21) | Published (21)”
??wp-admin/edit.php?post_type=page —?same issue
??wp-admin/post-new.php —?missing important form fields like “publish post” categories, tags, etc, the menu items are not available, “screen options” is also missing here

My two sites are working fine on the front-end, it’s just inside the CMS that these problems are occurring.

Also having the same issue. I’m running 3.0.3 on MediaTemple’s grid service. Symptoms:

• “No Posts Found” but post counts show up correctly.
• “You do not have sufficient permissions to access this page.” on all plugin pages.
• Can edit existing pages/posts but not add new posts.

Things I’ve tried:

• Increasing memory available to PHP
• Disabling all plugins
• Manually upgrading database by pushing back db_version number
• Setting back to the default theme
• Updating .htaccess rules

I’m curious if this is a MediaTemple issue. Someone else inferred that might be the case. Right now the blog in question — which normally has 3-5 new posts a day — is paralyzed until this can be resolved.

Josh, I too am on mediaTemple… hmmmm..

Experiencing the same issues as well AND the site is on MediaTemple.

I am experiencing all of these same problems… and I am ALSO on Mediatemple.

Hmmm, so we have several people experiencing a problem, ALL of whom seem to be running on Media Temple.

How long do you think we’ll have to wait before Media Temple drops their lame “we can’t support third party software” line and actually does something?

There’s a ‘known’ hack running around affecting MediaTemple. Which is to say I’ve heard of a hack, but no details about how it’s happening :/

Check your root directory for PE*.php files.

See https://www.ads-software.com/support/topic/problems-with-303?replies=17#post-1834901

@ipstenu: Thanks for following up with this post. I did eradicate some other malware but did not catch this one. Totally makes sense now as I suspected that there was still something else occurring on the site intermittently. I just didn’t know about this particular hack.

Curious if MediaTemple has a response to this.

I followed up with MT and below is their response. Totally makes sense and I’ll be taking their described steps to harden my sites. Here’s the main link they provided below:

GS:Improve your PHP security
https://wiki.mediatemple.net/w/GS:Improve_your_PHP_security

————
As a courtesy, I ran a scan on your (gs) Grid-Service to find and remove any known malware and payloads that our customers have been infected with recently. The results of this scan can be found in the mt_change.log file located in your home directory, as well as the changelog file located in data/mt_dbclean.

I definitely do see that the infection has spread across several domains as you’ve reported. However, this is most likely due to the infection gaining access to your (gs) Grid-Service through an out-of-date WordPress installation. Unless you enable open_basedir restrictions to secure PHP on your (gs) Grid-Service a bit further, it will be possible for these infections to spread across all domains. This is why you saw the infection on static HTML sites. That being said, enabling open_basedir restrictions would provide you with added security. This would essentially isolate your domains from each other, which would prevent the infection from spreading.

GS:Improve your PHP security
https://wiki.mediatemple.net/w/GS:Improve_your_PHP_security

The out-of-date WordPress installation that I’m seeing is for the domain xxxxxxx.com. You will want to update this, as well as other CMS installations that you have on your (gs) Grid-Service, to the latest version. Currently, the latest version of WordPress is 3.0.3. The latest releases, according to WordPress/Codex, are mandatory updates. This is due to the nature of the update, which was done as a security patch for exploits that were made known.

Please do keep in mind that we are happy to help you set up everything regarding our servers, and will often go the extra mile to help you set up third-party software to access our servers correctly; however, we are not responsible for the configuration or malfunctions of third-party software.

You may also consult the “Scope of Support” page for more details regarding the scope and amount of support covered by (mt) Media Temple for this and/or other specific products. Please visit the following URL for more information: https://www.mediatemple.net/go/sos/.

Let me know if there’s anything else I can answer for you regarding your (mt) Media Temple services.

Best regards,

Short answer: Fix your server security. If you’re paying MT for this crap support, give them hell and make them help you. Remember, you’re not going to ask them for help with WORDPRESS, you’re asking them for help securing your SERVER. And if they balk at supporting that, take your money to a better host.

Longer rant:

However, this is most likely due to the infection gaining access to your (gs) Grid-Service through an out-of-date WordPress installation.

Answers like this make me want to get a shotgun. They are WRONG. Yes, there are known security bugs in WP 3.0.1 (which is why you should be on 3.0.3 right now) BUT those flaws do not cause the type of exploit you’re seeing! That’s a lazy-ass off the cuff reply. BAD MT! No cookies!

But yes, please upgrade to 3.0.3 ASAFP.

(By the way, this ‘hack’ is happening on plain HTML sites – which makes it really unlikely that WordPress is the vector. Possible? Of course! Likely? Not so much – read https://blog.sucuri.net/2010/12/malware-update-publifacil-org-htaccess-changes-and-pe-php.html for more)

Unless you enable open_basedir restrictions to secure PHP on your (gs) Grid-Service a bit further, it will be possible for these infections to spread across all domains.

This is more correct. Basically, your server setup isn’t secure. Now, where I want to shoot them again is when THEY DON’T FIX IT! Their job is to go ‘Hey, you know what, this is BAD and dangerous for EVERYONE. Let’s fix it!’ And then tell you ‘You can’t do that anymore because it’s dangerous.’ That’s their damned job. Fail.

Any host that doesn’t get up off their butts to help you secure your server is a host you don’t need to do business with.

And this makes, what? The third time in the last year MT has had hacks like this???

This is the first time I’ve seen it on their Grid Services, mind you, but yes. It’s been a bad year for NetSol and MT.