Answer based on comments to the question.
Yes, you are currently vulnerable to the padding oracle attack.
This means they can download things like your config file and decrypt your viewstate and cookies.
Regarding access to the "admin priviledge", maybe. Depends on what is found. For example, if you have a database connection string in the web.config file AND that database server is accessible on the internet then the attacker might just completely bypass the app and go straight to the db. There are certainly numerous factors here that might limit the damage down by exposure of the web.config info but unfortunately a LOT of developers don't know what they are doing. They tend to not think about this.
So, what can you do about this?
First up, keep your servers up to date with their patches. Windows has ways to automate this through auto update. Which I highly recommend for web servers. MS tends to patch things pretty quickly. Further, in over 10 years of letting windows servers patch themselves I have never run into an issue. I wish I could say the same for DB patches, but even those are starting to become things you simply must do.
Second, look at the application itself. Is there anything in the web.config that could lead to compromising the data. Things like references to database servers, passwords to other systems, etc. If so, then I'd suggest immediately after patching you change all of those passwords. For DB access I tend towards ensuring even the application doesn't have direct rights to query tables. But that's a completely separate discussion.
Third, develop a tendency to not trust anything. Not your own servers nor even your own code. This will lead to being a better programmer anyway. If an attacker is able to drop a executable file in your website they could get access to literally everything your web app has access to.
Fourth, expose ONLY what's necessary to the internet. This requires a lot of education and testing to make sure your routers/firewalls/etc are properly configured. Unfortunately developers tend to lower those defenses as soon as it's inconvenient. For example, installing debugging tools on a server or exposing a database to the internet in order to get access to it from home... This goes along with #3 above.
Fifth, research research research. Take the time to learn how things are compromised and what that means. It's a lot easier to code defensively when you know what you are protecting and what you are protecting it against. There is a tremendous amount of bad information out there and knowing how attacks work will make it easier for you to filter it out. A simple example are sites showing how to dynamically build a sql statement. The vast majority of those don't use parameters; and the ones that do completely ignore the idea that the web application itself could be bypassed.
There's more, a lot more, but that's enough to chew on for now.