Could receiving in a text or an email, a URL link just like https://security.stackexchange.com/questions/ask of a website, which could be a pernicious one, ever pose a security problem at all? What I am asking is that: if I receive such a link but do NOT click on it, will it ever do harm to my account, computer or other website I will ever visit?

Edit: As a specific example, I would like to ask about the situation for receiving a link, https://down[.]nnjah68[.]me/app.php/Mjl1to, in WhatsApp.

  • 3
    If the link is not shown as plain text, but processed in any way (even just to highlight it), there could be an exploitable bug in the parsing code, such as a buffer overrun. Unlikely, but possible.
    – dbkk
    Commented Feb 8, 2021 at 21:39
  • 3
    Some apps generate previews of links. They might send some information to those websites; and the preview image/snippet could contain something you might not want to see. Commented Feb 9, 2021 at 9:08
  • 1
    @SalmanA To give an example if an app that does that do that: outlook's default is to show a link preview: support.microsoft.com/en-us/office/… Commented Feb 9, 2021 at 17:56
  • 1
    @dbkk Adding to what you said about bugs in a URL parser, there could also be bugs in the text rendering engine, e.g. soyacincau.com/2020/04/24/…
    – Nayuki
    Commented Feb 9, 2021 at 19:53
  • 2
    There was once a chrome bug where hovering over (or clicking) the link http://a//%%30%30 would cause the tab to crash (see superuser.com/questions/977604/… and e.g. 9to5google.com/2015/09/22/…) - this is an example of a URL-parsing bug, though I don't think it was ever exploitable in any interesting way.
    – Pokechu22
    Commented Feb 10, 2021 at 1:23

4 Answers 4


Many browsers send "pings" to any links on a page by performing a DNS query on them to populate the cache. This makes clicking the link faster because the IP is already in the DNS cache. In theory, a bug in this code could be exploitable simply because the link is there. In practice, this isn't an issue. Just because a link exists doesn't mean it can do much to you.

  • 3
    @Hans Yes, it is a malware analysis/detection site. It's a popular one. Obviously it does not have a 100% detection rate, however, so use it only with that limitation in mind.
    – forest
    Commented Feb 7, 2021 at 3:38
  • 23
    wait, so my browser is phoning home to every link on every page I visit? The owner of every link I ever see gets a ping when I do?
    – benxyzzy
    Commented Feb 7, 2021 at 13:40
  • 12
    @benxyzzy: Possibly, yes, depending on browser, version, settings, plugins, add-ons, etc. For priming the DNS cache, a simple DNS lookup would be enough and arguably both more efficient and more privacy-conscious, but OTOH, you'd miss out on redirects that way. Commented Feb 7, 2021 at 20:30
  • 4
    This seems like a huge privacy issue since any link posted by anyone on a comment section (blog, news, social media or here) would be able to track all visitors. Do you have any source for this or any additional information (which browser are affected, which version, etc.) ?
    – zakinster
    Commented Feb 8, 2021 at 8:44
  • 9
    @forest Do you have any reference for this ? The only documented behaviour I could find is link prefetching which supports dns-prefetch but it only concerns external resource links (HTML <link> tag for css, js, etc.) not hyperlinks (HTML <a> tag).
    – zakinster
    Commented Feb 8, 2021 at 9:26

