Here's a fun game for you: what do you expect to be the state of the filesystem after running the following commands in an empty directory on a Linux system?

$ touch foo:bar
$ tar -cpf foo:bar.tar foo:bar
$ rm foo:bar
$ tar -xpf foo:bar.tar

Do you expect the directory to contain the files foo:bar and foo:bar.tar?

What if I told you that instead the directory would only contain foo:bar.tar and stderr would say

tar (child): Cannot connect to foo: resolve failed

Yep! It turns out that GNU tar, if passed a filename containing a colon, treats the part before the colon as a hostname and attempts to connect to that host over rsh to download the part of the file after the colon. If you're not familiar with it, rsh is the completely-insecure predecessor to SSH. It's been at least 20 years since any reasonable system has shipped with RSH. This behavior is documented in Chapter 9.1 of the GNU tar manual but nobody I polled had ever heard of it.

Anyhow, GNU tar has a --force-local option to disable this behavior. If you ever process tar files whose names you do not completely control, or which might for some reason contain a colon, you should pass --force-local before every invocation.

An enterprising security researcher could probably have a lot of fun experimenting with vendor crap like security cameras and routers that take tar files with user-controlled filenames for firmware upgrades and see how many of them can be persuaded to establish a rsh shell to some attacker-controlled device...