Update 8/9/2016: Excel Workbooks may not open after installing MS16-088

UPDATE: This issue is resolved, scroll to the bottom to see the Resolution Section in todays update.


The Excel team has made a change in the behavior of certain file types to increase security. This change came in the security updates KB3115262, KB3170008, and KB3115322. Previously, when you tried to open an HTML or XLA file with an .XLS file extension from an untrusted location, Excel would warn about the mismatch between the file extension and content, but would still open the workbook without Protected View security. After the security updates Excel no longer will open the workbook because these files are not compatible with Protected View and there is no warning or other indication it was not opened. We apologize that Excel is showing a blank screen instead of a more helpful error message with information about what to do next.


We have a few options for workarounds. These are in order from safest to riskiest. While some people in the forums have suggested rolling back the security patch, we do not recommend that option as it can leave you open to other current and future threats.

  1. The best option is to move away from using HTML wrapped as .xls. If you use native formats (e.g. xls, xlsx, xlsb) which will open in protected view when untrusted, this will provide some level of protection from the documents being opened.
  2. You can unblock access for individual files you know are safe. To do this:
    1. Right click on the file and choose Properties
    2. On the General tab, click Unblock
    3. Click OK
  3. You can make use of existing Trusted Locations capabilities in Excel 2010, 2013, and 2016 via File -> options -> Trust Center -> Trust Center Settings -> Trusted Locations.
    1. You can save the web html file to a trusted location on the local machine (Excel comes with a set of default trust locations). If you do not see the local folder location you trust for these files, then press “Add new location…” button and add it in the Trusted Location dialog. If the HTML document is in a trusted location the KB fix is not applied (e.g. the unsafe HTML file is not blocked).
    2. This approach may unblock you, but it carries some risk as files of any file type in Trusted Locations are fully trusted. If an attacker can drop files into the trusted location they can easily exploit users who open such documents. Be especially cautious when specifying a custom folder as a trusted location.


Update 7/28/2016

Update: Our dev team is working on options to preserve security and assist customers with their workflow. Currently we do not have any further workarounds.

Additional background: The security update changed how Excel handles documents that are opened from untrusted locations (such the Internet zone) which are not supported in Protected View, such as HTML/XML/XLA files. Opening them without Protected View has led to a security vulnerability, and therefore files open from such locations are now blocked.  We realize this breaks compatibility with some existing solutions, and are working on getting these file types supported with Protected View.  Until that happens, users will need to manually trust the file before they open them in Excel, as demonstrated in one of the workaround suggestions.  Excel can still open these files without an issue if they are trusted. 

We strongly recommend against removing the security update. It will leave your systems vulnerable. More information is located here: https://technet.microsoft.com/library/security/MS16-088?f=255&MSPPError=-2147217396. Specifically, the section regarding "Microsoft Office Security Feature Bypass Vulnerability – CVE-2016-3279".

Additional information on implementing workaround options, by product version:

Office 2016

Here is information on Office Trusted Locations
and information on Protected View settings

Office 2013

Here is information on Office Trusted Locations
and information on Protected View settings

 Office 2010

Here is information on Office Trusted Locations
and information on Protected View settings

Update 8/9/2016


