FILE privilege is a MySQL capability that allows database operations to interact with the filesystem. In practice, it can turn a database compromise into a server compromise when attackers can write files into locations that the web server can execute or serve.
Expanded Definition
FILE privilege is a MySQL permission that lets a database user read from or write to the server filesystem, which makes it materially different from ordinary SQL data access. In NHI and database security work, it is treated as a high-risk capability because it can bridge application-layer compromise into host-level impact. The risk is not the privilege alone, but the combination of FILE access with writable web directories, executable paths, or insecure file import and export workflows. MySQL documents FILE as a global privilege, and in practice its safe use depends on strict server hardening and carefully constrained deployment patterns. Guidance varies across vendors and operational teams on whether FILE should ever be enabled outside tightly controlled administrative use, but the security principle is consistent: if a database account can interact with the filesystem, it deserves the same scrutiny as a privileged service identity. The most common misapplication is granting FILE to application-connected accounts, which occurs when teams prioritize convenience for exports, backups, or bulk loads over least privilege.
For broader NHI context, the pattern mirrors the governance failures described in the Ultimate Guide to NHIs – Key Challenges and Risks and the controls discussed in the OWASP Non-Human Identity Top 10.
Examples and Use Cases
Implementing FILE restrictions rigorously often introduces operational friction, requiring organisations to weigh administrative convenience against the possibility of filesystem exposure.
- A reporting user is allowed to export query results, but FILE is disabled so the account cannot write CSV output to arbitrary server paths.
- An administrator uses FILE during a controlled migration window to load data from a known directory, then removes the privilege immediately after completion.
- A compromised application service account is prevented from escalating into the web root because MySQL cannot write a server-executable file there.
- A security review finds that a backup utility depends on FILE, prompting a redesign toward a dedicated agent account and a locked-down transfer directory.
- An incident response team traces suspicious file creation on a database host back to a database identity with filesystem interaction rights, similar to patterns seen in the Replit AI Tool Database Deletion case study and the MySQL privilege model documented by MySQL privileges provided.
FILE is most defensible when tied to a narrow, auditable maintenance workflow with filesystem paths under explicit control. It becomes dangerous when paired with long-lived credentials, broad OS write permissions, or application accounts that also handle secrets, tokens, or deployment artifacts.
Why It Matters in NHI Security
FILE privilege matters because NHI compromise often becomes severe when a database identity can move beyond data access into host manipulation. In practice, a stolen service account, leaked password, or over-permissioned automation token can be enough to plant files, alter application behavior, or create a durable foothold. NHIMG research shows that 97% of NHIs carry excessive privileges, and FILE is a clear example of how an apparently small exception can materially widen blast radius. This is also why zero-trust and least-privilege programs must treat database identities as operational assets, not just schema users. The broader lesson appears in the Ultimate Guide to NHIs, where weak visibility and poor credential hygiene are recurring risk amplifiers. For defensive design, the relevant control question is whether a workload truly needs filesystem interaction or merely inherited it through legacy database setup. The security objective is to remove FILE wherever possible, confine it where unavoidable, and monitor for misuse through database audit trails and host telemetry. Organisatons typically encounter the consequences only after a database compromise begins producing unexpected files on the server, at which point FILE privilege becomes operationally unavoidable to address.
Those failure modes align with the OWASP Non-Human Identity Top 10 and the control concerns reflected in the Microsoft SAS Key Breach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | FILE privilege expands blast radius through over-permissioned non-human database identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management applies directly to database identities with FILE capability. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits lateral impact when a database identity can reach the filesystem. |
| NIST AI RMF | Risk management should account for filesystem-writable paths exposed by automated database identities. | |
| OWASP Agentic AI Top 10 | AIA-03 | Agentic systems using database tools must not inherit filesystem-write capabilities by default. |
Remove filesystem privileges from service accounts unless a documented workload need exists.