690 of Our 734 'SQL Injection' Rules Were Command-Line Flags. Four Things Our Feed Got Wrong, and What We Fixed Today.
We went looking for new CISA KEV entries to write about today and found four defects in our own feed instead. Each one was ours. Each one reported success while it was wrong. All four are fixed, redeployed and checked against the live artifact as of this afternoon. Here is what they were, how much harm each one actually did, and what changed.
One: our exploit harvester wrote 690 junk "SQL injection" rules
Our exploit harvester reads public proof-of-concept code on GitHub and pulls out detection hints: target endpoints, injection strings, hardcoded credentials. While checking the MikroTik RouterOS entry CISA added on September 25 (CVE-2026-67279, an SSH flaw), we saw the harvester had filed two "SQL injection patterns" for it. The values were the bare word "select" and the fragment " or". An SSH bug has no SQL in it.
So we pulled every harvested SQL injection rule out of our index. There were 734. When we tested each value against what an injection payload actually looks like, 690 of them, 94 percent, failed. The single most common value, on 314 rules, was a quote followed by two dashes. That is not a SQL comment. It is the opening of a command-line flag like '--target', which appears in nearly every Python exploit script ever written. The rest were Python's boolean "or", the "select" module Python uses for sockets, and "exec" from the SSH exec request in the MikroTik code. Every one of them carried confidence 90.
The fix has two parts. A rule now needs an injection-shaped marker: a comparison like OR 1=1, a UNION SELECT, a timing call, or a terminated statement. A bare keyword never makes a rule. Second, the harvester now reads the weakness class NVD assigns the CVE, and if that class is concrete and is not an injection class (CWE-89, 564 or 943), no SQL rule is emitted at all. We did not delete the 690. They stay in the index at confidence 0, marked false positive, so the record of what we got wrong survives. The 44 that passed are real payloads: UNION SELECT (31), OR 1=1 (6), AND SLEEP( (3), a terminated statement with a comment (3) and AND 1=1 (1).
Two: what those rules turned into on the way out
Sizing the harm honestly matters more than the count. In our STIX bundle, a detection rule with no URL path to match fell through to a fallback that built a software identifier out of the CVE number, cpe:2.3:::cve-2026-67279, with the CVE ID sitting in the vendor slot. No product on earth has that identifier, so those indicators matched nothing. They were dead weight carrying a high confidence score, not false alarms on your network. A second path was worse in principle: any value with a dot in it and no slash was guessed to be a domain, so a code fragment like os.popen could ship as a domain-name indicator. Both fallbacks are gone. A rule that has nothing observable to match is now skipped, and the guess-by-shape logic only applies to records that are untyped or already network types. The live bundle we downloaded after the deploy has zero junk SQL rules, zero fake software identifiers and zero code fragments typed as domains.
Three: a demoted record could come back at 80
When we correct a record we lower its confidence to 0 and mark it false positive. We do not delete it. Several of our feed outputs filled in a missing confidence with a line of code that reads, in effect, "confidence, or 80 if there isn't one." In JavaScript a zero counts as missing. So a record we had deliberately demoted to 0 went out at 80, in the STIX bundle and the hash, domain and URL CSVs. The IP blocklist was not affected: it has a separate suppression list, and we checked it directly, with zero rows from the LinkedIn address range we corrected earlier today. The fix treats 0 as a real value and skips anything marked false positive.
Four: the main STIX bundle timed out for most pollers
This one hurt the most people. Our full STIX 2.1 bundle at /api/v1/stix-feed is built on request and then cached. A cold build was taking two and a half to four minutes. Cloudflare, which sits in front of us, stops waiting after 100 seconds and returns a 524 timeout. The cache lasted four minutes, so anyone polling less often than that, which is nearly everyone, usually got a timeout instead of a feed. Our server logs show cold builds running past 100 seconds on most days since early September, and on all eight today.
The cause was paging. The builder read each indicator type in 25 pages of 1,000, sorted by time, and in our search engine a deep page costs about as much as everything before it. We measured on our own server: the page at position 24,000 took 9.7 to 12.4 seconds; one page of all 25,000 took 0.8 seconds. There was also a warmup job meant to keep the bundle hot every four minutes. It called the feed without a key, got a 401 and warmed nothing. Now each type is read in one page, the cache holds for 20 minutes, it is shared across every tier that gets identical real-time data, and the warmup authenticates and refreshes every 10 minutes. After the deploy, a request with a paid-tier key came back 200 from a warm cache built about four minutes earlier, and an immediate repeat answered in under half a second.
What we are taking from it
Every one of these returned success. The harvester logged its rules, the bundle builder logged its counts, the warmup ran on schedule, and the feed answered 200 whenever the cache happened to be warm. None of it was caught by an alarm. All of it was caught by downloading what we serve and reading it. That is the check we run, and today it paid.
If you pull our STIX bundle and saw 524s over the past weeks, try again now; it should answer. If you consume our hash, domain or URL CSVs, the next pull drops records we had already marked false. Nothing in the IP blocklist changes. We cap our confidence in this writeup at 95 percent like everything else we publish; if you see something we missed, tell us.
Our feed is free: get a key at https://analytics.dugganusa.com/stix/register.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=690-of-our-734-sql-injection-rules-were-command-line-flags-four-things-our-feed-got-wrong-and-wh
Comments