Magento 2.0.6 Security Update

Magento no longer permits an unauthenticated user to remotely execute code on the server through APIs. Previously, an unauthenticated user could remotely execute PHP code on the server using either REST or SOAP APIs. (These APIs are enabled by default in most installations.)

The Magento installation code is no longer accessible once the installation process has completed. Previously, an unauthenticated user or user with minimal permissions could execute PHP code on the server because the installation process would leave the /app/etc directory writeable, and many administrators would not change the permissions on this directory after installation. (During installation, the system requires the /app/etc directory to be writeable.)

Magento no longer allows authenticated customers to change other customers' account information using either SOAP or REST calls.  Magento  now confirms that the ID of the customer whose account is being edited matches the authentication token in use. Previously, a malicious user could hijack a customer account by logging in as an authenticated user, then editing the account of any other user.  (The SOAP and REST APIs are enabled by default in most installations.)

Several parameters in the Authorize.net payment module are vulnerable to reflected Cross-Site Scripting (XSS) attacks. Existing protection against such malicious parameters is not enough to stop all types of attacks.

Anonymous users can no longer retrieve the private data of registered customers. To prevent malicious attacks of this type, the quote_id_mask table of the Quote API no longer includes a cart_id_mask value.

Only a registered customer can assign a guest cart to himself. Previously, an anonymous user could modify the state  (that is, set an active quote) of a registered customer.

Application error messages no longer include the path to the file where the error occurred. Previously, when an unhandled exception occurred,  Magento would display an error message that could disclose sensitive information such as the location of the file that produced the unhandled exception. A malicious user could use this information to launch attacks against the application.