Total
419343 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2022-2982 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2026-11-02 | N/A | 7.8 HIGH |
| Use After Free in GitHub repository vim/vim prior to 9.0.0260. | |||||
| CVE-2022-2980 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2026-11-02 | N/A | 5.5 MEDIUM |
| NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.0259. | |||||
| CVE-2022-2923 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2026-11-02 | N/A | 5.5 MEDIUM |
| NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.0240. | |||||
| CVE-2022-2905 | 3 Debian, Linux, Redhat | 3 Debian Linux, Linux Kernel, Enterprise Linux | 2026-11-02 | N/A | 5.5 MEDIUM |
| An out-of-bounds memory read flaw was found in the Linux kernel's BPF subsystem in how a user calls the bpf_tail_call function with a key larger than the max_entries of the map. This flaw allows a local user to gain unauthorized access to data. | |||||
| CVE-2022-2889 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2026-11-02 | N/A | 7.8 HIGH |
| Use After Free in GitHub repository vim/vim prior to 9.0.0225. | |||||
| CVE-2022-2874 | 1 Vim | 1 Vim | 2026-11-02 | N/A | 5.5 MEDIUM |
| NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.0224. | |||||
| CVE-2022-2862 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2026-11-02 | N/A | 7.8 HIGH |
| Use After Free in GitHub repository vim/vim prior to 9.0.0221. | |||||
| CVE-2022-2819 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2026-11-02 | N/A | 7.8 HIGH |
| Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.0211. | |||||
| CVE-2022-2817 | 2 Fedoraproject, Vim | 2 Fedora, Vim | 2026-11-02 | N/A | 7.8 HIGH |
| Use After Free in GitHub repository vim/vim prior to 9.0.0213. | |||||
| CVE-2022-29546 | 1 Htmlunit | 1 Htmlunit | 2026-11-02 | 5.0 MEDIUM | 7.5 HIGH |
| HtmlUnit NekoHtml Parser before 2.61.0 suffers from a denial of service vulnerability. Crafted input associated with the parsing of Processing Instruction (PI) data leads to heap memory consumption. This is similar to CVE-2022-28366 but affects a much later version of the product. | |||||
| CVE-2022-29143 | 1 Microsoft | 1 Sql Server | 2026-11-02 | 6.0 MEDIUM | 7.5 HIGH |
| Microsoft SQL Server Remote Code Execution Vulnerability | |||||
| CVE-2022-29119 | 1 Microsoft | 1 Hevc Video Extensions | 2026-11-02 | 6.8 MEDIUM | 7.8 HIGH |
| HEVC Video Extensions Remote Code Execution Vulnerability | |||||
| CVE-2025-69820 | 1 Beam | 1 Beta9 Worker | 2026-11-02 | N/A | 6.0 MEDIUM |
| Directory Traversal vulnerability in Beam beta9 v.0.1.521 allows a remote attacker to obtain sensitive information via the joinCleanPath function. | |||||
| CVE-2026-95663 | 2026-11-02 | N/A | 4.8 MEDIUM | ||
| Insufficient Session Expiration vulnerability in Apache Camel Keycloak component. This issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2. When token introspection is enabled on the camel-keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), the security processor validates the access token of a request by sending it to Keycloak's OAuth 2.0 token introspection endpoint, and accepts the token while the response reports it as active. The introspection endpoint reports a token as inactive once its exp (expiration) time has passed, so on this path the active flag is what enforces token expiry. Introspection results are cached by default (introspectionCacheEnabled=true, introspectionCacheTtl=60 seconds), and both cache implementations shipped with the component, ConcurrentMapTokenCache and CaffeineTokenCache, expired an entry a fixed time after it was inserted, without bounding that lifetime by the exp claim that the cached response already carried. KeycloakSecurityProcessor in turn checked only the active flag of the result, on every path that uses introspection, and never compared exp with the current time. A response cached shortly before the token expired was therefore served to later requests carrying the same token for up to the configured time-to-live after the token's expiry, and those requests were admitted with the roles and permissions the expired token had carried, although RFC 7662, which defines token introspection, states that a response containing exp must not be cached beyond that time. The access token is supplied by the caller with each request, typically as a bearer token in the Authorization header, so a caller holding a token that was valid moments earlier could keep using it after it expired, for as long as the cached entry lived. The window is bounded by introspectionCacheTtl, which is 60 seconds by default and 300 to 600 seconds where the documentation's recommendation for internal services was followed, and it opens only for a token that the same Camel process introspected and cached while the token was still active. The issue grants nothing beyond what the token already carried: it allows no token forgery and no privilege escalation, and token introspection is not enabled by default, which is why the severity is assessed medium. The local JWT verification path, used when introspection is disabled, is not affected by this issue. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.16.x, 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it. | |||||
| CVE-2026-95629 | 2026-11-02 | N/A | 5.4 MEDIUM | ||
| Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory. | |||||
| CVE-2026-93006 | 2026-11-02 | N/A | 6.8 MEDIUM | ||
| A flaw was found in dnsmasq. The TFTP server can serve the wrong file contents because a recently used transfer cache is not invalidated when a transfer finishes. An attacker on the local network who can request a TFTP file may cause a later client to receive previously cached data instead of the requested file. In PXE network-boot environments this can substitute attacker-chosen boot content for a victim machine. | |||||
| CVE-2026-86390 | 2026-11-02 | N/A | 6.5 MEDIUM | ||
| Dell PowerProtect Data Domain, Feature Release versions 7.7.1.0 through 8.8, LTS2024 release versions 7.13.1.0 through 7.13.1.80, LTS2025 release versions 8.3.1.0 through 8.3.1.40, LTS2026 release versions 8.6.1.0 through 8.6.1.20, contain a Missing Authorization vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Unauthorized access. | |||||
| CVE-2026-86386 | 2026-11-02 | N/A | 4.3 MEDIUM | ||
| Dell PowerProtect Data Domain Management Center, Feature Release versions 7.7.1.0 through 8.8, LTS2024 release versions 7.13.1.0 through 7.13.1.80, LTS2025 release versions 8.3.1.0 through 8.3.1.40, LTS2026 release versions 8.6.1.0 through 8.6.1.20, contain an Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Information disclosure. | |||||
| CVE-2026-82947 | 2026-11-02 | N/A | 7.1 HIGH | ||
| SOEM version 2.0.0 and earlier contains multiple vulnerabilities in frame processing where a malicious device can cause the master to read data outside allocated buffers. The software uses length and offset values from device messages without validating them against buffer sizes. This can cause the master to access invalid memory locations, potentially disclosing sensitive information or causing crashes. | |||||
| CVE-2026-82944 | 2026-11-02 | N/A | 8.8 HIGH | ||
| SOEM version 2.0.0 and earlier contains a vulnerability in multi-segment data transfers where a malicious device can overflow memory buffers. The software checks the total size only once at the beginning, but doesn't track the cumulative size as multiple segments arrive. An attacker can declare a small initial size to pass validation, then send additional segments that exceed the allocated buffer. This allows the attacker to write controlled data beyond buffer boundaries, potentially enabling code execution. | |||||