I no longer believe it is a good idea to work with a list of dangerous functions. I have tried to edit the question is such a way that it respects my earlier perspective, but also so that it does not give users the impression that certain things are safe whereas they are not.


Running Mathematica code from an untrusted source is very dangerous. Luckily, Mathematica warns you about dynamic content, so that it is probably safe to open any notebook, as long as you don't run it.

I feel it would be very nice to have a list of functions that can harm a system. Using this, we may be able to make a function that checks if a notebook is safe.

A function to find dangerous functions

A naive function to see if dangerous expressions are present in a NotebookObject, could be the following.

Through[{Unprotect, ClearAll}[dangerousFunctionsQ]]

dangerousFunctionsQ[nb_] := ! 
   FreeQ[ToExpression[Unevaluated[#], StandardForm, 
       HoldComplete] & /@ (NotebookRead@Cells[nb])[[All, 1]], 
    Alternatives @@ listOfDangerousFunctions];


Where listOfDangerousFunctions is given. Unfortunately, this code does not guarantee safety, even we know the full list of dangerous functions.

Furthermore, getting the NotebookObject is a bit tricky. We could simply open the notebook and use Notebooks, but opening the notebook doesn't sound too safe. Also making an automated approach based on this is inelegant. Note however, that using the obvious alternative, which is to use Import (with one argument) on the notebook file turns out not to be safe.

The question is: Which built-in functions are dangerous (especially just by themselves)?


In a CDF can I suppress or avoid “This file contains potentially unsafe dynamic content…”

  • $\begingroup$ Important indeed! I have often been scared by the potential dangers of Mathematica files of unknown origins. $\endgroup$ Commented Jul 28, 2013 at 16:04
  • $\begingroup$ @SjoerdC.deVries and everyone else: If you think some technique is really dangerous or that it will cause more people to try to abuse than that it will help others to prevent abuse, please do not add such techniques. Also let me know if you feel I have added to much already, though I think nothing here is really advanced. $\endgroup$ Commented Jul 28, 2013 at 16:11
  • $\begingroup$ Pretty sure I recall seeing the dangerous functions in one of the *.tr files. $\endgroup$ Commented Jul 28, 2013 at 22:09
  • $\begingroup$ See also the package located at FileNameJoin@{$InstallationDirectory, "AddOns", "Applications", "Security"} $\endgroup$ Commented Aug 28, 2015 at 11:17
  • 2
    $\begingroup$ Even a whitelist is dangerous: it is essentially not possible to ban Symbol since anything[[0]] will be Symbol. E.g. with anything[[0]]["Del" ~~ "eteF" ~~ "ile"] I get DeleteFile in a way that would pass most whitelists and most blacklists. Of course, it can be prevented by undefining dangerous functions. $\endgroup$ Commented Apr 8, 2016 at 23:05

3 Answers 3


Honestly, Mathematica is so flexible and has so many undocumented functions tucked away in nooks that I think it would be better to create a white-list of safe functions than to try to list all potentially dangerous ones.

Better still would be to simply run Mathematica on a virtual machine or in an instance of Sandboxie where no damage is permanent (excepting privacy issues if network access is not blocked).

  • 3
    $\begingroup$ @JacobAkkerboom Range/Table/Array/ConstantArray--can exhaust all of the machine's memory unless wrapped in MemoryConstrained. $RecursionLimit--if set to infinity, one can crash Mathematica at will. Dot--matrix multiplication can easily consume all available CPU resources and effect a DoS attack. Mr. Wizard is IMO quite correct that whitelisting is the only workable approach, and indeed this is exactly what WRI does for CDFs and for the browser plugin. $\endgroup$ Commented Jul 28, 2013 at 20:53
  • $\begingroup$ @OleksandrR. Good points. Thanks for adding to the lists :). It is also important to know that Wolfram uses whitelists, potentially that would mean even obscure functions could be not safe. But the kind of attacks you point out are in my opinion nowhere near as threatening as taking over ones computer (discretely or otherwise). I feel approaches like: a) Either you can trust somebody or you can't at all, or b) a function can either be used harmfully or not at all, are not the most constructive. Today I executed some code by Nasser. I do not trust him blindly but skimming through his code $\endgroup$ Commented Jul 28, 2013 at 21:10
  • $\begingroup$ feels like its enough of a safeguard, right? $\endgroup$ Commented Jul 28, 2013 at 21:10
  • $\begingroup$ I have accepted your answer. I am a bit disappointed about this design choice, but I these investigations have been very useful. Maybe a whitelist can be made by doing something like DeleteCases[Names[Alternatives@@safeContexts~~"'*"], dangerousSymbols]. Maybe that could be quite nice :). $\endgroup$ Commented Jul 29, 2013 at 0:07
  • $\begingroup$ @Jacob Sorry I didn't have a more pleasing answer for you, but thanks for the Accept nevertheless. $\endgroup$
    – Mr.Wizard
    Commented Jul 29, 2013 at 12:06