Some software will automatically fetch any URL it sees, even if you don't click it. A few examples:

  • Browsers that are configured to pre-fetch certain URLs so that they load instantly after clicking (this isn't default on any major browser I'm aware of, but I've seen it).
  • Messaging clients that show a preview of the page (text and/or image thumbnail) when you send or receive a message with a link.
  • Browser extensions that pre-fetch certain links to check the page for malware (part of some AV suites).

In any of these cases, a vulnerability in the HTTP client (browser, AV software, messaging app or server, etc.) could be exploited by an attacker. However, such vulnerabilities are relatively rare unless the client supports JS (it is very hard to make a JS engine fully secure, though of course the developers try) and often sandboxed to limit the damage even if they are vulnerable.

Also, note that - in an ideal world where everything works correctly - fetching a URL would always be safe (it shouldn't be possible for fetching a URL to do anything harmful) and wouldn't even be state-changing (GET should be idempotent). Obviously, the real world is not nearly so ideal, since both software vulnerabilities and websites that ignore various standards exist. However, because those things exist, and for privacy reasons (fetching a URL always exposes, at a minimum, an IP address), automatically fetching URLs is relatively rare.

Just looking at a link (without fetching/visiting it) isn't going to be dangerous unless your text rendering library has some seriously wacky bugs, and most likely they could be set off by non-link text in a situation like that anyhow.

  • 4
    "vulnerability in the HTTP client" – I believe you mean HTML client there, although of course the HTTP client may also have a vulnerability. While HTTP is much simpler than HTML and HTTP clients are typically well-tested, we had a rapid evolution recently with the introduction of HTTP/2, HTTP/3, SPDY, and QUIC in rapid succession, which are much younger, less mature, and less well tested than HTTP/1.1. While the server cannot force the client to upgrade to one of those younger protocols, clients do that all by themselves anyway, at least up to HTTP/2. Commented Feb 7, 2021 at 20:35
  • 7
    No, I definitely meant HTTP. Although many HTTP clients are also HTML clients, the reverse is not necessarily true, see for example libcurl. Fetching a URL is 100% HTTP and 0% HTML, though rendering the result of the fetch might (or might not!) involve HTML. After all, an HTTP response can be literally any content type, most of which have nothing to do with HTML (common ones being JSON, various images or videos, any any sort of executable code in binary or script form), or have no content type at all (errors, redirects, 201 responses, etc.).
    – CBHacking
    Commented Feb 8, 2021 at 6:40
  • If your HTTP client also does something with the response, such as trying to parse / render / execute / etc. it, then of course that's additional attack surface. If it merely writes it to a file or console - as curl does by default - then it's possible whatever other software eventually consumes the output will be harmed by it but the problem won't be that you fetched a URL, it's that you fed a malicious input to some program that couldn't handle it. That's a problem, but it's not a "fetch a URL" problem except in the obvious sense that obviously the result of fetching a URL is untrusted.
    – CBHacking
    Commented Feb 8, 2021 at 6:44
  • 1
    Upvote, but the answer would be more awesome with one or two examples of browsers that pre-fetch, messaging clients that preview, and (popular) browser extensions that pre-fetch. Or if anyone else can contribute that information in the comments it could also be handy, purely for knowledge's sake.
    – stevec
    Commented Feb 8, 2021 at 15:52
  • I added a specific example of an app and a link to my question. You may use that example in your answer.
    – Hans
    Commented Feb 8, 2021 at 17:26

Yes We can be pretty sure this can happen, because something very similar to it did: https://www.nbcnews.com/tech/security/android-flaw-could-let-hackers-take-over-phone-text-n399016

Stage-fright: There was a bug that got named Stage-fright which was in the image or video-processing on Android. Because some apps will "view" media automatically to generate a preview, the app automatically runs the media through the buggy library without the need for user intervention.

Back to your question: Currently, many messaging apps, including Discord, generate a preview of links that are sent to you. If a similar bug were to come back, it would almost certainly affect people who view the link without opening it, since the app needs to render the link preview.

  • 1
    Right, but Stagefright (bug) as nothing to do with an URL!? If just an example, I think this could be specified. Commented Feb 8, 2021 at 9:57
  • I added a specific example of an app and a link to my question. You may use that example in your answer.
    – Hans
    Commented Feb 8, 2021 at 17:26
  • @Hans In your specific example, almost certainly, no. I haven't used the app, but it would be considered a security hole. Even if it did exist, such a bug would probably be patched by now, either by the OS, What'sApp patching it in the app, or blocking such URLs on the What'sApp server.
    – Patrick M
    Commented Feb 12, 2021 at 19:42


  • Yes but, if you use confined tools or smartphone.
    As already metioned in many answer there, confortable applications, with previews, pre-download and so on is subjet to software vulnerabilities (in tool himself or in system libraries).
    Of course, this kind of security issues is mostly quickly published and patched.

  • Near no, if you use text tools in VT console, without picture and preview.
    For sample, I use mutt mailer, without binding and I manually check attachment when I don't simply ignore them (mostly enterprise logo and other useless tips)
    So if a want to acceed to an url, I have to copy-paste them...(I use xterm wich don't offert to automatically open browser by clicking on URL)

  • I added a specific example of an app and a link to my question. You may use that example in your answer.
    – Hans
    Commented Feb 8, 2021 at 17:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .