Export limit exceeded: 413519 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (413519 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-114040 | 1 Dt42 | 1 Berrynet | 2026-10-22 | 3.5 Low |
| A security vulnerability has been detected in DT42 BerryNet up to 3.10.2. The affected element is the function DLModelManager.get_model_meta of the file berrynet/dlmodelmgr.py of the component Model Package Metadata Handler. The manipulation of the argument label leads to path traversal. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-82819 | 1 Cerberus | 1 Cerberus Ftp Server | 2026-10-22 | N/A |
| A vulnerability in Cerberus FTP Server allows an authenticated remote attacker to perform UNC path injection via a manipulated parameter. By supplying a malicious SMB share path, an attacker can execute authentication coercion against the underlying server, resulting in the leakage of the Cerberus service account's Net-NTLMv2 hash. This issue has been resolved in Cerberus FTP Server: 2026.3.0. | ||||
| CVE-2026-114058 | 1 Arcadedata | 1 Arcadedb | 2026-10-22 | 4.3 Medium |
| ArcadeDB from 26.2.1 before 26.10.1 contains a missing authorization vulnerability in the Bolt protocol handler that lets authenticated users read other databases' schema metadata. Attackers with credentials for one database can set the db field in RUN or BEGIN messages and call db.labels() or SHOW INDEXES to enumerate unauthorized schemas. | ||||
| CVE-2026-114059 | 1 Arcadedata | 1 Arcadedb | 2026-10-22 | 7.5 High |
| ArcadeDB before 26.10.1 contains a remote code execution vulnerability that allows authenticated users, including read-only reader role holders, to execute Groovy code because GremlinQueryEngine.command() lacks scripting authorization checks. Attackers can submit Gremlin commands to the POST /api/v1/command/{database} endpoint when the Groovy engine is enabled to run OS commands as the server process user. | ||||
| CVE-2026-114065 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-22 | 6.5 Medium |
| Trigger.dev before 4.7.3 contains a tenant filtering bypass vulnerability that allows authenticated users to read other tenants' data by using placeholder table syntax in POST /api/v1/query. Attackers can submit queries with FROM {database.table} expressions, including within subqueries, to skip table allowlist and tenant filters and expose run metadata and payloads. | ||||
| CVE-2026-114066 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-22 | 8.1 High |
| Trigger.dev before 4.7.0 contains a missing authorization vulnerability that allows holders of unrestricted environment API keys to block runs they do not own by supplying a foreign parentRunId to batch-creation endpoints. Attackers can send requests to POST /api/v3/batches or POST /api/v2/tasks/batch with resumeParentOnCompletion to suspend, indefinitely block, or inject errors into production or cross-organization runs. | ||||
| CVE-2026-114068 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-22 | 8.3 High |
| Trigger.dev before 4.6.0 contains a missing authorization vulnerability in the waitpoint token wait endpoint that allows authenticated attackers to block runs belonging to other organizations. Attackers holding any secret API key can supply a victim run ID with their own waitpoint, causing that run to block indefinitely on a waitpoint the victim cannot complete, and can inject resume data into it. | ||||
| CVE-2026-114069 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-22 | 8.1 High |
| Trigger.dev before 4.6.0 contains an improper authorization vulnerability in the GET /api/v1/projects/:projectRef/envvars endpoint, which returns the environment's root API key as TRIGGER_SECRET_KEY for staging, production, and preview environments. Attackers holding a restricted read:envvars key can obtain the root secret and plaintext secrets, then trigger tasks and mint admin public JWTs. | ||||
| CVE-2026-114074 | 1 Triggerdotdev | 1 Trigger.dev | 2026-10-22 | 5.4 Medium |
| Trigger.dev before 4.5.10 contains a server-side request forgery vulnerability that allows authenticated project members to bypass webhook SSRF protections by targeting the non-global 198.18.0.0/15 benchmarking range. Attackers can configure alert-channel webhooks pointing at internally routed services in this range, which isUnsafeIPv4 omits, to perform blind internal probing and limited state-changing POST requests. | ||||
| CVE-2026-114104 | 1 Adm-zip Project | 1 Adm-zip | 2026-10-22 | 5.9 Medium |
| adm-zip before 0.6.1 contains an inconsistent entry resolution vulnerability that allows attackers to bypass content validation by supplying ZIP archives with duplicate entry names. Attackers can craft archives where getEntry() returns the last duplicate while extractAllTo() writes the first, causing unvalidated bytes to be written to disk. | ||||
| CVE-2026-114106 | 1 Hkuds | 1 Vibe-trading | 2026-10-22 | 7.5 High |
| HKUDS Vibe-Trading from 0.1.0 before 0.1.7 contains a path traversal vulnerability that allows remote attackers to read sensitive server files through LLM agent file-read tools. Attackers can prompt the agent to invoke read_document, which lacks sandbox checks, or safe_user_path-gated tools to leak /etc/shadow, /proc/self/environ API keys, and /root credentials. | ||||
| CVE-2026-114108 | 1 Hkuds | 1 Vibe-trading | 2026-10-22 | 9.8 Critical |
| HKUDS Vibe-Trading from 0.1.0 before 0.1.7 contains a missing authentication vulnerability that allows unauthenticated attackers to access the FastAPI surface because require_auth() returns early when API_AUTH_KEY is unset. Attackers can post messages to /sessions/{id}/messages to trigger root shell commands via BashTool, upload .py or .sh files via /upload, read session histories, and obtain partial API keys. | ||||
| CVE-2026-114112 | 1 Lovell | 1 Sharp | 2026-10-22 | 7.8 High |
| Sharp before 0.35.4 bundles a vulnerable libheif dependency that allows attackers to achieve possible remote code execution on glibc-based Linux by supplying crafted images. Attackers can submit malicious AVIF/HEIF input to applications processing untrusted images with sharp, triggering libheif decoding flaws to execute code. | ||||
| CVE-2026-114113 | 1 Lovell | 1 Sharp | 2026-10-22 | N/A |
| Sharp before 0.35.0 bundles a version of libvips affected by multiple vulnerabilities (CVE-2026-33327, CVE-2026-33328, CVE-2026-35590, CVE-2026-35591 and CVE-2026-69242) in its GIF, TIFF and VIPS image decoders. Attackers can supply crafted GIF, TIFF or VIPS files to applications using sharp to process untrusted input, triggering these libvips flaws. | ||||
| CVE-2026-114114 | 1 Vyperlang | 1 Vyper | 2026-10-22 | 5.3 Medium |
| Vyper 0.1.0b1 before 0.1.0b12, 0.1.0b14, and 0.4.1 through 0.5.0b1 mix character-based line offsets with Python's UTF-8 byte col_offset values in vyper/ast/parse.py, so multi-byte characters shift the source slices used to reconstruct later numeric literals. An attacker contributing source with non-ASCII identifiers that NFKC-normalize to ASCII, or an invisible byte-order mark, can silently substitute addresses, integers or other constants in compiled code. | ||||
| CVE-2026-76481 | 1 Cisco | 4 Cisco Unified Communications Manager, Emergency Responder, Unified Communications Manager Im And Presence Service and 1 more | 2026-10-22 | 7.5 High |
| As part of Cisco's ongoing commitment to proactive security and product quality, engineering teams for Cisco Emergency Responder, Cisco Prime Collaboration Deployment, Cisco Unified Communications Manager (Unified CM), Cisco Unified Communications Manager IM & Presence Service (Unified CM IM&P), Cisco Unified Communications Manager Session Management Edition (Unified CM SME), and Cisco Unity Connection have conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76481 are related to issues concerning improper handling of exceptional conditions that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-703. | ||||
| CVE-2026-92203 | 1 Airbyte | 1 Airbyte | 2026-10-22 | N/A |
| Airbyte SharePoint Connector _get_shared_drive_object Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to initiate arbitrary server-side requests on affected installations of Airbyte. Authentication is required to exploit this vulnerability. The specific flaw exists within the implementation of the _get_shared_drive_object method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to disclose information in the context of the service account. Was ZDI-CAN-28215. | ||||
| CVE-2026-105869 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| Apache Pulsar's MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token's claims with the signature removed and trusted that authentication had already checked it. When authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker's HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request's Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token's role claim. As a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required. Deployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role. In fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider. This issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from 4.1.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients. | ||||
| CVE-2026-105926 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker's other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected. An authenticated client without any permission on the target topic, namespace or tenant could use these commands to: - read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed. - register a new schema version on an existing topic in another namespace or tenant. The topic's schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator. The standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first. This issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different. This issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. | ||||
| CVE-2026-105927 | 1 Apache | 1 Pulsar | 2026-10-22 | N/A |
| The Apache Pulsar WebSocket service allows a WebSocket consumer to configure a dead letter policy through query parameters of the consumer endpoint, including the deadLetterTopic parameter that names the topic to which messages are written after the maximum number of redeliveries is exceeded. When authorization is enabled, the WebSocket service checks only that the connecting user holds the CONSUME permission on the subscribed topic. It does not check whether the user holds the PRODUCE permission on the topic named in deadLetterTopic. The dead letter messages are then written by the WebSocket service using its own broker client identity rather than the identity of the connecting user. As a result, an authenticated user who holds the CONSUME permission on at least one topic can cause messages to be written to a topic of their choosing in any existing namespace, including namespaces belonging to other tenants, provided the role used by the WebSocket service to connect to the brokers is authorized to produce to that topic and the topic accepts a producer that registers no schema. The dead letter producer created by the WebSocket service registers no schema, so it is rejected when the target topic has a schema and schema validation is enforced for that topic or its namespace; this setting is not enabled by default. The same user is refused when attempting to produce to that topic directly. Where automatic topic creation is enabled, which is the default, the named topic is created if it does not already exist. The issue can only be triggered when the WebSocket service is enabled, either in the broker (webSocketServiceEnabled, which is disabled by default) or as a standalone WebSocket proxy. The impact is unauthorized injection of messages into topics the user is not permitted to produce to. The user can determine the content of the injected messages when they also control the messages on the subscribed topic. The issue does not allow reading, modifying or deleting existing messages in the target topic. Injected messages carry the dead letter message properties and a dead letter producer name, so they can be distinguished from messages produced normally; however, the values of these properties are not authenticated and should not be relied upon to establish the origin of a message. Whether an injected message has further consequences depends on how the applications consuming the target topic process it. Repeated injection also consumes storage and backlog capacity in the target namespace. This issue affects Apache Pulsar versions from 2.3.0 before 4.0.14 and from 4.1.0 before 4.2.5. - 4.0.x version users should upgrade to at least 4.0.14. - 4.1.x and 4.2.x version users should upgrade to at least 4.2.5. Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions. The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. Users who cannot upgrade immediately and do not require the WebSocket service should disable it. Where the WebSocket service is required, restricting network access to it and limiting the permissions granted to the role the WebSocket service uses to connect to the brokers to the namespaces WebSocket clients are intended to access reduces the exposure. | ||||