Second-order SQL injection is a delayed form of SQL injection. An attacker first stores crafted input in a database, file, or archive, and the payload becomes dangerous only later when the application reuses that data in a new SQL query without proper escaping or parameterization. This makes the flaw harder to spot than a classic injection on a visible form or URL parameter.
It matters because trusted workflows often process stored data automatically. Backup, import, and restore features are common examples: content that looks inert in a .wpress archive or database row can turn into an attack string during restoration. In real attacks, this can expose data, alter records, or help an attacker reach remote code execution if the SQL flaw opens a larger chain. Defenders reduce the risk by treating imported data as untrusted, using parameterized queries, validating all restore inputs, and limiting who can trigger administrative recovery functions.