This is a bug fix, security hardening, and maintenance release. Two of the bugs affect the integrity of your backups and your profile settings; please read the first two sections below. The security changes tighten access control and anti-CSRF protection across the backend. The security issues addressed are low severity and we have no indication any of them were exploited; we are releasing those changes as a precaution and as defence-in-depth.
If your site uses the PDO MySQL or the PostgreSQL database driver, every backup taken with an earlier version silently truncated the values of DOUBLE columns to 14 significant digits instead of the up to 17 digits such a column can hold. For example, 0.12345678901234568 was written to the backup as 0.12345678901235. This is now fixed; dumps render floating point values at full round-trip precision.
Sites using the standard MySQLi driver — the great majority of Joomla! sites — were never affected. If you were affected and you keep backups you may one day need to restore, we recommend taking a fresh backup with this version. Note that the loss of precision only ever affected the backup archive; the data in your live database was never touched.
When a backup was uploaded to Box, Dropbox, Google Drive, or OneDrive and the access token happened to need refreshing during the upload, the refreshed token was saved into whichever profile was currently selected in the backend interface, rather than the profile the backup actually belonged to. If those two profiles were different, the selected profile's remote storage configuration was overwritten with the uploading profile's settings.
This is now fixed. If you use several backup profiles with cloud storage — particularly if you have noticed a profile mysteriously pointing at the wrong account, folder, or storage provider — please review each profile's Configuration page and correct anything that looks wrong.
Box, Dropbox, Google Drive, and OneDrive keep two credentials per profile: a short-lived access token, and a refresh token used to mint a new one. Since version 10.3.6 these engines refreshed the access token ahead of its recorded expiry, which fixed uploads failing when a token lapsed mid-backup. However, a profile which had somehow lost its access token but kept a future expiry date would never refresh: the engine believed the token it no longer had was still good, sent an empty credential, and the provider rejected it with an error which said nothing about the real cause. On Google Drive this showed up as “Method doesn't allow unregistered callers” when fetching an archive back to your server.
A missing access token now always triggers a refresh, so such a profile heals itself on the next attempt without you having to reconnect your account. Two ways a profile could reach that state are also fixed: Google Drive and OneDrive used to record a rejected token refresh as if it had succeeded, storing a blank token (see below), and the cross-profile problem described above could overwrite a profile's credentials with another's.
A few backend pages did not consistently enforce the Akeeba Backup privilege they were meant to require. Most notably, the Schedule page — which displays the front-end and JSON API secrets — is now restricted to users who are allowed to edit the component's Options. These checks only ever applied to users who already had backend access to Akeeba Backup, but they were stricter in intent than in practice, so we have brought the enforcement in line with the design.
A number of backend actions now require an anti-CSRF token before they will run: the backup filter, exclusion and inclusion editors; remote archive delete and download; the Transfer Wizard, Upload and S3 import flows; the FTP/SFTP connection tests; the Configuration Wizard; and a handful of minor control panel actions.
To put the risk in perspective: every one of these actions was already restricted to a logged-in Akeeba Backup administrator, and triggering one would have required tricking that administrator into visiting a malicious web page while logged in. Most of the actions are submitted in a way that current web browsers' default cookie policy already blocked from cross-site abuse. Even in the worst case the impact was limited to tampering with or deleting backups — there was no path to running code, reading your data, or taking over an account. We have added the tokens because requiring them is simply the correct behaviour, regardless of the browser-side protections.
The backup page deserves a special mention: long-running backups now carry a dedicated per-backup token, so a backup can no longer be interrupted by the global session token changing midway through.
Several remote storage engines used to fail in ways that told you nothing useful. Box now tells you that your authorisation has lapsed and needs renewing, instead of reporting a bare HTTP 401. Dropbox now explains that your Download ID is missing or no longer valid, rather than failing obscurely. Google Drive and OneDrive now report a rejected token refresh — and, importantly, no longer treat it as a success and store the resulting blank credential. WebDAV now reports the actual reason an upload failed, both on screen and in the backup log.