From 639179a5d023b39576cc9b8ff0bae3ccbcfd9f6e Mon Sep 17 00:00:00 2001 From: Vulnerability Bot Date: Wed, 11 Nov 2026 10:40:50 +0100 Subject: [PATCH] CVE sync 2026-11-11T09:40:46Z --- data/2026/126xxx/CVE-2026-126607.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126609.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126610.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126611.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126612.json | 106 +++++++++ data/2026/126xxx/CVE-2026-126613.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126614.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126615.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126616.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126617.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126618.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126619.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126621.json | 103 +++++++++ data/2026/126xxx/CVE-2026-126622.json | 104 +++++++++ data/2026/126xxx/CVE-2026-126623.json | 106 +++++++++ data/2026/126xxx/CVE-2026-126624.json | 104 +++++++++ data/2026/126xxx/CVE-2026-126625.json | 104 +++++++++ data/2026/126xxx/CVE-2026-126626.json | 103 +++++++++ data/2026/18xxx/CVE-2026-18767.json | 312 ++++++++++++++++++++++++++ data/2026/18xxx/CVE-2026-18768.json | 312 ++++++++++++++++++++++++++ data/2026/18xxx/CVE-2026-18769.json | 312 ++++++++++++++++++++++++++ data/2026/76xxx/CVE-2026-76563.json | 9 +- data/2026/79xxx/CVE-2026-79655.json | 40 +++- data/2026/80xxx/CVE-2026-80179.json | 40 +++- data/2026/92xxx/CVE-2026-92091.json | 40 +++- data/delta.json | 18 +- data/deltaLog.json | 259 ++++++++++++++------- state/sync.json | 6 +- 28 files changed, 3089 insertions(+), 122 deletions(-) create mode 100644 data/2026/126xxx/CVE-2026-126607.json create mode 100644 data/2026/126xxx/CVE-2026-126609.json create mode 100644 data/2026/126xxx/CVE-2026-126610.json create mode 100644 data/2026/126xxx/CVE-2026-126611.json create mode 100644 data/2026/126xxx/CVE-2026-126612.json create mode 100644 data/2026/126xxx/CVE-2026-126613.json create mode 100644 data/2026/126xxx/CVE-2026-126614.json create mode 100644 data/2026/126xxx/CVE-2026-126615.json create mode 100644 data/2026/126xxx/CVE-2026-126616.json create mode 100644 data/2026/126xxx/CVE-2026-126617.json create mode 100644 data/2026/126xxx/CVE-2026-126618.json create mode 100644 data/2026/126xxx/CVE-2026-126619.json create mode 100644 data/2026/126xxx/CVE-2026-126621.json create mode 100644 data/2026/126xxx/CVE-2026-126622.json create mode 100644 data/2026/126xxx/CVE-2026-126623.json create mode 100644 data/2026/126xxx/CVE-2026-126624.json create mode 100644 data/2026/126xxx/CVE-2026-126625.json create mode 100644 data/2026/126xxx/CVE-2026-126626.json create mode 100644 data/2026/18xxx/CVE-2026-18767.json create mode 100644 data/2026/18xxx/CVE-2026-18768.json create mode 100644 data/2026/18xxx/CVE-2026-18769.json diff --git a/data/2026/126xxx/CVE-2026-126607.json b/data/2026/126xxx/CVE-2026-126607.json new file mode 100644 index 0000000000..f6211d061e --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126607.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126607", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:19.540Z", + "datePublished": "2026-11-11T08:30:27.131Z", + "dateUpdated": "2026-11-11T08:30:27.131Z" + }, + "containers": { + "cna": { + "title": "Uncontrolled Search Path Element in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "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." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.2.3", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-427: Uncontrolled Search Path Element", + "cweId": "CWE-427", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/116" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "attackVector": "LOCAL", + "attackComplexity": "LOW", + "privilegesRequired": "LOW", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 7.8, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, which on Windows always hands the bundled client its plugin folder in the bytes the client reads it in - the ANSI code page, or UTF-8 where that is the code page - or, where the code page lacks a character of the path, by the folder's short (8.3) name, which is the same folder; where neither can be written, it hands a folder under the Windows system folder that holds no plugin and that only administrators can create, so that a plugin found only in the installation's plugin folder is not loaded and the connection's error says why, and where even that folder cannot be written, it refuses the connection before attempting it, with error HM7537 in the log. It never hands Latin-1 bytes, the empty value or a folder the current drive or folder completes: that closes the service's case and the database commands' case alike. Before 6.3.8, install hMailServer in a folder whose path is ASCII alone, as the default folder under Program Files is, and start hMailServer.exe's database commands, and DBSetup when it finishes an installation, from a folder on the system drive. For a new installation of 6.3.4 or 6.3.5 with an external database, whose setup runs two or three of the commands in the Bin folder itself, only an installation folder whose path is ASCII avoids it. An installation whose path is ASCII is not affected; on a system whose code page for non-Unicode programs is 1252, the service is not affected unless the path holds a C1 control character (U+0080 to U+009F) whose byte code page 1252 reads as another character, but before 6.3.8 a path holding a character above U+00FF reaches a database command started from another drive on any code page. Setting MARIADB_PLUGIN_DIR in the service's environment does not help, since the client takes the option first and every affected version sets it." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:30:27.131Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126609.json b/data/2026/126xxx/CVE-2026-126609.json new file mode 100644 index 0000000000..806a16ae94 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126609.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126609", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:24.373Z", + "datePublished": "2026-11-11T08:30:17.425Z", + "dateUpdated": "2026-11-11T08:30:17.425Z" + }, + "containers": { + "cna": { + "title": "Improper Certificate Validation in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "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." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.2.25", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-295: Improper Certificate Validation", + "cweId": "CWE-295", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/114" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", + "attackVector": "NETWORK", + "attackComplexity": "HIGH", + "privilegesRequired": "LOW", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 7.5, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, which on Windows refuses before connecting, with HM7534 in the error log, a root certificate file name whose bytes in the code page outside ASCII also read as UTF-8, for PostgreSQLSslRootCert and TlsCaFile alike and whichever database client is loaded, and hands an Oracle MySQL client the name in UTF-8, which names the same file. Until then, name the root certificate file by a path in ASCII alone, which reads as the same name in the code page and in UTF-8 and which every affected version hands over unchanged; where a name outside ASCII must stay, make sure no one else can create the file or folder that the name's UTF-8 reading names." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:30:17.425Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126610.json b/data/2026/126xxx/CVE-2026-126610.json new file mode 100644 index 0000000000..599ae0dd39 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126610.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126610", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:29.376Z", + "datePublished": "2026-11-11T08:30:37.134Z", + "dateUpdated": "2026-11-11T08:30:37.134Z" + }, + "containers": { + "cna": { + "title": "Improper Certificate Validation in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "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." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.4", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-295: Improper Certificate Validation", + "cweId": "CWE-295", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/112" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N", + "attackVector": "NETWORK", + "attackComplexity": "HIGH", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "NONE", + "baseScore": 7.4, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, which hands the database client the CA file's name in the encoding the client opens it in - UTF-8 on Linux whatever the locale, the ANSI code page on Windows - and refuses before connecting, with HM7534 in the error log, a name it cannot write so, never handing over an empty one. Until then, give TlsCaFile a path in ASCII alone, which every affected version hands to the client as it is; on these versions the settings line of hmailserver --check-database names the configured file whether or not the client was given it, so it does not show the difference. On Linux, also update the distribution's MariaDB Connector/C to 3.4.11 or later, which fixes both CVE-2026-107819 and CONC-853, where one is offered; a version with the fix for CVE-2026-107819 alone still accepts a certificate whose issuer it cannot find." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:30:37.134Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126611.json b/data/2026/126xxx/CVE-2026-126611.json new file mode 100644 index 0000000000..9e15c0333e --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126611.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126611", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:34.376Z", + "datePublished": "2026-11-11T08:30:32.132Z", + "dateUpdated": "2026-11-11T08:30:32.132Z" + }, + "containers": { + "cna": { + "title": "Improper Certificate Validation in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "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." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.4", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-295: Improper Certificate Validation", + "cweId": "CWE-295", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/113" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", + "attackVector": "LOCAL", + "attackComplexity": "HIGH", + "privilegesRequired": "LOW", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 7, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, which reads Server= as MariaDB Connector/C does and refuses TlsMode=verify-full with no TlsCaFile before connecting, with HM7535 in the error log, on a connection the client treats as local or a Server= list that holds one, and which says, on such a connection with a TlsCaFile, that the certificate's issuer was checked and not its name. Until then, set TlsCaFile to a file holding only the CA that issues the database server's certificate, at a path in ASCII alone; the client then checks the certificate's issuer on such a connection, though not its name. On these versions the --check-database settings line and the application log say the certificate was checked either way, so they do not show the difference." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:30:32.132Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126612.json b/data/2026/126xxx/CVE-2026-126612.json new file mode 100644 index 0000000000..1ac2af529d --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126612.json @@ -0,0 +1,106 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126612", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:39.379Z", + "datePublished": "2026-11-11T08:30:52.135Z", + "dateUpdated": "2026-11-11T08:30:52.135Z" + }, + "containers": { + "cna": { + "title": "Improper Link Resolution Before File Access ('Link Following') in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "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." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.0.0", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-59: Improper Link Resolution Before File Access ('Link Following')", + "cweId": "CWE-59", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/78" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + }, + { + "url": "https://www.cve.org/CVERecord?id=CVE-2026-107571" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "attackVector": "LOCAL", + "attackComplexity": "LOW", + "privilegesRequired": "LOW", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 7.8, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, whose setup holds every folder from the root of the volume down to the program folder, Bin and ControlPanel open and, before anything changes, refuses with exit code 7 a junction, a symbolic link or a mount point on the way that anybody but SYSTEM, the Administrators and TrustedInstaller owns, may change or may remove - a junction made at a drive's root and left with the permissions the root hands down among them - and a folder on the way that another account may rename or remove, or empty, naming each with the icacls that deals with it. Until then, install hMailServer under Program Files, or at a path with no link on it below folders that only administrators may change. For a link that is meant to be on the path, make it the administrators' alone from an elevated Command Prompt - icacls \"\" /L /setowner *S-1-5-32-544, then icacls \"\" /L /inheritance:r /grant:r *S-1-5-18:F *S-1-5-32-544:F *S-1-5-32-545:RX - and check where it leads (dir /al of the folder that holds it); make the Administrators the owner of each folder above the program folder that other accounts may change, and take away their right to change it; then restart Windows. Where another account owned or could change such a link or folder while the installation was there, reinstall into a new folder as the hMailServer documentation, ServiceAccount.md, \"Reinstalling into a new folder\", says." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:30:52.135Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126613.json b/data/2026/126xxx/CVE-2026-126613.json new file mode 100644 index 0000000000..8b36dcaaa1 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126613.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126613", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:44.444Z", + "datePublished": "2026-11-11T08:31:12.127Z", + "dateUpdated": "2026-11-11T08:31:12.127Z" + }, + "containers": { + "cna": { + "title": "Allocation of Resources Without Limits or Throttling in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "Allocation of resources without limits in the JSON reader of Progressive Robot hMailServer 6.3.2 through 6.3.7 allows a remote attacker to exhaust the server's memory and hold its threads, making mail delivery, the REST API and the webmail unavailable. The reader built a tree of values far larger than the text it read, copying each value into every level above it, and set no bound on the number of values, so a single JSON document of many small values, within the 16 MB the server reads, raised the service's memory by about 2 GB and held one thread for seconds to minutes. From 6.3.4 a remote unauthenticated attacker reaches the reader by mailing such a document as a TLS-RPT report, up to 16 MB once decompressed, to a hosted domain's report mailbox, where an administrator has set one; it is read on a mail delivery thread (ten by default), and those threads deliver all mail, local and outbound. From 6.3.4 it is also reached without an account through the reply to a password-protected message, with the message's link alone, where the REST API is on (it is off by default) and a public base URL for such links is set; and by any account, from 6.3.2 through the webmail's send and draft routes and from 6.3.4 through its other routes granted 16 MB and the send API; the webmail's send, draft and settings routes parsed the body again for each member read. The REST API serves every request on four worker threads, in the process that also serves SMTP, IMAP and POP3, so a few such documents at once make it unavailable and can exhaust the machine's memory and end the whole service. This is a separate defect from CVE-2026-107574, the reader's handling of duplicate member names, fixed in 6.3.6." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.2", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-770: Allocation of Resources Without Limits or Throttling", + "cweId": "CWE-770", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/110" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "NONE", + "integrityImpact": "NONE", + "availabilityImpact": "HIGH", + "baseScore": 7.5, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, whose JSON reader moves each value into its place rather than copying it, and in which a REST request body is parsed within the bounds before any handler reads it, and the shared member readers read that one parse; a REST request body is held to 100,000 values, 10,000 members in an object and 32 levels, and a mailed TLS-RPT report to 200,000 values, 10,000 members in an object and 32 levels, each refused at the first value past a bound; the reply to a password-protected message is held to 2 MB. Until then, on 6.3.4 to 6.3.7, clear each domain's report mailbox, or move it off the domains the server hosts, so that no report is read by the server; and switch OpenPGP in the webmail off (portal_enabled under /api/v1/settings/openpgp), and off for any domain or account that holds openpgp_portal_enabled on, which refuses the reply to a password-protected message before its body is parsed; clearing the public base URL is not enough, since links already made stay usable. For the routes that take an account or an API key, only limiting who can reach the REST API avoids it (RestApiPort 0, the default, turns it off), or a reverse proxy in front of it that holds request bodies well below 16 MB. Restarting the service ends a busy thread." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:31:12.127Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126614.json b/data/2026/126xxx/CVE-2026-126614.json new file mode 100644 index 0000000000..cafb43fdc9 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126614.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126614", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:49.376Z", + "datePublished": "2026-11-11T08:32:32.127Z", + "dateUpdated": "2026-11-11T08:32:32.127Z" + }, + "containers": { + "cna": { + "title": "Improper Restriction of Excessive Authentication Attempts in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "The web services listener of Progressive Robot hMailServer 6.3.3 through 6.3.7 does not apply the server's IP ranges to the connections it accepts, which allows a remote unauthenticated attacker to go on guessing account passwords at the listener's sign-ins after the auto-ban has banned the attacker's address. The listener is off by default (WebServicesHttpPort and WebServicesHttpsPort 0). From 6.3.3 its CardDAV, and from 6.3.4 its CalDAV and its Outlook Autodiscover answer to a request that carries credentials, sign an account in with HTTP Basic over HTTPS. A failed sign-in there counts towards the auto-ban as a failed logon on any other protocol does: when the failures counted from one address reach MaxInvalidLogonAttempts (3 within 30 minutes by default), the server writes an IP range that refuses the address for AutoBanMinutes (60 by default), and the SMTP, POP3, IMAP and ManageSieve listeners refuse it. The web services listener asked no IP range when it accepted a connection (in 6.3.3 nothing, from 6.3.4 the country policy alone), so it went on serving such an address, whether its ban had been earned there or on another protocol, and also an address that an administrator's IP range allowing nothing holds. Each failed sign-in there closed only its own connection, and the next connection was accepted, during the ban and after it. The firewall rule and command the auto-ban can drive (AutoBanFirewall and AutoBanCommand, off by default) are told only the SMTP, POP3 and IMAP ports, so that the firewall rule and the packaged hook did not close the listener's ports, and the fail2ban jail packaged for Linux (off by default) lists only the mail and ManageSieve ports. The only limit left on the guesses at one account there was the per-name lockout (AccountLockoutThreshold in hMailServer.ini, 0, off, by default), which has a separate defect fixed in the same release. The flaw is reached on the listener's HTTPS port: behind a TLS-terminating proxy the listener sees the proxy's address for every client, and a ban never named the client there." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.3", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-307: Improper Restriction of Excessive Authentication Attempts", + "cweId": "CWE-307", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/105" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "LOW", + "integrityImpact": "NONE", + "availabilityImpact": "NONE", + "baseScore": 5.3, + "baseSeverity": "MEDIUM" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8. Its web services listener reads, once for each connection and before the TLS handshake, the IP range that decides for the address, and closes the connection without an answer when that range allows none of SMTP, POP3 and IMAP - every auto-ban, and an administrator's range that allows nothing - or when the ranges cannot be read; an address no range holds is let in, and loopback and the addresses in WebServicesTrustedProxies are never refused by a range. A connection opened before the ban has at most one guess after it, since every failed sign-in closes its connection. After the upgrade an administrator's range that allows none of the three also closes this listener - MTA-STS, ACME http-01 when this listener answers it, CalDAV, CardDAV, Autodiscover, autoconfiguration, the Web Key Directory, security.txt, the S/MIME root and CRL and the Apple profiles - to the addresses it holds, and such a refusal by a range that does not expire is named in the application log, once an hour for each address. Until then, keep WebServicesHttpsPort at 0 or reachable from trusted networks only, or block the listener's ports below the server: an AutoBanCommand of the administrator's own, which is run for every ban the server writes, can block the address on the listener's ports as well as on the ports it is told, for as long as the ban lasts; on Linux, turning the packaged fail2ban jail on (it is off as packaged) and adding the listener's ports to its port line blocks there, by the jail's own count (five matching lines within ten minutes as packaged; maxretry = 3 and findtime = 30m match the auto-ban's defaults), an address that goes on failing at the listener, where application logging is on (off by default), since its filter matches the \"Auto-ban: logon failure\" lines these sign-ins write. Turning on the per-name lockout (AccountLockoutThreshold above 0) limits the guesses at each account wherever they come from, within its separate defect. A rate-limiting proxy in front of the listener limits the guessing, but its clients' failures then ban the proxy's own address at the mail listeners unless that address is in AutoBanNeverBan." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:32:32.127Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126615.json b/data/2026/126xxx/CVE-2026-126615.json new file mode 100644 index 0000000000..d874613ec6 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126615.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126615", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:54.378Z", + "datePublished": "2026-11-11T08:32:57.155Z", + "dateUpdated": "2026-11-11T08:32:57.155Z" + }, + "containers": { + "cna": { + "title": "Authentication Bypass by Alternate Name in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "The sign-in of Progressive Robot hMailServer 6.2.22-pre2 through 6.3.7 takes for an account names that are not its address but under which the database's own comparison finds it, while the per-name lockout and the compromised-account hold are kept by the name as the client gave it. This allows a remote unauthenticated attacker to go on guessing an account's password beyond the lockout's threshold, and anyone who has the password of an account held for review to sign in to it. The per-name lockout (from 6.2.22-pre2; AccountLockoutThreshold in hMailServer.ini, 0, off, by default) locks a name after repeated failed sign-ins. The hold (from 6.3.4, where the compromised-account detection is set to enforce, which is not the default) refuses an account judged to have been taken over. Both are asked, before the password, of the name the client gave: trimmed, in lower case and with a domain alias or the default domain applied. The account whose password the sign-in then checks is whichever one the database finds under that name. The databases find an account under spellings that this key counts apart. MySQL and MariaDB find it under one with accented letters in place of plain ones, and MariaDB 11.8, in a database made before 6.3.4, also under one with full-width letters, with a single letter in place of a pair of plain ones, or with characters its comparison ignores in any number. SQL Server and SQL Server Compact find it under one with full-width letters or with characters their comparison ignores in any number, and SQL Server also under one with a single letter in place of a pair of plain ones, with a character of Latin-1 in place of a digit and, for an address holding letters of Latin-1 outside ASCII, under those letters in the other case, and, under an accent-insensitive collation, with accented letters. PostgreSQL finds it under one holding a letter whose lower case under the database's locale is a plain letter, and, for an address holding letters outside ASCII, under those letters in the other case; on the build for musl (from 6.3.6) the server's own lower case folds nearly all of these too. On every database, a domain alias saved with white space at the end of its name gives such a spelling too, and on every database but PostgreSQL so does an account's bare local part where the default domain was saved with spaces at its end and no other white space (neither is the default). Each such spelling has a lockout threshold of its own, so the lockout limits the guesses at an account only to its threshold times the number of the account's spellings. That is far beyond any threshold for most addresses on MySQL and MariaDB, and without limit on SQL Server, on SQL Server Compact, the database the Windows installer uses by default, and before 6.3.4 on MariaDB 11.8. A locked name is got round under another spelling. A held account is signed in to under another spelling with its password over IMAP, POP3 and SMTP AUTH, and, where they are turned on (off by default), over ManageSieve, the REST API and the webmail. IMAP LOGIN, offered as installed, carries such spellings on MySQL, MariaDB and SQL Server Compact, and, on SQL Server and PostgreSQL, for some addresses; the sign-ins that carry a name as UTF-8 carry them for the others on SQL Server, and on PostgreSQL for those holding one of the plain letters another letter lowers to or a letter outside ASCII with another case. The same lookup mapped to accounts the names given by an OAuth 2.0 token, a client certificate, a Kerberos ticket and an OpenID Connect or SAML identity provider, where those are set up (none is by default), so that a name an issuer gave to one party could sign in to another's account; OAuth 2.0 tokens were mapped so from 6.2.0, before the per-name lockout existed. A name holding a NUL character, carried from 6.3.0 on Linux and 6.3.3 on Windows, failed the statement on MySQL, MariaDB and PostgreSQL." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.2.22-pre2", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-289: Authentication Bypass by Alternate Name", + "cweId": "CWE-289", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/104" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "LOW", + "integrityImpact": "NONE", + "availabilityImpact": "NONE", + "baseScore": 5.3, + "baseSeverity": "MEDIUM" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8. There a name signs in to an account only when the account's stored address is that name, compared in lower case after a domain alias and the default domain by the function the lockout's key is made with, and a name that reaches the sign-in with white space at either end (POP3's USER takes it off the name it is given, as it always has) signs in to none, whatever the domain aliases hold. Any other spelling fails as a name that does not exist fails, and is counted as such a name is; the country policy asked before the password finds the account by the same rule, so such a spelling meets its domain's policy, as a name that does not exist does. A name a client gives holding a NUL character is refused before any account or domain is looked up with it. Once the password is proved, the lockout, the hold and the country policy of the account whose password it is, and the hold and the country policy of the account signed in to where that is another, as for the IMAP master user, are asked again of the account's own address. The same rule applies to the names a token, a certificate, a Kerberos ticket or an identity provider gives. The password reset keeps its per-address limit under the form of the address that the rule compares and looks up the address it counted, so that a mailbox's recovery address is sent no more links than that limit allows however the address is given. A domain alias's name and the default domain are saved without white space at their ends, and the default domain is read so however it was saved. Until then, an account held for review can be closed by making it inactive, or by changing its password and removing its app passwords, which the sign-in checks on the account it found, whatever spelling it was given, and a domain alias's name or the default domain that ends in white space can be saved again without it. No setting restores the per-name lockout's limit on MySQL, MariaDB, SQL Server or SQL Server Compact; the per-IP auto-ban, on by default, still counts each address's failed sign-ins whatever spelling they use. Keeping the web services listener off (the default) or reachable only from trusted clients keeps names holding a NUL character from the database on Windows; on Linux IMAP LOGIN carries them too." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:32:57.155Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126616.json b/data/2026/126xxx/CVE-2026-126616.json new file mode 100644 index 0000000000..3f372b43f3 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126616.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126616", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:04:59.386Z", + "datePublished": "2026-11-11T08:33:02.130Z", + "dateUpdated": "2026-11-11T08:33:02.130Z" + }, + "containers": { + "cna": { + "title": "Improper Restriction of Excessive Authentication Attempts in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "The auto-ban of Progressive Robot hMailServer 6.2.0 through 6.3.3, with a MySQL or MariaDB database, can be kept from banning an address after repeated failed logons, which allows a remote unauthenticated attacker to go on guessing account passwords from a single address without being banned. The server makes its MySQL tables in MySQL's utf8 character set, which holds no character outside the Basic Multilingual Plane, sends its statements as UTF-8 over a utf8mb4 connection and leaves the database's default strict mode in place. From 6.2.0 it decodes the user name of a SASL PLAIN logon as UTF-8, so the name can hold such a character. When the failed logons counted from one address reach MaxInvalidLogonAttempts (3 by default), the server clears that address's count, saves an IP range named \"Auto-ban: \" followed by the user name of the logon that reached the limit, and drops the connection. If such a character is in the part of the user name that the range's name keeps (the name is cut to 100 characters), the database refuses the range: no range is saved, the address is not refused, and, its count having already been cleared, it is given the next full set of attempts. An attacker can in this way spend all but the last attempt of each set on password guesses, and make the last under such a name. On Windows, POP3 AUTH PLAIN reaches it on a server as installed, and IMAP AUTHENTICATE PLAIN where IMAP SASL authentication is turned on (off by default); on Windows and on Linux (from 6.3.0), SMTP AUTH PLAIN reaches it where plain-text authentication is allowed (off by default), and ManageSieve and CardDAV where they are turned on (off by default). Each failed save is reported in the server's error log. A database whose strict mode has been turned off stores the character as a question mark and makes the first such ban, but refuses every later ban named after the same user name, or after one holding other such characters in their place, as a duplicate while the first stands, since the server cannot look up a name holding such a character there." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.2.0", + "status": "affected", + "lessThanOrEqual": "6.3.3", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-307: Improper Restriction of Excessive Authentication Attempts", + "cweId": "CWE-307", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/103" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.4" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "LOW", + "integrityImpact": "NONE", + "availabilityImpact": "NONE", + "baseScore": 5.3, + "baseSeverity": "MEDIUM" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.4 or later, whose database schema 6102 converts every MySQL and MariaDB table to utf8mb4, and which runs only on a database upgraded to its schema; 6.3.8 also fixes a separate way round the auto-ban. Until then, converting the IP range table as that step does (ALTER TABLE hm_securityranges ENGINE=InnoDB, ROW_FORMAT=DYNAMIC, CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci) lets the database store such a name, and setting MaxInvalidLogonAttempts to 1 closes this way round, since every failed logon then reaches the limit by itself, and a guess at an account, made under a name the table can hold, is banned under it." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:33:02.130Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126617.json b/data/2026/126xxx/CVE-2026-126617.json new file mode 100644 index 0000000000..a318513929 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126617.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126617", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:05:04.379Z", + "datePublished": "2026-11-11T08:33:22.129Z", + "dateUpdated": "2026-11-11T08:33:22.129Z" + }, + "containers": { + "cna": { + "title": "Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "SQL injection in the database layer of Progressive Robot hMailServer 6.0.0-B1 through 6.2.18, when the server uses MySQL/MariaDB or PostgreSQL, allows a remote attacker to alter SQL statements the server runs. On those two engines parameters are not bound: SQLStatement::GenerateFromCommand wrote each value into the statement's text as a quoted literal with a separate string replacement over the whole text per parameter, so a value holding the name of a parameter substituted after it had that name replaced, inside the value, by the later value with its own quotes, which ended the literal early and placed the later value in the statement as SQL. The row the server writes for each recipient of a queued message carries the recipient's address twice, so in the default configuration an authenticated user who may send mail reaches it by sending to an address of their choosing. A remote unauthenticated sender reaches the same statement through a message the server sends to the envelope sender, such as a delivery failure notice or an automatic reply, and, when greylisting or message indexing is enabled (both are off by default), through the greylisting record's envelope addresses or through the message metadata the server stores for IMAP SORT, which carries four header fields of a received message. An altered statement runs with the privileges of the server's database account; on PostgreSQL, whose client call runs every statement in the text it is given, further statements can follow it, while on MySQL/MariaDB, where one statement is run per call, the change is confined to the statement it is in. SQL Server and SQL Server Compact, where parameters are bound, are not affected." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.0.0-B1", + "status": "affected", + "lessThanOrEqual": "6.2.18", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')", + "cweId": "CWE-89", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/101" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.2.19" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "LOW", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 8.8, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.2.19 or later, which substitutes parameters in a single pass that never re-examines a value already written into the statement, and gives each parameter a name no other parameter's name and ordinal can form. There is no complete workaround for earlier versions on MySQL/MariaDB or PostgreSQL, since the recipient row is written for every queued message; keeping message indexing (MessageIndexing) and greylisting off, as they are by default, removes those two paths only. SQL Server and SQL Server Compact installations need no action for this issue." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:33:22.129Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126618.json b/data/2026/126xxx/CVE-2026-126618.json new file mode 100644 index 0000000000..d6b599e66d --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126618.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126618", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:05:09.446Z", + "datePublished": "2026-11-11T08:33:12.130Z", + "dateUpdated": "2026-11-11T08:33:12.130Z" + }, + "containers": { + "cna": { + "title": "Improper Restriction of Excessive Authentication Attempts in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "The auto-ban of Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 can be kept from banning an address after repeated failed logons, which allows a remote unauthenticated attacker who can connect from two or more addresses to go on guessing account passwords - over SMTP AUTH, IMAP and POP3, and over ManageSieve, CalDAV/CardDAV and the REST API where those are turned on (off by default) - without being banned. When the failed logons counted from one address reach MaxInvalidLogonAttempts (3 by default), the server clears that address's count, saves an IP range that refuses the address for AutoBanMinutes (60 by default) and drops the connection. The range is named \"Auto-ban: \" followed by the user name of the logon that reached the limit, and no two ranges may have the same name. The server chooses the name by checking candidates as written - the name, then the name with a number, a random suffix or a GUID added - and only then cuts it to the 100 characters the database column holds, so that with a user name of 90 characters or more every candidate is the same once cut. While one range named after such a user name stands, every later ban named after a user name with the same first 90 characters therefore fails at the database: no range is saved, the address is not refused, and, its count having already been cleared, it is given the next full set of attempts. A user name of 78 to 89 characters makes later bans fail in the same way: from the second, the third or the twelfth on, depending on its length and the database, or, from 78 to 85 characters, by chance. An attacker who has once had an address banned under such a name can in this way keep guessing passwords from any other address, ending each set of attempts with a logon under a name of that kind; each failed save is reported in the server's error log (as the database error HM5032, and from 6.2.19 also as HM6099). On SQL Server a user name holding characters outside the database's code page has the same effect at any length, because the check compared names in that code page; that save is refused by the server's own check of the name, with no database error, and is reported only from 6.2.19 (HM6099). A user name holding a NUL character, which the web services listener's HTTP Basic sign-in (off by default) carries from 6.3.3 and, on the Linux builds, IMAP LOGIN, offered as installed, from 6.3.0, makes bans fail at any length: on MySQL, MariaDB and PostgreSQL the statements that check the name and save the range end at the character, so that every ban named after such a name fails, from the first and from a single address, and, its count having already been cleared, the address is given the next full set of attempts; on SQL Server and SQL Server Compact the name is bound only as far as the character, so that while one range under the part before it stands, every later ban named after such a name fails. On SQL Server, and on MySQL and MariaDB for an account whose local part has nine characters or more, a guess at the account can itself carry a name of that kind, since those databases find an account under its address followed by spaces (and SQL Server also under one holding characters its comparison ignores), so that not even a MaxInvalidLogonAttempts of 1, which bans each failed logon under the name it gave, avoids it there." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.0.0-B1", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-307: Improper Restriction of Excessive Authentication Attempts", + "cweId": "CWE-307", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/102" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "LOW", + "integrityImpact": "NONE", + "availabilityImpact": "NONE", + "baseScore": 5.3, + "baseSeverity": "MEDIUM" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, which chooses an auto-ban's range name as the database will store it, keeping the part that makes it unique within the column's 100 characters, checks that exact name through a bound parameter, tries once more under a name unique by construction if the save still fails, and clears an address's counted failures only once its range has been saved, so that a ban that could not be saved is tried again at the address's next failure. Until then no setting of the auto-ban avoids it on MySQL, MariaDB or SQL Server; on PostgreSQL, MaxInvalidLogonAttempts 1, which bans an address at its first failed logon, avoids it for every account whose address, as the logon gives it, is shorter than 78 characters. From 6.3.2, where application logging is on (off by default), a filter outside the server on the \"Auto-ban: logon failure\" line it writes for every counted failure, such as fail2ban, still sees each address's failures and can block it." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:33:12.130Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126619.json b/data/2026/126xxx/CVE-2026-126619.json new file mode 100644 index 0000000000..8fd851868b --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126619.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126619", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:05:14.382Z", + "datePublished": "2026-11-11T08:33:47.151Z", + "dateUpdated": "2026-11-11T08:33:47.151Z" + }, + "containers": { + "cna": { + "title": "Misinterpretation of Input in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "Misinterpretation of SQL statement text in the database layer of Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 allows a remote unauthenticated attacker to have a failed database write reported to the server as successful. The layer answers a failed statement as a success when it finds the marker [IGNORE-ERRORS], which is meant only for the server's own schema statements (its upgrade scripts and the database log's tables), and statements carry values from outside - an envelope address, the user name of a failed logon, a message's headers - in their text on MySQL/MariaDB and PostgreSQL, and in the batches of the database log on every engine. Up to 6.2.18 the marker was honoured anywhere in a statement, a value included, on MySQL/MariaDB and PostgreSQL. From 6.2.19 it was honoured only inside a comment, but the layer read a backslash inside a string literal as an escape, which SQL Server, SQL Server Compact and PostgreSQL with standard_conforming_strings on (its default) do not, so that on those engines a value holding a backslash could make the layer take part of the statement's literals for statement text and find the marker there: on PostgreSQL from 6.3.3 for every statement carrying an outside value that holds a backslash, with no setting changed for a message delivered into a local mailbox (through an internationalised (SMTPUTF8) envelope sender) and for the IP range an auto-ban writes (named after the user name of the failed logon), and on SQL Server and SQL Server Compact for the database log, when the server logs to the database (logging is off, and the log device is files, by default). A statement run outside a transaction that then failed - a constraint, a deadlock, a lock or statement timeout, a full disk, and up to 6.2.18 a lost connection - was answered as a success, and its caller went on as if the row had been written: a message delivered into a local mailbox could be counted as delivered with no row to show it and no failure notice to its sender, and a message accepted with 250 could be left with no queue row and never delivered (up to 6.2.18, and on PostgreSQL from 6.3.3 when every recipient's address carries the marker too, which needs an address that takes any local part); an auto-ban whose IP range was not written could be logged and counted as applied, with no error reported, while the address stayed unbanned; and message metadata (written only when message indexing is on), entries of the database log and rows of features an administrator turns on could be lost without an error. On MySQL/MariaDB up to 6.2.18 the caller was handed whatever identifier the client library still held for the connection - 0, or that of an insert its last successful statement made, in whatever table - under which a queued message's recipients were then written, so that another message still in the queue could be delivered to them as well. This flaw gives a value no way to change what a statement does, and no privilege is gained." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.0.0-B1", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-115: Misinterpretation of Input", + "cweId": "CWE-115", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/100" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N", + "attackVector": "NETWORK", + "attackComplexity": "HIGH", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "LOW", + "integrityImpact": "LOW", + "availabilityImpact": "NONE", + "baseScore": 4.8, + "baseSeverity": "MEDIUM" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, which reads each string literal as the database engine reads it - a backslash as an escape only on MySQL/MariaDB, on PostgreSQL with standard_conforming_strings off and in PostgreSQL's E'...' strings - when it looks for the marker, so that no value can reach the comment where the marker is honoured, and which reads literals the same way when it masks them in the slow-query log line and the trace. Until then, on SQL Server and SQL Server Compact keep logging off or the log device on files (the defaults); on PostgreSQL 6.3.3 to 6.3.7, and on MySQL/MariaDB and PostgreSQL before 6.2.19, no setting of the server avoids it." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:33:47.151Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126621.json b/data/2026/126xxx/CVE-2026-126621.json new file mode 100644 index 0000000000..42793204ff --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126621.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126621", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:30:22.140Z", + "datePublished": "2026-11-11T08:36:26.283Z", + "dateUpdated": "2026-11-11T08:36:26.283Z" + }, + "containers": { + "cna": { + "title": "Improper Certificate Validation in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "Progressive Robot hMailServer 6.0.0-B1 through 6.3.7 on Windows hands OpenSSL the names of its own TLS files - the listeners' certificates, chains, private keys and Diffie-Hellman parameters, a port's client-certificate CA file (from 6.2.19), the object store's CA file (from 6.3.4) and the ACME client's keys and certificates - as Latin-1 bytes, which on code page 1252 are the code page's own for U+00A0 to U+00FF, and OpenSSL's file opening on Windows reads a name as UTF-8 first and opens the file at that reading when it is there, or creates it there when its folder is. When every byte of a configured name outside ASCII also reads as UTF-8 - for example U+00C3 U+00A9, the bytes C3 A9, which are U+00E9 in UTF-8 - the server used the file at that other name whenever one was there, which allows a local attacker who can create that file or its folder but cannot change the configured one, as any user can by default beside a file an administrator keeps under ProgramData, to have a port that logs on by client certificate (from 6.2.25) accept certificates from a certificate authority of the attacker's own and so sign in over the network as any mailbox without its password; to have the server trust such an authority for its object store and, intercepting that connection, read and modify the messages it stores; to receive the private keys the ACME client writes, the key of a certificate issued for the server's names among them; or to keep TLS ports from starting. The configuration is not the default: by default these files have names in ASCII, client certificates are off on every port, and the object store and ACME are off. The Linux builds are not affected." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.0.0-B1", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-295: Improper Certificate Validation", + "cweId": "CWE-295", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/115" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", + "attackVector": "NETWORK", + "attackComplexity": "HIGH", + "privilegesRequired": "LOW", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 7.5, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, which on Windows hands OpenSSL the name of each of these files in the code page and refuses, with HM7536 in the error log, a name with a character the code page does not have or whose bytes outside ASCII also read as UTF-8, so that nothing is read from or written to a refused file: a listener whose certificate or key file is refused does not start, a refused client-certificate CA file verifies no certificate, the object store's refused CA file allows no request, and the ACME client orders no certificate. Until then, name every TLS file, the ACME directory and the program and data folders by paths in ASCII alone, which read as the same name in the code page and in UTF-8 and which every affected version hands over unchanged; where a name outside ASCII must stay, keep each of its characters at or below U+00FF and one the system code page writes as its Latin-1 byte (on code page 1252, U+00A0 to U+00FF; none under a UTF-8 code page) - change any other name to ASCII - and make sure no one else can create the file or folder that the name's UTF-8 reading names." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:36:26.283Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126622.json b/data/2026/126xxx/CVE-2026-126622.json new file mode 100644 index 0000000000..9da054ab07 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126622.json @@ -0,0 +1,104 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126622", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:30:47.169Z", + "datePublished": "2026-11-11T08:31:37.129Z", + "dateUpdated": "2026-11-11T08:31:37.129Z" + }, + "containers": { + "cna": { + "title": "Incorrect Default Permissions in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "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 runs setup, when the server is installed into a program folder that is already there and that accounts other than the administrators could write, such as a folder made beforehand at the root of a drive, or when such an installation is upgraded or repaired. 6.3.7 fixed CVE-2026-107571 by giving the program folder, Bin and ControlPanel permissions that only administrators may change, but for a folder that is already there it does so only at the end of setup: setup first copies the programs into Bin, which every user may still write, and runs programs from Bin with the administrator's elevated rights, registering the service among them, before that hardening, so that a library another account places in Bin meanwhile is loaded in place of the system's. A handle an account opened on such a folder while it could write it keeps that access after the hardening. The default installation under Program Files, whose folders give ordinary users read and execute only, is not affected." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.7", + "status": "affected" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-276: Incorrect Default Permissions", + "cweId": "CWE-276", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/78" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + }, + { + "url": "https://www.cve.org/CVERecord?id=CVE-2026-107571" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H", + "attackVector": "LOCAL", + "attackComplexity": "LOW", + "privilegesRequired": "LOW", + "userInteraction": "REQUIRED", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 7.3, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, whose setup hardens a program folder, Bin and ControlPanel that are already there before it stops the service, copies a file or runs a program of the installation, reading each through a handle it holds; refuses to install into one it cannot harden, or one another account owns that is not the earlier installation's; makes an empty Bin or ControlPanel again rather than use it; and, where another account could change one of the program's folders before this installation, hardens it and refuses to install until Windows has restarted, which closes any handle opened while it could. Until then, install hMailServer under Program Files, or into a new folder inside one that only administrators may change. Before running setup into or over a program folder in a location other accounts can write, follow from an elevated Command Prompt the steps in the hMailServer documentation, ServiceAccount.md, \"Before upgrading an installation at a drive's root\", which make the program folder, Bin and ControlPanel the Administrators' with a protected set of permissions, then restart Windows before running setup. Where accounts that are not administrators could change the folder before, reinstall into a new folder as that page's \"Reinstalling into a new folder\" says." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:31:37.129Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126623.json b/data/2026/126xxx/CVE-2026-126623.json new file mode 100644 index 0000000000..042083e259 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126623.json @@ -0,0 +1,106 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126623", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:30:57.135Z", + "datePublished": "2026-11-11T08:31:47.129Z", + "dateUpdated": "2026-11-11T08:31:47.129Z" + }, + "containers": { + "cna": { + "title": "Inefficient Algorithmic Complexity in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "Inefficient algorithmic complexity in the JSON reader of Progressive Robot hMailServer 6.3.6 and 6.3.7 allows a remote attacker to hold the server's mail delivery threads or its REST API's worker threads, making mail delivery, the REST API and the webmail unavailable. 6.3.6 fixed CVE-2026-107574, in which reading a JSON object searched the member names already read for each new name, by keeping the names in a hash set; the set uses the standard library's hash, which takes no secret, so member names chosen to fall in one bucket of it still cost time growing with the square of their number. Against the released reader, one such object of 16 MB took about 5 seconds to read in the Linux build, and one of under 6 MB about 23 seconds in the Windows build, where objects of the same sizes with other names took under a tenth of a second. A remote unauthenticated attacker reaches the reader by mailing such an object as a TLS-RPT report, up to 16 MB once decompressed, to a hosted domain's report mailbox, where an administrator has set one; it is read on a mail delivery thread (ten by default), and those threads deliver all mail, local and outbound, so a stream of such reports stops all delivery for as long as it continues. It is also reached without an account through the reply to a password-protected message, with the message's link alone, where the REST API is on (it is off by default) and a public base URL for such links is set; and by any account through the webmail's routes granted 16 MB, and by an application's API key through the send API. Each such request holds one of the REST API's four worker threads, in the process that also serves SMTP, IMAP and POP3." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.6", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-407: Inefficient Algorithmic Complexity", + "cweId": "CWE-407", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/111" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + }, + { + "url": "https://www.cve.org/CVERecord?id=CVE-2026-107574" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "NONE", + "integrityImpact": "NONE", + "availabilityImpact": "HIGH", + "baseScore": 7.5, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, whose JSON reader keeps an object's member names in an ordered set, whose cost does not depend on which names are chosen, and holds a REST request body and a mailed TLS-RPT report to 10,000 members in an object; the reply to a password-protected message is held to 2 MB. Until then, clear each domain's report mailbox, or move it off the domains the server hosts, so that no report is read by the server; and switch OpenPGP in the webmail off (portal_enabled under /api/v1/settings/openpgp), and off for any domain or account that holds openpgp_portal_enabled on, which refuses the reply to a password-protected message before its body is parsed; clearing the public base URL is not enough, since links already made stay usable. For the routes that take an account or an API key, only limiting who can reach the REST API avoids it (RestApiPort 0, the default, turns it off), or a reverse proxy in front of it that holds request bodies well below 16 MB. Restarting the service ends a busy thread." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:31:47.129Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126624.json b/data/2026/126xxx/CVE-2026-126624.json new file mode 100644 index 0000000000..41ef29adef --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126624.json @@ -0,0 +1,104 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126624", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:31:02.145Z", + "datePublished": "2026-11-11T08:31:52.133Z", + "dateUpdated": "2026-11-11T08:31:52.133Z" + }, + "containers": { + "cna": { + "title": "Unverified Ownership in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "Unverified ownership in the Windows installer of Progressive Robot hMailServer 6.3.7 allows a local authenticated user to run code as the mail server's service account or as an administrator when setup installs into, or upgrades, a program folder that accounts other than the administrators could write before, such as one made beforehand at 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 setup refused nothing that was already in them, or in the folders that hold the event script, the add-ons and the database scripts: a program, a library, a script or a settings file that another account owns, or whose own permissions let another account change it, is kept with that owner and those permissions, which the hardening of the folders does not take away. Setup then runs programs from Bin with the administrator's elevated rights, and the service, which runs as LocalSystem or as its virtual account, runs them and the event script, so that a library such an account placed in Bin is loaded in place of the system's; the account can still change the file after the installation. The default installation under Program Files is not affected." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.7", + "status": "affected" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-283: Unverified Ownership", + "cweId": "CWE-283", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/78" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + }, + { + "url": "https://www.cve.org/CVERecord?id=CVE-2026-107571" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H", + "attackVector": "LOCAL", + "attackComplexity": "LOW", + "privilegesRequired": "LOW", + "userInteraction": "REQUIRED", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 7.3, + "baseSeverity": "HIGH" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, whose setup looks, before it stops the service and again once the folders are hardened, at everything in Bin and ControlPanel, on the program folder's own level, and in Addons, Events, DBScripts, WebAdmin, Languages and MySQL, and refuses with exit code 7 to install where a program, a library, a script, a settings file or a folder there is owned by anybody but SYSTEM, the Administrators or TrustedInstaller, has an owner that cannot be read, or has an entry of its own that lets another account change it, naming each with the icacls that deals with it and a restart of Windows before setup runs again. Until then, install hMailServer under Program Files, or into a new folder inside one that only administrators may change. Before running setup into or over a program folder that other accounts could write, list the owners from an elevated Command Prompt - dir /q /a \"\" and dir /q /s /a over its Bin, ControlPanel, Events, WebAdmin, DBScripts, Addons, Languages and MySQL, as the hMailServer documentation, ServiceAccount.md, \"Before upgrading an installation at a drive's root\", gives them for all but MySQL - and the entries of their own, with icacls \"\" and icacls \"\" /T over the same folders, where an entry not marked (I) that gives anybody but SYSTEM, the Administrators or TrustedInstaller a right to change the item is another account's (the service's own Modify on hMailServerApiKeys.ini in Bin apart); where anybody but those owns anything there, or has such an entry, do not install over it: reinstall into a new folder as that page's \"Reinstalling into a new folder\" says." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:31:52.133Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126625.json b/data/2026/126xxx/CVE-2026-126625.json new file mode 100644 index 0000000000..a0fbe1a345 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126625.json @@ -0,0 +1,104 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126625", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:31:07.141Z", + "datePublished": "2026-11-11T08:31:57.131Z", + "dateUpdated": "2026-11-11T08:31:57.131Z" + }, + "containers": { + "cna": { + "title": "Incorrect Default Permissions in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "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." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.7", + "status": "affected" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-276: Incorrect Default Permissions", + "cweId": "CWE-276", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/78" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + }, + { + "url": "https://www.cve.org/CVERecord?id=CVE-2026-107571" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H", + "attackVector": "LOCAL", + "attackComplexity": "HIGH", + "privilegesRequired": "LOW", + "userInteraction": "REQUIRED", + "scope": "UNCHANGED", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "availabilityImpact": "HIGH", + "baseScore": 6.7, + "baseSeverity": "MEDIUM" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, whose setup makes a new program folder, every folder above it that is not there, and Bin and ControlPanel in it, with permissions of their own from the moment each exists - SYSTEM and the Administrators full control, Users read and execute, nothing inherited, the Administrators the owner - before Inno Setup makes a folder or copies a file, each made by its name relative to the folder above it, which setup holds open. Until then, install hMailServer under Program Files, or into a new folder inside a folder that only administrators may change. To install elsewhere, first make the program folder from an elevated Command Prompt and give it a protected set of permissions - icacls \"\" /inheritance:r /grant:r *S-1-5-18:(OI)(CI)F *S-1-5-32-544:(OI)(CI)F *S-1-5-32-545:(OI)(CI)RX, then icacls \"\" /setowner *S-1-5-32-544 - check with dir /q /a \"\" that nothing has been made in it, and restart Windows before running setup, so that nothing opened in it before its permissions were set stays open." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:31:57.131Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/126xxx/CVE-2026-126626.json b/data/2026/126xxx/CVE-2026-126626.json new file mode 100644 index 0000000000..3ec090c703 --- /dev/null +++ b/data/2026/126xxx/CVE-2026-126626.json @@ -0,0 +1,103 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-126626", + "assignerOrgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "state": "PUBLISHED", + "assignerShortName": "GitLab", + "dateReserved": "2026-11-11T08:36:36.171Z", + "datePublished": "2026-11-11T08:36:46.162Z", + "dateUpdated": "2026-11-11T08:36:46.162Z" + }, + "containers": { + "cna": { + "title": "Overly Restrictive Account Lockout Mechanism in hMailServer", + "descriptions": [ + { + "lang": "en", + "value": "The web services listener of Progressive Robot hMailServer 6.3.3 through 6.3.7 counts every failed CardDAV, CalDAV or Autodiscover sign-in from a proxy it trusts - one on the same machine, or one named in WebServicesTrustedProxies, whose X-Forwarded-Proto it believes - against the proxy's own address, which allows a remote unauthenticated attacker who can reach the proxy to have that address banned from the server's mail listeners. The listener, off by default (WebServicesHttpPort and WebServicesHttpsPort 0), signs an account in with HTTP Basic over HTTPS for CardDAV from 6.3.3 and for CalDAV and Outlook Autodiscover from 6.3.4. Behind a TLS-terminating proxy, which the server trusts when it is on the same machine or named in WebServicesTrustedProxies, the listener takes the client's HTTPS from the proxy's X-Forwarded-Proto header, but it does not believe X-Forwarded-For and sees the proxy's address for every client. Each failed sign-in counted towards the auto-ban against that address, so that failed sign-ins through the proxy from anybody, under any user name, reaching MaxInvalidLogonAttempts (3 within 30 minutes by default) wrote an IP range that refused the proxy's address at the SMTP, POP3, IMAP and ManageSieve listeners for AutoBanMinutes (60 by default), and could write it again each time it lapsed. For a proxy on the same machine that address is the loopback address, so that a webmail on that machine, local scripts that submit mail and the other local clients of the mail listeners were shut out; for a proxy at another address that also carries mail, every mail client behind it was. Such a proxy forwarding to the listener's HTTPS port, re-encrypting, was counted against in the same way, and listing it in WebServicesTrustedProxies did not spare it. The auto-ban is on by default and AutoBanNeverBan, which spares an address, is empty by default; the listener itself went on serving the proxy." + } + ], + "affected": [ + { + "vendor": "Progressive Robot Ltd", + "product": "hMailServer", + "repo": "https://gitlab.com/hmailserver/hmailserver", + "versions": [ + { + "version": "6.3.3", + "status": "affected", + "lessThanOrEqual": "6.3.7", + "versionType": "semver" + } + ], + "defaultStatus": "unaffected" + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "lang": "en", + "description": "CWE-645: Overly Restrictive Account Lockout Mechanism", + "cweId": "CWE-645", + "type": "CWE" + } + ] + } + ], + "references": [ + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/work_items/106" + }, + { + "url": "https://gitlab.com/hmailserver/hmailserver/-/releases/v6.3.8" + } + ], + "metrics": [ + { + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ], + "cvssV3_1": { + "version": "3.1", + "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L", + "attackVector": "NETWORK", + "attackComplexity": "LOW", + "privilegesRequired": "NONE", + "userInteraction": "NONE", + "scope": "UNCHANGED", + "confidentialityImpact": "NONE", + "integrityImpact": "NONE", + "availabilityImpact": "LOW", + "baseScore": 5.3, + "baseSeverity": "MEDIUM" + } + } + ], + "solutions": [ + { + "lang": "en", + "value": "Upgrade to hMailServer 6.3.8, in which a failed sign-in at the web services listener from loopback or from an address in WebServicesTrustedProxies is counted against the user name alone, towards the per-name lockout (AccountLockoutThreshold in hMailServer.ini, 0, off, by default), and never towards a ban of the address, as for an address in AutoBanNeverBan; a failure from any other address counts as before. A proxy at another address that is not listed, forwarding to the HTTPS port, is not taken for a proxy and is charged as before, as a load balancer is at the mail listeners, until its address is in WebServicesTrustedProxies; from 6.3.8 a ban its clients earn also closes the web services listener to it. Through a proxy the per-name lockout is then the limit on the guesses at one account, so turn it on there. Until then, put the proxy's address in AutoBanNeverBan (127.0.0.1 and ::1 for a proxy on the same machine), which keeps the auto-ban from counting that address's failed logons on any protocol; turning the auto-ban on failed logons off, or setting MaxInvalidLogonAttempts or AutoBanMinutes to 0, also avoids it, for every address. From 6.3.6 the never-ban list by reverse name spares a proxy at another address whose forward-confirmed reverse name it covers, lifting the ban once the name is confirmed; it cannot name loopback." + } + ], + "credits": [ + { + "lang": "en", + "value": "Found by the hMailServer project (Progressive Robot Ltd)", + "type": "finder" + } + ], + "providerMetadata": { + "orgId": "ceab7361-8a18-47b1-92ba-4d7d25f6715a", + "shortName": "GitLab", + "dateUpdated": "2026-11-11T08:36:46.162Z" + } + } + } +} \ No newline at end of file diff --git a/data/2026/18xxx/CVE-2026-18767.json b/data/2026/18xxx/CVE-2026-18767.json new file mode 100644 index 0000000000..e906bb435f --- /dev/null +++ b/data/2026/18xxx/CVE-2026-18767.json @@ -0,0 +1,312 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-18767", + "assignerOrgId": "270ccfa6-a436-4e77-922e-914ec3a9685c", + "state": "PUBLISHED", + "assignerShortName": "CERTVDE", + "dateReserved": "2026-08-04T07:16:35.058Z", + "datePublished": "2026-11-11T08:19:35.444Z", + "dateUpdated": "2026-11-11T08:19:35.444Z" + }, + "containers": { + "cna": { + "affected": [ + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x64 3.1.0.2364", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.1.0.2364" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x64 <3.1.0.2365", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.1.0.2365", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x86 3.1.0.2364", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.1.0.2364" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x86 <3.1.0.2365", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.1.0.2365", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TwinCAT.XAR.Base.KM 3.16.29", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.16.29" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TwinCAT.XAR.Base.KM <3.18.1", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.18.1", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + } + ], + "cpeApplicability": [ + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:3.1.0.2364:*:*:*:*:Windows:x64:*", + "versionStartIncluding": "3.1.0.2364", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:*:*:*:*:*:Windows:x64:*", + "versionEndExcluding": "3.1.0.2365", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:3.1.0.2364:*:*:*:*:Windows:x86:*", + "versionStartIncluding": "3.1.0.2364", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:*:*:*:*:*:Windows:x86:*", + "versionEndExcluding": "3.1.0.2365", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:twincat.xar.base.km:3.16.29:tcpkg:*:*:*:Windows:*:*", + "versionStartIncluding": "3.16.29", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:twincat.xar.base.km:tcpkg:*:*:*:*:Windows:*:*", + "versionEndExcluding": "3.18.1", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + } + ], + "credits": [ + { + "lang": "en", + "type": "finder", + "value": "Chi Siang Choo from 4rthur Security Team" + }, + { + "lang": "en", + "type": "finder", + "value": "Julian Horoszkiewicz" + }, + { + "lang": "en", + "type": "finder", + "value": "Patrick Saif" + } + ], + "descriptions": [ + { + "lang": "en", + "supportingMedia": [ + { + "base64": false, + "type": "text/html", + "value": "

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.

" + } + ], + "value": "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." + } + ], + "metrics": [ + { + "cvssV4_0": { + "Automatable": "NOT_DEFINED", + "Recovery": "NOT_DEFINED", + "Safety": "NOT_DEFINED", + "attackComplexity": "LOW", + "attackRequirements": "NONE", + "attackVector": "LOCAL", + "baseScore": 8.5, + "baseSeverity": "HIGH", + "privilegesRequired": "LOW", + "providerUrgency": "NOT_DEFINED", + "subAvailabilityImpact": "NONE", + "subConfidentialityImpact": "NONE", + "subIntegrityImpact": "NONE", + "userInteraction": "NONE", + "valueDensity": "NOT_DEFINED", + "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N", + "version": "4.0", + "vulnAvailabilityImpact": "HIGH", + "vulnConfidentialityImpact": "HIGH", + "vulnIntegrityImpact": "HIGH", + "vulnerabilityResponseEffort": "NOT_DEFINED" + }, + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ] + }, + { + "cvssV3_1": { + "attackComplexity": "LOW", + "attackVector": "LOCAL", + "availabilityImpact": "HIGH", + "baseScore": 7.8, + "baseSeverity": "HIGH", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "privilegesRequired": "LOW", + "scope": "UNCHANGED", + "userInteraction": "NONE", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "version": "3.1" + }, + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ] + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "cweId": "CWE-782", + "description": "CWE-782 Exposed IOCTL with Insufficient Access Control", + "lang": "en", + "type": "CWE" + } + ] + } + ], + "providerMetadata": { + "orgId": "270ccfa6-a436-4e77-922e-914ec3a9685c", + "shortName": "CERTVDE", + "dateUpdated": "2026-11-11T08:19:35.444Z" + }, + "references": [ + { + "url": "https://www.certvde.com/en/advisories/VDE-2026-087/" + } + ], + "source": { + "advisory": "VDE-2026-087", + "defect": [ + "CERT@VDE#642195" + ], + "discovery": "UNKNOWN" + }, + "title": "Insufficient IOCTL access control allows local access to I/O ports", + "x_generator": { + "engine": "Vulnogram 0.4.0" + } + } + } +} \ No newline at end of file diff --git a/data/2026/18xxx/CVE-2026-18768.json b/data/2026/18xxx/CVE-2026-18768.json new file mode 100644 index 0000000000..022fe3bdc7 --- /dev/null +++ b/data/2026/18xxx/CVE-2026-18768.json @@ -0,0 +1,312 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-18768", + "assignerOrgId": "270ccfa6-a436-4e77-922e-914ec3a9685c", + "state": "PUBLISHED", + "assignerShortName": "CERTVDE", + "dateReserved": "2026-08-04T07:16:36.454Z", + "datePublished": "2026-11-11T08:19:58.767Z", + "dateUpdated": "2026-11-11T08:19:58.767Z" + }, + "containers": { + "cna": { + "affected": [ + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x64 3.1.0.2364", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.1.0.2364" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x64 <3.1.0.2365", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.1.0.2365", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x86 3.1.0.2364", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.1.0.2364" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x86 <3.1.0.2365", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.1.0.2365", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TwinCAT.XAR.Base.KM 3.16.29", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.16.29" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TwinCAT.XAR.Base.KM <3.18.1", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.18.1", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + } + ], + "cpeApplicability": [ + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:3.1.0.2364:*:*:*:*:Windows:x64:*", + "versionStartIncluding": "3.1.0.2364", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:*:*:*:*:*:Windows:x64:*", + "versionEndExcluding": "3.1.0.2365", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:3.1.0.2364:*:*:*:*:Windows:x86:*", + "versionStartIncluding": "3.1.0.2364", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:*:*:*:*:*:Windows:x86:*", + "versionEndExcluding": "3.1.0.2365", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:twincat.xar.base.km:3.16.29:tcpkg:*:*:*:Windows:*:*", + "versionStartIncluding": "3.16.29", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:twincat.xar.base.km:tcpkg:*:*:*:*:Windows:*:*", + "versionEndExcluding": "3.18.1", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + } + ], + "credits": [ + { + "lang": "en", + "type": "finder", + "value": "Chi Siang Choo from 4rthur Security Team" + }, + { + "lang": "en", + "type": "finder", + "value": "Julian Horoszkiewicz" + }, + { + "lang": "en", + "type": "finder", + "value": "Patrick Saif" + } + ], + "descriptions": [ + { + "lang": "en", + "supportingMedia": [ + { + "base64": false, + "type": "text/html", + "value": "

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.

" + } + ], + "value": "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." + } + ], + "metrics": [ + { + "cvssV4_0": { + "Automatable": "NOT_DEFINED", + "Recovery": "NOT_DEFINED", + "Safety": "NOT_DEFINED", + "attackComplexity": "LOW", + "attackRequirements": "NONE", + "attackVector": "LOCAL", + "baseScore": 8.5, + "baseSeverity": "HIGH", + "privilegesRequired": "LOW", + "providerUrgency": "NOT_DEFINED", + "subAvailabilityImpact": "NONE", + "subConfidentialityImpact": "NONE", + "subIntegrityImpact": "NONE", + "userInteraction": "NONE", + "valueDensity": "NOT_DEFINED", + "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N", + "version": "4.0", + "vulnAvailabilityImpact": "HIGH", + "vulnConfidentialityImpact": "HIGH", + "vulnIntegrityImpact": "HIGH", + "vulnerabilityResponseEffort": "NOT_DEFINED" + }, + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ] + }, + { + "cvssV3_1": { + "attackComplexity": "LOW", + "attackVector": "LOCAL", + "availabilityImpact": "HIGH", + "baseScore": 7.8, + "baseSeverity": "HIGH", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "privilegesRequired": "LOW", + "scope": "UNCHANGED", + "userInteraction": "NONE", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "version": "3.1" + }, + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ] + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "cweId": "CWE-782", + "description": "CWE-782 Exposed IOCTL with Insufficient Access Control", + "lang": "en", + "type": "CWE" + } + ] + } + ], + "providerMetadata": { + "orgId": "270ccfa6-a436-4e77-922e-914ec3a9685c", + "shortName": "CERTVDE", + "dateUpdated": "2026-11-11T08:19:58.767Z" + }, + "references": [ + { + "url": "https://www.certvde.com/en/advisories/VDE-2026-087/" + } + ], + "source": { + "advisory": "VDE-2026-087", + "defect": [ + "CERT@VDE#642195" + ], + "discovery": "UNKNOWN" + }, + "title": "Insufficient IOCTL access control allows local access to arbitrary physical memory", + "x_generator": { + "engine": "Vulnogram 0.4.0" + } + } + } +} \ No newline at end of file diff --git a/data/2026/18xxx/CVE-2026-18769.json b/data/2026/18xxx/CVE-2026-18769.json new file mode 100644 index 0000000000..bc2b13b6b6 --- /dev/null +++ b/data/2026/18xxx/CVE-2026-18769.json @@ -0,0 +1,312 @@ +{ + "dataType": "CVE_RECORD", + "dataVersion": "5.2", + "cveMetadata": { + "cveId": "CVE-2026-18769", + "assignerOrgId": "270ccfa6-a436-4e77-922e-914ec3a9685c", + "state": "PUBLISHED", + "assignerShortName": "CERTVDE", + "dateReserved": "2026-08-04T07:16:37.968Z", + "datePublished": "2026-11-11T08:20:24.350Z", + "dateUpdated": "2026-11-11T08:20:24.350Z" + }, + "containers": { + "cna": { + "affected": [ + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x64 3.1.0.2364", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.1.0.2364" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x64 <3.1.0.2365", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.1.0.2365", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x86 3.1.0.2364", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.1.0.2364" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TcRouter.sys for Windows on x86 <3.1.0.2365", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.1.0.2365", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TwinCAT.XAR.Base.KM 3.16.29", + "vendor": "Beckhoff Automation", + "versions": [ + { + "status": "affected", + "version": "3.16.29" + } + ] + }, + { + "defaultStatus": "unaffected", + "product": "TwinCAT.XAR.Base.KM <3.18.1", + "vendor": "Beckhoff Automation", + "versions": [ + { + "lessThan": "3.18.1", + "status": "affected", + "version": "1.0.0", + "versionType": "semver" + } + ] + } + ], + "cpeApplicability": [ + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:3.1.0.2364:*:*:*:*:Windows:x64:*", + "versionStartIncluding": "3.1.0.2364", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:*:*:*:*:*:Windows:x64:*", + "versionEndExcluding": "3.1.0.2365", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:3.1.0.2364:*:*:*:*:Windows:x86:*", + "versionStartIncluding": "3.1.0.2364", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:tcrouter.sys:*:*:*:*:*:Windows:x86:*", + "versionEndExcluding": "3.1.0.2365", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:twincat.xar.base.km:3.16.29:tcpkg:*:*:*:Windows:*:*", + "versionStartIncluding": "3.16.29", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + }, + { + "nodes": [ + { + "cpeMatch": [ + { + "criteria": "cpe:2.3:a:beckhoff:twincat.xar.base.km:tcpkg:*:*:*:*:Windows:*:*", + "versionEndExcluding": "3.18.1", + "versionStartIncluding": "1.0.0", + "vulnerable": true + } + ], + "negate": false, + "operator": "OR" + } + ], + "operator": "OR" + } + ], + "credits": [ + { + "lang": "en", + "type": "finder", + "value": "Chi Siang Choo from 4rthur Security Team" + }, + { + "lang": "en", + "type": "finder", + "value": "Julian Horoszkiewicz" + }, + { + "lang": "en", + "type": "finder", + "value": "Patrick Saif" + } + ], + "descriptions": [ + { + "lang": "en", + "supportingMedia": [ + { + "base64": false, + "type": "text/html", + "value": "

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.

" + } + ], + "value": "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." + } + ], + "metrics": [ + { + "cvssV4_0": { + "Automatable": "NOT_DEFINED", + "Recovery": "NOT_DEFINED", + "Safety": "NOT_DEFINED", + "attackComplexity": "LOW", + "attackRequirements": "NONE", + "attackVector": "LOCAL", + "baseScore": 8.5, + "baseSeverity": "HIGH", + "privilegesRequired": "LOW", + "providerUrgency": "NOT_DEFINED", + "subAvailabilityImpact": "NONE", + "subConfidentialityImpact": "NONE", + "subIntegrityImpact": "NONE", + "userInteraction": "NONE", + "valueDensity": "NOT_DEFINED", + "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N", + "version": "4.0", + "vulnAvailabilityImpact": "HIGH", + "vulnConfidentialityImpact": "HIGH", + "vulnIntegrityImpact": "HIGH", + "vulnerabilityResponseEffort": "NOT_DEFINED" + }, + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ] + }, + { + "cvssV3_1": { + "attackComplexity": "LOW", + "attackVector": "LOCAL", + "availabilityImpact": "HIGH", + "baseScore": 7.8, + "baseSeverity": "HIGH", + "confidentialityImpact": "HIGH", + "integrityImpact": "HIGH", + "privilegesRequired": "LOW", + "scope": "UNCHANGED", + "userInteraction": "NONE", + "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", + "version": "3.1" + }, + "format": "CVSS", + "scenarios": [ + { + "lang": "en", + "value": "GENERAL" + } + ] + } + ], + "problemTypes": [ + { + "descriptions": [ + { + "cweId": "CWE-782", + "description": "CWE-782 Exposed IOCTL with Insufficient Access Control", + "lang": "en", + "type": "CWE" + } + ] + } + ], + "providerMetadata": { + "orgId": "270ccfa6-a436-4e77-922e-914ec3a9685c", + "shortName": "CERTVDE", + "dateUpdated": "2026-11-11T08:20:24.350Z" + }, + "references": [ + { + "url": "https://www.certvde.com/en/advisories/VDE-2026-087/" + } + ], + "source": { + "advisory": "VDE-2026-087", + "defect": [ + "CERT@VDE#642195" + ], + "discovery": "UNKNOWN" + }, + "title": "Insufficient IOCTL access control allows local relocation of arbitrary physical memory", + "x_generator": { + "engine": "Vulnogram 0.4.0" + } + } + } +} \ No newline at end of file diff --git a/data/2026/76xxx/CVE-2026-76563.json b/data/2026/76xxx/CVE-2026-76563.json index 07be82fbe2..c2bf7ed749 100644 --- a/data/2026/76xxx/CVE-2026-76563.json +++ b/data/2026/76xxx/CVE-2026-76563.json @@ -8,14 +8,14 @@ "assignerShortName": "TR-CERT", "dateReserved": "2026-08-19T13:11:34.748Z", "datePublished": "2026-11-05T13:47:15.045Z", - "dateUpdated": "2026-11-05T17:28:52.645Z" + "dateUpdated": "2026-11-11T08:30:42.286Z" }, "containers": { "cna": { "providerMetadata": { "orgId": "ca940d4e-fea4-4aa2-9a58-591a58b1ce21", "shortName": "TR-CERT", - "dateUpdated": "2026-11-05T13:47:15.045Z" + "dateUpdated": "2026-11-11T08:30:42.286Z" }, "title": "HTML Injection in Fileorbis", "datePublic": "2026-11-05T13:44:00.000Z", @@ -108,6 +108,11 @@ "lang": "en", "value": "Merve Hatice ARSLAN", "type": "finder" + }, + { + "lang": "en", + "value": "Defense Technologies Engineering and Trade Inc.", + "type": "sponsor" } ], "source": { diff --git a/data/2026/79xxx/CVE-2026-79655.json b/data/2026/79xxx/CVE-2026-79655.json index 5c94ae4fe4..e19ff29817 100644 --- a/data/2026/79xxx/CVE-2026-79655.json +++ b/data/2026/79xxx/CVE-2026-79655.json @@ -8,7 +8,7 @@ "assignerShortName": "redhat", "dateReserved": "2026-08-25T10:58:31.542Z", "datePublished": "2026-08-25T13:49:37.593Z", - "dateUpdated": "2026-11-10T22:28:00.240Z" + "dateUpdated": "2026-11-11T08:36:31.222Z" }, "containers": { "cna": { @@ -48,6 +48,24 @@ } ], "affected": [ + { + "vendor": "Red Hat", + "product": "Red Hat Enterprise Linux 10", + "collectionURL": "https://access.redhat.com/downloads/content/package-browser/", + "packageName": "sos", + "defaultStatus": "affected", + "versions": [ + { + "version": "0:4.11.2-7.el10_3", + "lessThan": "*", + "versionType": "rpm", + "status": "unaffected" + } + ], + "cpes": [ + "cpe:/o:redhat:enterprise_linux:10.3" + ] + }, { "vendor": "Red Hat", "product": "Red Hat Enterprise Linux 9", @@ -66,16 +84,6 @@ "cpe:/o:redhat:enterprise_linux:9::baseos" ] }, - { - "vendor": "Red Hat", - "product": "Red Hat Enterprise Linux 10", - "collectionURL": "https://access.redhat.com/downloads/content/package-browser/", - "packageName": "sos", - "defaultStatus": "affected", - "cpes": [ - "cpe:/a:redhat:enterprise_linux:10" - ] - }, { "vendor": "Red Hat", "product": "Red Hat Enterprise Linux 6", @@ -116,6 +124,14 @@ "x_refsource_REDHAT" ] }, + { + "url": "https://access.redhat.com/errata/RHSA-2026:98076", + "name": "RHSA-2026:98076", + "tags": [ + "vendor-advisory", + "x_refsource_REDHAT" + ] + }, { "url": "https://access.redhat.com/security/cve/CVE-2026-79655", "tags": [ @@ -179,7 +195,7 @@ "providerMetadata": { "orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749", "shortName": "redhat", - "dateUpdated": "2026-11-10T22:28:00.240Z" + "dateUpdated": "2026-11-11T08:36:31.222Z" }, "x_generator": { "engine": "cvelib 1.8.0" diff --git a/data/2026/80xxx/CVE-2026-80179.json b/data/2026/80xxx/CVE-2026-80179.json index 694608c4f6..584b379e66 100644 --- a/data/2026/80xxx/CVE-2026-80179.json +++ b/data/2026/80xxx/CVE-2026-80179.json @@ -8,7 +8,7 @@ "assignerShortName": "redhat", "dateReserved": "2026-08-25T21:13:03.622Z", "datePublished": "2026-08-27T21:14:23.428Z", - "dateUpdated": "2026-11-06T00:55:24.488Z" + "dateUpdated": "2026-11-11T08:45:44.848Z" }, "containers": { "cna": { @@ -48,6 +48,24 @@ } ], "affected": [ + { + "vendor": "Red Hat", + "product": "Red Hat Enterprise Linux 10", + "collectionURL": "https://access.redhat.com/downloads/content/package-browser/", + "packageName": "python-jwcrypto", + "defaultStatus": "affected", + "versions": [ + { + "version": "0:1.6.1-1.el10_3", + "lessThan": "*", + "versionType": "rpm", + "status": "unaffected" + } + ], + "cpes": [ + "cpe:/o:redhat:enterprise_linux:10.3" + ] + }, { "vendor": "Red Hat", "product": "Red Hat Ansible Automation Platform 2", @@ -178,16 +196,6 @@ "cpe:/a:redhat:ansible_automation_platform:2" ] }, - { - "vendor": "Red Hat", - "product": "Red Hat Enterprise Linux 10", - "collectionURL": "https://access.redhat.com/downloads/content/package-browser/", - "packageName": "python-jwcrypto", - "defaultStatus": "affected", - "cpes": [ - "cpe:/a:redhat:enterprise_linux:10" - ] - }, { "vendor": "Red Hat", "product": "Red Hat Enterprise Linux 9", @@ -300,6 +308,14 @@ } ], "references": [ + { + "url": "https://access.redhat.com/errata/RHSA-2026:98061", + "name": "RHSA-2026:98061", + "tags": [ + "vendor-advisory", + "x_refsource_REDHAT" + ] + }, { "url": "https://access.redhat.com/security/cve/CVE-2026-80179", "tags": [ @@ -354,7 +370,7 @@ "providerMetadata": { "orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749", "shortName": "redhat", - "dateUpdated": "2026-11-06T00:55:24.488Z" + "dateUpdated": "2026-11-11T08:45:44.848Z" }, "x_generator": { "engine": "cvelib 1.8.0" diff --git a/data/2026/92xxx/CVE-2026-92091.json b/data/2026/92xxx/CVE-2026-92091.json index 3b38cbb77c..85a23499db 100644 --- a/data/2026/92xxx/CVE-2026-92091.json +++ b/data/2026/92xxx/CVE-2026-92091.json @@ -8,7 +8,7 @@ "assignerShortName": "redhat", "dateReserved": "2026-09-15T14:30:45.109Z", "datePublished": "2026-09-16T07:34:08.840Z", - "dateUpdated": "2026-11-10T22:39:00.942Z" + "dateUpdated": "2026-11-11T08:45:44.871Z" }, "containers": { "cna": { @@ -48,6 +48,24 @@ } ], "affected": [ + { + "vendor": "Red Hat", + "product": "Red Hat Enterprise Linux 10", + "collectionURL": "https://access.redhat.com/downloads/content/package-browser/", + "packageName": "python-jwcrypto", + "defaultStatus": "affected", + "versions": [ + { + "version": "0:1.6.1-1.el10_3", + "lessThan": "*", + "versionType": "rpm", + "status": "unaffected" + } + ], + "cpes": [ + "cpe:/o:redhat:enterprise_linux:10.3" + ] + }, { "vendor": "Red Hat", "product": "Red Hat Enterprise Linux 9", @@ -196,16 +214,6 @@ "cpe:/a:redhat:ansible_automation_platform:2" ] }, - { - "vendor": "Red Hat", - "product": "Red Hat Enterprise Linux 10", - "collectionURL": "https://access.redhat.com/downloads/content/package-browser/", - "packageName": "python-jwcrypto", - "defaultStatus": "affected", - "cpes": [ - "cpe:/a:redhat:enterprise_linux:10" - ] - }, { "vendor": "Red Hat", "product": "Red Hat Enterprise Linux 7", @@ -416,6 +424,14 @@ "x_refsource_REDHAT" ] }, + { + "url": "https://access.redhat.com/errata/RHSA-2026:98061", + "name": "RHSA-2026:98061", + "tags": [ + "vendor-advisory", + "x_refsource_REDHAT" + ] + }, { "url": "https://access.redhat.com/security/cve/CVE-2026-92091", "tags": [ @@ -470,7 +486,7 @@ "providerMetadata": { "orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749", "shortName": "redhat", - "dateUpdated": "2026-11-10T22:39:00.942Z" + "dateUpdated": "2026-11-11T08:45:44.871Z" }, "x_generator": { "engine": "cvelib 1.8.0" diff --git a/data/delta.json b/data/delta.json index 1c24d6f493..de19e05dc2 100644 --- a/data/delta.json +++ b/data/delta.json @@ -1,13 +1,19 @@ { - "fetchTime": "2026-11-11T08:11:04.661Z", - "numberOfChanges": 1, + "fetchTime": "2026-11-11T08:47:48.283Z", + "numberOfChanges": 2, "new": [], "updated": [ { - "cveId": "CVE-2026-121885", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-121885", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/121xxx/CVE-2026-121885.json", - "dateUpdated": "2026-11-11T08:05:52.838Z" + "cveId": "CVE-2026-80179", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-80179", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/80xxx/CVE-2026-80179.json", + "dateUpdated": "2026-11-11T08:45:44.848Z" + }, + { + "cveId": "CVE-2026-92091", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-92091", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/92xxx/CVE-2026-92091.json", + "dateUpdated": "2026-11-11T08:45:44.871Z" } ], "error": [] diff --git a/data/deltaLog.json b/data/deltaLog.json index 0bf39e5aa1..30065b456c 100644 --- a/data/deltaLog.json +++ b/data/deltaLog.json @@ -1,4 +1,188 @@ [ + { + "fetchTime": "2026-11-11T08:47:48.283Z", + "numberOfChanges": 2, + "new": [], + "updated": [ + { + "cveId": "CVE-2026-80179", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-80179", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/80xxx/CVE-2026-80179.json", + "dateUpdated": "2026-11-11T08:45:44.848Z" + }, + { + "cveId": "CVE-2026-92091", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-92091", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/92xxx/CVE-2026-92091.json", + "dateUpdated": "2026-11-11T08:45:44.871Z" + } + ], + "error": [] + }, + { + "fetchTime": "2026-11-11T08:41:55.510Z", + "numberOfChanges": 3, + "new": [ + { + "cveId": "CVE-2026-126621", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126621", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126621.json", + "dateUpdated": "2026-11-11T08:36:26.283Z" + }, + { + "cveId": "CVE-2026-126626", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126626", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126626.json", + "dateUpdated": "2026-11-11T08:36:46.162Z" + } + ], + "updated": [ + { + "cveId": "CVE-2026-79655", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-79655", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/79xxx/CVE-2026-79655.json", + "dateUpdated": "2026-11-11T08:36:31.222Z" + } + ], + "error": [] + }, + { + "fetchTime": "2026-11-11T08:36:08.023Z", + "numberOfChanges": 17, + "new": [ + { + "cveId": "CVE-2026-126607", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126607", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126607.json", + "dateUpdated": "2026-11-11T08:30:27.131Z" + }, + { + "cveId": "CVE-2026-126609", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126609", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126609.json", + "dateUpdated": "2026-11-11T08:30:17.425Z" + }, + { + "cveId": "CVE-2026-126610", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126610", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126610.json", + "dateUpdated": "2026-11-11T08:30:37.134Z" + }, + { + "cveId": "CVE-2026-126611", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126611", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126611.json", + "dateUpdated": "2026-11-11T08:30:32.132Z" + }, + { + "cveId": "CVE-2026-126612", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126612", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126612.json", + "dateUpdated": "2026-11-11T08:30:52.135Z" + }, + { + "cveId": "CVE-2026-126613", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126613", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126613.json", + "dateUpdated": "2026-11-11T08:31:12.127Z" + }, + { + "cveId": "CVE-2026-126614", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126614", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126614.json", + "dateUpdated": "2026-11-11T08:32:32.127Z" + }, + { + "cveId": "CVE-2026-126615", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126615", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126615.json", + "dateUpdated": "2026-11-11T08:32:57.155Z" + }, + { + "cveId": "CVE-2026-126616", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126616", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126616.json", + "dateUpdated": "2026-11-11T08:33:02.130Z" + }, + { + "cveId": "CVE-2026-126617", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126617", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126617.json", + "dateUpdated": "2026-11-11T08:33:22.129Z" + }, + { + "cveId": "CVE-2026-126618", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126618", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126618.json", + "dateUpdated": "2026-11-11T08:33:12.130Z" + }, + { + "cveId": "CVE-2026-126619", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126619", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126619.json", + "dateUpdated": "2026-11-11T08:33:47.151Z" + }, + { + "cveId": "CVE-2026-126622", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126622", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126622.json", + "dateUpdated": "2026-11-11T08:31:37.129Z" + }, + { + "cveId": "CVE-2026-126623", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126623", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126623.json", + "dateUpdated": "2026-11-11T08:31:47.129Z" + }, + { + "cveId": "CVE-2026-126624", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126624", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126624.json", + "dateUpdated": "2026-11-11T08:31:52.133Z" + }, + { + "cveId": "CVE-2026-126625", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-126625", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/126xxx/CVE-2026-126625.json", + "dateUpdated": "2026-11-11T08:31:57.131Z" + } + ], + "updated": [ + { + "cveId": "CVE-2026-76563", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-76563", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/76xxx/CVE-2026-76563.json", + "dateUpdated": "2026-11-11T08:30:42.286Z" + } + ], + "error": [] + }, + { + "fetchTime": "2026-11-11T08:21:25.050Z", + "numberOfChanges": 3, + "new": [ + { + "cveId": "CVE-2026-18767", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-18767", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/18xxx/CVE-2026-18767.json", + "dateUpdated": "2026-11-11T08:19:35.444Z" + }, + { + "cveId": "CVE-2026-18768", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-18768", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/18xxx/CVE-2026-18768.json", + "dateUpdated": "2026-11-11T08:19:58.767Z" + }, + { + "cveId": "CVE-2026-18769", + "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-18769", + "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/18xxx/CVE-2026-18769.json", + "dateUpdated": "2026-11-11T08:20:24.350Z" + } + ], + "updated": [], + "error": [] + }, { "fetchTime": "2026-11-11T08:11:04.661Z", "numberOfChanges": 1, @@ -832983,80 +833167,5 @@ ], "updated": [], "error": [] - }, - { - "fetchTime": "2026-10-12T08:45:43.025Z", - "numberOfChanges": 11, - "new": [ - { - "cveId": "CVE-2023-25996", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2023-25996", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2023/25xxx/CVE-2023-25996.json", - "dateUpdated": "2026-10-12T08:15:39.939Z" - }, - { - "cveId": "CVE-2026-104710", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-104710", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/104xxx/CVE-2026-104710.json", - "dateUpdated": "2026-10-12T08:34:09.401Z" - }, - { - "cveId": "CVE-2026-107423", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-107423", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/107xxx/CVE-2026-107423.json", - "dateUpdated": "2026-10-12T08:27:41.050Z" - }, - { - "cveId": "CVE-2026-107863", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-107863", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/107xxx/CVE-2026-107863.json", - "dateUpdated": "2026-10-12T08:25:48.399Z" - }, - { - "cveId": "CVE-2026-107869", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-107869", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/107xxx/CVE-2026-107869.json", - "dateUpdated": "2026-10-12T08:26:50.077Z" - }, - { - "cveId": "CVE-2026-108168", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-108168", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/108xxx/CVE-2026-108168.json", - "dateUpdated": "2026-10-12T08:23:51.283Z" - }, - { - "cveId": "CVE-2026-108815", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-108815", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/108xxx/CVE-2026-108815.json", - "dateUpdated": "2026-10-12T08:15:11.857Z" - }, - { - "cveId": "CVE-2026-108816", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-108816", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/108xxx/CVE-2026-108816.json", - "dateUpdated": "2026-10-12T08:30:18.854Z" - }, - { - "cveId": "CVE-2026-108817", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-108817", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/108xxx/CVE-2026-108817.json", - "dateUpdated": "2026-10-12T08:45:20.909Z" - }, - { - "cveId": "CVE-2026-1907", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2026-1907", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/1xxx/CVE-2026-1907.json", - "dateUpdated": "2026-10-12T08:38:54.485Z" - } - ], - "updated": [ - { - "cveId": "CVE-2025-10162", - "cveOrgLink": "https://www.cve.org/CVERecord?id=CVE-2025-10162", - "githubLink": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2025/10xxx/CVE-2025-10162.json", - "dateUpdated": "2026-10-12T08:36:09.589Z" - } - ], - "error": [] } ] \ No newline at end of file diff --git a/state/sync.json b/state/sync.json index a36eb73b9a..6247b0be25 100644 --- a/state/sync.json +++ b/state/sync.json @@ -1,7 +1,7 @@ { "source": "https://github.com/CVEProject/cvelistV5.git", - "upstream_commit": "2a64647fb47b795182264decd4abb7f7f43c4932", + "upstream_commit": "4c07ec36f2902d5d14707eb349fb9509074b68c2", "since_year": 2017, - "records": 330857, - "synced_at_utc": "2026-11-11T08:34:22.422799+00:00" + "records": 330878, + "synced_at_utc": "2026-11-11T09:32:07.828143+00:00" }