Focus on getvera vulnerabilities and metrics.
Last updated: 08 Mar 2025, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with getvera. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total getvera CVEs: 14
Earliest CVE date: 17 Jun 2019, 17:15 UTC
Latest CVE date: 23 Aug 2019, 04:15 UTC
Latest CVE reference: CVE-2019-15498
30-day Count (Rolling): 0
365-day Count (Rolling): 0
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 7.03
Max CVSS: 10.0
Critical CVEs (≥9): 7
| Range | Count |
|---|---|
| 0.0-3.9 | 1 |
| 4.0-6.9 | 6 |
| 7.0-8.9 | 0 |
| 9.0-10.0 | 7 |
These are the five CVEs with the highest CVSS scores for getvera, sorted by severity first and recency.
cgi-bin/cmh/webcam.sh in Vera Edge Home Controller 1.7.4452 allows remote unauthenticated users to execute arbitrary OS commands via --output argument injection in the username parameter to /cgi-bin/cmh/webcam.sh.
LuaUPnP in Vera Edge Home Controller 1.7.4452 allows remote unauthenticated users to execute arbitrary OS commands via the code parameter to /port_3480/data_request because the "No unsafe lua allowed" code block is skipped.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "request_image" as one of the service actions for a normal user to retrieve an image from a camera that is controlled by the controller. It seems that the "res" (resolution) parameter passed in the query string is not sanitized and is stored on the stack which allows an attacker to overflow the buffer. The function "LU::Generic_IP_Camera_Manager::REQ_Image" is activated when the lu_request_image is passed as the "id" parameter in the query string. This function then calls "LU::Generic_IP_Camera_Manager::GetUrlFromArguments". This function retrieves all the parameters passed in the query string including "res" and then uses the value passed in it to fill up buffer using the sprintf function. However, the function in this case lacks a simple length check and as a result an attacker who is able to send more than 184 characters can easily overflow the values stored on the stack including the $RA value and thus execute code on the device.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "request_image" as one of the service actions for a normal user to retrieve an image from a camera that is controlled by the controller. It seems that the "URL" parameter passed in the query string is not sanitized and is stored on the stack which allows an attacker to overflow the buffer. The function "LU::Generic_IP_Camera_Manager::REQ_Image" is activated when the lu_request_image is passed as the "id" parameter in query string. This function then calls "LU::Generic_IP_Camera_Manager::GetUrlFromArguments" and passes a "pointer" to the function where it will be allowed to store the value from the URL parameter. This pointer is passed as the second parameter $a2 to the function "LU::Generic_IP_Camera_Manager::GetUrlFromArguments". However, neither the callee or the caller in this case performs a simple length check and as a result an attacker who is able to send more than 1336 characters can easily overflow the values stored on the stack including the $RA value and thus execute code on the device.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a shell script called connect.sh which is supposed to return a specific cookie for the user when the user is authenticated to https://home.getvera.com. One of the parameters retrieved by this script is "RedirectURL". However, the application lacks strict input validation of this parameter and this allows an attacker to execute the client-side code on this application.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device allows a user to install applications written in the Lua programming language. Also the interface allows any user to write his/her application in the Lua language. However, this functionality is not protected by authentication and this allows an attacker to run arbitrary Lua code on the device. The POST request is forwarded to LuaUPNP daemon on the device. This binary handles the received Lua code in the function "LU::JobHandler_LuaUPnP::RunLua(LU::JobHandler_LuaUPnP *__hidden this, LU::UPnPActionWrapper *)". The value in the "code" parameter is then passed to the function "LU::LuaInterface::RunCode(char const*)" which actually loads the Lua engine and runs the code.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a shell script called relay.sh which is used for creating new SSH relays for the device so that the device connects to Vera servers. All the parameters passed in this specific script are logged to a log file called log.relay in the /tmp folder. The user can also read all the log files from the device using a script called log.sh. However, when the script loads the log files it displays them with content-type text/html and passes all the logs through the ansi2html binary which converts all the character text including HTML meta-characters correctly to be displayed in the browser. This allows an attacker to use the log files as a storing mechanism for the XSS payload and thus whenever a user navigates to that log.sh script, it enables the XSS payload and allows an attacker to execute his malicious payload on the user's browser.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a script file called "get_file.sh" which allows a user to retrieve any file stored in the "cmh-ext" folder on the device. However, the "filename" parameter is not validated correctly and this allows an attacker to directory traverse outside the /cmh-ext folder and read any file on the device. It is necessary to create the folder "cmh-ext" on the device which can be executed by an attacker first in an unauthenticated fashion and then execute a directory traversal attack.
An issue was discovered on Vera Veralite 1.7.481 devices. The device has an additional OpenWRT interface in addition to the standard web interface which allows the highest privileges a user can obtain on the device. This web interface uses root as the username and the password in the /etc/cmh/cmh.conf file which can be extracted by an attacker using a directory traversal attack, and then log in to the device with the highest privileges.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "wget" as one of the service actions for a normal user to connect the device to an external website. It retrieves the parameter "URL" from the query string and then passes it to an internal function that uses the curl module on the device to retrieve the contents of the website.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides UPnP services that are available on port 3480 and can also be accessed via port 80 using the url "/port_3480". It seems that the UPnP services provide "file" as one of the service actions for a normal user to read a file that is stored under the /etc/cmh-lu folder. It retrieves the value from the "parameters" query string variable and then passes it to an internal function "FileUtils::ReadFileIntoBuffer" which is a library function that does not perform any sanitization on the value submitted and this allows an attacker to use directory traversal characters "../" and read files from other folders within the device.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device firmware file contains a file known as relay.sh which allows the device to create relay ports and connect the device to Vera servers. This is primarily used as a method of communication between the device and Vera servers so the devices can be communicated with even when the user is not at home. One of the parameters retrieved by this specific script is "remote_host". This parameter is not sanitized by the script correctly and is passed in a call to "eval" to execute another script where remote_host is concatenated to be passed a parameter to the second script. This allows an attacker to escape from the executed command and then execute any commands of his/her choice.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a user with the capability of installing or deleting apps on the device using the web management interface. It seems that the device does not implement any cross-site request forgery protection mechanism which allows an attacker to trick a user who navigates to an attacker controlled page to install or delete an application on the device. Note: The cross-site request forgery is a systemic issue across all other functionalities of the device.
An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device firmware file contains a file known as proxy.sh which allows the device to proxy a specific request to and from from another website. This is primarily used as a method of communication between the device and Vera website when the user is logged in to the https://home.getvera.com and allows the device to communicate between the device and website. One of the parameters retrieved by this specific script is "url". This parameter is not sanitized by the script correctly and is passed in a call to "eval" to execute "curl" functionality. This allows an attacker to escape from the executed command and then execute any commands of his/her choice.