From CVE advisories to rules

A built-in rule is a generic signature, such as SQL injection in a query string. A CVE in a product that runs behind the router is more specific. Its advisory usually names the endpoint, the parameter or the payload that exploits it, and a user rule can block that request until the product is upgraded. This page covers how to choose such a flaw, how to write and roll out the rule, what rules cannot cover, and the policy for the vh-cve-* rules that ship with the router.

Watch a CVE feed

Read advisories regularly, from sources such as:

• Cloudflare Threat Signals,
• Assure Start,
• the vendor advisory of each product you run,
• JPCERT/CC,
• Wordfence, for WordPress plugins.

A feed lists many flaws, and most do not apply to your deployment. Start from the products that run behind the router.

When to write a rule

Write a user rule when all three hold:

• the CVE is critical for your deployment, and it affects a product behind the router,
• the flaw can be reached over HTTP through the router,
• the exploit is a request you can recognise: an endpoint, a parameter, or a payload.

If one of these does not hold, a rule either does nothing or blocks traffic it should not.

Triage

Check the following before you write anything.

1. Is the flaw reachable over HTTP through the router? A flaw that needs local access, a client application or an operating system bug is not reached by any request that the router sees.
2. Does the exploit have a signature that legitimate use never has? An endpoint that the product's own users call is a poor target for a rule, because blocking it breaks the feature. A signature such as a payload that only exploits can carry is a good target.
3. Scope the rule. A rule at the top level applies to every site, so write it inside the site that runs the product, or name the site with site at the top level. Rules have no location scope; narrow the match with method, path, client and the other conditions instead. If the rule blocks a whole endpoint, narrow it to the methods that the exploit uses.
4. Roll the rule out in two steps. Run -t to check that the configuration parses; it does not show what the rule matches. Then set mode shadow; on the site. Shadow mode forwards every request and records the rule's decision as would_have=block in the access log. Look at those lines, and check that no legitimate request appears, before you switch the site back to mode enforce;.

Remove the rule

A rule is a stop-gap until the product is upgraded past the affected versions. Once the upgrade is done, remove the rule, because it keeps blocking an endpoint that the fixed product may use. Check the vendor advisory for the fixed version rather than assuming one.

What rules cannot cover

A rule looks at one HTTP request. It cannot cover:

• client-side and operating system bugs, since no request that reaches the router carries the exploit,
• logic bugs that have no request signature, such as an authorization check that fails for one valid input,
• deserialisation that is reached through stored data: the payload is saved by one request and triggered later by another, with no signature in either.

For these, the fix is the upgrade, the vendor's configuration change, or a control outside the router.

Worked example: CVE-2026-9103

IBM Langflow OSS 1.0.0 through 1.10.0 issues long-lived superuser bearer tokens from /api/v1/login/auto_login without authentication, when AUTO_LOGIN is enabled. AUTO_LOGIN is enabled by default, so a default install is exposed. IBM's bulletin lists no workaround and recommends upgrading to 1.10.1. The router ships the rule vh-cve-2026-9103, which blocks any request to that path in any letter case. It is off everywhere until a site enables it. For a Langflow site, enable it on that site only:

site langflow.example.com {
    upstream http://langflow:7860;
    enable_rule vh-cve-2026-9103;
}

The rule blocks every method on that path, and it blocks before the decision backend is called. The access log records it as rule_id vh-cve-2026-9103. If the Langflow instance needs auto_login for its own clients, the rule breaks them, so do not enable it on a site where that is the case. Upgrade Langflow to 1.10.1, the fixed release named in IBM's bulletin, and then remove the rule. Setting AUTO_LOGIN to false is a configuration option that turns off the behaviour the rule blocks. IBM's bulletin does not list it as a workaround, so confirm its effect on your deployment before you rely on it.

vh-cve-2026-8481 (POST /api/v1/validate/code runs user-supplied Python through exec() without a sandbox) is in the same product and the same range. An authenticated user can exploit it, and the rule protects against misuse of any account, including a stolen account or one that anyone can register. IBM's bulletin gives no workaround and does not confirm the fixed version in the text checked here, so upgrade past 1.10.0 and check the bulletin for the fixed release. If the site runs that product, enable both rules together:

enable_rule vh-cve-2026-9103 vh-cve-2026-8481;

Worked example: CVE-2026-8505

Langflow OSS 1.0.0 through 1.10.0 skips the API key check on webhook endpoints when WEBHOOK_AUTH_ENABLE is false, which is its default. A remote attacker who knows a flow's UUID can run that flow. IBM's bulletin recommends upgrading to 1.10.1 and lists no workaround.

The router does not ship a rule for this flaw. The rule language matches on what is present in a request, and it cannot match a header that is absent, so it cannot tell a webhook call that carries a key from one that does not.

The options are:

• upgrade to 1.10.1, the fix that IBM's bulletin gives.
• set WEBHOOK_AUTH_ENABLE to true. IBM does not list this. Third parties suggest it (OpenCVE does), so confirm its effect on your deployment before you rely on it.
• if the webhooks must stay open, restrict who can reach the site with the access list. A site that has allow or deny lines applies that list to every path of the site, so use it only when the whole site is for the callers that need access. A rule's client condition cannot express "every address except these", so it cannot restrict one path to a set of callers.

Later releases

Later Langflow bulletins can list newer fixed releases than 1.10.1. Run the latest release, not only the release a bulletin names, and check each bulletin for the version it recommends.

Policy for the shipped vh-cve-* rules

The router ships a vh-cve-* rule only when it meets all of these:

• the flaw is widely exploitable,
• the exploit has a fingerprint that a request shows and legitimate use does not,
• the advisory names the affected product and versions.

A rule that blocks a whole endpoint is a virtual patch, and it ships with default off; so that it runs only where an operator enables it with enable_rule. A shipped rule is removed after the product has had a fixed release for long enough that operators have had the chance to upgrade. The period is not a fixed number of days; the maintainers decide it per advisory and record the removal in the changelog.

The rules vh-cve-2026-9103 and vh-cve-2026-8481 follow this policy. Their descriptions name the product and the CVE. vh-cve-2026-9103 names 1.10.1, the fixed release in IBM's bulletin; vh-cve-2026-8481 advises an upgrade past 1.10.0 and points to the bulletin for the fixed version.