Is .txt the only email attachment type that can always be opened without risk?

Source of the claim: Training program on phishing at my company

  • 10
    .txt isn't a valid MIME type. Did you mean text/plain? Commented May 4 at 14:35
  • 26
    so you're saying that people at your company are trained to open any email attachement, as long as the extension is .txt? Good to know. Out of curiosity, what's the name of your company?
    – njzk2
    Commented May 4 at 18:03
  • 3
    What do you mean "open?" I would bet fopen("foo.txt", "r") is safe, barring a malicious colpiler. From the conversation, it seems like "open" means "interpret or execute the contents." It might improve security if users knew that double-click icon has the effect of interpret the file represented by the icon using the program associated with the file extension, with executable files being important special cases.
    – Ana Nimbus
    Commented May 4 at 19:56

6 Answers 6


There is no such thing as a "file that can be opened without risk".

A file can be one of two things: it can be instructions that get executed, or it can be data. Data itself can be used by a program to execute commands (for example a scripting language interpreter) or it can be used as input for another program. For example, a bunch of bytes might be a pretty picture when read and understood by a graphics program.

For obvious reasons, both executable code and data interpreted by a program to execute code are inherently dangerous. It could do almost anything.

Opening executable code is very risky. It is the equivalent of sending you a knife with a note that says "please stab yourself hard, thanks". You can do it, but the risk that it isn't to your benefit is quite high.

Then there is plain data. Plain data should not be dangerous, because it's just data. You may not like what you see in that picture sent to you, you may not like the opinion in a text document, but your computer should be safe. This is where "bugs" and "vulnerabilities" come in. Interpreting data is not always easy and if programmers make mistakes, the data they interpret might lead to the program doing something it should not do. And people will "exploit" that by crafting data in a way that makes sure this happens in a way they want.

There is no such thing as a program that interprets data that is "without risk"; therefore there is no file that can be opened without some degree of risk.

Text files, however, are the simplest way of transmitting data. Compared to more complicated types of data and their specialized handling processes, there are less places to make mistakes and less chances for exploits. Less. Not zero.

The statement as given is trivially wrong, and any professional programmer (especially one with a security background) can tell you that.

However, when training people, you have to tailor your message to the audience. There is no point in overloading people with details; otherwise, you can only ensure they take nothing home other than confusion and boredom.

A plain text file, opened with the operating system's default editor probably has the lowest risk compared to other options. It's not technically zero, but maybe shortening it to "zero risk" is just the simplification the audience needs.

I would not discredit your training course just because they don't teach the gritty details to people that don't care for the computer's inner workings. Whatever your day job is, just imagine you'd have to explain it to me, a totally clueless person. How much would you need to simplify that to get it into an hour long presentation? Exactly.

To summarize:

Technically, the statement is obviously wrong. As a guideline for non-technical people to go by, it is still questionable. If that level of simplification were necessary, the audience would have more pressing problems than this (e.g. lacking the knowledge needed to even identify when something is a plain text file). However, we are missing a lot of context here, so I would not condemn the whole training based only off of one single snippet.

  • 46
    As a security awareness trainer, I'm not sure of the benefit of making this claim in the first place. It is fraught with problems. Not the least of which is encouraging people to open "file.txt.pdf" So, I do discredit the course. Something is wonky here. This isn't a valuable bit of knowledge to have, so simplifying a non-useful message has no value.
    – schroeder
    Commented May 3 at 12:12
  • 3
    Well, yeah you are right, once you need to simplify it to that level for an audience, the point is moot because they cannot tell whether something even is a plain text file.
    – nvoigt
    Commented May 3 at 12:25
  • 3
    I was about to post a new answer, before I saw your final paragraph. Indeed, the email client and email itself are probably both far more complex and bug-ridden than the text editor and text file are. So I think for any realistic scenario you must already have accepted a far greater risk before you even obtain the attachment. (and "no extra risk" is a common interpretation of "no risk") Commented May 3 at 21:21
  • 5
    Exactly right. While .txt files can be mere ascii text with reasonable line lengths, they can also be UTF files with arbitrary encoding and arbitrary line lengths, and parsers need to gracefully handle invalid byte sequences, large files, control characters like line-break and EOF, and so much more. Text-file-parsing bugs have been found in MacOS (eg CVE-2019-8761), Linux vim (CVE-2019-12735), and plenty on Windows. Commented May 3 at 23:35
  • 4
    and of course, windows with default settings hides the actual file extension. So anyone taught ".txt files are safe" might just be a good person to send my innocent text file "notAVirus.txt.exe" to
    – Syndic
    Commented May 6 at 12:58

