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?

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

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

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

<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

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

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 Saterenko3, 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 Yandex4, Rambler.ru5, Mail.ru6, Opera.com7, Rbk.ru8, 003.ru9, Bolero.ru10 and habrahabr.ru11. Then the remaining 3000+ Russian websites received their letters. After that, we sent emails to the top .com websites.

Some Numbers

  • 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.


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

The original Russian article12 was written by Anton Isaykin1513 in collaboration with the company 2comrades14 that specializes in Web project analytics, development and support.

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



  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17

↑ Back to topShare on Twitter

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.


Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  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.

  31. 31

    As mentioned several times already, svn export should be used to deploy your websites. Having your repo live on your web server is a dumb idea. Silly developers should learn how to use a tool properly before inflicting themselves on paying customers.

  32. 32

    Forgot to add: If you aren’t using capistrano ( to deploy your sites (yes, even the PHP ones) then you’re doing too much work.

  33. 33

    Nick, everyone can make a mistake. I don’t think major players who were affected are silly.

  34. 34

    Just concider you forgot as well not to put prod. DB password in your files. Here is the flaw !

  35. 35

    This really isn’t a bug, it’s an issue caused by people not knowing the different between exporting and checking out. Okay, maybe SVN’s makers need to do more to bring it to the attention of their users, but at the end of the day if people aren’t using it properly then it’s the user’s fault. Perhaps better documentation is needed here, perhaps the software should emit some kind of warning when checking in to advise users to export instead, but I don’t see any reason why the actual behaviour of the software needs to change.

  36. 36

    Here’s what I used to clean out the .svn directories from one of my websites:

    find . -depth -type d -name .svn -exec rm -rf {} ;

    Needless to say, you’ll want to run that with -print instead of -exec rm -rf {} ; the first time. I haven’t figured out how to get it to prompt for each one without prompting for *every* file inside each .svn folder.

    For a long-term solution, use --exclude=.svn when you rsync your files out (if that is what you use to deploy.)

  37. 37

    This seems to get rediscovered at least once a year. I knew about it in 2006. is one example of prior coverage.

  38. 38

    So.. this really isn’t a vulnerability in SVN, or any other version control system. There are very useful reasons to want to be able to serve revisions over HTTP on any webserver. The problem comes in when idiotic web admins don’t protect sensitive directories. As demonstrated in the article, it is very easy to properly configure the web server. Blame the idiot who stabbed himself, not the knife for being sharp.

  39. 39

    @Ryan Right on! It seem like veteran developers assume that everyone in the world is using best practices all of the time. I, for one, am glad that SM is alerting us to issues such as this.

    I’m a designer and not a developer, but I still need to understand the back-end and related issues. Thanks SM!

  40. 40

    This article is phishing for a story. Retards publish their source directly to the web. They deserve to be hacked.

  41. 41

    Thank you for posting this.

  42. 42

    And to think that this whole big problem could have been adverted if people weren’t dumb enough to have private source code in a public code repository.

  43. 43

    One of the easiest solutions for this is to use a post-commit hook that does the export to webroot. No .svn directories, no FTP uploading and no such vulnerabilities ;)

  44. 44

    I agree with all posts that say that this is not a bug.

    It’s a feature :D

    And if you are an admin for a site which has this feature, it’s time to look at the mirror and ask yourself: Am I really ready to be an admin?

  45. 45

    Look folks, I just read through all the comments and there are three types here:

    “I could care less they should burn in hell [this is not a bug,use export, blah blah]”
    “Look! soso/soso/.svn!!!!! lol ROFL I haz filez”
    And the explanations from the authors.

    The point of this is a public service, YES they might not be the brightest crayon to have let this happen to them. BUT that is the point of this research and study! Help them fix the problem. What’s the point of posting here and telling nobody that they are an idiot?

    The fact remains that there are over 3300 websites that have made a mistake, and these guys are telling them how to quickly cover up their missing clothing!

  46. 46

    just to reiterate what others have said in the comments, it is only a problem when bad practices are in place. you should not be exposing an svn managed folder structure to a public interface at all. any public facing build should be tagged and exported. period.

  47. 47

    If you don’t have acces to your server’s httpd.conf file, you can put this in your .htaccess file (in the parent directory of your .svn folder):

  48. 48

    Oops, sorry, I meant this:

    RewriteEngine On
    RewriteRule ^.svn . [F]
  49. 49

    Rémi, your .htaccess entry only matches the .svn in root, I have this in my .htaccess, which matches all .svn directories

    RewriteEngine On
    RewriteRule ^(.*/)?.svn/ - [F,L]
    ErrorDocument 403 "Access Forbidden"

  50. 50

    Yep, yours is better :)

  51. 51

    That’s why I like git
    btw.. that can be a problem while using svn, great artice!

  52. 52

    Disclaimer: I don’t use subversion. …Color me stupid but I don’t see why anyone would put Subversion (or any other software like it) on their web site. Package up a release or a fix and move it to the server.

  53. 53

    Right, so i feel abit intimidated asking this because i will probably get ripped by some developers. I am a junior developer and quite new to svn, after reading this article i too have the /.svn/entries directory showing on my website (about to change this i might add). I have seen that alot of people here have mentioned about using svn export instead – i didnt even know this existed untill now. So i have just changed to this method, and now i cant svn up updates of my code to show on the live website, do i have to export the whole site everytime i want my changes applied to the live websitesite copy? thanks.

  54. 54

    All of the source code was printed and then burned.”

    seriously, who makes this shit up??

    PRINT the source code…then BURN IT???

    Is SmashingMagazine full of idiots?? perhaps when it comes to security – their own site got hacked recently.. Next up: Leaving the keys in your Lexus may cause your insurance rates to go up.

  55. 55

    I don’t read Smashing Magazine for security information. Especially since the last security related article I read here amounted to “Our WordPress got hacked and we’re not sure how or why”.

    I’ve always found this site to be interesting reading. I’m sure it’s hard to turn down well-written articles, but if they don’t fit the focus of the web site, it would be better for both Smashing and the author if the article was published elsewhere.

  56. 56

    That was not a literal statement. It is called an exaggeration, used to make a point.

  57. 57

    Well I think, this is a problem that really only affect those developers who chucks the whole SVN checkout onto a web accessible location. That’s unfortunately a problem that could happen in many ways not just involving SVN.

    Usually, the SVN repo path are HTTP password AUTH enabled, so people won’t be able to access folders such as /entries anyway? Or maybe i am not following very well?

  58. 58

    It might be an issue with the translation but I really don’t understand this part:
    “All of the source code was printed and then burned.”
    Does that mean that you printed the 100GB+ of data onto paper and then burned it? Or does it mean that you printed the code onto paper and then burned the HDD? Either way, it’s pretty stupid.

  59. 59

    Mark & Bjorn:

    you cannot be serious, right? Right?

  60. 60

    @dram I sure hope not…

    Yes, SM found the guy who wrote this article, made them print out every page of code for every website they found this issue on, and then made them burn everything right after. SM likes to give the environment “the finger” and then publish it in other people’s articles

  61. 61

    Thank you for posting this!

  62. 62

    I’m not sure this is a flaw, but more of an oversight on the part of the system administrators / web developers who are using SVN as a deployment tool instead of as a revision control system.

    Think of it this way. When your working for a client, do you send them all your scratch pads, prototypes and other “working” documents or just the final polished product? You always clean up your work for presentation. You’d never include the .svn directories because you don’t want the clients to have access to your repository – in most cases your repository is private and it wouldn’t do the client any good anyways.

    The exact same mentality should be applied to your deployments too. You don’t want your repository to be public, so why are you putting your revision control files (.svn, CVS control folders, whatever) in the most public place imaginable (the internet)??

    IF your deploying directly from subversion. The real solution is to trim your revision control directories from the deployment.


    find myapplication/path/ -type d -name .svn | xargs rm -rf

    Theres a reason why most enterprise companies have deployment procedures, and why most application developers have a build process that generates a separate distributable file.

  63. 63

    SSPI logins are not exposed by this I presume? You are only revealing the source code but not the logins?

  64. 64

    Coming next week.. Common code mistakes of leading .com developers

  65. 65

    Visual SVN server doesn’t show the information (this server is based on Apache).
    So, it works for us well.

  66. 66

    @dram and the aptly monikered “Disposable_Hero”

    who cares if he was ‘exaggerating’ or not?
    frankly, (and no exaggeration here) the article was bullshit as valid and as useful as

    1. Dont run with scissors while trimming the hair on your Adam’s apple.

    2. If you drop off a hooker and she ‘cant make change for a $50 bill” for a $30 blow job, DO NOT wait there at 3am till she finds an ‘open store’, DO NOT leave the keys in your car and the engine running while you go get your $20 and NEVER argue with the big, gold toothed man towering over both of you.

    I respect your Mom and always follow her advice (maybe I should ask HER for security and configuration management advice!)

↑ Back to top