What are the subjects of the false-positive (domains, URLs, or IPs)?
lnk.ink
*.lnk.ink
https://lnk.ink
https://www.lnk.ink
Why do you believe this is a false-positive?
Why do you believe this is a false-positive?
lnk.ink is a legitimate URL-shortener service (similar to bit.ly, tinyurl,
short.io) operating since 2025. It is not a phishing domain — it is a
target of phishing abuse, like every other shortener. The platform has
robust abuse moderation:
- Public abuse-report form: https://lnk.ink/abuse (no login required,
rate-limited to prevent abuse, sends notifications to abuse@lnk.ink)
- RFC 9116 security.txt: https://lnk.ink/.well-known/security.txt
- Active moderation: phishing links are bulk-blocked on detection
(e.g. just blocked 49 Spanish "Correos" postal-phishing shortcodes in
the past week, and a wave of South-African *-za.cfd financial scams
this morning). Blocked links serve a warning interstitial, not the
malicious destination.
- Failed-URL cache: when our preview-fetcher hits 404/timeout on a
destination, the URL is cached so subsequent abuse waves are flagged
faster.
- Footer "Report Abuse" link in 20 languages on every page.
Google Safe Browsing currently shows lnk.ink as clean
(https://transparencyreport.google.com/safe-browsing/search?url=lnk.ink).
The presence of phishing submitted to a shortener is not the same as
the shortener itself being phishing. Blocking lnk.ink punishes thousands
of legitimate users whose links are correctly being shortened, and gives
attackers the same blocking outcome whether they're caught by us or not —
removing the incentive for us to invest in moderation. Most major
shorteners (bit.ly, tinyurl, t.co, lnkd.in, ow.ly, is.gd) are NOT in your
ACTIVE list for the same reason.
How did you discover this false-positive(s)?
Other (Please fill out the next box)
Where did you find this false-positive if not listed above?
User report → traced to AdGuard DNS sinkhole (returns 94.140.14.33 for
lnk.ink). AdGuard sources from Phishing Army, which sources from this
repository's phishing-domains-ACTIVE.txt.
Verification commands:
$ dig +short @94.140.14.14 lnk.ink A
94.140.14.33 # AdGuard sinkhole = blocked
$ dig +short @94.140.14.140 lnk.ink A # AdGuard non-filtering
104.21.56.153
172.67.152.193 # real Cloudflare IPs
$ curl -s https://raw.githubusercontent.com/Phishing-Database/Phishing.Database/master/phishing-domains-ACTIVE.txt | grep '^lnk.ink$'
lnk.ink # ← present here
$ curl -s https://phishing.army/download/phishing_army_blocklist.txt | grep '^lnk.ink$'
lnk.ink # ← propagated to Phishing Army
Have you requested a review from other sources?
Yes:
Do you have a screenshot?
Screenshot
Additional Information or Context
About the service:
- Legitimate URL shortener, public registration, multi-language UI (20 locales)
- Hosted on dedicated infra, Cloudflare-fronted
- Active since early 2025
- Open source backend code visible at
https://github.com/mrvuit/lnk.ink (monorepo with frontend + backend)
Abuse pipeline:
- POST /api/abuse/report endpoint (express-rate-limit: 10/hr/IP)
- AbuseReport model with categories: phishing, malware, spam, scam, other
- Admin moderation panel at /admin/abuse-reports
- Email notifications to abuse@lnk.ink (Zoho Group → support@)
- Automatic block:
blockedType=phishing ENUM on Link model serves
warning interstitial that links to /abuse for further reports
Why the original entry probably exists:
- A specific phishing campaign abused lnk.ink as a redirect (the
Validin "lnk.ink/crealitycloud" Creality Cloud impersonation, March 2026)
- That campaign was added to
validin-phish-feed, which propagated
lnk.ink (the bare domain, not the specific shortcode) here
- Hagezi has already fixed this on their side; ask is for parity here
Thank you for maintaining this important resource — and for the obvious
care taken with the FP review process. Happy to provide additional
verification, abuse statistics, or a maintainer-to-maintainer call if
useful.
What are the subjects of the false-positive (domains, URLs, or IPs)?
lnk.ink
*.lnk.ink
https://lnk.ink
https://www.lnk.ink
Why do you believe this is a false-positive?
Why do you believe this is a false-positive?
lnk.inkis a legitimate URL-shortener service (similar to bit.ly, tinyurl,short.io) operating since 2025. It is not a phishing domain — it is a
target of phishing abuse, like every other shortener. The platform has
robust abuse moderation:
rate-limited to prevent abuse, sends notifications to abuse@lnk.ink)
(e.g. just blocked 49 Spanish "Correos" postal-phishing shortcodes in
the past week, and a wave of South-African
*-za.cfdfinancial scamsthis morning). Blocked links serve a warning interstitial, not the
malicious destination.
destination, the URL is cached so subsequent abuse waves are flagged
faster.
Google Safe Browsing currently shows
lnk.inkas clean(https://transparencyreport.google.com/safe-browsing/search?url=lnk.ink).
The presence of phishing submitted to a shortener is not the same as
the shortener itself being phishing. Blocking
lnk.inkpunishes thousandsof legitimate users whose links are correctly being shortened, and gives
attackers the same blocking outcome whether they're caught by us or not —
removing the incentive for us to invest in moderation. Most major
shorteners (bit.ly, tinyurl, t.co, lnkd.in, ow.ly, is.gd) are NOT in your
ACTIVE list for the same reason.
How did you discover this false-positive(s)?
Other (Please fill out the next box)
Where did you find this false-positive if not listed above?
User report → traced to AdGuard DNS sinkhole (returns 94.140.14.33 for
lnk.ink). AdGuard sources from Phishing Army, which sources from this
repository's
phishing-domains-ACTIVE.txt.Verification commands:
$ dig +short @94.140.14.14 lnk.ink A
94.140.14.33 # AdGuard sinkhole = blocked
$ dig +short @94.140.14.140 lnk.ink A # AdGuard non-filtering
104.21.56.153
172.67.152.193 # real Cloudflare IPs
$ curl -s https://raw.githubusercontent.com/Phishing-Database/Phishing.Database/master/phishing-domains-ACTIVE.txt | grep '^lnk.ink$'
lnk.ink # ← present here
$ curl -s https://phishing.army/download/phishing_army_blocklist.txt | grep '^lnk.ink$'
lnk.ink # ← propagated to Phishing Army
Have you requested a review from other sources?
Yes:
False Positive: lnk.ink (URL shortener with active abuse moderation) hagezi/dns-blocklists#10061 — already silently
resolved (
*.lnk.inkno longer in pro/pro.plus/tif/ultimate/light as oftoday)
this repo is the upstream root cause for AdGuard.
Do you have a screenshot?
Screenshot
Additional Information or Context
About the service:
https://github.com/mrvuit/lnk.ink (monorepo with frontend + backend)
Abuse pipeline:
blockedType=phishingENUM on Link model serveswarning interstitial that links to /abuse for further reports
Why the original entry probably exists:
Validin "lnk.ink/crealitycloud" Creality Cloud impersonation, March 2026)
validin-phish-feed, which propagatedlnk.ink(the bare domain, not the specific shortcode) hereThank you for maintaining this important resource — and for the obvious
care taken with the FP review process. Happy to provide additional
verification, abuse statistics, or a maintainer-to-maintainer call if
useful.