CVE-2023-51949 is a high severity cross site request forgery flaw in the role controller of Verydows 2.0, scored 8.8. A logged in administrator who visits a hostile page can have roles created for them. A fix is not confirmed, so restrict the admin panel and add anti CSRF tokens.
What's affected
CVE-2023-51949 affects Verydows version 2.0, a PHP shopping cart application, in the /protected/controller/backend/role_controller component. NVD published it on 2024-01-12 with a score of 8.8 (high) and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. User interaction is required.
The reporter's note names the version and points at the project's Gitee repository. It shows that the form which creates a role in the back end can be submitted from another site without any token. I found no fixed version or vendor advisory, so check the project repository for a newer release.
Only version 2.0 is named in the record. Whether earlier releases share the code is unverified.
Weakness class: CWE-352.
How to check if you're exposed
Check the version of Verydows in your deployment by looking at the project files or the back end footer, then compare to 2.0. If you maintain a fork, search the back end controllers for forms that change roles or permissions and see whether they carry a token:
grep -rn "role" protected/controller/backend/ | head
Check whether the admin panel is reachable from the public internet. The risk needs an administrator with an active session, so the number of people who stay logged in matters.
Review the list of roles and their permissions in the back end for any you do not recognise.
What to do now
- Find every Verydows instance and confirm version 2.0.
- Check the project repository for a patched release and upgrade if one exists. If none does, plan to patch the controller yourself or migrate.
- Add an anti CSRF token to each state changing back end form, and verify it on the server for every POST. Frameworks usually provide helpers for this.
- Set the session cookie SameSite attribute to Lax or Strict, and ask administrators to log out when they finish.
- Restrict the admin path by IP address or VPN, and review the role list for entries you did not create.
Why it matters
This is CWE-352, cross site request forgery. A browser sends the administrator's session cookie along with any request to the site, whether the request came from the admin's own click or a hidden form on another page. Without a secret token that the attacker's page cannot know, the server cannot tell the difference.
The impact is high because the target is role management. An attacker who can create a role with broad permissions has built a path to take over the store, including customer and order data. The record's KEV flag is false and I found no report of exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the attacker need a password?
No, but the victim must be an administrator with a live session who visits the attacker's page. That is the user interaction in the vector.
Do SameSite cookies fix this?
They help a great deal in modern browsers, but they are a layer. Add server side tokens as the real fix.
Sources
Reporter write-up on GitHub (fetched, third party; it contains proof of concept details that are not reproduced here)
NVD record for CVE-2023-51949 (the record this guide is built from)
Last reviewed: 19 October 2026.
