Rule (rev 1, 2023-12-12) :
drop http [$HOME_NET,$HTTP_SERVERS] any → any any (msg:“ET WEB_SPECIFIC_APPS Atlassian Bitbucket CVE-2022-1471 Vulnerable Server Detected Version 7.17.x - 7.21.15”; flow:established,to_client; http.response_body; content:“Atlassian|20|Bitbucket|20 3c|span|20|”; fast_pattern; content:“data|2d|system|2d|build|2d|number|3d 22|”; within:250; content:“|22 3e 20|v7|2e|”; within:50; pcre:“/^(?:2(?:1.(?:[023456789]|1[012345]?)|0.)|1[789].)/R”; … sid:2049637; rev:1;)
Problem: The version-range PCRE intends to bound at 7.21.15 but matches every 7.21.x, including all patched releases (7.21.16+, where SnakeYAML 2.0 fixes CVE-2022-1471). Two defects:
1[012345]?— the optional second digit means “21.16” through “21.19” match on the bare “1” (backtracks to the one-digit interpretation).- The one-digit branch
[023456789]has no trailing boundary, so “21.23” matches on the “2”, “21.34” on the “3”, etc.
Observed impact: Environment running patched Bitbucket 7.21.23 (banner data-system-build-number="..."> v7.21.23) triggers the signature on every page load. Since the rule ships as detection for a vulnerable server, deployments that convert WEB_SPECIFIC_APPS to drop end up blocking legitimate responses from fully patched servers indefinitely.
Verification (Python re, equivalent semantics):
v7.21.15 -> MATCH (correct)
v7.21.16 -> MATCH (FP - patched)
v7.21.23 -> MATCH (FP - patched)
v7.21.99 -> MATCH (FP)
v7.22.0 -> no match (correct)
Suggested corrected PCRE:
pcre:"/^(?:2(?:1\.(?:1[0-5]?|[02-9])(?!\d)|0\.)|1[789]\.)/R"
Verified to match exactly 7.17.0–7.21.15 and reject 7.16.x, 7.21.16+, 7.22+.
Request: Please also review the sibling CVE-2022-1471 “Vulnerable Server Detected” rules published the same day (2049638 Bitbucket 8.0–8.12.0; 2049639–2049644 Confluence; 2049645–2049646 Jira 9.4–9.11.1) for the same boundary pattern.