Gallery 2.1.2 Security Fix Release

Gallery 2.1.2 is now available for download. This release adds no new features. It fixes a minor information leakage in Gallery 2.1 and 2.1.1a and a major session ID disclosure in all versions prior to Gallery 2.1. Note that these flaws only affect installations where Gallery's storage folder is accessible directly from the web, which we strongly discourage during the installation process.

We recommend that you upgrade to version 2.1.2 as soon as possible. Please follow our upgrading instructions and download and install the latest release.

If you prefer to apply this security patch without all changes that are part of prior upgrades since your current Gallery version, you can just add a .htaccess file in your Gallery storage folder with the following contents:

Order allow,deny
Deny from all

Alternatively (even better): Move your storage folder to a path outside the web-root.

We would like to thank Ingus Krumins for reporting this issue and working with us on an appropriate solution.

schultmc's picture

Version 2.1.2-1 of the Debian gallery2 package was uploaded to Debian unstable in the afternoon (EDT) of Thursday, August 17, 2006 and will be available after the archive push in the afternoon (EDT) of Friday, August 18, 2006.

Debian gallery package maintainer

lwclam's picture

Thanks for the update! ^_^

Can I ask when will Gallery 2.2 release?
According to the Roadmap (, it should be released Aug 1.
Any progress?

mindless's picture

Look for check marks on the roadmap to see what is completed.

I am extremely upset by this upgrade... It caused some very unexpected problems on my site, and the handful of client sites I manage. These errors occurred because of the way I installed G2. Can someone please discuss the best practices, and pros and cons with me? (Please note that I am not angry at the developers (you've got a wonderful program here!) but rather just frustrated that this caught me by suprise and caused problems for me and my clients.)

I have my G2 data folder installed inside the web root. My site (and clients' sites) run a combination of Wordpress and Gallery2. I wanted images used in Gallery to quickly and easily be accessible for use in Wordpress posts. I especially didn't want to use more storage, more bandwidth, and the great hassle of uploading images for use in Wordpress that have already been uploaded in Gallery. Thus I installed G2's data folder into the made wp-content Wordpress folder.

Upon upgrading to 2.1.2, suddenly images everywhere were broken. I narrowed this down to the .htaccess folder inside the g2data folder... I've since deleted that .htaccess file and gotten things back up and running.

So here are my questions...

First, what's so horribly wrong about having one's g2data folder in the web-root?

Second, if this is so bad, why can't you have an .htaccess file to deny access to g2data, but another .htcaccess file within the g2data/albums directory to allow serving of those image files? (There's no security flaw in serving images).

Finally, since we're talking about serving images inside the g2data folder, I proposed a while back an excellent way to provide hotlink protection, yet still allow images to be served. (See this thread). Mindless wrote that he added it to SVN, but I still don't understand quite what that means... Does this mean it will be in gallery 2.1? The reason I ask here, is that this technique, involving hotlink protection, seems to be a part of what we're talking about in protecting the g2data folder.

If the developers could please address this issue, I would be extremely appreciative. I want to set things up properly, and not get killed when I perform an update to Gallery. At the same time, I'd like to have easy access to all my G2 images via Wordpress plugins that browse the directories.

I've posted this same information in this thread on the forums, as I thought a discussion might be better placed there. Please leave your responses there too.


Edit:The user's problem is that he was directly exploiting the weakness that we resolved in the 2.1.2 release. In the forum thread we suggested alternative ways for him to defeat the security. --Bharat

Please see my answer in your dedicated thread. No need to discuss it in 2 places. Thanks.

Great update guys and girls! Im feeling release 2.2 is on its way with a little delay. But no problem, it will be beter then expected. I Hope ;) Also feedback is great of this upgrade, see above.

maximale hypotheek

Upgrading 2.1.1a to 2.1.2 scrambles Chinese characters. :( Aside from the security fix, are there any other changes?

Edit: this issue appears to have been caused by an O/S upgrade, not by the 2.1.2 upgrade. 2.1.2's cache caused the user not to notice the problem right away after the O/S upgrade --Bharat

bharat's picture

That's strange. The patch didn't change anything fundamental. Can you open a forum topic with more information so that we can figure out what's going on? Thanks.

Edit: this issue appears to have been caused by an O/S upgrade, not by the 2.1.2 upgrade. 2.1.2's cache caused the user not to notice the problem right away after the O/S upgrade --Bharat

Could it be a good idea to let the upgrade script clear the database cache so that such charset problems can be easily noticed?

See for details of the problem that I encountered. Strictly speaking, it's caused by the fact that gallery's upgrade script cannot properly deal with such an upgrade sequence, isn't it?

mindless's picture

Yup, good idea.. the upgrader has always done that :)

Oh, yup, you're right! I am a little confused when writing my previous post. I upgraded the OS and MySQL when I was on 2.1.1a. When upgrading to 2.1.2, the upgrader cleared the database cache, and made me aware of the charset problem.