About OIXLY
OIXLY aggregates seven public threat intelligence feeds into one searchable, filterable view. It is free, requires no account, and the underlying data files are open for anyone to download.
What this is for
The individual feeds are all public, but each ships a different format — a bare text file of IPs here, a CSV there, a JSON API somewhere else. Checking an indicator against all of them means writing a parser for each. OIXLY does that once, normalises the result into a single schema, and publishes it as static files.
It is a lookup and triage surface, not a detection product. Treat every entry as a lead to verify, not a verdict.
Sources
Core feeds
| Feed | Contributes | Categories | Severity |
|---|---|---|---|
| CISA KEV | Vulnerabilities confirmed exploited in the wild | CVE, CISA KEV, Exploited | Critical |
| NVD | Published CVEs from the last 90 days | CVE, NVD CVE | From the CVSS score |
| OpenPhish | Confirmed credential-harvesting URLs | Phishing | High |
| Threatview.io | Malware file hashes (MD5) | Malware | High |
| SANS ISC | Network blocks recorded as heavy attack sources | Scanning | High |
| Blocklist.de | IPs reported for brute force, spam and DDoS | Brute force | Medium |
| Tor Exit Nodes | Current Tor exit relays | Tor exit | Low |
Supplementary feeds
| Feed | Contributes | Categories | Severity |
|---|---|---|---|
| Spamhaus DROP | Hijacked and criminally controlled netblocks | Botnet C2 | High |
| CINS Army | IPs with poor reputation across the Sentinel network | Scanning | Medium |
| Binary Defense | Artillery ban list | Scanning | Medium |
| Emerging Threats | Compromised hosts generating attack traffic | Brute force | Medium |
| Feodo Tracker | Botnet command-and-control servers | Botnet C2, Malware | Critical |
| URLhaus | Malware distribution URLs | Malware (+ Phishing) | High |
| ThreatFox | Indicators tied to named malware families | Malware, Botnet C2 | High |
The last three require a free abuse.ch API key. If the operator of this instance has not configured one, those feeds contribute nothing and the pipeline reports them as skipped rather than pretending they ran.
A record can be in several categories
Categories are not exclusive. A CVE on CISA's KEV list that was exploited before disclosure and is used by a ransomware crew appears under CVE, CISA KEV, Exploited, Zero-day and Ransomware — filtering by any one of them finds it.
This means category counts add up to more than the number of records, on purpose. The headline count is always one per record.
NVD CVE is the vulnerability roll-up: every CVE carries it, whichever feed surfaced it. CISA KEV is the exploited subset — a KEV entry is an NVD-published CVE, so it carries both NVD CVE and CISA KEV. Filtering NVD CVE shows every vulnerability; filtering CISA KEV narrows to the ones confirmed exploited in the wild. There is no separate generic CVE category — it was redundant once every CVE carries NVD CVE.
How zero-day is determined
CISA does not publish a zero-day flag. What it publishes is the date a CVE was added to the KEV catalog, and NVD publishes the date the CVE became public. When a CVE reaches KEV at or within seven days of publication, it was already being exploited when it became public, and OIXLY marks it as a zero-day.
This is an inference, not a vendor statement. It errs toward under-reporting: a missing date on either side means no flag rather than a guess. Treat it as a strong hint to prioritise, not as an authoritative classification.
Duplicates
Records are deduplicated twice. First by identifier, so the same entry from the same feed never appears more than once. Then by indicator, so an IP reported by three different feeds becomes one record rather than three.
Merging keeps the most severe assessment and the union of the categories, and names the other feeds in an Also Reported By field. Corroboration is worth seeing — three independent feeds agreeing is a stronger signal than one — so it is surfaced rather than discarded.
CVEs are exempt from indicator merging. An NVD entry and a KEV entry for the same CVE are merged earlier, by CVE identifier, because they are two statements about one vulnerability rather than two sightings of one host.
Every entry links back to its origin. Where a feed does not assign a severity, OIXLY assigns one per the table above — that is an editorial judgement about the feed as a whole, not an assessment of the individual indicator.
How severity is meant to be read
- Critical — known exploited. Act on these first.
- High — confirmed malicious by the reporting feed.
- Medium — reported abusive behaviour, community sourced.
- Low — notable but not inherently malicious. Tor exit nodes are the main case: they are legitimate infrastructure that also carries attack traffic.
Processing
The pipeline runs every six hours and does the following, in order:
- Fetch each feed. A feed that fails or returns an empty body is skipped, never treated as empty.
- Parse each into the common schema: id, title, category, severity, source, indicators, timestamp.
- Merge against everything already published, keyed by id. Existing records are preserved.
- Merge duplicate reports of the same CVE from different sources into one entry.
- Merge records that describe the same indicator, keeping the strongest assessment.
- Drop anything older than the 90-day retention window.
- Write the day-bucketed static files this site reads.
Retention
OIXLY keeps a rolling 90 days. Older records are removed, not archived. The window is applied in one place, at build time, so what you see and what you download always agree.
What this does not cover
Being explicit about the gaps matters more than the feature list:
- No commercial or paid intelligence. Public feeds only.
- No malware samples, no PCAPs, no YARA rules.
- No attribution, no threat actor tracking, no campaign clustering.
- No confidence scoring. An indicator is present because a feed reported it, though the Also Reported By field shows when several agree.
- Delisting is not tracked. A record staying in the window does not mean the indicator is still live.
- Coverage depends entirely on the upstream feeds. A quiet day here may mean a quiet feed, not a quiet internet.
Accuracy and false positives
Public feeds contain false positives. Compromised sites get cleaned, IPs get reassigned, and shared hosting means one bad URL can implicate a domain serving thousands of legitimate sites. Verify before you block anything with a blast radius, and prefer the narrowest indicator that solves your problem.
To report a mistake, open an issue against the repository. Corrections belong upstream — if a feed is wrong, reporting it to the feed fixes it for everyone rather than only here.
Licensing
The aggregation, code and site are open. The underlying data belongs to the feed operators and carries their terms — check each source before redistributing commercially. Attribution to the original feed is included on every record for exactly this reason.