Kaseya Community

Kaseya VSA Product Vulnerability

  • I had a few questions about the email notification that was sent toaday about the VSA vulnerability.

    Is this patch automatically applied when hotfixes are run in version 6.3?

    What is the best way to verify that it is installed in version 6.3?

    Does the agent software need to be updated on endpoints in 6.3?

    Thank you,

  • For 6.3 the patch is applied with hotfixes - check hotfix is at level 8813 to verify it is installed

    There is no requirement to upgrade the agents for this issue.


  • Hi eperson,

    Question #1 - Yes. The patch will be applied to your 6.3 server when hotfixes are run.

    Question #2 - Check Hotfix History on the System -> Configure page. If you see IP-119 has been applieed, you have the fix.

    Question #3 - No, your agents do not need to be updated.

  • Hello Kai

    This email is genuine and sent by Kaseya. Please use the support system for any queries in order that we may address concerns directly.

    Alan Davis, Kaseya

  • Hi Kai

    Yes, that's a legit communication. See https://helpdesk.kaseya.com/entries/45223063 for official statement and https://helpdesk.kaseya.com/entries/46371906 for further instructions


    Amado Hidalgo

    [edited by: amado.hidalgo at 2:01 PM (GMT -7) on Mar 24, 2014]
  • Hello!

    We just received a "Action Required - Kaseya VSA Product Vulnerability" E-Mail.

    We can not found any information that this E-Mail is correct and really from kaseya. Did anyone get this mail too? Any official statement from kaseya?


  • If we were already running do we have to re-apply the update and Schema again? As of this writing, the release notes for do not list any security fixes.

    Would a two form factor authentication add-on have prevented this attack?

    When was the attack first discovered?


  • Is this valid? The URL's don't seem to go to a Kaseya Server.

  • Mark Combs's announcement about the "Kaseya VSA Product Vulnerability" indicated that an "application vulnerability was exploited to compromise..." the various support accounts used by Kaseya staff to remotely administer our VSA servers. 

    I hate to ask the obvious question, but doesn't this indicate that all of these accounts shared the same password?  After all, the support accounts are "master" administrator accounts just like ours, they're stored in the same dbo.administrators table, adminType=2, just like ours.  If there had been an application-level vulnerability, it would have affected all of our user accounts, not just the Kaseya support accounts. 

    My servers are already patched, and I'm not interested in restoring a backup just to compare password hashes with other Kaseya customers, but I would really like an answer to this.  I would be very happy to learn the full explanation of the "application vulnerability" that compromised support accounts and not our own accounts.  I would be very unhappy to learn that Kaseya simply used the same password (or handful of passwords) over and over again. 


  • Hi

    Yes, those are valid URL's in our Helpdesk. If you have any further questions, please feel free to log a ticket with the instructions described in those articles.

    Thank you

  • Bump to Brian's question - we're on, I don't see anything about the security fix with that release.

  • Bill, from our release notes for (help.kaseya.com/.../index.asp):

    Limit capabilities of video streaming and update security. (IP-102)

  • One question. Why is it that the patch was released on the 17th yet we are only being alerted to this 8 days later?

  • Hi all,

    How long?

    how did you find the problem?

    A report with the following feat

    Kaseya 6.3 Suffers from an Arbitrary File Upload vulnerability That can be leveraged to gain remote code

    execution on the Kaseya server. The code in this way Executed Will run with a local IUSR account's privileges.

    The vulnerability Lies Within the / SystemTab / UploadImage.asp file. This constructs a file object file on disk using user input, without first checking if the user is authenticated or if input is valid. The implementation preserves the file name and extension of the upload, and Allows an attacker to traverse from the default destination directory.

    Directory traversal is not Necessary to gain code execution HOWEVER, as the default path Lies Within the

    Application's web-root.

  • Rom,

    That particular vulnerability was disclosed to us and quickly patched in October of 2013.