Opened 3 years ago
Closed 3 years ago
#50274 closed defect (bug) (duplicate)
Database upgrade without an admin session
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | |
| Component: | Database | Keywords: | |
| Focuses: | administration | Cc: |
Description
Recently I experienced an interesting breach in WordPress security, which I haven’t found discussed anywhere yet (excuse me if so!).
It seems WordPress allows any single visitor to perform a database upgrade after a core system upgrade.
How is this possible?
In order to notice this your WordPress installation had to be updated recently with a version jump that requires database upgrade as well. This can happen even by itself because the majority of WordPress installations are upgrading by themselves using the wp-cron.
So let’s say your WordPress has been recently updated from v 4.9 to 5.4. Then the upgrade is usually finished with this screen, asking you to upgrade the database.
This seems pretty normal and straight forward. Yes, for sure if you are a logged-in the administrator that just performed the upgrade.
The problem – you don’t have to be logged to perform this
However, if you decide to destroy your session and open the /wp-admin as a guest visitor – you will notice the same screen. We attach it with a screenshot of our active cookies. No logged-in session is present as you can see.
That doesn’t seem so right. Let’s watch the whole process with the cookies tab opened in our specially recorded for the case YouTube video.
https://www.youtube.com/watch?v=sODsvSykUqw&feature=emb_title
As you can see we first performed the database upgrade as a guest visitor and after that, we logged ourselves in the admin area.
I don't consider this a hacker thing, but more like not following good practices.
I would like to personally fix the code, how can I contribute?
Hello @vipestudio, thanks for the ticket and your interest in contributing to WordPress.
Unfortunately, the ticket is a duplicate of #3901, as this is working as expected/designed and is not a security issue. Please see previous discussions on #3901 and #34200 for more background on the decision.