What is privilege escalation in DB?
In the world of database security, Privilege Escalation is the digital equivalent of a janitor finding a way to transform their lobby key into a master key that opens the CEO’s office and the bank vault.
It is a type of attack where a user with low-level permissions exploits a bug, a design flaw, or a configuration oversight to gain higher-level privileges (like DBA or SYSDBA).
The attacker moves up the hierarchy. A standard application user finds a way to become a Database Administrator. This is the most dangerous type because it leads to total system takeover.
The attacker moves sideways. A user who is only supposed to see their own medical records finds a way to see everyone else’s medical records. They haven't become an "admin," but they have accessed data they shouldn't see.
AUTHID DEFINER)By default, when you create a PL/SQL procedure, it runs with the permissions of the person who created it, not the person running it.
The Exploit: If a DBA creates a procedure that is poorly written and grants EXECUTE to PUBLIC, a low-level user can run that procedure to perform actions only a DBA should do (like creating a new user or deleting a table).
As we discussed in the SQLi blog, if an attacker can "inject" code into a high-privileged procedure, they aren't just stealing data—they are executing commands with the authority of that procedure's owner.
Sometimes, simple mistakes lead to escalation. For example, granting CREATE ANY TRIGGER to a junior developer.
The Exploit: That developer could create a trigger on a table that a DBA uses. When the DBA logs in and touches that table, the trigger fires—executing code as the DBA and potentially granting the developer the DBA role.
Modern databases are deeply interconnected. A privilege escalation in one database often provides the "stepping stone" to:
Lateral Movement: Using the database server to attack the rest of the corporate network.
Ransomware: Once an attacker escalates to SYSDBA, they can encrypt the datafiles or drop the backups before demanding payment.
| Prevention Strategy | Action |
| Use Invoker’s Rights | Use AUTHID CURRENT_USER in PL/SQL so procedures only have the power of the person running them. |
| The "Least Privilege" Rule | Never grant ANY privileges (e.g., DROP ANY TABLE) to non-admin users. |
| Secure "PUBLIC" | Revoke unnecessary EXECUTE grants from the PUBLIC user account. |
| Patching | Apply Critical Patch Updates (CPUs) regularly to fix known "exploit" bugs in the database kernel. |
You cannot stop a user from trying to escalate, but you can make it impossible for them to succeed.
Monitor: Use Unified Auditing to watch for users trying to grant themselves roles.
Harden: Use Database Vault to ensure that even if someone does become a DBA, they still can't see the most sensitive data.
Validate: Regularly run "Privilege Analysis" to see who has "God-mode" powers they don't use.
Privilege escalation is often a "quiet" attack. It doesn't crash the database; it just changes the rules of the game in the attacker's favor. The best defense is a "Zero Trust" mindset where every privilege is questioned and every administrative action is logged.