Release date: March 30, 2020
About this release
Version 4.12.6 of DRACOON Core Service for on-premises customers fixes several, potentially serious issues in the current LTS release 2019-1. It also includes a security update for Spring Boot that fixes a vulnerability in Apache Tomcat.
The new version 4.12.2 of the DRACOON OAuth component, the new version 1.2.2 of the DRACOON Branding Service, and the new version 5.2.2 of the DRACOON WebDAV Proxys also include the Spring Boot security update mentioned above.
The installation is recommended for all customers who run DRACOON on their own servers.
The installation packages are available on our download portal (download.dracoon.com).
The following problems have been fixed in version 4.12.6 of DRACOON Server:
- With the latest versions of DRACOON for Windows/Mac, users who did not have the "Manage Download Shares" permission in the data room could not save new versions of files in the data room.
- Files uploaded to encrypted data rooms via upload shares in some cases could not be opened because file keys were missing. Non-encrypted data rooms were not affected.
- Deleting many files from the recycle bin (e.g. when emptying the recycle bin) could take a long time.
- When deleting files (moving them to the Recycle Bin), the expiration date of the files, if present, was removed. If a deleted file was later restored from the Recycle Bin, it no longer had an expiration date.
- In rare cases, the S3 migration (after connecting S3 storage to DRACOON in the system settings) might not finish.
- When a file upload to connected S3 storage was interrupted, the internal upload status of the file was not reset.
- Version 4.12.6 of DRACOON Core Service, version 4.12.2 of the DRACOON OAuth component, version 1.2.2 of the DRACOON Branding Service, and version 5.2.2 of the DRACOON WebDAV Proxy contain an update for Spring Boot, which in turn contains the new version 9.0.31 of Apache Tomcat. This fixes the Tomcat vulnerability CVE-2020-1938, which became known as Ghostcat. This vulnerability could not be exploited if the DRACOON server was configured as recommended by DRACOON (thus, if port 8009/tcp was not publicly accessible).