A weak ACLs implementation in Emsisoft Anti-Malware prone to vulnerable with ACLs bypass. Further investigation found the driver lack of security checks where the FILE_DEVICE_SECURE_OPEN flag is not set. The security issue has been reported to vendor (Emsisoft) and acknowledge.
Emsisoft Anti-Malware prone to vulnerable with ACLs bypass. The vulnerability found to be part of the main driver EPP.sys. It is quite trivial to spot the issue by using DeviceTree tool. We extract the driver using the tool and spot the interpreted device characteristics empty, which is missing FILE_DEVICE_SECURE_OPEN. This means the driver didn’t protect well that could allow to impersonate or create object to bypass the ACL. Screenshot below shows the driver prone to lack of ACL protection: 
According to Microsoft (as part of Windows security model), it is required to perform a security checks in the driver and set FILE_DEVICE_SECURE_OPEN. If developer did not set FILE_DEVICE_SECURE_OPEN, the driver are responsible for ensuring the security of its namespace. I listed important notes from Microsoft when creating / implementing a driver:
1. The driver checks any ACLs for the file name in its DispatchCreate routine. (Even in this case the driver should set the FILE_DEVICE_SECURE_OPEN characteristic unless opens into the device's namespace can have weaker security settings than the device object.).
2. The operating system kernel treats every driver, in effect, as a file system with its own namespace. Consequently, when a caller attempts to create an object in the device namespace, the I/O Manager checks that the process has traversal rights to the directories in the path.
3. With WDM drivers, the I/O Manager does not perform security checks against the namespace, unless the Device Object has been created specifying FILE_DEVICE_SECURE_OPEN.
4. For WDF drivers, the FILE_DEVICE_SECURE_OPEN flag is always set, so that there will be a check of the device's security descriptor before allowing an application to access any names within the device's namespace.
In this case, the flag is not set with ACL and this only applied only to the device, not any ‘file’ inside it. Any open as non-admin of \Device\EPP will fail, but if there’s any open for \Device\EPP\bypass, it will succeed. Because the FILE_DEVICE_SECURE_OPEN flag is not set, the IO Manager assumes this is a file system driver, and as such, will implement its own ACLs on files and directories inside the device. A proof-of-concept can be crafted by creating a simple
CreateFile("\\\\.\\EPP\\ACLBypass", 0, 0, 0, 0, 0, 0)
Example of the successful ACLs bypass: 
Disclosure timeline
2018-09-14 - Reported to Emsisoft
2018-09-19 - Vendor ack
2018-09-20 - Full report provided (reported several issues)
2018-10-04 - Vendor update and ack only on driver issue (the rest not eligible)
2018-11-04 - Follow up with vendor on fix issue. No ETA on release date.
2018-12-04 - Follow up with vendor on fix issue. No ETA on release date.
2019-01-04 - Follow up with vendor on fix issue. Vendor ack and they released new version and ship the fix, https://blog.emsisoft.com/en/32517/new-in-2018-12-safe-web-browsing-with-emsisoft-browser-security/
References
https://docs.microsoft.com/en-us/windows-hardware/drivers/driversecurity/windows-security-model
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/specifying-exclusive-access-to-device-objects
https://ioactive.com/wp-content/uploads/2018/05/IOActive_Advisory_F-Secure-1.pdf
https://d3gpjj9d20n0p3.cloudfront.net/fortiguard/research/The%20Dawn%20of%20AV%20Self-Protection.pdf