PostgreSQL users have been put in a potentially sticky situation by a serious security flaw made public this week.

The flaw allows for SQL injection attacks, and affects all versions of PostgreSQL, aside from fixed versions released this week. However, the fix, PostgreSQL developers admit, will break many users' applications.

"Six PostgreSQL programmers worked for four weeks to come up with a method to fix the vulnerability without affecting production applications," said core developer Josh Berkus in documentation published to explain the complex bug. "This was the best we could do - it leaves most users' applications untouched."

Those using Far Eastern multi-byte encodings such as SJIS, BIG5, GBK, GB18030 and UHC, are out of luck, however, and will need to rework their applications for them to work after applying the patch. Specifically, they will need to remove any non-standard string escaping mechanisms, such as the popular "backslash-escape", or at least modify them to use SQL-standard escaping, according to Berkus.

He admitted the modifications would be "painful" for many users.

Since the update affects client functionality, admins will need to install new drivers. Drivers for most programming languages should be available within days, according to Berkus. Binaries for some platforms should already be available from the PostgreSQL download page.

Most at risk are PostgreSQL servers that are both exposed to "untrusted input" and use multi-byte encodings such as UTF-8 or SJIS. "Basically, most open source database users with Web applications," said Berkus. In particular danger are those using Far East encodings and using ad-hoc methods to "escape" strings going into the database, such as regexes, or PHP3's addslashes() and magic_quotes, Berkus said.

"Since these bypass database-specific code for safe handling of strings, many such applications will need to be re-written to become secure," Berkus wrote. "Note that the PHP team deprecated addslashes() and magic_quotes in version 4.0 because of the security risk. Unfortunately, it still appears in a distressing number of freeware PHP applications online."

The bug is fixed in versions 8.1.4, 8.0.8, 7.4.13 and 7.3.15, released this week and available from PostgreSQL's Web site.