Magento recommends to not use templates via symlinks:

Advanced > Developer > Template Settings > Allow Symlinks

Warning! Enabling this feature is not recommended on production environments because it represents a potential security risk.

Until today I can't see any risks here.

  • What is the risk?
  • 8
    I can only imagine this being a risk on shared hosts, which shouldn't be used for eCommerce in the first place.
    – benmarks
    Sep 9, 2014 at 12:23
  • 3
    @benmarks. Why don't you put this as an answer?
    – Marius
    Sep 9, 2014 at 12:24
  • 2
    Very good question @Fabi! Sep 9, 2014 at 12:27
  • 3
    I knew that others would offer more complete answers. I was RIGHT :-D
    – benmarks
    Sep 9, 2014 at 13:27
  • 3
    @benmarks The website needs a higher answer per question rate in any way ;-) Sep 9, 2014 at 13:34

5 Answers 5


Symlinks aren't necessarily bad.

First of all: If trying to open a symlink target, the file permissions of the target are in effect. If you're not allowed to read/write/execute the symlink target, nothing happens.

But: You might be able to run files outside your document root (sometimes that's actually what you want to do with them, right?). The problem can occur if your're not in a suEXEC environment and have an apache or www-data user on a shared hosting which, is in charge of serving files from different accounts. Your system user is not allowed to access files of another customer, but the apache/www-data user will mostly have read rights on all the shared accounts. This might be a scenario where one user can access files of another user on a shared host. Not with your own user, but by accessing the file via browser with the apache/www-data user. To sum up: In this scenario you will be able to access other users' files => bad.

The next bad thing is that an attacker could create symlinks, also to files like /etc/passwd,..., download this data and proceed with this information. This is not just only up to the symlink, but also up to a bad server configuration (where access to these files is strictly limited). So not using symlinks prevents from some more possible attacks.

It's not just about the symlink itself being a security risk, but a server configuration problem.

  • 5
    Great explanation - this is the correct answer, essentially, "use at your own risk"
    – philwinkle
    Sep 9, 2014 at 14:41
  • 2
    Probably worth mentioning (although there's always a balance with security related bugs in a 'loath to upgrade' environment) -- Magento strongly discouraging symlinks was related to an exploit where template and layout files outside of the app/design folder, when combined with other minor exploits, could be used by an admin user for privilege escalation and other server exploits. Dec 23, 2014 at 21:02
  • 1
    On Apache httpd if you want to support symlinks, consider that SymLinksIfOwnerMatch option is used instead of FollowSymlinks.
    – hakre
    Nov 11, 2015 at 14:49

yes they are, thats why webservers usually also have a "dont follow symlinks" configuration or at least a "only follow symlinks of target with same user" Thats because webserver/php usually does run with more rights then you should have access to.

And as webservers usually try to avoid things like visible /etc/shadow, it is for magento templates even more dangerous, as templates get parsed via include() so you have possible very strong security leaks if you dont have full controll over your files.

You may argue, that there are other problems then, but who does really know every potential attack scenario, and most times its the combination of different less problematic security holes, which lead to the big breaks.

Also, there was some time ago a security fix regarding media directory and symlinks, so you should look there for possible attack scenarios.

  • 1
    If someone else can create symlinks on your server you're already in bigger trouble than that. I mean - see Ben's comment below. Who would ever host a Magento in a shared hosting? Who would ever host anything in a shared hosting nowadays and why?:)
    – Sven
    Sep 9, 2014 at 20:27
  • 3
    simply because there are people who do it. You cant expect others to act reasonable. There will be always people who do this, and there will always be people who make mistakes regarding general server configuration.
    – Flyingmana
    Sep 10, 2014 at 8:59

I can only imagine this being a risk on shared hosts, which shouldn't be used for eCommerce in the first place.

  • 1
    Unfortunately it is used quite a lot. Sep 9, 2014 at 16:53
  • 2
    According to the PCI Security Council standards technically the public cloud is multi-tenant so even that is considered to be a "risk".
    – philwinkle
    Sep 11, 2014 at 19:36

Magento patch SUPEE-9767 includes APPSEC-1281: Remote code execution through symlinks, so yes, Symlinks on templates are a security problem.

Remote Code Execution (RCE)

CVSSv3 Severity:
8.8 (High)

Known Attacks:
Yes. Attackers are disabling a configuration protection after gaining admin access and are uploading malicious code.

Use of the AllowSymlinks option in configuration settings can enable the upload of an image that contains malicious code. Although this option is disabled by default, an attacker with access to store configuration settings can enable it and remotely execute code.

Product(s) Affected:
Magento CE prior to, and Magento EE prior to

Fixed In:
CE, EE, SUPEE-9767

Wilko Nienhaus


Not recommend to allow. I was facing js loading errors while symlinks enabled.
Lots of;

TypeError: $.widget is not a function

I have to do try 4-5 refresh for successfuly loaded pages.
After closing it, may be not deployed resources loads slowly for first time but js errors gone.

PS: After disabling symlink, you have to delete deployed copy of files after every change for static.php re-copy it for you.

  • 1
    Sorry, I don't understand - you have to make 4-5 refreshes, before it works? What does this have to do with symlinks? Oct 9, 2016 at 18:04
  • Before disabling symlinks :) Sorry for my english.
    – rbostan
    Oct 9, 2016 at 18:14
  • Are we talking about magento2? Then I understand, that I don't understand - no clue about 2 yet. Oct 10, 2016 at 8:38

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.