Configuration reads across two parameters: follow the PHP filter

The week's finding

During 2026-09-14 through 2026-09-20 UTC, BlackDome retained 12 configuration-read request-body records across 4 sensors within a keyword-selected HTTP/HTTPS review cohort. The captured inputs used two action/parameter pairs to request a local WordPress configuration file through PHP's base64-encoding filter.

The investigative payoff is that both forms share the same file-read operation even though the parameter name and path style differ. Treat the common php://filter/convert.base64-encode/resource= request as the pivot, then review whether the application resolved a configuration path and returned encoded source.

Follow the requested operation

One action/parameter pair is campress_woocommerce_get_ajax_products with layout; the other is extensive_vc_init_shortcode_pagination with options[template]. One body targets an absolute wp-config path under the web root, while the other targets a relative ../wp-config.php path. Each parameter form appears in 6 current-week records.

This points to a file-disclosure investigation rather than a shell-command-execution investigation. PHP filter resource syntax requests a local file through an encoding transform, and the shared operation requests base64-encoded local-file content.

A WordPress configuration file can contain database connection settings and authentication key material, which explains why response-content review matters when this request pattern appears.

MITRE ATT&CK's Credentials In Files technique describes adversaries searching local file systems and remote file shares for files containing insecurely stored credentials, including configuration files containing passwords for a system or service. Primary-source document

Counts and variations

The 2026-09-14 to 2026-09-21 half-open UTC window contains 1141 retained review-cohort event records in 123 daily source/input groups. The configuration-read case contains 12 matching records across 4 sensors, 8 daily source/input groups and 2 distinct body texts.

The two earlier half-open UTC windows provide useful retained-cohort context: 2026-08-31 to 2026-09-07 had 374 retained review-cohort records and 0 PHP-filter configuration-read records; 2026-09-07 to 2026-09-14 had 754 retained review-cohort records and 2 PHP-filter configuration-read records. The current window had 1141 retained review-cohort records and 12 PHP-filter configuration-read records.

For the current week, the mechanism is the important normalizing feature: both observed body texts request php://filter/convert.base64-encode/resource= and end in a wp-config or wp-config.php basename. Keep an operation-level detector so the hunt does not depend on only one action name or only one path style.

A practical local hunt

Use this local filter on retained form bodies. It accepts a UTF-8 string up to 65536 bytes, parses form query pairs with 1 decoding pass, checks layout or options[template], and requires the PHP base64-encoding resource prefix followed by a wp-config or wp-config.php basename.

def matches_config_read(body):
    from urllib.parse import parse_qsl

    if not isinstance(body, str) or len(body.encode("utf-8")) > 65536:
        return False
    prefix = "php://filter/convert.base64-encode/resource="
    for name, value in parse_qsl(body, keep_blank_values=True):
        if name not in {"layout", "options[template]"}:
            continue
        if value.startswith(prefix):
            filename = value[len(prefix):].rsplit("/", 1)[-1]
            if filename in {"wp-config", "wp-config.php"}:
                return True
    return False

For a match, review the caller, requested operation, route, resolved file path, response status, response size and owning workload. Where a response body is retained, inspect it in a restricted local workflow for encoded configuration source. Check whether the workload owner has an approved test or change record covering this request; if exposure is confirmed, rotate the affected secrets and close the file-resolution path.