The dangerous symbols are contained in MiscExpressions.tr

enter image description here

  • 5
    $\begingroup$ Great! This should the location on all OSes: FileNameJoin[{$InstallationDirectory, "SystemFiles", "FrontEnd", "TextResources", "MiscExpressions.tr"}] $\endgroup$ Commented Jul 28, 2013 at 22:45
  • 3
    $\begingroup$ I have to wonder if that list is really complete. I bet someone with special knowledge could cause trouble with Raw for example. $\endgroup$
    – Mr.Wizard
    Commented Jul 28, 2013 at 22:52
  • $\begingroup$ @Mr.Wizard also for your own functions existence of DownValues can cause a security warning. Have related before that last year for me a tick function caused a warning but changing to a pure tick function was fine. $\endgroup$ Commented Jul 28, 2013 at 23:11
  • $\begingroup$ Possibly also missing: 'System'ConvertersDump'ImportTest'. It would seem that is the function that does most of the work of Import. After importing a file, you can remove attribute ReadProtected from Import and see that it just refers to this function. You can also code of ImportTest, but this is really hard to read. $\endgroup$ Commented Jul 28, 2013 at 23:19
  • 1
    $\begingroup$ Through[{ClearAttributes[#, ReadProtected] &, Information}@ "ImportExport'FileUtilities'DeleteFileOrDir"]; (sorry for the bad delimiters). I feel I have to agree with @Mr.Wizards answer now :O $\endgroup$ Commented Jul 28, 2013 at 23:26


Throughout this answer, direct and indirect are used to mean directness in the sense of dependence of a function on other functions to do harm. A directly dangerous function is then a function that needs no other functions to do harm. I state dangerous combinations in cases only a combination of such functions is dangerous. Directness is the factor in the structure of this answer.

I think a good way to find dangerous functions is the documentation entry about notebook security. Especially the table below is a nice place to start

enter image description here

Directly dangerous and really nasty

{Get, Put, DeleteFile, RenameFile, Run, RunThrough,
Export, FrontEndExecute, FrontEndTokenExecute, Read, ReadList, OpenRead, SendMail}

1) Dangerous combinations

OpenAppend/OpenWrite + any write function LoadJavaClass + any function to use functions from a java class.

2) Functions that are dangerous if other powerful programs are available

{Install, Import, NotebookGet}

Notes: Export and Put can overwrite files. RenameFile cannot overwrite files, but it can move a file and then replace it with another, which seems very dangerous to me. Possibly SetOptions should be included. Another candidate is SetSystemOptions. Mathematica evaluates the result of Import, which makes Import dangerous. Possibly Install always has access to powerful code and is dangerous in any context. Read and ReadList can be used to execute commands, as can OpenRead. Missing here are: NetLink functions. SendMail can send files as attachments.

Indirectly dangerous

Below are indirectly dangerous functions, but they are especially dangerous in the sense that a function that checks for dangerous functions may be fooled by these

Functions that convert strings to code

{Uncompress, ToExpression, Symbol}

Notes: Symbol can be used to generate the symbols/functions we want to ban.

Expression fetching functions

By "expression fetching functions", functions are meant that import Mathematica expressions, from which dangerous functions can be extracted. This is a danger even if the Mathematica expressions themselves are harmless.


Box converting functions

{MakeExpression, ToExpression}


Functions that can be undesirable and that do not depend on other functions (much less of an issue)

{CopyFile, SetFileDate, SetDirectory (*kind of silly*)}


If enough functions get listed, I will assemble them into lists of useful combinations so that you do not have to copy and paste and then join these yourselves.

Feel free to add functions to this answer, I am sure the lists are not complete yet.

  • $\begingroup$ Add Read and ReadList to the list, as they can be used to execute external commands (see this). $\endgroup$ Commented Jul 28, 2013 at 16:00
  • $\begingroup$ @SjoerdC.deVries I have tried to consider those to be special case of abuse by converting Boxes to expressions. If there is abuse possible without using MakeExpression or ToExpression feel free to add them. I suppose we should at least mention them :) $\endgroup$ Commented Jul 28, 2013 at 16:13
  • $\begingroup$ I'm on vacation and using my iPad. So anything other than small edits is a real pain. $\endgroup$ Commented Jul 28, 2013 at 16:18
  • $\begingroup$ Not dangerous, except perhaps to your privacy: SendMail $\endgroup$ Commented Jul 28, 2013 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.