Wake up.
An email from a vendor recently argued that a SQL injection vulnerability in their database backup CLI was merely "informational" because:
"If an attacker can create a table with a malicious name, they already have access."
The response also stated:
"We do not consider the CLI to be suitable for machine usage and do not use it for internal workflows."
There are two fundamental problems with this reasoning.
First, the threat model assumes only the workflows the vendor personally envisions.
There are SaaS n-tier designs where users actually create datasets, workspaces, projects, import jobs, tenant-specific resources, temporary analysis tables, plugin-defined objects, and many other entities that eventually become database object names. User-controlled object names are not an edge case.
Second, the threat model ignores how customers actually operate systems.
DevOps teams use CLI tools for automation every day. Backups, restores, migrations, exports, CI/CD jobs, disaster recovery procedures, and offsite archival processes are frequently driven by platform CLIs. Whether the vendor uses the CLI internally is largely irrelevant. Customers do.
The security question is not whether an attacker can create a table.
The security question is whether attacker-controlled metadata can be processed later by a different trust boundary: an administrator, a service account, a backup pipeline, a CI runner, or an automated operational workflow.
As a platform provider, your threat model cannot stop at your own assumptions about how customers should use your product.
(Oh by the way, yes we have these both use-cases at PRODAFT :)