ruleset_feeds.cve_url points an installation at its own channel document, from
engine 3.2.7. It replaces the published channel rather than adding to it: the
channel owns its ruleset source, a fetch clears that source before rebuilding
it, and two feeds claiming it would delete each other's rules on alternating
ticks.
So a new patch can be published to your own document, run as log against your
own traffic for as long as it takes to trust, and only then proposed here.
Until now there was nowhere to do that.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N5fpE6Gu4W6JoFMXyb7t7r
This document reaches every customer's agents from one hardcoded URL, so a
publish is a decision taken on their behalf. Records what earns that — an
actively exploited vulnerability, recognisable in one request, in software
customers run, in the days before a fix — and the three steps out: in as log,
promoted only with a reason, then into the engine or deleted.
Also records that customers do not need this channel for their own rules.
Create Custom Ruleset takes the same fields and reaches their own agents; the
config pull and this feed are each forbidden from touching the other's
sources.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N5fpE6Gu4W6JoFMXyb7t7r
A CVE record describes a vulnerability, not a request, which is why this
channel is written by hand. A Nuclei template contains the request — path,
query, headers, body — because that is what it sends, so for thousands of CVEs
the shape a virtual patch needs is already written down.
What cannot come across is the template's matchers: they read the RESPONSE to
decide whether the target was actually vulnerable, and a WAF decides before a
response exists. So an imported rule is strictly weaker than the template it
came from — it recognises the attempt, not the exploitation. That is why they
land as action "log", which the engine now honours: observed, recorded as an
event, scoring nothing.
Also records what the importer skips rather than guesses: a CVE already
patched in compiled code, a request that is entirely template variables, a
literal under twelve characters, the site root. And what it corrects: one
leading path segment, because a template is written against a laboratory where
the application is mounted somewhere — /laravel52/vendor/phpunit/... would
have been published unable to match a real attack at /vendor/phpunit/...
Documentation only. cve.json is untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N5fpE6Gu4W6JoFMXyb7t7r
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) <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
AndreandClaude Opus 5