Vault - Site backup and migration

The "Config overrides" backup pre-check renders each configuration override in a table. In configoverride::format_setting_value_for_details() the setting value is escaped with s(), but the setting name and plugin are placed into the template array unescaped, and the template outputs all three with the raw/unescaped Mustache triple-brace syntax {{{name}}} / {{{plugin}}}.

The setting keys and plugin identifiers come from $CFG->config_php_settings and $CFG->forced_plugin_settings, i.e. exclusively from the site's config.php. To place HTML/script into one of these keys an actor must already be able to edit config.php, which requires filesystem access to the server (equivalent to full site compromise), and the report is only ever viewed by a site administrator. There is therefore no realistic cross-user exploit, but this is still an output-encoding gap that departs from the escaping the rest of the plugin applies consistently.

During a restore, dbtable::get_fix_sequence_sql() builds raw DDL by string-concatenating the table name (and the sequence field name) directly into ALTER SEQUENCE {prefix}{table}_{field}_seq … (Postgres) or ALTER TABLE {prefix}{table} AUTO_INCREMENT = … (MySQL). The $nextid value is an integer, but $tablename and $field originate from the backup's __structure__.xml (parsed in dbstructure::load_definitions_from_backup_xml()), i.e. from data outside the running site. The plugin quotes identifiers with getEncQuoted() in most other places, but not here.

Crucially, this code is reachable only from site_restore::restore_db(), which runs when a site administrator restores a backup. A restore rebuilds the entire database from the backup's contents, so an actor who can supply a malicious backup already controls all restored schema and data (including the config, user and capability tables). Injecting SQL through a table identifier therefore grants nothing beyond what performing the restore already grants. This is a defence-in-depth/code-quality issue, not a privilege escalation.

siteinfo::is_table_preserved_in_restore() decides, for a table with no schema definition, whether it should be preserved during restore by reading api::get_setting_array('restorepreservetables'). That setting is never defined in settings.php (the comparable backup path uses backupexcludetables), and the author's own inline TODO states "this setting does not exist!". As a result the lookup always returns an empty array, so preservation of definition-less ("extra") tables silently never happens.

This is a latent functional bug rather than a security issue: administrators who expect an undefined custom table to be preserved during restore will find it is dropped/overwritten with no error.

The Privacy API provider implements null_provider (whose get_reason() asserts the plugin "stores no data") plus a metadata\provider that declares an external-location transfer to lmsvault.io. However, the plugin does persist personal data of the operating administrator in its own tables: site_backup::schedule() writes usercreated, fullname and email into tool_vault_operation.details, and site_restore::schedule() writes id, username, fullname and email. Operation logs (tool_vault_log) can also contain usernames.

Because null_provider signals that no personal data is stored locally, this local storage is undeclared. The affected data subjects are limited to site administrators (only they can trigger backups/restores), so the exposure is small, but the Privacy API implementation is nonetheless inaccurate/incomplete.