WordPress wp-config.php Permission Is Too Open

Why wp-config.php Permissions Matter

wp-config.php is not an ordinary WordPress file. It can contain database credentials, authentication salts, table-prefix details, debug settings, custom constants, and environment-specific configuration. If the file is readable by the wrong system user, writable by too many accounts, or reachable through the web server, a small permission mistake can become a serious security exposure.

The right fix is not a universal chmod command copied from a forum. WordPress installations run under different hosting models: shared hosting with suexec, managed WordPress, VPS accounts, containers, deploy pipelines, and hosts where the web server user differs from the file owner. You need to know who owns the file, who must read it for PHP to run WordPress, and who should never be able to modify or download it.

Check the Current State First

• Record the current owner, group, and permission mode for wp-config.php before changing anything.
• Confirm whether wp-config.php is inside the web root or one directory above the WordPress installation.
• Ask the host which user PHP runs as and whether the web server needs group read access on this file.
• Check whether a direct browser request for wp-config.php is denied rather than downloaded or displayed.
• Look for backup copies such as wp-config.php.bak, wp-config.old, config.txt, or editor swap files in public folders.
• Confirm debug logging does not expose database credentials, server paths, salts, or stack traces in public locations.

How to Fix Open wp-config.php Permissions

1. Take a backup or snapshot before editing permissions or server rules.
2. Remove world-write access immediately if the file is writable by everyone.
3. Set the file so only the required owner and server context can read it. On many systems this may be stricter than ordinary 644 files, but the correct value depends on the host.
4. If your host supports it safely, place wp-config.php one directory above the WordPress install so it is outside the public document root.
5. Add direct-access protection at the server layer where appropriate, such as a web-server rule denying requests for wp-config.php.
6. Remove public backup copies, temporary files, old exports, and duplicate config files after preserving evidence and confirming they are no longer needed.
7. Reload the site and wp-admin immediately after every change. If WordPress cannot connect to the database, restore the previous permission mode and ask the host which account must read the file.

The practical target is simple: WordPress should be able to read wp-config.php when PHP runs, administrators should be able to manage it through approved server access, and anonymous visitors should never be able to download it. Avoid permission changes that make the file writable by unrelated users or readable by every account on a shared server.

After the site still loads, test a direct request to the file and one authenticated wp-admin request. The right outcome is boring: WordPress can read configuration through PHP, administrators can manage the file through approved server access, and anonymous web requests cannot retrieve the file contents or backup copies.

Common Mistakes

• Do not use 777 on wp-config.php. That gives far more access than the file should ever need.
• Do not assume every host can use the same 400 or 440 setting; test and follow the host's PHP/user model.
• Do not leave editor backups, deployment copies, or compressed archives containing wp-config.php in public folders.
• Do not expose raw debug output while testing permission changes on a live site.
• Do not treat a green scanner result as proof the file is secure forever; deployment and backup tools can recreate risky copies later.

How Web Plura Security Center Helps

Web Plura Security Center is useful for this workflow because it focuses on local security evidence inside WordPress. The free plugin includes local security scans, risky configuration review, relevant file-permission signals, executable-file checks in upload locations, debug-log exposure indicators, public archive indicators, recent component changes, file-integrity context, incident visibility, reports, and administrative guidance.

Use it after you record the current permission state. Run a local review, compare findings with your host-level checks, then document what changed and why. Security Center does not promise automatic repair for every permission problem, does not guarantee every compromise will be detected, and does not upload suspicious file samples or local security reports to Web Plura Cloud by default.

Prevent the Problem From Returning

1. Add wp-config.php permission checks to launch, migration, staging-push, and backup-restore checklists.
2. Review backup plugin destinations so archives containing wp-config.php are not written into public folders.
3. Disable dashboard file editing where appropriate so compromised admin access cannot directly edit theme or plugin PHP files.
4. Keep a short record of the approved owner, group, permission mode, and host-specific reason.
5. Rerun permission and public-archive checks after changing hosts, deployment tooling, backup plugins, or file ownership.

Also review deployment scripts, backup restores, and file manager workflows after the immediate fix. Many wp-config.php exposures return when a restore recreates old permissions, a backup plugin writes an archive into a public directory, or a developer downloads a copy and leaves it beside the live file. Add those checks to the same maintenance note as the approved owner, group, and permission mode.

Related WPlura Plugin Help

If wp-config.php permissions look too open on a real site, finish the manual ownership and host checks first, then use Web Plura Security Center as the related WPlura review tool. Start with the free WordPress.org plugin download: download the free plugin on WordPress.org. For teams that need connected policy, vulnerability visibility, scheduled reporting, or coordinated incident workflows, use the WPlura Pro path after the local security review. Pro purchase and private download access starts here: WPlura Pro purchase and private download. Review product details and Free versus Pro fit here: WPlura product details.

1. Install and activate the free Web Plura Security Center plugin from WordPress.org after you preserve server access and avoid overwriting evidence.
2. Review file-permission, debug-log, public-archive, suspicious-file, and file-integrity findings.
3. Use the findings to decide what belongs to the site admin, developer, host, or incident-response owner.
4. Document the approved wp-config.php owner, group, permission mode, direct-access behavior, and final test result.
5. After cleanup, rerun relevant checks and keep monitoring for backup copies or deployment tools that recreate exposed config files.

References

Frequently Asked Questions