Summary `t:htmlEntityDecode` recognises only five named HTML entities — `"`, `&`, `<`, `>` and ` `. Every other named entity is copied through undecoded, so a rule that relies on the transformation to normalise its input can be evaded by spelling the payload's ASCII characters as entities. A browser decodes them; the rule never sees them. ``` SecRule ARGS "@rx javascript:" "id:10002,phase:2,t:none,t:htmlEntityDecode,deny" ``` `q=javascript:execute_my_code();` is blocked. `q=javascript&colon;execute_my_code();` is not — and the browser executes it. Scope The original report named two missing entities (`&apos;`, `&colon;`) and stated they were the only ones. That is not correct, and the correction matters for anyone assessing exposure: 39 named entities that expand to a single ASCII character are not decoded, along with `­` (U+00AD) and the `&NonBreakingSpace;` spelling of NBSP. The complete set is not curated by hand — it is derived from the WHATWG named character reference list, <https://html.spec.whatwg.org/entities.json>, selecting every entity that expands to a single code point in U+0000..U+007F plus U+00A0 and U+00AD. That yields 44 entities, of which the decoder previously handled five. Two consequences of the list having been assembled by hand in earlier drafts of the fix, both now resolved by generating it: - Aliases were missed. Several ASCII characters are reachable under more than one name — `{` is both `&lbrace;` and `&lcub;`, `[` is `&lbrack;` and `&lsqb;`, `^` is `&Hat;`, `|` is `&vert;`, `&verbar;` and `&VerticalLine;`. Covering one spelling and not the other leaves the bypass open. This is not theoretical: CRS rules 944150, 944151 and 944152 match `&l(?:brace|cub);?` directly in their regex, because real Log4Shell payloads use both spellings. - Three entities were mapped to characters the specification does not assign them. `&caret;` is U+2041, `&hyphen;` is U+2010 and `˜` is U+02DC — none of them ASCII. Decoding them to `^`, `-` and `~` makes ModSecurity see characters the browser will not render, which is a false-positive source, and it left the genuine spellings (`&Hat;`) unhandled. Impact Any rule using `t:htmlEntityDecode` to normalise input before matching can be evaded. In OWASP CRS that is 35 rules: 28 in `REQUEST-941-APPLICATION-ATTACK-XSS`, 3 in `REQUEST-921-PROTOCOL-ATTACK`, 3 in `REQUEST-944-APPLICATION-ATTACK-JAVA` and 1 in `REQUEST-920-PROTOCOL-ENFORCEMENT`. There is no general safety net behind those rules. `@detectXSS` (CRS 941100) tokenises tags, so it still flags entity-encoded content — but entity-encoding an attribute separator defeats it outright, and `&equals;` is one of the entities this bug leaves undecoded: ``` <img src=x onerror=alert(1)> detected <img src=x onerror=alert&lpar;1&rpar;> detected <img src=x onerror&equals;alert&lpar;1&rpar;> NOT detected ``` The Java/Log4Shell rules (944150–944152) are unaffected, because their authors already worked around this decoder by matching the entity spellings inside the pattern itself. Patches - v2: `apache2/msc_util.c` — `html_entities_decode_inplace()` - v3: `src/actions/transformations/html_entity_decode.cc` — `inplace()` Both replace the five-way `if`/`else` cascade with a generated table matched on the full token with an exact length comparison. The table is produced by `tools/gen-html-entities.py` from `entities.json`; regenerating it is a documented one-liner, so the list cannot drift from the specification again. The exact-length comparison also fixes a second defect in v3, which compared only the first 2–4 characters of the token: `&ltest;` decoded to `<` and silently dropped `est`, `&amped;` decoded to `&`, and `&gtfoo;` decoded to `>`. v2 was not affected by that one — it compared the full token. Matching remains case-insensitive, which the specification is not. Where two spec entities differ only in case and disagree on the character (`&colon;` = U+003A but `&Colon;` = U+2237; likewise `&LT;`/`&Lt;`, `&GT;`/`&Gt;`, `&vert;`/`&Vert;`, `&verbar;`/`&Verbar;`), the ASCII one wins. This preserves existing behaviour and errs toward decoding more, not less; the collisions are listed in the generated table's header comment. Workarounds None that fully substitute for the fix. Detection that does not depend on `t:htmlEntityDecode` — `@detectXSS`, `@detectSQLi`, or rules matching the entity spellings directly, as CRS 944150–944152 do — is unaffected.