Atomicorp WAF Rule 314143

Rule Summary

• Rule ID: 314143
• Status: Active
• Alert message: Atomicorp.com WAF Rules: PHP session upload progress activation blocked (CVE-2026-109618 and CVE-2026-109619)
• Observed CWEs: CWE-416 (2), CWE-755 (2), CWE-824 (2), CWE-1325 (2)
• Phase: 2 (request body)
• Rule action: deny
• HTTP status: 403
• Public tags: attack-surface/php-upload-progress, cve/CVE-2026-109618, cve/CVE-2026-109619
• Logging: log

Description

Rule 314143 blocks POST form submissions containing PHP’s default session upload-progress activation field. This prevents those requests from activating the upload-progress mechanism on the protected PHP backend. The rule inspects parsed form-field names and applies independently of the destination URL or the field’s value.

Atomicorp’s manual PHP core review associates this control with the session upload-progress attack path for CVE-2026-109618 and CVE-2026-109619. The protection is based on removing the reviewed request-side activation path. Keep PHP updated using the fixed package for your branch as well as maintaining current Atomicorp rules.

Behavior

• Evaluation occurs in ModSecurity phase 2, after request-body parsing.
• With blocking enabled, a matching request is denied with HTTP 403 and the rule logs its alert.
• In DetectionOnly mode, the rule reports the match without denying the request.
• Request-body inspection must be enabled, and the WAF must inspect the request before the protected PHP backend processes it.

An alert identifies a request attempting to use the blocked feature. It does not by itself establish malicious intent or successful exploitation.

Examples

A file-upload form using PHP’s standard session upload-progress control can trigger this rule even when the file and its contents are legitimate. The resulting alert identifies rule 314143 with the message PHP session upload progress activation blocked.

Ordinary upload forms that omit that control field do not meet this rule’s condition. Other WAF rules may independently evaluate the upload.

Troubleshooting

False Positives and Application Compatibility

Applications that intentionally use PHP’s built-in session upload-progress feature will have those requests blocked. This is expected behavior for this feature restriction, but it can interrupt a legitimate upload workflow. Check the affected form and its progress reporting before treating every alert as an attack.

The rule follows PHP’s default activation-field name. If an application changes session.upload_progress.name, have the protection policy reviewed against that configuration. The control concerns session upload-progress activation, rather than the contents of uploaded files.

Recommended Action

Install the security update for the applicable PHP branch: PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a vendor package containing the corresponding fixes. Follow the PHP advisories linked below for deployment-specific guidance. Where upload-progress tracking is unnecessary, PHP also documents disabling session.upload_progress.enabled administratively and restarting PHP workers.

Keep request-body inspection and blocking enabled for the protected application. If a legitimate application requires an exception, review its PHP update status and narrowly scope any local tuning to that application. Avoid disabling the rule globally to accommodate a single upload form.

Reporting and Tuning

Report unexpected matches with rule ID 314143, the application/version, request content type, relevant form-field names, PHP upload-progress configuration, and a sanitized alert. Remove session cookies, credentials, personal information and uploaded file contents before sharing evidence.

Use customer-owned configuration for approved exceptions; do not edit Atomicorp-managed rule files. See Atomicorp rule tuning guidance and reporting false positives .

References

• PHP: Session Upload Progress (opens in a new tab)
• PHP advisory for CVE-2026-109618 (opens in a new tab)
• PHP advisory for CVE-2026-109619 (opens in a new tab)
• PHP security announcement and updates (opens in a new tab)

CVEs Referenced by This Rule

The current ModSecurity rule metadata explicitly names the following CVEs. These references explain the rule author’s association; they do not claim that the rule is limited to these vulnerabilities or that this is an exhaustive coverage list.

CVE-2026-109618

PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).

• Association: The rule references CVE-2026-109618 in its alert message and tag.
• CVE Record (opens in a new tab)
• NVD (opens in a new tab)

CVE-2026-109619

PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).

• Association: The rule references CVE-2026-109619 in its alert message and tag.
• CVE Record (opens in a new tab)
• NVD (opens in a new tab)

Selected Related CVEs

This is a selected list of documented research observations, not an exhaustive coverage matrix. Absence of a CVE does not imply absence of protection.

Observed CWEs

These CWEs are recorded on published CVEs in the selected observations associated with this rule. They are observational relationships, not a claim that the rule universally blocks every vulnerability assigned to a CWE.