Adminer patches an RCE hiding behind a UTF-8 byte-order mark
A regex filter meant to block dangerous SQLite commands in Adminer missed statements prefixed with a UTF-8 BOM, letting an authenticated user write PHP straight to a web-accessible directory. Fixed in 6.1.1.
Adminer, the single-file PHP database manager a lot of developers drop onto a server instead of installing phpMyAdmin, patched a remote code execution bug on 25 September. It’s fixed in 6.1.1; every version up to 6.1.0 is affected.
Adminer blocks dangerous SQLite operations like ATTACH and VACUUM INTO with a regex filter, precisely so a logged-in user can’t use them to write a database file into a web-accessible directory. The filter never accounted for a UTF-8 byte-order mark at the start of a statement: SQLite strips the BOM before executing, but Adminer’s filter doesn’t recognise a statement starting with it as the command it is. Prefix ATTACH or VACUUM INTO with EF BB BF and the restriction just doesn’t fire. From there, an authenticated user with SQLite access can write a .php file into a web root and get code execution as the web server account.
Why it matters: Adminer gets deployed on production boxes and then forgotten about, often reachable from the internet with nothing but its own login in front of it. If you or a client has one sitting around, that login is the only thing standing between “someone has a database account” and “someone has a shell.” Update to 6.1.1.
The caveat: this needs an authenticated session with access to a SQLite connection, it isn’t pre-auth. But Adminer accounts are often shared or weakly protected precisely because people treat the tool as low-stakes.