Export limit exceeded: 425601 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 425601 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (425601 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-64670 | 1 Waline | 1 Waline | 2026-11-13 | 9.3 Critical |
| Waline is a comment system with backend support. In versions 3.15.2 and prior, @waline/client renders the comment editor's live preview with marked and no sanitizer (utils/markdown.ts), and the preview is injected with v-html. When a comment is edited, the editor is seeded with the comment's raw, un-sanitized body (orig). Only administrators and the comment owner can edit. So an administrator who clicks Edit on an attacker's comment renders that attacker's raw HTML in their own session: an unauthenticated commenter achieves privilege-escalation stored XSS against a moderator with a single Edit click. At time of publication, there are no publicly available patches. | ||||
| CVE-2026-64668 | 1 Mcdope | 1 Pam Usb | 2026-11-13 | 7.4 High |
| pam_usb provides hardware authentication for Linux using removable media. From version 0.8.0 to before version 0.9.3, the deny_remote feature in pam_usb uses /usr/bin/w -i to detect whether the authenticating user has an active remote tmux session. In pusb_tmux_has_remote_clients() (src/tmux.c), the IPv6 detection pattern matched the address group and then immediately expected whitespace. On Linux systems with multi-homed network interfaces, w -i appends a zone index (scope identifier) to link-local IPv6 addresses — e.g. fe80::1%eth0. The %eth0 suffix appeared between the address and the next whitespace field, causing the regex match to fail even for an otherwise-matching remote session. The function returned "no remote clients" and granted access. This issue has been patched in version 0.9.3. | ||||
| CVE-2026-64666 | 1 Mcdope | 1 Pam Usb | 2026-11-13 | 7.1 High |
| pam_usb provides hardware authentication for Linux using removable media. Prior to version 0.9.3, src/local.c reads XRDP_SESSION with plain getenv(3) at the head of pusb_local_login while every other env consumer in the same function uses secure_getenv(3). When pam_usb.so loads into a setuid PAM host, the calling user controls the environment passed in. Clearing XRDP_SESSION before invoking the host bypasses the explicit XRDP-deny rule. Other remote-detection signals (rmsvc, evdev, loginctl, utmp) may still catch the session, but the env-based detection alone is defeated. This issue has been patched in version 0.9.3. | ||||
| CVE-2026-64667 | 1 Mcdope | 1 Pam Usb | 2026-11-13 | 4.4 Medium |
| pam_usb provides hardware authentication for Linux using removable media. Prior to version 0.9.3, src/local.c (pusb_get_tty_from_display_server) allocates a 4096-byte cmdline buffer, reads up to 4096 bytes from /proc//cmdline, then replaces every NUL separator with a space. When read(2) returns exactly 4096 bytes for any process the function inspects, the buffer ends without a terminator and the subsequent strstr() calls scan past the allocation boundary. The function is invoked during normal PAM authentication when DISPLAY is set, so the read fires for every process at auth time. Consequences are bounded: strstr output is a Boolean substring match (limited info-disclosure surface) but a hostile heap layout can produce a SIGSEGV that terminates the host PAM process. This issue has been patched in version 0.9.3. | ||||
| CVE-2026-64669 | 1 Mcdope | 1 Pam Usb | 2026-11-13 | 7.4 High |
| pam_usb provides hardware authentication for Linux using removable media. From version 0.8.0 to before version 0.9.3, the deny_remote feature in pam_usb uses /usr/bin/w -i to detect whether the authenticating user has an active remote tmux session. In pusb_tmux_has_remote_clients() (src/tmux.c), the IPv6 detection regex required exactly four explicit colon-separated groups of 1-4 hex digits (e.g. 2001:0db8:85a3:0000). Any IPv6 address in compressed notation — including loopback (::1), link-local (fe80::1), and global unicast addresses (2001:db8::1) — did not match this pattern. As a result the remote-client check silently returned "no remote clients" even when a remote tmux client was connected from such an address. This issue has been patched in version 0.9.3. | ||||
| CVE-2026-61810 | 1 Dmtf | 1 Libspdm | 2026-11-13 | N/A |
| libspdm is a sample implementation that follows the DMTF SPDM specifications. In version 1.4.0, both the FINISH request (Table 80) and the FINISH_RSP response (Table 81) gained two new fields, OpaqueDataLength and OpaqueData, placed before the trailing signed/authenticated field. The transcript definitions used to compute and verify the FINISH signature, the FINISH HMAC (RequesterVerifyData), and the FINISH_RSP HMAC (ResponderVerifyData) were not updated and still terminate with a step of the form. Per DSP0274, the "SPDM Header Fields" are only the four header bytes (SPDMVersion, RequestResponseCode, Param1, Param2). A literal reading therefore excludes OpaqueDataLength and OpaqueData, even though those fields are transmitted before the trailing signature/HMAC field. Because the signature/HMAC must cover every field transmitted before it to "protect the entire handshake against manipulation by an active attacker," an active attacker could otherwise modify the opaque data in flight without invalidating the signature or HMAC. This issue has been patched in version 1.4.1. | ||||
| CVE-2026-88813 | 1 Wordpress-extensions | 1 Yith Woocommerce Gift Cards | 2026-11-13 | 5.3 Medium |
| The YITH WooCommerce Gift Cards WordPress plugin through 4.39.0 does not reconcile the value of a gift card it issues against the amount actually paid for it, instead crediting the new card with the item's pre-discount price, which allows customers to apply an ordinary store coupon at checkout and receive a gift card worth more than they paid. | ||||
| CVE-2026-92408 | 1 Wordpress-extensions | 1 Wps Bookings For Woocommerce | 2026-11-13 | 5.3 Medium |
| The WPS Bookings for WooCommerce WordPress plugin before 3.13.1 does not validate a price value taken from user input before using it to set the product price, allowing unauthenticated users to purchase bookable services at a price of their choosing, including zero. | ||||
| CVE-2026-125659 | 1 Emudhra | 1 Embridge | 2026-11-13 | N/A |
| This vulnerability exists in the eMudhra emBridge due to missing authorization checks in the FileBrowser API endpoints. These endpoints perform file system enumeration using the LocalSystem account without adequately validating the requesting caller's authorization. An unauthenticated attacker on the same LAN could exploit this vulnerability by sending malicious webpage to the local HTTPS Web API. Successful exploitation of this vulnerability could allow the attacker to enumerate file and directory names and obtain information about the directory structure of the targeted system. The vulnerability however, does not provide access to file contents or permit file modification, deletion, or code execution, or access to cryptographic keys and hardware token PINs. | ||||
| CVE-2026-121529 | 1 Fortinet | 3 Forticlientmac, Forticlientwindows, Forticlientwindowspam | 2026-11-13 | 9.1 Critical |
| A origin validation error vulnerability in Fortinet FortiClientMac 7.4.0 through 7.4.7, FortiClientWindows 7.4.0 through 7.4.7, FortiClientWindows 7.2.0 through 7.2.14, FortiClientWindowsPAM 7.4.7, FortiClientWindowsPAM 7.2.14 may allow an unauthorized remote attacker to execute unauthorized code or commands. Successful exploitation requires interaction with the victim. | ||||
| CVE-2026-126609 | 1 Progressive Robot | 1 Hmailserver | 2026-11-13 | 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-126607 | 1 Progressive Robot | 1 Hmailserver | 2026-11-13 | 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-126625 | 1 Progressive Robot | 1 Hmailserver | 2026-11-13 | 6.7 Medium |
| Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.3.7 allow a local authenticated user to run code as the administrator who installs the product, when it is installed into a new program folder in a location whose permissions let every user write, such as the root of a drive. 6.3.7 fixed CVE-2026-107571 by giving the program folder, Bin and ControlPanel permissions that only administrators may change, but its setup lets Inno Setup make a new program folder first, with the permissions the folder above hands down, and replaces them only afterwards, tens of milliseconds later (33 to 139 milliseconds in the project's test runs). In that time any local account may make files and folders in the new folder, which keep that account as their owner, among them the Bin folder that setup then copies the programs into. Setup runs programs from Bin with the administrator's elevated rights, registering the service among them, before its hardening at the end of setup takes such a folder back, and those programs load a library placed in Bin in place of the system's. The default installation under Program Files, whose folders give ordinary users read and execute only, is not affected. | ||||
| CVE-2026-90993 | 1 Apache | 1 Xml Graphics Batik | 2026-11-13 | N/A |
| XXE vulnerability in Apache XML Graphics Batik. This issue affects Apache XML Graphics Batik: through 1.19. Users are recommended to upgrade to version 1.20, which fixes the issue. | ||||
| CVE-2026-92379 | 1 Synology | 1 Diskstation Manager | 2026-11-13 | 5.4 Medium |
| An improper neutralization of input during web page generation vulnerability in the Notification API in Synology DiskStation Manager (DSM) before 7.3.2-86009-5 and 7.4.1-90080-1 allows remote authenticated users to read or write specific files. | ||||
| CVE-2026-74850 | 1 Synology | 1 Diskstation Manager | 2026-11-13 | 4.3 Medium |
| An improper limitation of a pathname to a restricted directory vulnerability in the contentextract in Synology DiskStation Manager (DSM) before 7.3.2-86009-5 and 7.4.1-90080-1 allows remote authenticated users to read specific files. | ||||
| CVE-2026-91007 | 1 Zephyrproject | 1 Zephyr | 2026-11-13 | 7.8 High |
| The user-mode syscall verifiers for the charger driver API in drivers/charger/charger_handlers.c did not inspect the prop argument before copying union charger_propval across the user/kernel boundary. Two members of that union are function pointers — status_notification (CHARGER_PROP_STATUS_NOTIFICATION) and online_notification (CHARGER_PROP_ONLINE_NOTIFICATION), declared in include/zephyr/drivers/charger.h — and z_vrfy_charger_set_prop() forwarded the caller-supplied union verbatim to the driver's set_property callback for any property. z_vrfy_charger_get_prop() had the mirror defect and copied the stored kernel callback address back out to user memory. With CONFIG_USERSPACE enabled, any user-mode thread that has been granted a charger device object could call charger_set_prop() with CHARGER_PROP_STATUS_NOTIFICATION or CHARGER_PROP_ONLINE_NOTIFICATION and an arbitrary pointer value. Drivers that implement these properties — drivers/charger/charger_max20335.c, drivers/charger/charger_pf1550.c and drivers/charger/charger_bq2518x.c — store the pointer in device data and later invoke it from their interrupt work handlers, which run in supervisor mode, on any charger state change such as a cable plug/unplug. The result is a control-flow hijack at kernel privilege from an unprivileged thread, defeating the isolation that CONFIG_USERSPACE is meant to provide; the read path additionally disclosed a kernel code address to user mode, and clearing a notifier installed by a supervisor thread let user mode suppress charger notifications. Supervisor-mode callers of charger_set_prop()/charger_get_prop() are unaffected. The fix makes both verifiers reject the two notifier properties outright — including when the supplied callback is NULL, since the notifiers are device state — and adds a BUILD_ASSERT on CHARGER_PROP_COMMON_COUNT so that new properties force a re-review of the union's user-mode safety. | ||||
| CVE-2026-112182 | 1 Openkm | 1 Openkm Community Edition | 2026-11-13 | N/A |
| Unauthorization vulnerability in the management of workflow definitions in OpenKM Community Edition. The REST endpoints `registerProcessDefinition` and `runProcessDefinition` require authentication but do not verify roles in the WorkflowService or in lower layers. An attacker with the `ROLE_USER` role can register and execute a process definition containing BeanShell scripts, allowing them to execute Java code and operating system commands with the service’s privileges. In the official Docker image, the process runs as root. | ||||
| CVE-2026-106172 | 1 Fortinet | 2 Fortisandbox, Fortisandboxcloud | 2026-11-13 | 4.9 Medium |
| A use of hard-coded cryptographic key vulnerability in Fortinet FortiSandbox 5.2.0 through 5.2.1, FortiSandbox 5.0.0 through 5.0.6, FortiSandbox 4.4 all versions, FortiSandbox Cloud 5.2.0 through 5.2.1, FortiSandbox Cloud 5.0.0 through 5.0.6, FortiSandbox Cloud 4.4 all versions may allow attacker to escalation of privilege via specially crafted HTTP requests | ||||
| CVE-2026-112181 | 1 Openkm | 1 Openkm Community Edition | 2026-11-13 | N/A |
| Vulnerability due to inadequate restriction of references to external XML entities in OpenKM Community Edition. The XML processing in FormUtils / LocalEntityResolver does not properly restrict the resolution of external resources. An authenticated remote attacker with the ROLE_USER role can exploit the flaw via a REST request. In the 6.3.x branch, this allows the attacker to trigger HTTP requests under their control (SSRF); in 7.0.3, it allows the attacker to read local files and access internal HTTP resources from the server. | ||||