Phishing.Database: Active phishing domain and link feeds

Phishing.Database scope and intended consumers

Phishing.Database addresses a specific collection problem: organizations and researchers need reusable lists of known phishing infrastructure without depending on a proprietary feed. The repository covers phishing domains, complete links, and IP addresses. The README describes organizations integrating threat data, researchers studying phishing activity, and developers adding context to security tools as intended users.

The project is a data repository rather than a blocking service or scanning API. It does not document a policy engine, an incident-response workflow, or a function that accepts an arbitrary URL and returns a phishing verdict. Consumers must select the files they need, interpret the records, update local copies, and apply their own handling rules.

The README identifies VirusTotal as an integration in which Phishing.Database supplies feeds. That relationship defines its scope. The repository can add indicators to systems that already analyze URLs and hosts, but it does not explain why each domain appears in a list or whether every listed resource currently behaves in the same way.

The repository includes cumulative domain and link downloads as well as files named for active, inactive, invalid, newly discovered, and recently active records. Consumers can choose between broad historical coverage and smaller time-oriented feeds. The trade-off is straightforward: a compact feed reduces the amount of data to ingest, but it also provides a narrower view of the collection.

Status files and the repository data model

Based on the repository layout, its central abstraction is a set of text files. The README links to `phishing-links-ACTIVE-NOW.txt`, `phishing-links-ACTIVE-today.txt`, and `phishing-links-NEW-today.txt`. The top-level entries also contain matching flat files and directories for active, inactive, invalid, new, and last-hour categories across domains, links, and IP addresses. Several categories exist in both forms, but the README does not document the format or purpose of every directory entry.

The status names are data labels, not permanent properties of an Internet resource. A host or URL can change state as infrastructure is reassigned, taken down, observed again, or classified differently. The repository description says PyFunceble validates the status of known phishing domains and provides statistics about how many unique domains remain active. The README does not explain PyFunceble's settings, retry policy, network identity, timeout behavior, or exact mapping from validation results to every file category.

Consumers should preserve the distinction between a newly discovered record and an active record. Importing every `NEW-today` entry as a permanent assertion would discard that distinction and turn a point-in-time observation into a long-lived classification. The README does not define retention rules, so update policy belongs to the integrating system.

Several cumulative downloads are published through the project's `phish.co.za` site, including `ALL-phishing-domains.lst` and `ALL-phishing-links.lst`. The README also links to checksum files in the separate `Phishing-Database/checksums` repository. Checksums help a consumer confirm that a downloaded file matches its published value, although they do not establish the accuracy of the classifications inside that file.

Downloading a first feed without a package installer

The README does not give package-manager installation commands, a container image, or a supported command-line client. This fits its repository-centered distribution model. A first use consists of obtaining a documented data file and passing its records to a security workflow controlled by the consumer.

For cumulative domain coverage, the README identifies `ALL-phishing-domains.lst` as the official download. A first integration can select that file when historical coverage matters more than limiting ingestion to active records. For a time-sensitive workflow, `phishing-domains-ACTIVE.txt`, `phishing-domains-NEW-today.txt`, or `phishing-domains-NEW-last-hour.txt` offer narrower starting points based on status and discovery period.

The documented checksum links cover `ALL-phishing-domains.lst` and other named files with MD5, SHA1, SHA256, and SHA512 variants. Use a checksum that matches your deployment's verification requirements. The checksum repository establishes file integrity relative to its published value; it does not certify that every domain record is correct.

Before loading a cumulative file, inspect its actual line format. The README does not specify whether records are bare hostnames, URLs, normalized values, comments, or another arrangement. It also does not document deduplication rules. A developer who assumes the wrong format can create empty matches, malformed lookups, or excessive memory use without receiving a project-specific schema error.

A sensible first use has three concrete parts: download only a documented file, verify it against its matching checksum, and inspect representative records before importing them. No installation command should be treated as official because the README does not publish one.

PyFunceble validation and operational trade-offs