Install the update for your version of Office.

  • Office 365 subscription (Click-to-Run)—install the latest updates (this includes, Current Channel, First Release Deferred Channel and Deferred Channel)
  • Installer version (MSI)—To get the fix today, use the links in the KB for your version of Office to download the update from the Download Center. The updates will also publish to Windows Update/WSUS service next week where they will be updated automatically based on the Windows Update settings.


    Comments (13)
    1. James Auman says:

      Is it possible to set our local web server as a trusted location in Office?

    2. Paddy says:

      Any updates on the “more permanent solution”?

    3. John 75 says:

      We continue to hope that the current answer is just a temporary workaround and is not the actual long term answer.

      My response to this is:
      Option 1 – Not a (timely enough) option because third party code is involved.
      Option 2 – Works but is tedious and not practical. Users are balking when we tell them to do this. Users tell us, “Excel is broken! Fix it!”
      Option 3 – Simply doesn’t work as advertised. We have sent a PSR to Microsoft that demonstrates this.

      Users are seeing this Security Fix as introducing a new bug to Excel: when attempting to load certain Excel files downloaded from the Internet, Excel opens an empty window with no error message. Many less savvy users do not know how to unblock an Excel file. Some users process many of these types of Excel files a day and will be extremely annoyed if they must unblock every single one.

      Bottom line is users see Excel in its current state as broken and are asking us to fix it. We provide them with the three options that Microsoft has suggested. Options 1 and 2 are NOT appealing because they are either not timely enough or impractical. Option 3 would be great if it actually worked consistently.

      Users just want Excel in the state that it was prior to installing these Security Patches – when functionality actually worked as expected.

      At this point, we have no other choice but to leave KB3115322, KB3115262, & KB3115272 unapproved and hope for an actual hotfix that will restore prior functionality.

      P.S. Microsoft, there should be “Known issues” posted in the above three KB articles. As of 7/29/16 7AM EST, there still are none posted.

    4. Andrei R says:

      Hello and sorry to disturb you. I represent a software company in Romania and currently we are facing an issue regarding this updates you ve mentioned here. I didn’t find an email to send you this issues so I’m posting it here, hoping to receive an answer from you or a possible stable solution.

      We have a couple of web applications written in Java (Struts and JSP) and they are generating most of the reports in a form of a HTML table. The user has an option to select which kind of output he wants to see (between Web page / Ms Word / MS Excel) and after we execute some SQL queries the final result in shown in a JSP page which contains plain HTML , tags…..
      The HTML table is the same for all 3 final pages (Web/Word/Excel) and is included using a line.
      The only thing that differs in those 3 final pages is the page directive which tells the browser how to open the respective file

      1 – for normal HTML (generated by JSP) in order to show the result in browser

      2 – for opening the final page in Ms Word ( WHICH STILL WORKS FINE )


      3 – for opening the final page in Ms Excel ( WHICH DOESN’T WORK AFTER YOUR UPGRADES, IT SHOWS A BLANK SCREEN )

      From your list of possible workarounds we couldn’t find one to work in all situations
      1 – Including Windows Downloads folder to Excel “Trusted Locations” is not an option because some user choose from the popup browser the Open.. option instead of the Save in which case the Excel file is downloaded to Temp folder and we don’t want to put that folder to the “Trusted Location”…. The same thing does exclude the Unblock file option
      2 – Also disabling those security updates KB3115262, KB3170008, and KB3115322 does not look like a valid workaround…

      Unfortunatelly THE ONLY VALID WORKAROUND we have found was to downgrade to Excel 2007 or even 2003. We don’t think that moving backwards is the best option, not for us and also not for Microsoft, but until now it’s the only solution we have found and it is working on every client facing this new problem.

      Please help us to find a stable solution, maybe you can put back the error message which was asking the user if he wants to open the file even if it is in a different format not-familiar to Excel and which was fine until those upgrades were installed.

      Thank you for your time

    5. Ryan says:

      Note that this also affects XLAM add-ins, which are not specifically identified above. This post contains very important information that users require to use Excel add-ins, and the workarounds described here should be more prominently featured in the general instructions for installing/loading add-ins until they are no longer necessary.

    6. Greg says:

      The option #3 workaround is not working. Here is what you said in this workaround:
      You can make use of existing Trusted Locations capabilities in Excel 2010, 2013, and 2016 via File -> options -> Trust Center -> Trust Center Settings -> Trusted Locations.

      You can save the web html file to a trusted location on the local machine (Excel comes with a set of default trust locations). If you do not see the local folder location you trust for these files, then press “Add new location…” button and add it in the Trusted Location dialog. If the HTML document is in a trusted location the KB fix is not applied (e.g. the unsafe HTML file is not blocked).

      I followed these instructions for setting up a new trusted location, However, the HTML files in this location are still blocked. Is there something else that needs to be done, which is not stated in your instructions?

    7. Robbie Gerling says:

      How can we uninstall these updates? They’re not listed in the Installed Updates window on any machine that I’ve seen affected in my organization – even through a powershell window using WMIC to manually uninstall this specific KB… (3115262/3115272)

    8. Dorian says:

      How can i code a solution when i export my excel document who is in html like this:
      header(‘Content-Encoding: UTF-8’);
      header(“Expires: 0”);
      header(“Cache-Control: must-revalidate, post-check=0, pre-check=0”);
      header(“Content-disposition: attachment; filename=myfile.xls”);
      header(“Pragma: no-cache”);
      We must write the file with no html :(?

    9. Ashwin Rayaprolu says:

      There is an open source code to convert HTML to Excel (xls 2003 format). You can install that and embed that service and improve on it if required as its opensource.


    10. Ab Dessouki says:

      This has been causing some serious conflicts with some web-based applications.

      Thank you very much.
      Ab Dessouki
      System Engineer | Microsoft Technologies

    11. Greg says:

      Thanks for the Update 8/9/2016 in this article. I downloaded the fix, and Excel now opens up normally for HTML files with .XLS file extensions.

    12. Dory Owen says:

      A related issue?
      We don’t permanently load .xlam files as Add-Ins. They are opened as needed by clicking a button on custom toolbar.
      This has worked well for years until this week when ProPlus Version 1701 7766.2092 was pushed site-wide.
      Toolbar is created upon opening .xlam file. That’s good.
      But when user closes all workbooks the newly created toolbar immediately disappears.
      So user’s method of re-opening is also gone. No buttons. 🙁
      Putting .xlam file in Trusted Location does not fix this.
      Only manually installing the Add-In via File…Options…Add-Ins…Browse…checkbox, etc. will allow toolbar to stay in place after closing Excel. But that means loading .xlam in memory every time user is in Excel (not needed) and I have to either train users to manually install Add-In or change my deployment to automate Add-In install. As a dev I prefer having persistent toolbars but not persistent .xlam files that all load, all the time.
      Experimenting shows that as long as the toolbar is created while the .xlam is selected as an Enabled Add-In, the toolbar persists.
      So although possible to enable the add-in, create the toolbar, then disable the add-in…its not an optimal solution.

      Any guidance would be appreciated.

    Comments are closed.

    Skip to main content