Of course not. Text file readers can have vulnerabilities:

And that's just what I found after 5 minutes of light browsing.

What a silly claim for them to make, even if they believed it. Some new vulnerabilities could be found... The claim won't age well.

What they probably meant to say was that notepad.exe has had very few flaws and is a very low-risk way to open txt files. TextEdit, Notepad++, Vim, Emacs, or whatever other program you might have that you use as a default text file reader (which are likely more complex than notepad.exe) are an open field for vulnerabilities.


No file type can be opened without risks.

Of course some types are associated with a bigger risk than others. For example, anything that includes executable code like Microsoft Office files with VBA macros are inherently dangerous, because an attacker only has to get the victim to execute the code. However, this is not the only attack variant. Another option would be to exploit a known vulnerability in the program which processes the attached file (like a PDF viewer automatically opening .pdf files). This second variant can, in principle, be applied to any file -- PDF documents, pictures and even plaintext files. A concrete example for a vulnerability in text editors is CVE-2019-8761 in macOS. This allows an attacker to inject HTML markup into .txt files and get the default text reader TextEdit to process it. Using CSS elements, for example, it's possible to steal local files.


People have said that implicitly, but to say it explicitly:

The ending of a file is just politeness.

There's nothing stopping you from renaming virus.exe to cookie_recipe.txt. So just because it has a .txt ending does not mean that it's plaintext. In fact whatever it is, it is just data, so a series of 1s and 0s. So what it does is largely determined by whoever tries to take it as input, read it and interpret it.

Not to mention that the end of the filename, might not be at the right most spot. Like there are apparently ways to spoof the file extension by using a Left-to-right-character in the middle of the filename so if exe appears somewhere in the name, even though it ends in txt it might still be an exe.


Or if your system doesn't display the file extension you might add another one so virus.txt.exe, the .exe is not displayed but the txt appears. The icon being displayed can also be changed and so on. Now these are pretty old, but new ways of spoofing might come around.

So if by "open" you mean double click a file, it might still behave differently from what you're expecting.

And even if by "opening" you mean giving it as input to a program, you'd need to make sure that the program itself doesn't have any vulnerabilities, that enable the interpretation of the data as code. Like even ASCII didn't just include the alphabet but also had control characters. And if you delete the right things or have the cursor jump to the wrong places overriding the wrong stuff and whatnot you might still do interesting stuff.

So opening it with a text editor is probably safer than double click and safer than other file types, but that doesn't mean it's without risk.


The answers by fellow community members nvoigt and schroeder are superb. There is one critical point I would like to add to both of those excellent answers:

