---
id: "CVE-2026-112904"
kind: "vulnerability"
aliases: ["CVE-2026-112904"]
title: "Vvveb CMS: admin backup controller reads and writes arbitrary server files"
severity: "high"
cvss: 8.7
epss: 0.00506
exploited: false
status: "open"
category: "other"
products: []
ecosystems: []
tags: ["other", "php", "self-hosted", "vvveb"]
not_affected_if: ["patched-builds"]
published_at: "2026-10-23T12:18:11+00:00"
first_seen_at: "2026-10-23T21:57:32+00:00"
updated_at: "2026-10-25T12:38:51+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112904", "first_seen_at": "2026-10-23T21:57:32+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-112904", "first_seen_at": "2026-10-25T12:38:51+00:00"}]
---

# Vvveb CMS: admin backup controller reads and writes arbitrary server files

Vvveb, a PHP content management system, fails to sanitize a file parameter in its backup restore and backup functions. An logged-in administrator can read arbitrary files from the server and write SQL dump content to arbitrary paths.

_Summary, check and fix written by a model from the sources; labelled as such._

## Fix

Update Vvveb to a release that includes commit aa29cb0; versions 1.0.8.6 and prior are affected. The fixed release number is unknown from the sources.

## Timeline

- 2026-10-23T21:57:32+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-112904
- 2026-10-25T12:38:51+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-112904

## From the sources

Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. In versions 1.0.8.6 and prior, the nextRestore() and nextBackup() functions in the backup controller accept a file GET parameter and concatenate it directly to DIR_BACKUP without calling sanitizeFileName(). This allows an authenticated administrator to read arbitrary files on the server (via nextRestore) and write SQL dump content to arbitrary locations (via nextBackup). This is inconsistent with the sibling functions restore(), delete(), and download() which all correctly call sanitizeFileName() first. This issue has been patched via commit aa29cb0.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_