FILE Privilege

What FILE privilege actually changes in MySQL

FILE privilege is unusual because it expands the database from data access into host-level file interaction. That makes it qualitatively more dangerous than ordinary read or write permissions, since a successful database compromise can become a foothold for filesystem access, file placement, and sometimes code execution or web content exposure, depending on how the server is configured.

The practical significance is not just “can the database read or write a file,” but whether the MySQL process can reach sensitive paths, drop files into application directories, or influence other services that trust the filesystem. In other words, FILE privilege changes the blast radius of a MySQL breach.

Why FILE privilege is a server security boundary issue

FILE privilege matters because it crosses a boundary that defenders often assume is already contained. A database account with this capability may be able to read local files, write export files, or place content where a web server or scheduled task can later use it. That turns a database-layer issue into a platform security problem, especially when MySQL runs with broad operating-system permissions.

The risk increases when filesystem permissions, web root layout, and database service accounts are poorly separated. Even if the SQL layer is well protected, FILE privilege can still expose host files or create files that become reachable through other components on the same server.

Common attack paths and operational consequences

Attackers value FILE privilege because it can simplify post-compromise movement from application data access to server control. The most concerning paths are file exfiltration, file placement into sensitive directories, and writing content that another service will later execute, parse, or serve.

When FILE privilege is combined with a vulnerable application, weak web server isolation, or overly permissive directory access, the result can be persistence, data theft, or command execution. That is why defenders treat it as a high-risk capability rather than a routine database feature.

How organisations reduce exposure

The safest assumption is that FILE privilege should exist only where a concrete business need has been proven. In many environments, teams can eliminate it entirely for application accounts and use dedicated export or backup workflows instead. Where it must remain, the database service account and filesystem permissions should be constrained so that a database compromise cannot easily reach executable or web-served paths.

That same principle is reinforced in the MySQL Security Guide, which covers privilege minimisation, secure file handling and broader MySQL hardening. On the host side, Linux permission boundaries still matter, so defenders should also align MySQL with the operating-system controls described in the Linux Fundamentals for Defenders Guide.

Detection and recovery after suspected abuse

Monitoring for FILE privilege abuse should focus on unexpected file creation, unusual export activity, writes outside expected directories, and database accounts that suddenly begin touching the filesystem. If compromise is suspected, review both the database audit trail and the filesystem for suspicious output, web-shell-like artefacts, or altered configuration files.

After a confirmed incident, treat the event as a combined database-and-host response problem. Database credentials, related application secrets, and any sessions or keys that could have been used to reach the database should be rotated, and the affected server should be reviewed for persistence before returning to service.

Risk and Threat Considerations

FILE privilege is dangerous because it can convert a SQL-level compromise into a broader system compromise. The risk is highest when MySQL can write into directories that are executable, web-accessible, or otherwise trusted by adjacent services.

Failure mechanism: An attacker with database access abuses FILE to read sensitive local files or write attacker-controlled content to a path that another process later serves, loads, or executes.

Impact: Exposure can extend beyond the database itself to file disclosure, web content tampering, persistence, and in some deployments full server compromise.

Practitioner Guidance

Why practitioners should care: FILE privilege is not a normal application permission and should be treated as a special-case capability that deserves explicit ownership. If an account needs it, the use case should be documented and periodically re-justified, because the security consequences are materially larger than for typical data read or write access.

Common misunderstanding: Teams sometimes assume FILE only affects database exports. In reality, its risk depends on where MySQL can read and write, what the host will trust, and whether another service will consume the file afterwards.

Practitioner takeaway: If you cannot state exactly why an account needs FILE, remove it and redesign the workflow around a safer export, import, or backup path.

Related resources from NHI Mgmt Group

• Why do long-lived file shares create compliance and least-privilege risks for regulated data?
• How should security teams use file auditing to prove least privilege on protected data?
• What happens when ransomware operators combine privilege escalation with file encryption and command and control?
• How should security teams manage NTFS ACLs without breaking least-privilege access on shared Windows file systems?