Patch Thursday! Handling a new vulnerability

David te Kloese

Earlier today we became aware of a vulnerability in Kentico which allowed any site visitor to view a page they shouldn't be able to see. To protect unpatched installations I wont go into detail about this specific vulnerability, but more what to do when you come across such problems.


First you'll have to find out if a vulnerability forms a problem for one of your projects. A SQL-injection in a Kentico Webpart you know you never use is not an immediate threat. Of course when it's not reachable by anyone. Unfortunately in this case it involved a page included in basic Kentico Installation.

It's also important to know how many of your projects could be at risk and what would be the impact of one being targeted with this vulnerability. Best case they could see unimportant information, worst case they could destroy your site or steal confidential/personal data.


Do you need to take immediate action or is there time to create and test a solid solution or get a hotfix via Kentico Support. This will probably depend heavily on the answers given at the impact questions. But when its friday 18:00 and half your colleagues are drunk enjoying their weekend you might have to act quickly.


This one and most other bugs are of course fixed by Kentico before you can say "Trees for bugs" so if you apply the latest hotfix you'll be fine. But usually a hotfix doesn't just fix a thing or two. As applying a hotfix would mean retesting the whole site it isn't always the best option.

In our case it was a serious vulnerability inflicting 95% of our sites and could do serious harm if being misused. So I created a quick fix altering this particular Kentico Page and in the "Page_Init()" I added a redirect if the current user wasn't Authenticated.

   if (!CMSContext.IsAuthenticated())

If needed you could of course also check for Editors, Administrators of even specific roles:

   if (CMSContext.CurrentUser.IsEditor)
   if (CMSContext.CurrentUser.IsGlobalAdministrator)
   if (CMSContext.CurrentUser.IsInRole("roleName", "SiteName")

It's also wise to log any attempt into the Kentico Eventlog so you know if this is actively being misused. Finally let Kentico handle the request via a handy redirect function in the CMSPage class called RedirectToAccessDenied():

   this.RedirectToAccessDenied("Access denied!");

The complete code looked somewhat like this:

protected void Page_Init(object sender, EventArgs e)
   // Vulnerability fix
   if (!CMSContext.IsAuthenticated())
         "event code",

      // redirect to acces denied
      this.RedirectToAccessDenied("Access denied!");

 Keep in mind

When applying any fix to older Kentico Installations (we needed to even patch a Kentico 4 installation), you might not have all the methods available.


I hope this helps someone and if you have any questions about this specific vulnerability send me a message or your Kentico contact.