[crowdsec-automation]

The rule requires both the Langflow /api/v1/validate/code endpoint and a Python import statement in the JSON code argument. This focuses detection on the vulnerable import-validation path rather than matching imports elsewhere in requests. URL decoding and lowercasing normalize the URI and request value before matching. The test template uses the relevant third-stage request from the original flow and checks only for an HTTP 403 response, as required.

Exploit URL: https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2026/CVE-2026-93674.yaml

[github-actions]

Hello @crowdsec-automation and thank you for your contribution!

❗ It seems that the following scenarios are not part of the 'crowdsecurity/appsec-virtual-patching' collection:

🔴 crowdsecurity/vpatch-CVE-2026-93674 🔴

[github-actions]

Hello @crowdsec-automation,

Scenarios/AppSec Rule are compliant with the taxonomy, thank you for your contribution!

[github-actions]

Hello @crowdsec-automation,

✅ The new VPATCH Rule is compliant, thank you for your contribution!

[he2ss]

pb-rule-review verdict: needs human

Checked against the nuclei template. The rule blocks /api/v1/validate/code when json.code contains import .

• validate_waf_rule: pass. lint_waf_rule: only the crowdsecurity/ namespace warning (expected for hub rules). Rule listed in the vpatch collection, CI green.
• Exploit: POST /api/v1/validate/code {"code":"import nprobe"} → 403 on the harness.
• False positive, confirmed on the harness: a standard Langflow component (from langflow.custom import Component … class CustomComponent(Component)) posted to /api/v1/validate/code → 403. The Langflow editor sends exactly this to validate component code, and every component contains import, so the vpatch would block normal editing. Code without import → passes (404 from the backend).

Not fixed automatically: the single validate/code request of the exploit (a bare import <module>) has nothing that sets it apart from legitimate code; what is specific is the planting step (POST /api/v1/custom_component writing into site.getsitepackages()). Moving the rule there changes what it detects and needs a decision. The AC rule (alert-context-rules#1159) and taxonomy (cti_taxonomy_list#1621) are fine and do not depend on this PR.

[he2ss]

will trigger FP