Menu Search
Jump to the content X

SVN Server Admin Issue: Fix It!


A few months ago, Anton Isaykin in collaboration with the company 2comrades discovered a serious security problem that is quite typical of big projects (we do not name names here). To test it, they obtained the file structures and even the source code of about 3320 Russian websites and some major English-language websites. Serious problems like this aren’t supposed to exist nowadays. Every serious or visible exploit is found and fixed quickly. But here we will show you something simple and ordinary yet quite dangerous.

What was found is not actually a vulnerability because it’s documented. What we really wanted to show is that major websites and even unique services are affected (SM can’t list them, sorry). That shows again that bad developer habits is the most dangerous vulnerability we can imagine.

What Is It? Link

Almost every developer has used or is using a version control system such as SVN. SVN is an advanced tool for managing source code and is used by teams consisting of anywhere from two to hundreds of developers. In its architecture, SVN stores some meta data in a hidden sub-directory (called .svn) of every directory. One of the files in there, named entries, is a list of all of the files and directories contained in the folder where .svn is located. source code

It also has a link to the repository itself, developer log-ins, file sizes and dates. That’s a problem right there, isn’t it? So, if a project was developed using SVN, we could go to and see the project’s root file structure, with all of this information.

And we could go even further. In the same .svn directory are some text-base directories containing the latest versions of all project files. Moreover, these files carry the non-standard extension .svn-base (for example, index.php.svn-base). So, the files are not run in PHP, Ruby, Python or Perl but are displayed outright!

We should note that not all websites use SVN this way. We were not able to get the source code in every case.

When we realized that this problem has persisted for almost nine years, we decided to create a crawler to check websites with Russian top-level domains and major .com websites to collect some statistics. But before we report this, let’s go over how to prevent such a thing from happening to your own project.

How To Defend Yourself Link

You can solve the problem in different ways. The simplest solution is to deny access to SVN meta data directories from port 80 using a Web server configuration.

Solution for nginx Link

