# Bug: SID 2064326 has severity:1 but is labeled "ET INFO" **URL:** \ **Category:** Feedback & Support\ **Tags:** suricata, false-positives\ **Created:** [January 17, 2026, 1:45pm UTC](https://community.emergingthreats.net/t/bug-sid-2064326-has-severity-1-but-is-labeled-et-info/3171 "2026-01-17T13:45:41Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Hans2026](https://avatars.discourse-cdn.com/v4/letter/h/c4cdca/32.png) [@Hans2026](https://community.emergingthreats.net/u/Hans2026)\ **Post date:** [January 17, 2026, 1:45pm UTC](https://community.emergingthreats.net/t/bug-sid-2064326-has-severity-1-but-is-labeled-et-info/3171/1 "2026-01-17T13:45:41Z")
Rule SID 2064326 “ET INFO Python aiohttp User-Agent Observed Inbound” has conflicting severity indicators, causing false positives in downstream security tools. This rule has: - severity: 1 in Suricata alert output (critical) - signature\_severity: Informational in metadata - Name prefix “ET INFO” (informational alert) normal HTTP requests from Python aiohttp clients to my own web server triggered instant IP bans due to severity:1 ET INFO rules should have severity:2 or severity:3, matching their informational classification. - Suricata 8.0.2 on Ubuntu 24.04 - ET Open ruleset (updated 2026-01-17 via suricata-update) If this is the wrong place for bug reports then please redirect me to the proper location. ---
**Author:** ![rgonzalez](https://avatars.discourse-cdn.com/v4/letter/r/bc79bd/32.png) [@rgonzalez](https://community.emergingthreats.net/u/rgonzalez)\ **Post date:** [January 20, 2026, 2:26pm UTC](https://community.emergingthreats.net/t/bug-sid-2064326-has-severity-1-but-is-labeled-et-info/3171/2 "2026-01-20T14:26:45Z")
Hello @Hans2026 ! In the rule text the severity is informational, as below: `alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET INFO Python aiohttp User-Agent Observed Inbound"; flow:established,to_server; http.user_agent; content:"python/"; startswith; nocase; content:"aiohttp/"; within:20; nocase; fast_pattern; reference:url,cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift; classtype:trojan-activity; sid:2064326; rev:1; metadata:affected_product Web_Server_Applications, attack_target Web_Server, tls_state plaintext, created_at 2025_09_04, deployment Perimeter, performance_impact Low, confidence High, signature_severity Informational, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2025_09_04; target:dest_ip;)` Are you doing perhaps some pre or post-processing of the rules, or is a tool interpreting the severity incorrectly? ---
**Author:** ![Hans2026](https://avatars.discourse-cdn.com/v4/letter/h/c4cdca/32.png) [@Hans2026](https://community.emergingthreats.net/u/Hans2026)\ **Post date:** [January 20, 2026, 3:22pm UTC](https://community.emergingthreats.net/t/bug-sid-2064326-has-severity-1-but-is-labeled-et-info/3171/3 "2026-01-20T15:22:32Z")
Hi rgonzales/ET Team, That looks to be the case indeed. I feed this to Suricata and it assigns alert severity from the classtype, not from signature\_severity in metadata. This rule has: classtype:trojan-activity In Suricata’s default classification.config, trojan-activity maps to priority 1: config classification: trojan-activity,A Network Trojan was detected,1 So when Suricata writes to eve.json, the alert gets “severity”: 1, regardless of what signature\_severity says in metadata. And next CrowdSec acts on the severity field, not the metadata. Should the classtype perhaps be misc-activity (priority 3) instead of trojan-activity for an ET INFO rule? I think most Python aiohttp is legitimate traffic, not a trojan. – Hans ---
**Author:** ![ishaughnessy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.emergingthreats.net/ishaughnessy/32/491_2.png) [@ishaughnessy](https://community.emergingthreats.net/u/ishaughnessy)\ **Post date:** [January 20, 2026, 10:27pm UTC](https://community.emergingthreats.net/t/bug-sid-2064326-has-severity-1-but-is-labeled-et-info/3171/4 "2026-01-20T22:27:33Z")
Hello @Hans2026 Thanks for pointing this out! I went through the rest of the ruleset and adjusted the metadata so there should no longer be any `INFO` signatures with a priority 1 classification, let us know if you see any other oddities and we’re happy to help! Cheers, Isaac ---
**Author:** ![rgonzalez](https://avatars.discourse-cdn.com/v4/letter/r/bc79bd/32.png) [@rgonzalez](https://community.emergingthreats.net/u/rgonzalez)\ **Post date:** [January 21, 2026, 3:33pm UTC](https://community.emergingthreats.net/t/bug-sid-2064326-has-severity-1-but-is-labeled-et-info/3171/5 "2026-01-21T15:33:05Z")
Thanks @ishaughnessy @Hans2026 !