What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The message Access to the script '...' has been denied (see security.limit_extensions) is produced by PHP-FPM, even though you usually notice it while troubleshooting an Nginx request. PHP-FPM is refusing to execute the requested primary script because its filename extension is not in the pool’s security.limit_extensions allow-list. Add only the extension you deliberately need, verify that Nginx passes the correct script path, test the configuration, and reload PHP-FPM.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
If the log instead says Access to the script '' has been denied, start with the path and FastCGI-parameter checks: PHP-FPM is receiving an empty or malformed script name rather than simply rejecting a disallowed extension.
As an Amazon Associate I earn from qualifying purchases.
What this FastCGI error actually means
PHP-FPM checks the filename of the primary script before executing it. Its pool-level security.limit_extensions directive contains the extensions PHP-FPM is willing to run. The PHP manual lists the default as .php .phar; older documentation described only .php, and the default changed to include .phar in the PHP 5.3.9/5.4.0RC2 timeframe.
When Nginx forwards a request whose target ends in an extension outside that list, PHP-FPM writes an access-denied message to its log. A request for an HTML or XML file can therefore trigger the same wording if your Nginx rules route that file to PHP-FPM. The denial is an execution safeguard, not proof that the file is missing or that Nginx’s filesystem permissions are wrong.
The exact wording matters:
- A path appears between the quotes: inspect the extension in that path and the pool’s
security.limit_extensionsvalue. - The quotes are empty: investigate how Nginx constructs and sends the script path, especially
SCRIPT_FILENAME,PATH_TRANSLATED,PATH_INFO, and named-location routing.
Fastest safe fix when an extension is intentionally executable
Only change the pool that serves the affected site, and keep the allow-list as narrow as possible. The PHP manual’s security guidance is to restrict execution to .php whenever that meets your application’s needs.
- Read the log entry. Copy the complete path shown after
Access to the script. Its suffix is the extension PHP-FPM evaluated. - Locate the active PHP-FPM pool file. It is commonly named
www.confinside a distribution-specificpool.ddirectory, but the directory and PHP version are installation-dependent. Make sure you edit the pool referenced by the Nginx site, not an unused pool for another PHP version. - Inspect or set the directive. In the pool file, use one space-separated list, for example:
security.limit_extensions = .php .phar .xmlReplace
.xmlwith the extension your application genuinely needs. Do not copy this example unchanged if XML, HTML, or another format should remain non-executable. - Save the file and reload PHP-FPM. Pool changes are read by PHP-FPM, so reload or restart the PHP-FPM service using the service name supplied by your operating system. A web-server reload alone does not apply a changed pool directive.
- Reproduce one request and read the log again. A successful request should no longer generate the extension-denied message. If it still does, confirm that the request reaches the pool you edited and that the extension is spelled exactly as PHP-FPM receives it, including the leading dot.
Adding an extension permits PHP-FPM to treat files with that suffix as primary PHP scripts. It does not convert the file’s contents into valid PHP, and it broadens the set of files an attacker could attempt to execute if another vulnerability lets them place or modify files. For that reason, do not solve a routine PHP request by allowing every extension.
Check the Nginx FastCGI hand-off before changing the allow-list
If the denied path is unexpected, or if the message contains an empty script name, verify the variables Nginx sends to PHP-FPM. The key value is SCRIPT_FILENAME: it must resolve to the real file on disk that PHP-FPM should execute. A common pattern is:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;The correct expression depends on your document-root and URI design. What matters is that the resulting filesystem path is neither empty nor a URI, and that it points to the intended file. Compare the path in the PHP-FPM log with the actual file location and with the root (or equivalent document-root setting) in the Nginx server block.
Confirm the PHP location block
In the Nginx server configuration, inspect the location that passes requests to PHP-FPM. Confirm that it:
- matches the PHP requests your application actually generates;
- passes the expected FastCGI parameter file or explicit parameters;
- sets
SCRIPT_FILENAMEto a real filesystem path; and - uses the socket or TCP endpoint belonging to the intended PHP-FPM pool.
After any Nginx edit, run:
nginx -tProceed with an Nginx reload only when the test reports a valid configuration. This catches syntax errors, missing include files, and other mistakes before they replace a working configuration.
Remove path parameters that produce an empty script name
A documented variant of this error is Access to the script '' has been denied. Sources associate that form with the script path not being passed through correctly. If your configuration explicitly sends PATH_TRANSLATED or PATH_INFO, temporarily remove those parameters and retest. Keep only the parameters your application needs; an incorrect path parameter can cause PHP-FPM to evaluate an empty script name even when the requested URL looks valid.
Do not treat removal as a universal recipe. First compare the variables sent by your location block with the path shown in the PHP-FPM log and with the application’s URL scheme. The objective is a correct, non-empty SCRIPT_FILENAME, not simply fewer parameters.
Routing patterns that commonly trigger the denial
try_files fallback into a named location
Routing can make a normal-looking PHP URL arrive at PHP-FPM with the wrong script information. One reported cause was a try_files fallback into a named location. Switching to a plain regular-expression PHP location resolved that case because the request was handled by the expected PHP block instead of a named fallback with different FastCGI variables.
Review every internal redirect in the request path. Trace where try_files sends a miss, then check which location ultimately sets SCRIPT_FILENAME. If the final location does not set it correctly, PHP-FPM may receive an empty value or a path that does not match the requested script.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Non-PHP URLs routed to PHP-FPM
If the logged path ends in .html, .xml, or another non-PHP suffix, determine why that URL is being sent to PHP-FPM. It may be intentional—for example, an application that uses a nonstandard extension for executable templates—or it may be an overly broad Nginx location. The safer correction is usually to route static files as static files or narrow the PHP location, rather than adding a broad extension to security.limit_extensions.
Choosing the right correction
| What you observe | Most likely check | Preferred action |
|---|---|---|
| The log shows a real path ending in an extension your application intentionally executes. | The active pool’s security.limit_extensions. |
Add that one extension, retain .php, reload PHP-FPM, and retest. |
| The log shows a real path with an unexpected extension. | Nginx location matching and internal redirects. | Correct routing so only intended scripts reach PHP-FPM; do not expand the allow-list merely to hide the symptom. |
The log says Access to the script '' has been denied. |
SCRIPT_FILENAME, PATH_TRANSLATED, PATH_INFO, and named-location routing. |
Make the script path non-empty and filesystem-based, then retest. |
| The value appears correct, but the error persists. | Which pool and PHP-FPM endpoint serve the request. | Verify the Nginx socket or port and edit that pool’s configuration, then reload the matching PHP-FPM service. |
Security implications of the available workarounds
Keep the extension list narrow
security.limit_extensions is an execution boundary. The PHP manual recommends limiting it to .php where possible because allowing additional suffixes increases the number of filenames PHP-FPM will attempt to execute. If a feature requires another suffix, allow only that suffix and document why it is needed.
Do not enable cgi.fix_pathinfo as a reflex
Some troubleshooting posts suggest setting cgi.fix_pathinfo to 1. The cited discussions warn that this can open security holes. It is not a general fix for an incorrect Nginx-to-PHP path. Correct the location matching and FastCGI parameters instead, and assess any legacy application requirement separately.
Be skeptical of disabling the check
A community bug comment mentions setting security.limit_extensions to FALSE to bypass the restriction. That is not the PHP manual’s recommended configuration and is broader than allowing a specific required suffix. Treat it as an unsafe last-resort experiment, not a production solution; verify behavior against the PHP version’s current documentation before considering it.
Recommended Free Tools
Permissions: what to verify, and what this error does not prove
PHP-FPM’s worker user and group still need read access to the target file and traversal access to its parent directories. Check those permissions if the path and extension are correct but execution fails in a different way. However, the cited causes for this exact “see security.limit_extensions” message concern the extension rule and script-path construction; permissions were not established as the root cause by those sources.
SELinux was not identified in the cited material as a cause of this specific message. Do not label SELinux the cause without separate evidence from your system’s audit logs and policy diagnostics.
A complete validation sequence
- Capture the exact error. Note whether the quoted script path is populated and record its extension.
- Identify the serving pool. Follow the Nginx FastCGI socket or TCP endpoint to the PHP-FPM pool and PHP version that actually handle the request.
- Compare the extension. Read
security.limit_extensionsin that pool. Remember that the documented default is.php .phar, not an unrestricted list. - Inspect the generated path. Ensure
SCRIPT_FILENAMEresolves to the intended file under the configured document root. Check for an empty value, a URI instead of a filesystem path, or a path produced by the wrong internal redirect. - Review path-related parameters. If the script name is empty or inconsistent, examine
PATH_TRANSLATEDandPATH_INFOand remove incorrect explicit settings. - Check routing. Trace
try_filesfallbacks and named locations. Make sure the final PHP location supplies the same correct FastCGI parameters as the direct PHP path. - Test before reloading Nginx. Run
nginx -t; fix any reported error before reloading. - Reload PHP-FPM after pool edits. Then send one request and inspect the logs again.
- Check file access only after the above. Confirm the PHP-FPM worker can read the file and traverse its directories if the extension and path now pass validation.
Common mistakes and their safer alternatives
- Editing the wrong configuration file: a server may have multiple PHP versions or pools. Follow the endpoint used by Nginx and edit that pool.
- Reloading only Nginx: pool directives are read by PHP-FPM. Reload the PHP-FPM service after changing
www.confor its equivalent. - Allowing every suffix: this removes the protection that the directive provides. Add one justified extension instead.
- Changing
cgi.fix_pathinfowithout understanding the path: this can create a security exposure while leaving the routing error intact. - Assuming every denial is a permission problem: the “see security.limit_extensions” wording specifically points first to PHP-FPM’s extension check.
- Skipping syntax validation: always run
nginx -tbefore a reload after editing Nginx configuration.
When the error is resolved
A successful correction has two parts: PHP-FPM receives a non-empty SCRIPT_FILENAME that points to the intended file, and that file’s extension is explicitly allowed by the serving pool. The narrowest configuration that meets both conditions is the safest one. Leave unrelated files routed as static content, retain the default restriction when you can, and keep the log entry from the first successful retest so future configuration changes can be compared against a known-good request.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
