Description

Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.4, Vvveb backend post revision operations allow a low-privileged Author to access revisions for posts owned by another Author. The admin/controller/content/revisions.php controller and admin/sql/sqlite/post_content_revision.sql queries trust caller-controlled post_id, language_id, and created_at values without consistently applying the current admin_id to revision lists, reads, restores, and deletes. An attacker can read historic post content, restore a revision over another Author's live post content, or delete revision records, exposing drafts, corrupting published content, and removing audit history. This issue is fixed in version 1.0.8.4.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.3",
  "pubDate": "2026-08-18T17:16:57.977Z",
  "pubdate": "2026-08-18T17:16:57.977Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) vulnerability exists in Vvveb prior to version 1.0.8.4 within the backend post revision operations.\nThe vulnerability allows a low-privileged Author to access, read, restore, and delete post revisions owned by other authors.\nThe impacted systems include Vvveb instances running versions prior to 1.0.8.4, specifically affecting content management and administrative revision controllers.\nRisk implications include exposure of sensitive draft content, unauthorized corruption of live published articles via malicious revision overwrites, and deletion of critical audit history records.\nAn attacker requires low-privileged Author authentication within the backend interface to exploit the missing authorization checks.\nThe flaw stems from the application trusting caller-controlled parameters without validating ownership against the current session's admin_id.",
  "technicalDetails": "The root cause of this vulnerability is an authorization bypass resulting from missing context validation within backend controller and database query logic.\nSpecifically, the vulnerable components include the admin/controller/content/revisions.php controller and the underlying database queries located in admin/sql/sqlite/post_content_revision.sql.\nDuring revision management operations, the application accepts caller-controlled parameters such as post_id, language_id, and created_at without consistently enforcing authorization boundaries.\nThe system fails to cross-reference these supplied parameters against the current authenticated session's admin_id to verify whether the requesting user actually owns the target post or revision.\nAuthentication is required to access the backend, but the privilege level required is merely that of a low-privileged Author.\nAttack flow proceeds as follows: an authenticated Author intercepts or crafts HTTP requests directed at the revision management controller.\nBy manipulating parameters such as post_id or associated revision identifiers within the request, the attacker can bypass logical access controls.\nThis allows the attacker to query and read historic post content belonging to other authors, execute arbitrary restorations of unauthorized revisions over another author's live post content, or issue delete commands to purge revision history records.\nPost-exploitation impact involves unauthorized information disclosure of drafts, integrity compromise of published content through forced state reversion, and non-repudiation failures due to audit trail deletion.\nThe issue is definitively resolved in Vvveb version 1.0.8.4 by implementing proper access control checks that bind revision lists, reads, restores, and deletes to the verified owner of the resource."
}