How it works

Four steps: find the files, parse them as PHP would, layer them into effective configurations, then evaluate every rule against each one.

Safety model #

• No execution. The tool never runs php, a shell or any other process, never calls eval, and never opens a network connection. tests/SafetyTest.php walks the source tokens and fails if such a call appears.
• Read-only file access. Only regular files are opened. FIFOs, devices and sockets are refused so that a planted php.ini FIFO cannot hang the scan. Files over 4 MiB or containing binary data are skipped with a warning.
• Confined roots. With --root, every symlink is resolved component by component inside the root. An absolute link such as php.ini → /etc/shadow resolves to <root>/etc/shadow, never to the host file.
• Metadata only for paths. Paths referenced by settings are inspected with stat(); their contents are never read.
• No environment expansion. ${VAR} in a value is kept literally and reported (CFG-007). The scanner's own environment is not PHP's.

1. Discovery #

Without arguments, these locations are searched (inside --root when given):

The SAPI and PHP version come from the path, e.g. /etc/php/8.2/fpm/ is FPM on 8.2. A PHP directory that has php.ini-production or a conf.d/ but no php.ini is audited as running on built-in defaults (CFG-006). That is the layout of the official Docker images.

2. Parsing like PHP #

• ; starts a comment, including after an unquoted value. # is not a comment since PHP 7 and is reported.
• Unquoted On/Yes/True become 1; Off/No/False/None/Null become empty. That is why session.cookie_samesite = None unquoted actually means "not set".
• Double- and single-quoted values, concatenation and multi-line quoted values follow the INI scanner.
• error_reporting expressions such as E_ALL & ~E_DEPRECATED are evaluated by a small parser with PHP's operator rules, never by eval.
• Quantities (128M, 2G, 0x10) and booleans are read with the semantics of zend_ini_parse_quantity() and zend_ini_parse_bool().
• Directive names are case-sensitive; Display_Errors is ignored by PHP and reported as a likely typo.

3. Layering #

A base configuration is built in PHP's order, with the last assignment winning:

1. PHP's compiled-in defaults
2. php.ini
3. scan-directory *.ini files in alphabetical order

Each of these is then evaluated as a separate overlay on top of its base:

An overlay that tries to set a PHP_INI_SYSTEM directive, such as disable_functions or allow_url_fopen in .user.ini, does not take effect in PHP. The scanner reports it (CFG-005) rather than counting it as protection. Overlay findings only cover what the overlay changes, so base findings are not repeated.

Built-in defaults matter #

When a directive is not set anywhere, PHP uses its compiled-in default, not the value in php.ini-production. Several of those defaults are insecure:

Findings caused by a default say at built-in default and have "from_default": true in JSON.

4. Rule evaluation #

• Config rules see one effective configuration. Most security checks are config rules.
• Pool rules see an FPM pool's own settings (listen, user, env[…]).
• File rules run once per file, wherever it is layered: syntax problems, typos, obsolete or deprecated directives, file permissions, .htaccess handlers.

Rules declare the SAPIs they apply to. Web-only checks such as session cookies or open_basedir are skipped for cli, and an unknown SAPI is treated as web-facing. The development profile caps disclosure rules at info and skips production-only rules.

Known vulnerabilities and the PHP version #

Some PHP vulnerabilities can only be exploited when a feature is enabled. CVE-2024-4577 needs php-cgi on Windows, CVE-2024-9026 needs catch_workers_output in an FPM pool, and the 2025 HTTP-wrapper bugs need allow_url_fopen. For each tracked CVE the scanner checks two things:

1. Version: is the PHP patch release older than the fix for its branch? Branches that reached end of life between fixed branches never got the fix, so they count as affected.
2. Configuration: does the effective configuration use the vulnerable feature?

A CVE is reported only when both are true. Fixed-in releases come from the official PHP 8 and PHP 7 changelogs. VULN-001 also reports branches past, or within 180 days of, the end of security support.

Every other publicly disclosed CVE fixed in a later release (parsers, extensions, bundled libraries) is listed in one warning per configuration, VULN-003, with the severity of the worst one. Fixed-in releases come from the changelogs and php-src security advisories, severities from those advisories or NVD.

Where the version comes from

The exact version is read from files, never by running php -v:

When only the branch is known, the CVEs that apply to the configuration are summarised in one finding (VULN-002) with the release that fixes each, instead of one finding per CVE. Version files are read for host scans and --root scans; for copied configuration files, pass --php-version. RPM databases are binary and are not read.

Path checks #

About 25 directives name paths: extension_dir, session.save_path, upload_tmp_dir, error_log, mail.log, opcache.file_cache, openssl.cafile, curl.cainfo, sendmail_path, absolute extension= paths and others. Each gets a severity for two situations:

• World-writable (FS-005): the path, or the directory where it can be created or replaced, is writable by every local user. For example, a world-writable extension_dir is critical.
• Web-served (FS-006): the path is under a --webroot. Without one, a guess from directory names such as public_html or htdocs is used, with low confidence.

Configuration files themselves are checked as well (FS-011).

Limitations #

• A static audit sees files only. It cannot see php -d flags, PHP_INI_SCAN_DIR or PHP_VALUE set by a web server, ini_set() at runtime, or which extensions are compiled in.
• php_admin_value in Apache vhost files is not parsed (.htaccess is).
• Only configuration-dependent CVEs are matched to settings; the rest are matched to the version alone and may not be reachable by your code. Distribution backports can make a patched package look vulnerable, which is why those findings carry low confidence.
• The built-in defaults table follows PHP 8. Paths compiled into a particular build (extension_dir, include_path) may differ.