Export limit exceeded: 384590 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 384590 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (384590 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-66906 | 1 Apache | 1 Camel | 2026-08-27 | 9.1 Critical |
| Relative path traversal vulnerability in Apache Camel Azure Storage Blob component. This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-azure-storage-blob component can download an Azure Storage blob to the local filesystem through its downloadBlobToFile operation, writing into the directory named by the fileDir endpoint option, which is documented as usable from both the producer and the consumer. BlobOperations.downloadBlobToFile built the local target by joining fileDir with the remote blob name exactly as the Azure SDK reported it (new File(fileDir, client.getBlobName())) and passed the result straight to the SDK download call, with no lexical normalization and no check that the resolved location stayed inside fileDir. The blob name is not route-controlled data: the consumer enumerates the container in BlobConsumer.createBatchExchangesFromContainer, which lists blobs and creates one exchange per entry from BlobItem.getName() verbatim, applying no name filtering by default. A blob name containing parent-directory segments therefore resolved to a location outside the configured fileDir, letting anyone able to influence the names present in the consumed container cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. Azure Storage blob containers use a flat namespace in which the blob name is an opaque key, so a name carrying such segments is stored and listed as given. The fileDir option is an ordinary common-group configuration parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp and camel-azure-files - already constrained their local downloads to the configured directory using a path-segment boundary check; the camel-azure-storage-blob download path was not covered by that work. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, constrain the names the consumer will act on using the regex endpoint option, which is applied to each listed blob name as a full-string match, so that only simple single-segment names are accepted and any name carrying a path separator or a parent-directory segment is filtered out before an exchange is created; the prefix option can additionally narrow the listing server-side, noting that when both are set regex takes priority and prefix is ignored. Alternatively, avoid the downloadBlobToFile operation on untrusted containers and write the payload from the route under a file name the route itself controls, rather than one taken from the remote listing. As defence in depth, treat the blob names in any externally writable container as untrusted input and do not derive local filesystem paths from them. | ||||
| CVE-2026-62380 | 1 Netty | 1 Netty | 2026-08-27 | 7.5 High |
| Netty (io.netty:netty-codec-socks) versions 4.2.0.Final through 4.2.16.Final and 4.1.x through 4.1.136.Final contain null byte, CRLF, and credential injection vulnerabilities in the SOCKS4 (Socks4ClientEncoder) and SOCKS5 (Socks5ClientEncoder) client encoders, which fail to validate domain address and authentication (username/password) fields. An attacker able to control these fields can inject null bytes or CRLF characters to truncate or alter values, potentially enabling domain spoofing, SOCKS4 userid truncation, authentication data injection, and protocol confusion. Fixed in 4.2.17.Final and 4.1.137.Final. | ||||
| CVE-2026-81725 | 1 Nltk | 1 Nltk | 2026-08-27 | 3.7 Low |
| NLTK before 3.10.3 contains a regular expression denial of service vulnerability in Pl196xCorpusReader that allows attackers to cause quadratic CPU consumption by supplying malformed TEI blocks with many unmatched opening tags. Attackers can exploit lazy regex patterns in the read_block method through public APIs like words() and tagged_words() to force repeated rescans and achieve near-quadratic runtime growth. | ||||
| CVE-2026-68745 | 1 Apache | 1 Cloudstack | 2026-08-27 | 8.1 High |
| Certificate validation failures in SAML authentication in Apache CloudStack 4.20.3.0 and 4.22.1.0 on all platforms allow a malicious agent to forge a SAML response to the management server. The agent will have to spoof the ip address of the IdP or get an url of its own choosing registered in the management server, after which it can allow logging on with forged signatures. Users are recommended to upgrade to versions 4.20.3.1 or 4.22.1.1 and above, which fix this issue. | ||||
| CVE-2026-8173 | 1 Murrelektronik | 24 6 Tx M Ge + 4 Power M12 Ip67, Xelity-16tx-m-ge, Xelity-16tx-m-ge-pn and 21 more | 2026-08-27 | 5.3 Medium |
| The web GUI of affected Murrelektronik Xelity switches logs MAC addresses from the devices MAC address table when an authenticated administrator uses the 'Copy learned MAC Addresses' function. Due to improper generation of error messages, an unauthenticated attacker with network access to the web interface can retrieve the logged MAC addresses via browser developer tools. | ||||
| CVE-2026-81827 | 1 Flowintel | 1 Flowintel | 2026-08-27 | N/A |
| Affected versions of Flowintel incorrectly attempted to validate login email addresses by calling Email(email). That does not perform WTForms field validation; it merely constructs a validator object. Consequently, malformed attacker-controlled email input could continue through the login process and be written to security-relevant logs. The vulnerable code inserted the supplied email into both a warning log and the custom audit logger. Since CR/LF characters were not escaped, an unauthenticated attacker could potentially inject additional physical log lines or forge misleading log entries. The patch corrects the validation call to Email()(form, form.email), changes the standard logging call to parameterized logging, and introduces _sanitize_log_fragment() so carriage returns and line feeds are encoded instead of creating new records. Version impacted >=3.3.0 | ||||
| CVE-2026-81826 | 1 Flowintel | 1 Flowintel | 2026-08-27 | N/A |
| Affected versions of Flowintel do not revoke existing authenticated sessions when a user’s password is changed. This means that if an attacker already possesses a valid session—for example, from prior access or a stolen session token—the victim changing their password does not terminate that attacker’s access. The session remains usable until it expires naturally. The upstream commit describes this directly as: “session keeps working until it expires.” The fix detects password changes and explicitly invokes _invalidate_user_sessions(user.id) after the database update. This is applied in both edit_user_core() and admin_edit_user_core(). Version impacted >=3.3.0 | ||||
| CVE-2026-81820 | 1 Flowintel | 1 Flowintel | 2026-08-27 | N/A |
| Affected versions of Flowintel construct timeline HTML using attacker-controllable MISP object fields such as: * object UUID; * object name; * attribute value; * attribute type; * comment; * first/last seen values; * IDS flag. Those values were concatenated directly into HTML strings before rendering. The upstream commit explicitly states that DOMPurify removed XSS vectors but still allowed other HTML elements, such as forms, through. The fix replaces direct string interpolation with DOM construction via document.createElement() and assigns all attacker-controlled values using textContent. The headline is similarly converted to escaped HTML through a temporary element. Version impacted =>3.3.0 | ||||
| CVE-2026-81819 | 1 Flowintel | 1 Flowintel | 2026-08-27 | N/A |
| Affected versions of Flowintel expose the /my_assignment/user API endpoint to any authenticated API user. The endpoint accepts a user_id parameter identifying the user whose assignments should be returned, but previously had no role restriction beyond general API authentication. As a result, a lower-privileged authenticated user could potentially query another user’s assignment information by supplying that user’s identifier. The fix changes: method_decorators = [api_required] to: method_decorators = [admin_or_org_admin_required, api_required] so only administrators or organization administrators can perform cross-user assignment queries. Version impacted =>3.3.0 | ||||
| CVE-2026-81818 | 1 Flowintel | 1 Flowintel | 2026-08-27 | N/A |
| Affected versions of Flowintel contain an authorization flaw in the administrative user-edit API. The existing authorization check correctly prevented an organization administrator from editing users in another organization, but it did not prevent them from editing a full administrator within their own organization. As a result, an org admin could modify that full administrator account, including changing its password. The upstream commit explicitly describes the issue as: “Org admin can change the password of a full admin in the same organization.” The fix adds a higher-privilege boundary check: if user_to_edit.is_admin(): return ... 403 so organization administrators can no longer modify full administrator accounts. Version impacted >=3.3.0 | ||||
| CVE-2026-81817 | 1 Flowintel | 1 Flowintel | 2026-08-27 | N/A |
| Affected versions of Flowintel contain an insecure direct object reference / broken object-level authorization issue across numerous task endpoints. The routes generally received both a case identifier and a task identifier, but previously they did not enforce that the task actually belonged to the supplied case. As a result, an authenticated user with editor-level access to one case could potentially substitute the ID of a task from another case and invoke operations against that foreign task. The patch introduces task_case_bound_required, which loads both objects and returns 404 unless the task belongs to the requested case. This protection is applied to edit, delete, note, assignment, status, file, export, MISP-linking, subtask, external-reference, and other task-related endpoints. The fix also adds explicit checks that a requested note_id belongs to the current task before returning or exporting it, closing related cross-object access paths. Version impacted =>3.3.0 | ||||
| CVE-2026-81731 | 1 Frappe | 1 Frappe | 2026-08-27 | 5.4 Medium |
| Frappe 15.11.0 through 16.32.0 stores and renders the workspace card description without XSS filtering. The description field of the Workspace Link doctype is declared with "ignore_xss_filter": 1 in frappe/desk/doctype/workspace_link/workspace_link.json, and _sanitize_content() in frappe/model/base_document.py skips any field carrying that flag, so the value is stored exactly as submitted. frappe.desk.desktop.get_desktop_page returns it unchanged, and LinksWidget.set_body() in frappe/public/js/frappe/widgets/links_widget.js interpolates it into a Bootstrap popover created with html: true, by way of the __() translation helper, which performs no HTML escaping. A user holding the Workspace Manager role can therefore place arbitrary markup in a public workspace's card description and have it execute in the session of any desk user who opens that workspace and hovers the description, including higher-privileged users, allowing session token theft and authenticated requests as the victim. The flag is removed on the development branch but remains present in the shipped 15.x and 16.x release lines, so no released version carries the fix. | ||||
| CVE-2026-81724 | 1 Nltk | 1 Nltk | 2026-08-27 | 5.3 Medium |
| NLTK before 3.10.3 contains an uncontrolled recursion vulnerability in nltk.featstruct.FeatStructReader that allows unauthenticated attackers to cause a denial of service by supplying deeply nested feature-structure input. Attackers can craft trivial payloads with nested brackets that exceed Python's recursion limit and raise an unhandled RecursionError, crashing applications that parse user-supplied feature structures or feature grammars. | ||||
| CVE-2026-81722 | 1 Nltk | 1 Nltk | 2026-08-27 | 7.5 High |
| nltk PorterStemmer in versions <= 3.10.2 (fixed in 3.10.3) contains an inefficient-algorithmic-complexity denial of service in PorterStemmer.stem(). The _is_consonant() helper walks backward over the entire run of trailing 'y' characters on every call, and _measure() invokes it for each stem position, causing O(n^2) behavior. A single ~20-50 KB untrusted token consisting of a long run of the letter 'y' followed by a matching suffix (e.g., 'ness') can pin a CPU core for seconds to minutes, causing availability impact. | ||||
| CVE-2026-81721 | 1 Jahlives | 1 Openssl Encrypt | 2026-08-27 | 7.5 High |
| openssl_encrypt before 1.4.9 fails to validate KDF cost parameters in encrypted file metadata and keystore headers, allowing attackers to trigger unbounded memory allocation. Attackers can craft malicious encrypted files declaring arbitrarily large Argon2, scrypt, or balloon KDF parameters to exhaust system memory and crash the process without authentication. | ||||
| CVE-2026-81719 | 1 Jahlives | 1 Openssl Encrypt | 2026-08-27 | 7.8 High |
| openssl_encrypt before 1.4.9 executes untrusted third-party plugins with insufficient controls: the plugin signature policy defaulted to WARN, so an unsigned/unverifiable non-built-in plugin was compiled and executed in the host process at import time, before the runtime sandbox is installed. The only default gate was an incomplete, bypassable AST denylist. If a user is induced to load an attacker's plugin, this results in arbitrary code execution with the privileges of the user running openssl_encrypt. Fixed in 1.4.9 by defaulting the signature policy to ENFORCE for non-built-in plugins. | ||||
| CVE-2026-81717 | 1 Jahlives | 1 Openssl Encrypt | 2026-08-27 | 3.5 Low |
| openssl_encrypt (pip package openssl-encrypt) before 1.4.9 contains two weaknesses in the portable USB drive feature, whose threat model treats the removable drive as untrusted (attacker with physical write access). USBDriveCreator._verify_integrity_file only validates files listed in the manifest, so files added to the drive — including a root-level autorun payload — are not detected and integrity verification still passes. Additionally, a globally constant, source-embedded KDF salt (_LEGACY_FIXED_SALT) is used to derive the drive encryption key for any drive lacking a per-drive salt file, defeating precomputation resistance and enabling an offline rainbow-table attack. | ||||
| CVE-2026-81716 | 1 Jahlives | 1 Openssl Encrypt | 2026-08-27 | 5.2 Medium |
| openssl_encrypt (pip: openssl-encrypt) versions before 1.4.9 contain a path traversal flaw in PluginSandbox._is_safe_path, which authorized file access using a bare string-prefix match. A sandboxed plugin without the READ_FILES permission could read or write another plugin's directory that merely shares a name prefix (e.g., .../plugins/foobar matching allowed .../plugins/foo), breaking per-plugin isolation within the same user. Fixed by matching each allowed directory exactly or with a trailing path separator. | ||||
| CVE-2026-81714 | 1 Jahlives | 1 Openssl Encrypt | 2026-08-27 | 7 High |
| openssl_encrypt (pip: openssl-encrypt) versions <= 1.4.8 use suffix-tolerant fingerprint matching in enroll_trust_key when binding a plugin-signing trust anchor. An operator who confirms a short (forgeable, ~32-bit) GPG key id could unknowingly enroll an attacker's colliding key as a trusted anchor, which then vouches for malicious plugins under the ENFORCE signature policy. Version 1.4.9 fixes this by requiring the confirmed value to exactly match the full primary-key fingerprint (case-insensitive, whitespace-stripped). | ||||
| CVE-2026-81706 | 1 Jahlives | 1 Openssl Encrypt | 2026-08-27 | 6.8 Medium |
| openssl_encrypt before 1.4.9 fails to prevent namespace collisions between own identities and contacts in IdentityStore, allowing attackers to create shadowed contact entries invisible until the corresponding own identity is deleted. When the own identity is deleted, the shadowed contact becomes visible and resolves to the attacker's keys, enabling silent key substitution for encrypted files. | ||||