The link you about the bug you posted above is really outdate. But anyway we have indeed a serious Zenphoto security hole here, it is strange that these links even work...

I just checked my database on the Zenpage site and if using this link it really adds to the database. Now we need to find out why it does that. I have opened a top priority ticket for this issue. Thanks for the help so far.

Seems like it's just found a string that gets ignored by the PHP album filters, but not by the database. So it's creating records for all these albums even though they do not exist.

It's not SQL-injection per se as nothing malicious is being inserted (this is normal Zenphoto operation, but with a bug that allows more "albums" to be created in the database), but it's still a problem due to the large amounts of data that take up space, etc.

We just need to improve the filtering code to handle cases like this. It may be that it's simply ignoring UTF-16 characters in the PHP string but passing them on to the database. Could be anything, but with these test cases it shouldn't be too hard to filter out.

What I do not understand here is how it is getting past the filesystem check. Seems that file-exixts() returns true for this string. BTW, the URL gets rejected by my server and returns a 500 error.

We have figured out how to prevent this. Fix is in tonight's nightly build. You will have to clean out the database manually, though.

Thanks to all