Asheshv

An issue exists in the named restore point endpoint 'POST /browser/server/restore point/{gid}/{sid}' where the user-supplied `value` field is interpolated directly into the SQL string using `str.format()` instead of being passed as a bound parameter. This allows an authenticated user with a connected PostgreSQL session to inject additional SQL statements. The injected code executes under the database role of the authenticated user, meaning it does not cross privilege boundaries. However, this provides an alternative execution path that could bypass application-layer restrictions placed on the Query Tool.

An authorization issue in server mode affects the Server Groups, Servers, Shared Servers, Background Processes, and Debugger modules. Multiple endpoints fail to filter user-owned objects by the requesting user's identity, allowing an authenticated user to access another user's private servers, server groups, background processes, and debugger function arguments by guessing object IDs. The Shared Servers feature also allows credential leakage of `passfile`, SSL keys, and `passexec cmd`. Furthermore, non-owners can write to owner-only fields via the API, including `passexec cmd`, `passexec expiration`, `db res`, and `db res type`. Modifying `passexec cmd` (a shell command executed during connection establishment) can lead to privilege escalation and arbitrary command execution within the owner's process context. Additionally, fields such as `kerberos conn`, `tags`, and `post connection sql` lack per-user persistence, meaning edits by non-owners mutate the owner's record, leading to data corruption via SQLAlchemy session mutations.