location ~ /.svn/ {
    deny all;

nginx has no global location support, so we have to apply this solution to every server section. For the solution to stick, you have to apply it before any other locations with regular expressions. In most cases, you can use the first location.

Solution for Apache Link

<Directory ~ ".*.svn">
    Order allow,deny
    Deny from all
    Satisfy All

Apache is simpler. Just add the lines above to httpd.conf, which will secure all of your projects.

Solution Using SVN Link

The cure for the problem is to use the Web server. Every doctor will tell you that prevention is easier and cheaper than treatment. The best solution, then, is to not let .svn in your Web root. To do this, use svn export. It’s a common good developer’s practice, but apparently in many cases some developers do not follow it.

svn console

Let The Robot Do The Work Link

As we said, we decided to check the Russian-language Internet for this problem. We established proxy servers, developed a crawler and got a list of .ru domains.

The first crawler version ran for two weeks, getting websites one by one in a thread. When it was finished, we found about 3000 websites affected and had about 100 GB of source code. The problem was that the crawler downloaded every resource, even if the HTTP response code was 500 and not 200, including images and JavaScript. Also some servers responded with a 200 code even when files were not actually there.

The second version was faster. It was multi-threaded and launched from two servers. Also it could work with HTTP response codes and check meta data syntax. This time, the entire .ru zone was covered in four days. Next, we wanted to check .com, but that would have taken about two years with our resources (there are more than 700,000,000 .com domains, compared to only 2,000,000 .ru domains). source code

So, we partnered with a good C developer, Andrey Saterenko, who implemented a really fast daemon that could do the job 200% faster. Unfortunately, the summer ended and we had jobs to do. We decided not to check the entire .com domain. So, we picked the top websites based on Alexa statistics and threw in some famous websites that we really like.

We had to alert the developers involved in all of these affected projects before we published this article. We first sent letters to the major Russian services, such as Yandex,,,,,, and Then the remaining 3000+ Russian websites received their letters. After that, we sent emails to the top .com websites.

Some Numbers Link

  • Domains checked: 2,253,388.
  • Projects affected: 3332. source code

We have no detailed statistics on how many projects have been fixed since our report. Perhaps we’ll publish that information in two weeks. We received replies from six major Russian projects. One .com project sent us thanks. We got an email from Wikimedia, and Rasmus Lerdorf of emailed us (immediately!). Both projects are open source, so their source code couldn’t be “stolen,” but we emailed them just in case. Ten projects ignored our emails, and four fixed the problem without replying.

Fun fact: approximately 10 websites with “hack” or “secure” in their domain name are actually not secure.

Credentials Link

All of the source code was printed and then burned. Don’t ask us to sell it or publish it. We don’t have it anymore. Please check if your favorite website is affected. If it is, write a letter to its support team, with a link to this article. If this article has helped you find and fix the problem, please send an email to sam [at] rmcreative [dot] ru. We’ll be glad to read it.

About the authors Link

The original Russian article was written by Anton Isaykin in collaboration with the company 2comrades that specializes in Web project analytics, development and support.

Anton Isaykin is professional PHP/Python developer in Russia who specializes in high-load projects and architecture. Translated and adapted by Alexander Makarov, professional Russian Web developer, who is behind RMCreative, a Russian blog dedicated to Web developers, designers and everyone interested in how the Web is built.


Smashing Book #5

Hold on tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? For example, Smashing Book 5, packed with smart responsive design patterns and techniques.

↑ Back to top Tweet itShare on Facebook

Alexander Makarov is a professional Web developer in Russia. He is also the person behind RMCreative, a Russian blog dedicated to Web developers, designers and everyone interested in how the Web is built.

  1. 1

    Solution for Apache and Nginx is much easier and adoptable.

  2. 2

    As publishing this information (the .svn content) without restriction may affect one site or another, it is not correct to say that it is a security flaw for OSS projects. All websites sources and structure are public anyway, since day #1 (see the SVN web frontend for the websites).

    Rasmus also replied to the mail sent to our security list, giving this explanation as well (plus a precision), no reply so far.

  3. 3

    I don’t think I’d consider this a vulnerability. Everyone I know and have ever worked with is aware of the .svn directory and its risk if it is pushed to the server. There’s a reason ‘svn export’ exists and there is a reason that Capistrano recipes quite often make use of it. Yes, it can be a problem if you are not aware of the situation, but it shouldn’t be if you keep yourself familiar and knowledgeable with the technologies you are working with. Nice points on ways to fix the problem for developers who may not be aware of the situation.

  4. 4

    Always use svn export when deploying a site, then this problem doesn’t exist. There is no reason to leave the .svn directories on a live site.

  5. 5

    It’s a feature not a bug. Apache’s default configuration denies access to all dotted files and directories.

  6. 6

    It is OK that you think is exposing sensitive information by serving .svn on couple of ours websites. All this information (and more) is public information, and we try our very best to have _all_ information about the project accessible to anyone who wants to know. We take OSS seriously and do our best to keep everything open.

    I do however not think its OK that you blog about “serious vulnerability” (which is bogus, but thats besides the point) and mentioning the projects – without ever trying to contact the said projects.
    Thats a serious issue, and someone should give you a good bitch slap.

  7. 7

    That’s why you should never use a “checkout” to deploy releases. Use an “export” instead…

  8. 8

    Erm. Every good developer should know or at least be aware of that. That’s why SVN Export exists.

    Am I the only one to think that uploading the .svn folder for EVERY FOLDER in the directory tree of a project is a waste of time and space and thus developers do use the export feature?

  9. 9

    Hannes Magnusson, we’ve contacted all the projects mentioned before posting this.

  10. 10

    Pierre, I completely agree to Rasmus’s reply and it’s mentioned in the post.

  11. 11

    I always presumed this was pretty obvious. This is why we use the export command as opposed to checkout when moving files to our test environment. FTP to live servers is always done from test server but as an extra precaution my FTP client is configured to ignore .svn folders. Simples!

  12. 12

    where’s the vulnerability?

    i’ve re-read this article twice and looking for it.

    Bad developer habits != vulnerability.

  13. 13

    Alexander Makarov, whoopsy. I should have read the entire thing before posting.
    Your intro made it sound like a critical problem for the project :)

  14. 14

    Diz, Bad developer habits == the most dangerous vulnerability I can imagine.

  15. 15

    I don’t agree it’s a vulnerability in the sense of something being overlooked, as the manual is rather explicit about using svn export instead.

    However, thank you for the article. Some developers might not appreciate the danger of files contained with .svn, or worse, erroneously assume that their fellow developers do!

  16. 16

    I like that Smashing Magazine posted this — more security-related info can be helpful, so don’t hesitate and publish it {:

  17. 17

    btw, yes, export is the right way to do it.

    It is only faster to do it as we do it ((r)sync procedures). I don’t know all the latest details of our sync scripts but it was the reason to keep usin co instead of export, afair :).

  18. 18

    That’s not a vulnerability. That’s user stupidity.

  19. 19

    Exactly! As already mentioned there is no reason to upoload the .svn directories…

  20. 20

    i see they blurred out the root folder names after posting them previously…lol so much for vulnerability issue!

  21. 21

    This is not a vulnerability in any way. As a web admin, you should not put any kind of sensible information in any http accessible directory, including .svn/ directories. More over, you should always separate development and production environments, and thus not transfering development files, such as .svn directories, to the production service. If, for any reason, a person does this it could be either because he doesn’t know how SVN works, or because he is not aware that this could pose a security issue, plus he is not using the proper development vs production environment distinction.

  22. 22

    @The Author: Pffbwahaha…. Who do you think you’re teaching something to?

    The whole purpose behind using HTTPS is so that unauthorized clients cannot access your code or SVN metadata — your example using HTTP is hardly relevant. And then only a complete noob would copy-paste their project build folder as opposed to performing an SVN Export for deployment. And as you yourselves said, if it’s an open source project, nobody cares anway.

    I’m amazed that you guys would go to this amount of effort to research an issue that is an accepted/documented part of using SVN. As Steven Haddox commented, “I wouldn’t call this an issue.”

    (SM) As the author points out below, we have not posted the URLs of the affected sites, but they all are really major players. Please follow the original article in Russian to find more “prominent” sites that have this problem.

    You’re trying to generate hype, but you failed. I suggest you get proper technical QA on your articles in future before you publish them, because this load of hot air just makes you look really inept.

  23. 23

    Nick Wiggill, You aren’t right about this is hardly relevant. SM editors have not posted names here but I can assure you they all are really major players.

  24. 24

    I read this in Russian using Google translate and checked some .com websites after that. A lot of websites are still affected! Got full source of classmaters and some info about alistapart!!!

  25. 25

    this is amazing! I go to scan :)))

  26. 26

    I think you guys are missing a very important point of the article. True.. there is no vulnerability in svn itself or open source projects (such as

    BUT for young novice web developers (one of Smashing’s target audience) that only know how to use SVN to “update” and “commit” it could be a huge vulnerability. Say that they work on a project and use svn (which is a good thing) but just FTP all the whiles to the live site, including the .svn files that contain the DB connection strings or perhaps an admin config that could contain FTP info itself.

    As Alexander said “Bad developer habits == the most dangerous vulnerability I can imagine.” I agree and that is what this post is about. For everyone comenting saying “One should just know to use Export” does not solve the root issue of unlearned developers. This article helps to teach them.

    Good article, I’d like to see more.

    As an aside, we often use Springloops to host our SVN, which has a deploy feature to push out SVN updates to your servers. Works great and solves this issue taking the guesswork out.

  27. 27

    Holy %#@3! and )))

  28. 28


  29. 29

    It’s not a security issue, it’s a misuse of SVN. For deployment “svn export” should be used.

    But it’s still good to point people to the problem and show the solution. :)

  30. 30

    Thank you comrade. I shall use this information for good.


↑ Back to top