When one talks about "opening" a file, they are typically talking about opening the file with the program currently associated with that file type in the operating system or web browser. (Depending on the situation, the file type may be determined by the file's content, its MIME type, or its actual extension, which can be obscured.) Such associations can be changed to an executable that is more vulnerable by a new user, a poorly trained user, a malicious user, or by malware. Thus, in addition to it being essential to always know what one is actually opening, it is also imperative to also always know what executable will be processing that data.

The best practice is to not download or open any unsolicited files, even if they seem to "just be text files". That said, I do agree with the general notion that plain text files, when opened on a properly configured system, with an up-to-date version of a thoroughly tested and simple text editor (without macro/scripting capabilities) that has no known security issues is one of the relatively safer types of data you can process, especially when compared to opening word processing files, presentations, or spreadsheets.

  • I do cover this in the last line of my answer.
    – schroeder
    Commented May 5 at 9:12
  • 1
    @schroeder Not quite. I didn't see any mention that the association can be changed intentionally by malware or a malicious user or unintentionally by a new or poorly trained user. Commented May 6 at 0:42

Scripts are usually plaintext, aren't they? For example, Bash.

Here we have fs/binfmt_script.c in the Kernel v6.8:

static int load_script(struct linux_binprm *bprm)
    const char *i_name, *i_sep, *i_arg, *i_end, *buf_end;
    struct file *file;
    int retval;

    /* Not ours to exec if we don't start with "#!". */
    if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))
        return -ENOEXEC;
// ...

A text file may have a shebang. If umask was set during downloading and storing to anything resulting in executable permission set for the file, too, its "opening" may cause Kernel to actually execute the content passing file to the respective program.

Though, there are many variables to it, including ACL, distribution environment protections, the Email client, the current Kernel defaults, except the umask, make it fairly possible.

Please correct if mistaken, but the "default" umask for supported file-systems is normally 0022 in Kernel v.6.8, that is 755 or rwxr-xr-x for general files, including directories:

/* to be mentioned only in INIT_TASK */
struct fs_struct init_fs = {
    .users      = 1,
    .lock       = __SPIN_LOCK_UNLOCKED(init_fs.lock),
    .seq        = SEQCNT_SPINLOCK_ZERO(init_fs.seq, &init_fs.lock),
    .umask      = 0022,

It stays that way untouched relatively normally in environments, however, the umask may be changed with a corresponding command, Systemd, or during system or SSH User authentication/authorization also via pluggable authentication modules (PAM) like pam_umask, for example:

pam_umask is a PAM module to set the file mode creation mask of the current
environment. The umask affects the default permissions assigned to
newly created files.

The PAM module tries to get the umask value from the following places
in the following order:

- umask argument;
- umask entry of the users GECOS field;
- pri entry of the users GECOS field;
- ulimit entry of the users GECOS field;
- UMASK entry from /etc/default/login;
- UMASK entry from /etc/login.defs.


$ cat -- './test.txt'; # Preview the file contents
#! /bin/sh

id > "$( mktemp; )" `# Should create file in `/tmp/`` \
  && echo Created; 
$ stat -c '%a,%A' -- './test.txt'; # Current file permissions
$ './test.txt'; # Execute


- How to trace where php5-fpm umask settings are coming from on ubuntu...

  • 3
    That is not how umask works; it removes permissions, it doesn't define them, and applications do not create ordinary files with the executable bit set (unlike directories). The example seems to rely on an existing script that has been given executable permissions and so doesn't really show much. Commented May 4 at 20:43
  • 3
    While maybe interesting technically, I doubt the OP has any idea what you are talking about. They probably cannot even ascertain if your answer amounts to "yes" or "no". While I am very reluctant to downvote a good faith answer, I have a hard time seeing this as useful to the OP. What would your answer practically mean, to someone in corporate, wondering whether they should double-click the .txt attachement to their email in their Windows Outlook client?
    – nvoigt
    Commented May 5 at 8:53
  • @MichaelHomer , thank you! Do we know where is the default permissions are set in Kernel? Considering the removal you stated, where is umask used to remove the permissions in Kernel?
    – Artfaith
    Commented May 5 at 13:18
  • There are no default permissions set in the kernel, in POSIX compliant systems, permissions are given in the third argument of the call to open(3). Calling open() with O_CREAT but without the required third argument results in undefined behaviour. In the Linux implementation of open(2) this results in reading arbitrary bytes from the stack. Please do not do this.
    – timuzhti
    Commented May 6 at 5:55

You must log in to answer this question.

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