ctl:ruleRemoveTarget* rejects any target containing `@` (e.g. XPath attribute selectors)

[fzipi]

Summary

The action parser refuses to load a rule when the value of ctl:ruleRemoveTargetByTag (or ctl:ruleRemoveTargetById) contains a @ character. The same rule loads cleanly under ModSecurity v2.

The cause appears to be in the scanner: @ is tokenized as the operator prefix (as in @rx, @detectXSS) and that interpretation leaks into action-value tokenization. Likely in src/parser/seclang-scanner.ll.

Affected

• libmodsecurity 3.0.15 (owasp/modsecurity-crs:nginx image, current pinned digest)
• ModSecurity-nginx connector

Reproducer

SecRule REQUEST_URI "@unconditionalMatch" \
    "id:999990,\
    phase:2,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetByTag=attack-xss; XML://@*"

Expected

Rule loads. XML://@* is a valid ModSecurity XPath target and is accepted as a SecRule variable in the same engine.

Actual

[emerg] "modsecurity_rules_file" directive Rules error.
Line: 6. Column: 47. Expecting an action, got:  @*"

The error column always points at the @.

Bisect

Value passed to ctl:ruleRemoveTargetByTag	Result
attack-xss; XML:/*	✓ loads
attack-xss; XML://foo	✓ loads
attack-xss; XML://node	✓ loads
attack-xss; XML:/element	✓ loads
attack-xss; REQUEST_HEADERS:Foo	✓ loads
attack-xss; XML://@*	✗ fails at @
attack-xss; XML://@foo	✗ fails at @
attack-xss; XML://@	✗ fails at @
attack-xss; ARGS:@foo	✗ fails at @
attack-xss; FOO@BAR	✗ fails at @

So the problematic character is @, regardless of its position or what follows it. Quoting ('…') and backslash escaping (\@) are not honored.

ModSecurity v2 comparison

The same rule loads and runs correctly under Apache + mod_security2 2.9.x.

Impact

ctl:ruleRemoveTargetByTag / ctl:ruleRemoveTargetById cannot be used to runtime-toggle any target that includes a @ — which includes the entire XPath attribute axis (XML://@*, XML://@name, etc.). The only workaround is ctl:ruleRemoveById, which disables the whole rule rather than a single target.

Asks

1. Allow @ (and ideally the full target/XPath grammar) inside ctl:ruleRemoveTarget* values.
2. If a scanner change is non-trivial, document the limitation in the v3 reference manual.

[airween]

@fzipi,

thanks for reporting this.

It's a very annoying bug, but I think it's easy to fix (with a minimum modification).

The problem is that the REMOVE_RULE_BY does not cover the character @.

Adding the @ solves it partially, but probably it would be much better to split up the tokens for ruleRemoveBy... and ruleRemoveTargetBy... cases.

And of course, add as many tests as possible.

[Jitterx69]

@airween

If nobody’s working on this yet, I’d be down to patch it

[airween]

If nobody’s working on this yet, I’d be down to patch it

Go for it!

[Jitterx69]

Hope it helps @airween