The repository description assigns validation of known phishing domains to PyFunceble. Based on that statement, the collection is more than a static list of submitted domains. Its status statistics depend on a separate tool checking whether known domains remain valid or reachable.

That design raises operational questions for maintainers and serious consumers. Phishing infrastructure can respond differently depending on DNS resolution, IP address geography, redirects, TLS behavior, user agent, or intermittent availability. A failed request does not necessarily establish that a service is permanently inactive. The README does not document whether the project controls these variables, so consumers cannot infer a detailed consistency guarantee from the status names alone.

File naming also separates discovery from current status. `NEW-last-hour`, `NEW-today`, `ACTIVE-today`, and `ACTIVE-NOW` suggest different views, but the README does not define their exact inclusion criteria. This documentation gap matters for an automated consumer. Map each filename to an explicit internal policy and review that mapping when file behavior changes.

Large cumulative files introduce another cost. The README lists archive sizes of 4.4 MB for all phishing domains and 14 MB for all phishing links, while also providing list downloads. Those figures do not describe memory use after parsing. An uncompressed list loaded into an inefficient in-memory structure can consume considerably more space. Streaming may be appropriate, but Phishing.Database does not publish a streaming schema or client, so the integrator must implement that behavior without assuming repository-specific conventions.

Limits, false positives, and incompatible security workflows

The main limitation is that a domain or URL feed answers a narrow question: it contains records that the project classifies as phishing-related. It does not provide enough documented context to serve as a complete abuse verdict for every request. The README mentions an issue process for false-positive reports found through VirusTotal, which confirms that users can encounter incorrect classifications. It does not state a correction service level or explain how quickly affected records are removed.

Status can also change after publication. An active phishing host may be taken down, while an inactive or invalid domain may later resolve and serve new content. A file downloaded once will become stale unless the consuming system updates it. The README does not define a stable API, a guaranteed update cadence for each file, or a rollback procedure.

Phishing.Database is the wrong tool when you need live URL inspection, redirect tracing, page-content classification, attachment analysis, or an incident-specific determination. Those tasks require systems designed to examine the requested resource and its behavior. A static feed can contribute indicators, but it cannot replace contextual analysis.

An alternative approach is to use a request-time reputation service that evaluates an individual URL as a browser or client requests it. The architectural difference is concrete: Phishing.Database supplies precomputed repository files, while a request-time service evaluates a submitted resource and returns a current decision. Keeping Phishing.Database alongside DNS, proxy, or secure web gateway logs can also reveal whether listed destinations were actually contacted. Each approach addresses a different part of phishing detection.

MIT licensing, updates, and maintenance expectations

The repository is distributed under the MIT license. That permits reuse and modification under the license's conditions, including retaining the required copyright and license notice in copies or substantial portions of the distribution. This is a licensing summary rather than legal advice. Consumers should inspect the repository's `LICENSE` file and preserve notices appropriate to their distribution model.

The repository is not archived, and the last push was on 2026-10-02. That establishes recent repository activity. However, the repository has no GitHub releases and documents no release schedule. Consumers should not interpret the absence of formal releases as an endpoint that never changes. File contents can change directly on the default `master` branch.

Upgrade work extends beyond downloading a new archive. Integrators must account for moved or changed files, altered status categories, record-format differences, false-positive reports, and checksum updates. A cached local copy should be replaceable with a verified newer copy without assuming that every historical record remains present or that classification labels are immutable.

The README identifies external downloads and a separate checksum repository, but it does not document mirror policy, historical snapshots, retention guarantees, or rollback. Organizations that need audit evidence should retain the exact imported file, its matching checksum, and the retrieval time in their own operational records. The feed can supply indicators, but reproducible handling depends on those external controls.

Editorial conclusion

Adopt Phishing.Database when you need an openly licensed source of phishing domains, links, or IP records for filtering, research, or security tooling. Do not treat it as a complete phishing verdict engine or as a replacement for controls that inspect traffic in context. Before deployment, verify the chosen file's format and checksum, sample it for stale or false-positive records, and confirm that your consumer can handle its status and recency categories.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Phishing-Database/Phishing.Database on GitHub
4. README