Export limit exceeded: 414644 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 414644 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (414644 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-126612 | 2026-11-11 | 7.8 High | ||
| Improper link resolution in the Windows installer of Progressive Robot hMailServer 6.0.0 through 6.3.7 allows a local authenticated user to run code as the mail server's service account or as an administrator when the path to the program folder passes through a junction, a symbolic link or a mount point that the user controls or that every user may change, such as a junction made at the root of a drive, which takes the root's permissions, or through a folder that every user may rename. Setup installed the programs through any such link without first checking who controls it, or whether a folder above the program folder may be renamed, and the service is registered to run the programs by that path, so the programs are installed where a link another account controls leads, or that account can later make the path lead to a folder it controls; the service, which runs as LocalSystem or as its virtual account, and the programs administrators run from Bin are then started from there. 6.3.7's fix for CVE-2026-107571 does not cover this: its hardening of the program folder, Bin and ControlPanel does not change a folder reached through a link that the administrators do not alone control, and setup does not refuse such a path: it installs through the link and at most reports afterwards that the folders could not be hardened. The default installation under Program Files is not affected. | ||||
| CVE-2026-126610 | 2026-11-11 | 7.4 High | ||
| Progressive Robot hMailServer 6.3.4 through 6.3.7, with a MySQL or MariaDB database and TlsMode=verify-full, does not hand the database client the CA file that TlsCaFile names when the file's name contains a character outside ASCII on Linux, or above U+00FF on Windows, which allows an attacker who can intercept the connection to the database server to read and modify the traffic between hMailServer and its database, by presenting, with MariaDB Connector/C 3.4.2 to 3.4.10 as the client, a certificate from any authority, its own included, for any name, and otherwise a certificate for the database server's name issued by any certificate authority in the system's trust store. The server converted the name for the client with the C runtime's conversion in the C locale, which gives an empty string for such a name, and then set no CA file at all, without an error, while certificate verification stayed on, so the client - MariaDB Connector/C, bundled on Windows and the distribution's on Linux - verified the certificate of a database server over the network against the system's trust store instead of the configured CA; Connector/C 3.4.2 to 3.4.10 (bundled on Windows in 6.3.4 to 6.3.6) went further and, with no CA file, took a certificate within its dates whose issuer it could not find, for any name, with neither its chain nor its name checked and no password proof, when the server offered first a sign-in method that hashes the password, which an attacker in the middle chooses (MariaDB's CONC-853, fixed in Connector/C 3.4.11), and Connector/C 3.4 accepted from a MariaDB 11.4 or later server a certificate the store did not vouch for when that server proved it held the account's password; on a connection it treats as local (127.0.0.1, ::1, a Unix socket, a named pipe, and localhost on Windows), Connector/C 3.4.1 and later checked neither the certificate's issuer nor its name, so that a local attacker able to stand in for the database server could present any certificate within its dates of its own making. The settings line of hmailserver --check-database still named the configured file, and the application log said the certificate had been checked. With MariaDB Connector/C 3.4.1 to 3.4.9 as the client - bundled on Windows in 6.3.4 to 6.3.6, and the client of Linux distributions that have not patched it - the missing CA file also met the precondition of CVE-2026-107819, so that a certificate issued for any other name by a trusted authority was enough to obtain the database password. On Linux the file was found only when the server ran on glibc under a locale whose character set holds the name's characters (a UTF-8 locale, or a legacy 8-bit one the system has, in whose bytes the file is then named); with no locale, LC_ALL=C or a locale the system lacks, and on Alpine (musl), the connection failed instead. The configuration is not the default: TlsMode defaults to prefer, which checks no certificate. | ||||
| CVE-2026-126611 | 2026-11-11 | 7 High | ||
| Progressive Robot hMailServer 6.3.4 through 6.3.7, with a MySQL or MariaDB database, TlsMode=verify-full and no TlsCaFile, does not verify the database server's certificate's issuer or name when the connection is one that MariaDB Connector/C treats as local - Server= set to 127.0.0.1, ::1 or localhost (on Linux a Unix socket), to . on Windows (a named pipe), or to a comma-separated list of servers that holds such an element - which allows a local attacker who can stand in for the database server, for example by listening on its port while it is stopped or restarting, to receive the database sign-in, the password included, and to read and modify the traffic between hMailServer and its database. hMailServer applied verify-full by turning the client's certificate verification on without a CA file, but MariaDB Connector/C 3.4.1 and later, on a connection they treat as local and with no CA file, accept any certificate within its validity period that is self-signed or sent with its own root, for any name (Connector/C 3.4.2 to 3.4.10 also one whose issuer they cannot find), so the client accepted the certificate an impostor made, asked no proof of the password and allowed a switch to an authentication method that sends the password unhashed, while hmailserver --check-database said the certificate had been checked against the system's trust store and the application log that it had been checked. The Windows builds bundle Connector/C 3.4.9 (6.3.4 to 6.3.6) and 3.4.11 (6.3.7); on Linux the distribution's client is used, and Connector/C 3.3 and 3.4.0 and Oracle's MySQL client are not affected. The configuration is not the default: TlsMode defaults to prefer, which checks no certificate. | ||||
| CVE-2026-126607 | 2026-11-11 | 7.8 High | ||
| Progressive Robot hMailServer 6.2.3 through 6.3.7 on Windows, with a MySQL or MariaDB database, hands the bundled MariaDB Connector/C the folder of its authentication plugins (the plugin folder in the installation's Bin folder) as Latin-1 bytes, which the client reads in the system's ANSI code page when it builds a plugin's path and loads the plugin with LoadLibraryExA, which allows a local authenticated user to execute code as the hMailServer service's account (LocalSystem, or the service's virtual account for a new installation from 6.3.4) by creating the folder those bytes name in the code page and placing in it a DLL with a plugin's name, when the installation folder's path holds a character between U+0080 and U+00FF whose byte the code page reads as another character, and none above U+00FF, and the user can create that other folder (by default any authenticated user may create a folder directly under the root of the system drive). The server converted the path with the C runtime's wcstombs_s in the C locale, which writes each character up to U+00FF as the byte of the same value: on code page 1252 those bytes are the same letters, while on another code page, such as 1251, or on a UTF-8 code page, they name another folder. The client loads the plugin the database server names in its greeting, unless it is built in, and any plugin the server names in an authentication switch, and tries again at each connection while a load fails, so with a MySQL 8.0 or later server, whose greeting names caching_sha2_password by default, the DLL is loaded at the next connection the service makes, whatever plugin the database account uses; a DLL's entry point runs when it is loaded. A path holding any character above U+00FF was handed over as an empty string, whatever the code page, from which the client makes a plugin's name at the root of the current drive: for the service, whose current folder is System32, that is the root of the system drive, where by default only administrators can create a file, but the server's own database commands (hMailServer.exe --check-database, --upgrade-database and the others from 6.3.4, and the /Debug and /Test console modes from 6.2.3) run in the folder they are started from - the product tells administrators to run them from an elevated prompt in the Bin folder, and the setup of 6.3.4 and 6.3.5 ran two or three of them itself with the Bin folder as their working folder for a new installation with an external database - so a DLL that a local authenticated user placed under a plugin's name at the root of a drive other users may write, such as a FAT or exFAT volume, was loaded into the administrator's process at the command's first connection to a MySQL 8.0 or later server. 6.3.8 fixes both cases: it hands the folder in the code page's bytes or by its short (8.3) name, and where neither can be written, a folder under the Windows system folder that holds no plugin and that only administrators can create, or else refuses the connection before attempting it; it never hands the empty value or a folder the current drive completes. The configuration is not the default: the default installation folder, under Program Files, is ASCII. Linux builds set no plugin folder and are not affected. | ||||
| CVE-2026-126609 | 2026-11-11 | 7.5 High | ||
| Progressive Robot hMailServer 6.2.25 through 6.3.7 on Windows, with a PostgreSQL database, the connection's sslmode require, verify-ca or verify-full, and a root certificate file named by PostgreSQLSslRootCert (from 6.2.25) or, with TlsMode=verify-full and neither PostgreSQL key set, by TlsCaFile (from 6.3.4), hands the file's name to libpq as bytes in the system's ANSI code page (up to 6.3.5 as Latin-1 bytes, which on code page 1252 are the code page's own for U+00A0 to U+00FF), and libpq looks for the file by those bytes and then hands the same bytes to OpenSSL, whose file opening on Windows reads a name as UTF-8 first and opens the file at that reading when one is there. When every byte of the name outside ASCII also reads as UTF-8 - for example U+00C3 U+00A9, the bytes C3 A9 on code page 1252, which are U+00E9 in UTF-8 - the database server's certificate was checked against the file at that other name whenever one was there, which allows a local attacker who can create that file but cannot change the configured one, as any user can by default beside a file an administrator keeps under ProgramData, or beside a folder directly under the system drive's root whose permissions the administrator restricted, and who can intercept the connection to the database server or stand in for it, to have hMailServer trust a certificate authority of the attacker's own and read and modify the traffic between hMailServer and its database, the database password included; the file alone, holding no authority that issued the database server's certificate, stops hMailServer from connecting to its database. The same applies in 6.3.4 through 6.3.7 to TlsCaFile when an Oracle MySQL client library has been put in place of the bundled MariaDB Connector/C, since that client opens the file through OpenSSL in the same way; the bundled MariaDB Connector/C opens the file in the code page and is not affected, and neither are the Linux builds. The configuration is not the default: by default no root certificate file is named. | ||||
| CVE-2026-18769 | 1 Beckhoff | 2 Tcrouter.sys, Twincat.xar.base.km | 2026-11-11 | 7.8 High |
| A local low privileged attacker can move arbitrary physical memory content via TcRouter.sys because of exposed IOCTL function calls resulting in a full compromise of the affected devices. | ||||
| CVE-2026-18768 | 1 Beckhoff | 2 Tcrouter.sys, Twincat.xar.base.km | 2026-11-11 | 7.8 High |
| A local low privileged attacker can access arbitrary physical memory or define its mapping via TcRouter.sys because of exposed IOCTL function calls resulting in a full compromise of the affected devices. | ||||
| CVE-2026-18767 | 1 Beckhoff | 2 Tcrouter.sys, Twincat.xar.base.km | 2026-11-11 | 7.8 High |
| A local low privileged attacker or process can access I/O ports via TcRouter.sys because of exposed IOCTL function calls resulting in a full compromise of the affected devices. | ||||
| CVE-2026-92905 | 1 Zohocorp | 4 Eventlog Analyzer, Log360, Manageengine Eventlog Analyzer and 1 more | 2026-11-11 | 5.3 Medium |
| Zoho Corporation ManageEngine EventLog Analyzer and Log360 versions below 13071 are vulnerable to a denial-of-service (DoS) vulnerability in the log collector component. | ||||
| CVE-2026-116468 | 1 Redhat | 2 Build Keycloak, Red Hat Single Sign On | 2026-11-11 | 6.6 Medium |
| A flaw was found in the group-move and organization group reparenting endpoints of the keycloak-services component. This component is responsible for core authentication and authorization services in the Red Hat build of Keycloak. The issue occurs because the system fails to check if a target parent group confers administrative roles when a group is moved. A delegated administrator can exploit this to move a group they control under an administrative group, causing all members to inherit full realm-admin privileges and gain complete control over the realm. | ||||
| CVE-2025-59847 | 2026-11-11 | 6.8 Medium | ||
| HCL Domino Leap is vulnerable to Stored XSS through malicious application titles in Manage page dialogs, allowing an attacker to take over a user's session | ||||
| CVE-2026-12062 | 1 Zohocorp | 1 Adaudit Plus | 2026-11-11 | 8.8 High |
| Zoho Corporation ManageEngine ADAudit Plus versions below 8703 are vulnerable to an authenticated SQL injection vulnerability in ADAudit Plus Reports API. | ||||
| CVE-2026-121885 | 1 Redhat | 3 Enterprise Linux, Hummingbird, Openshift | 2026-11-11 | 6.5 Medium |
| A flaw was found in Podman. An attacker can trigger a Denial of Service (DoS) by supplying a container image containing crafted metadata labels. Podman's auto-update mechanism improperly trusts these image labels to determine which system services to restart. If a user runs the malicious container and auto-update processes it, arbitrary system services are restarted with the user's privileges, potentially allowing an attacker to shut down the host system when Podman runs with administrative privileges. | ||||
| CVE-2026-76981 | 1 Zohocorp | 1 Adaudit Plus | 2026-11-11 | 8.8 High |
| Zoho Corporation ManageEngine ADAudit Plus versions below 8711 are vulnerable to an authenticated second order SQL injection vulnerability affecting ADAudit Plus custom reports module. | ||||
| CVE-2026-111190 | 2026-11-11 | 8.1 High | ||
| The ARForms plugin for WordPress is vulnerable to arbitrary file upload in all versions up to, and including, 7.2.4 via its form file-upload handler. The name of the stored file is taken from an attacker-controlled request header and is not adequately restricted to safe file types, and the plugin's file-type and content-safety checks can be evaded, allowing files that contain executable PHP code to be written to a publicly accessible directory. This makes it possible for unauthenticated attackers to upload malicious files to the affected site's server, which may make remote code execution possible. Exploitation requires a published form containing a File field to be publicly accessible on the site. | ||||
| CVE-2026-12427 | 2026-11-11 | 7.2 High | ||
| The ARforms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'description' parameter in all versions up to, and including, 7.2.4 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The injected payload is deserialized via maybe_unserialize() when an administrator views the affected entry; if the attacker's array contains a 'referrer' key, the attacker-controlled page_url and http_referrer values are used as-is and rendered unescaped into the admin entry detail view. | ||||
| CVE-2026-12424 | 2026-11-11 | 7.2 High | ||
| The ARforms plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Referer Header in all versions up to, and including, 7.2.4 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The arf_save_incomplete_form_data() AJAX handler is registered with wp_ajax_nopriv_, meaning unauthenticated attackers can store a malicious payload by submitting a partial form entry with a forged Referer header, with no authentication required at any step. | ||||
| CVE-2026-15785 | 2026-11-11 | 6.1 Medium | ||
| The Joinchat – Enhanced "click to chat" plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via '{HREF}' Dynamic Variable via Query Parameter Name in all versions up to, and including, 6.3.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. Exploitation requires that an administrator has configured a telephone number and included the {HREF} dynamic variable in the Call-to-Action text. | ||||
| CVE-2026-93487 | 2026-11-11 | N/A | ||
| In affected versions of Octopus Server, incorrect validation of the permissions assigned to a user that would allow them to create project triggers could result in the user being able to run runbooks or create deployments they were not authorised to perform. | ||||
| CVE-2026-96414 | 2026-11-11 | N/A | ||
| In affected versions of Octopus Server, insufficient integrity protection of authentication cookies, combined with incorrect validation of permissions assigned to a user that allowed them to view users or audit events, could result in the user escalating their privileges to those of an Administrator. | ||||