PatchFirst · Aktuelle Sicherheitslücken
In den letzten 30 Tagen veröffentlichte Sicherheitslücken für zabbix: 5. Davon im KEV-Katalog: 0.
Sicherheitslücken: 128
A regular Zabbix user with no permission to the Monitoring -> Problems view is still able to call the problem.view.refresh action and therefore still retrieve a list of active problems.
A regular Zabbix user can search other users in their user group via Zabbix API by select fields the user does not have access to view. This allows data-mining some field values the user does not have access to.
The LDAP 'Bind password' value cannot be read after saving, but a Super Admin account can leak it by changing LDAP 'Host' to a rogue LDAP server. To mitigate this, the 'Bind password' value is now reset on 'Host' change.
A Zabbix adminitrator can inject arbitrary SQL during the autoremoval of hosts by inserting malicious SQL in the 'Visible name' field.
Due to a bug in Zabbix API, the hostprototype.get method lists all host prototypes to users that do not have any user groups assigned to them.
Zabbix Agent 2 smartctl plugin does not properly sanitize smart.disk.get parameters, allowing an attacker to inject unexpected arguments into the smartctl command. This can be used to leak the NTLMv2 hash from a Windows system.
Zabbix Agent 2 smartctl plugin does not properly sanitize smart.disk.get parameters, allowing an attacker to inject unexpected arguments into the smartctl command. In Zabbix 5.0 this allows for remote code execution.
Zabbix server is vulnerable to a DoS vulnerability due to uncontrolled resource exhaustion. An attacker can send specially crafted requests to the server, which will cause the server to allocate an excessive amount of memory and perform CPU-intensive decompression operations, ultimately leading to a service crash.
The endpoint /zabbix.php?action=export.valuemaps suffers from a Cross-Site Scripting vulnerability via the backurl parameter. This is caused by the reflection of user-supplied data without appropriate HTML escaping or output encoding. As a result, a JavaScript payload may be injected into the above endpoint causing it to be executed within the context of the victim's browser.
Zabbix API user.get returns all users that share common group with the calling user. This includes media and other information, such as login attempts, etc.
Execution time for an unsuccessful login differs when using a non-existing username compared to using an existing one.
A low privilege (regular) Zabbix user with API access can use SQL injection vulnerability in include/classes/api/CApiService.php to execute arbitrary SQL commands via the groupBy parameter.
A bug in the code allows an attacker to sign a forged zbx_session cookie, which then allows them to sign in with admin permissions.
When exporting media types, the password is exported in the YAML in plain text. This appears to be a best practices type issue and may have no actual impact. The user would need to have permissions to access the media types and therefore would be expected to have access to these passwords.
The researcher is showing that it is possible to leak a small amount of Zabbix Server memory using an out of bounds read in src/libs/zbxmedia/email.c
The researcher is showing that due to the way the SNMP trap log is parsed, an attacker can craft an SNMP trap with additional lines of information and have forged data show in the Zabbix UI. This attack requires SNMP auth to be off and/or the attacker to know the community/auth details. The attack requires an SNMP item to be configured as text on the target host.
In the src/libs/zbxembed/browser.c file, the es_browser_ctor method retrieves a heap pointer from the Duktape JavaScript engine. This heap pointer is subsequently utilized by the browser_push_error method in the src/libs/zbxembed/browser_error.c file. A use-after-free bug can occur at this stage if the wd->browser heap pointer is freed by garbage collection.
The HttpRequest object allows to get the HTTP headers from the server's response after sending the request. The problem is that the returned strings are created directly from the data returned by the server and are not correctly encoded for JavaScript. This allows to create internal strings that can be used to access hidden properties of objects.
The webdriver for the Browser object expects an error object to be initialized when the webdriver_session_query function fails. But this function can fail for various reasons without an error description and then the wd->error will be NULL and trying to read from it will result in a crash.
When the webdriver for the Browser object downloads data from a HTTP server, the data pointer is set to NULL and is allocated only in curl_write_cb when receiving data. If the server's response is an empty document, then wd->data in the code below will remain NULL and an attempt to read from it will result in a crash.
Gleichen Sie Ihren installierten Stack und seine Versionen mit den aktuellen Sicherheitsmeldungen ab.