From c0633f11e7cd5ee253eb76a66782a3721fb27aa9 Mon Sep 17 00:00:00 2001 From: "andre.bolinhas" Date: Wed, 4 Nov 2026 00:22:49 +0000 Subject: [PATCH] The example was the one rule this channel refuses to publish MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CVE-CHANNEL.md showed the PHP upload-progress rule as its worked example, and that CVE is patched in compiled code. The guard forty lines below the example exists to refuse exactly that — both rules would fire, the scores would add, and one attack would be reported as two. So the example a reader was most likely to copy was the only example that could not be published: published rule CVE-2026-109618-01 patches CVE-2026-109618, which the compiled rule "php_upload_progress" already patches The example is now a CVE that is not patched in code, extracted from this file and run through the engine's own guard to prove it validates. A sentence beside the example says why it is not the PHP one, instead of leaving the reader to find the warning at the bottom after the refusal. cve.json is untouched and its build_datetime is unchanged, so nothing an edge node enforces changes with this commit. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N5fpE6Gu4W6JoFMXyb7t7r --- CVE-CHANNEL.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/CVE-CHANNEL.md b/CVE-CHANNEL.md index b92e596..06711e4 100644 --- a/CVE-CHANNEL.md +++ b/CVE-CHANNEL.md @@ -31,21 +31,27 @@ it, so the stamp is what makes a publish take effect. "enabled": true, "priority": 1, "rules": [{ - "id": "CVE-2026-109618-01", - "name": "PHP upload-progress field present", - "pattern": "^php_session_upload_progress$", - "targets": ["param_names"], + "id": "CVE-2025-31161-01", + "name": "CrushFTP authentication bypass via crafted Authorization header", + "pattern": "(?i)AWS4-HMAC-SHA256.*Credential=[^/]*/", + "targets": ["headers"], "action": "block", "severity": "critical", "category": "cve", - "cve": "CVE-2026-109618, CVE-2026-109619", + "cve": "CVE-2025-31161", "enabled": true, - "references": ["https://nvd.nist.gov/vuln/detail/CVE-2026-109618"] + "references": ["https://nvd.nist.gov/vuln/detail/CVE-2025-31161"] }] }] } ``` +That example is deliberately NOT the PHP upload-progress rule, which this +document used to show. That CVE is patched in compiled code, so the guard below +refuses it — the one example a reader was most likely to copy was the one +example that could not be published. Anything already patched in code belongs +in code; see the end of this page. + `source` must be `edgeguard-cve`. That is the source the channel owns and the only one it may clear, which is also what makes a rule **withdrawable**: remove it, bump the stamp, and it stops being enforced everywhere within the hour.