ModSecurity defines 920120 with !@rx: its pattern describes a filename made only
of SAFE characters, and the rule fires when the filename does NOT match. A
quote, an apostrophe, a semicolon, an equals sign or a backslash in a filename
is an attempt to break out of the Content-Disposition header, and that is what
the rule exists to catch.
This format had no way to express a negation, so the rule was imported as a
plain pattern and means the exact opposite: it matched every legitimate upload
and missed every dangerous filename. It did no harm only because the engine
carried a built-in rule under the same ID — a different rule entirely, matching
content-type.*boundary.* on every ordinary multipart upload — which took
precedence.
The engine gained a `negate` field (3.0.61); this declares it. Both are needed:
the flag alone with no engine support does nothing, and engine support with no
flag leaves the rule inverted.
build_datetime bumped, because an agent skips a feed whose stamp has not moved
without reading it.
Rule 932180 "Restricted File Upload Attempt" targets filename, scores 10 and
blocks. Its pattern carries CRS's OS-pseudo-file list with no path anchor, so
bare words matched any uploaded filename:
module modules meminfo mounts misc mdstat mtrr loadavg locks version
uptime cmdline stat swaps slabinfo partitions pagetypeinfo
So release-version-2.zip, company-misc-notes.pdf and meminfo.txt were refused
as critical RCE attempts. Found because it blocked an image upload to our own
wiki, which sits behind EdgeGuard: the response carried x-edgeguard-id, the
console found the event by that id, and the match was `module-` in the
filename.
These names mean something as a PATH and nothing as a filename, so the branch
now requires a leading slash. The dotfile branch keeps its own (?:\b|^) anchor
and is untouched.
Measured against the previous pattern over a corpus of 51 names: 16 ordinary
filenames released, NOTHING newly blocked, and every true positive still
caught — .htaccess, .env, .aws/credentials, wp-config.php, /proc/version,
/proc/self/environ, ../../proc/modules, uploads/../../proc/kcore.
build_datetime bumped. An agent skips a feed whose stamp has not changed
without reading it, so a corrected pattern under the old stamp would reach
nobody.
A deliberately temporary rule, to prove that a rule published through this
channel reaches every edge node and is enforced, and that withdrawing it
stops the enforcement. It matches a parameter name no real request carries.
To be withdrawn as soon as the test is recorded.
Validated against the engine's TestPublishedFeedDoesNotDuplicateACompiledRule
guard.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N5fpE6Gu4W6JoFMXyb7t7r
cve.json carries virtual patches: rules written against a named
vulnerability, published as data so that every edge node enforces them
within the hour instead of waiting for an engine release. Engine 3.0.47 and
later fetch it hourly.
It starts empty, which is a valid state and says "no virtual patches at the
moment" — the engine accepts an empty rulesets list as of 3.0.47, and
publishing one is also how the whole channel stands down.
Separate from rulesets.json rather than part of it: each has its own
build_datetime, so each is applied or skipped on its own, and a mistake in
one cannot take out the other. Publishing a patch should not mean
republishing a 357KB mirror of the Core Rule Set.
CVE-CHANNEL.md documents the format, the param_names target, how severity
becomes the anomaly score, and the two mistakes worth avoiding: publishing a
rule for a CVE the engine already patches in code (both fire and the scores
add), and forgetting that there is no backtest for a patch written in the
hours after a disclosure — which is why withdrawal is a first-class
operation here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N5fpE6Gu4W6JoFMXyb7t7r
Andre
Andre
