Export limit exceeded: 401118 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (4248 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-82432 | 2026-09-14 | 8.1 High | ||
| Description Nimbus validated `topology.blobstore.map` against the calling subject at submission time only. The rebalance operation accepts configuration overrides and stripped a small set of keys from them, but never re-ran that validation, so a caller authorised to rebalance a topology could introduce a blobstore map entry naming a blob whose ACL does not grant them access. Supervisors localise whatever key the map names, placing the blob's contents into the topology's working directory. The same advisory covers `listBlobs`, which performed no authorization check and passed no subject, unlike the neighbouring `getBlobMeta` and `beginBlobDownload` operations. It therefore returned every key in the blobstore to any caller able to reach the Nimbus Thrift port, which provides the key names that make the above practical. On its own the disclosure is metadata only. Mitigation Upgrade to 3.1.0, where rebalance configuration overrides are validated exactly as submission-time configuration is, against the rebalancing caller, and where `listBlobs` applies the configured authorization. Users who cannot upgrade immediately should restrict rebalance rights to trusted principals, keeping in mind that membership of a topology's `topology.users` or `topology.groups` confers them. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | ||||
| CVE-2026-77181 | 1 Apache | 1 Syncope | 2026-09-14 | 9.8 Critical |
| Incorrect Authorization vulnerability in Apache Syncope. An administrator with ClientApp's update entitlement is unable to perform the related operation, while ClientApp's create entitlement is checked both for create and update operations on ClientApp. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. | ||||
| CVE-2026-72524 | 1 Apache | 1 Doris | 2026-09-14 | 8.8 High |
| Incorrect Authorization vulnerability in Apache Doris allows an authenticated user to bypass privilege checks and access or modify data they are not authorized to. This issue affects Apache Doris: from 3.1.0 through 3.1.*, from 4.0.0 through 4.0.7, and from 4.1.0 through 4.1.3. Users are recommended to upgrade to a fixed release (4.0.8 or 4.1.4), which fixes the issue. | ||||
| CVE-2026-85620 | 1 Crystaldba | 1 Postgres-mcp | 2026-09-14 | 8.6 High |
| Postgres MCP Pro 0.3.0 contains a restricted-mode bypass vulnerability where function-name validation is not applied to RangeFunction nodes in FROM clauses. Attackers can execute file-reading functions like pg_read_file through FROM-clause syntax to read arbitrary files despite restricted-mode protections. | ||||
| CVE-2026-82920 | 1 Mattermost | 1 Mattermost | 2026-09-14 | 5.5 Medium |
| Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7 fail to enforce authorization boundaries on the access control policy update endpoint which allows a channel or team administrator to detach a system-assigned ABAC parent policy via a crafted PUT /api/v4/access_control_policies request with an empty imports list.. Mattermost Advisory ID: MMSA-2026-00724 | ||||
| CVE-2026-82431 | 2026-09-14 | 9.8 Critical | ||
| Description `SimpleACLAuthorizer` evaluated the user-level command set by returning early when `nimbus.users` was empty, before `nimbus.groups` was considered. An operator who restricted cluster access by group alone, leaving `nimbus.users` unset, therefore received no restriction at all: every authenticated principal was permitted every user-level operation, including `submitTopology`, `beginFileUpload` and `getNimbusConf`. `docs/SECURITY.md` presents `nimbus.groups` as a supported way to lock down a cluster, so a deployment following the documentation could believe it was restricted while it was not. The failure is silent; nothing in the logs or the configuration indicates that the group list is being ignored. Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged. Mitigation Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set. Users who cannot upgrade immediately should additionally populate `nimbus.users` with the intended principals, since a non-empty user list causes the group list to be evaluated on affected versions. Operators should review Nimbus access logs for operations by principals outside the intended groups. Note that after upgrading, a cluster configured with `nimbus.groups` alone becomes restrictive for the first time. This includes `NimbusClient`, which calls `getLeader` on every connection, so clients outside the configured groups will begin to be refused. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | ||||
| CVE-2026-73668 | 1 Apache | 1 Syncope | 2026-09-14 | 9.8 Critical |
| Incorrect Authorization vulnerability in Apache Syncope. An administrator with adequate entitlements in a given Realm may be able to read via REST the full Connector configuration, confidential properties included, scoped in another Realm and thus be able to effectively duplicate such Connector instance into the Realm they have administration rights for. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. | ||||
| CVE-2026-73370 | 1 Apache | 1 Syncope | 2026-09-14 | 9.8 Critical |
| Incorrect Authorization vulnerability in Apache Syncope. Delegated administration security checks performed by Reconciliation service's pull and push, being incomplete, could accept calls by administrator not provided with adequate entitlements. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. | ||||
| CVE-2026-73318 | 1 Xenforo | 1 Xenforo | 2026-09-14 | 3.8 Low |
| XenForo before 2.3.13 contains a missing authorization vulnerability in the force-agreement controller that allows any ACP administrator to access and submit force-agreement forms regardless of their assigned permissions. Attackers can bypass the option permission declared in the navigation configuration to update the global policy last-updated timestamp, forcing all users to re-agree to the privacy policy or terms of service. | ||||
| CVE-2026-73313 | 1 Xenforo | 1 Xenforo | 2026-09-14 | 6.8 Medium |
| XenForo before 2.3.13 contains a multi-factor authentication bypass vulnerability in the passkey TFA provider that allows an authenticated attacker to complete login as another user by submitting their own registered passkey credential during the WebAuthn assertion step. The passkey verification path performs a global credential lookup without validating that the matched credential belongs to the user whose login is pending, enabling an attacker who knows a target account's password to sign the challenge with their own passkey and bypass multi-factor authentication on both public forum and ACP login paths. | ||||
| CVE-2026-73236 | 1 Apache | 1 Syncope | 2026-09-14 | 7.5 High |
| Incorrect Authorization vulnerability in Apache Syncope. Delegated administration security checks are based on Realm hierarchy and enforced via prefix matches. Due to incorrect implementation, two sibling Realms whose names begin with the same string cannot be correctly distinguished, resulting in incorrect authorization. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. | ||||
| CVE-2026-88008 | 1 Traefik | 1 Traefik | 2026-09-14 | 9.1 Critical |
| Traefik is an open source HTTP reverse proxy and load balancer. From 2.11.26 until 2.11.57 and 3.7.13, Traefik forwards a client-supplied Connection header requesting Upgrade, the Upgrade: h2c token, and HTTP2-Settings to a shared backend. If the backend accepts h2c and returns 101 Switching Protocols, Traefik enters a raw tunnel and no longer applies routers, BasicAuth, ForwardAuth, IPAllowList, RateLimit, access logging, metrics, or tracing to later HTTP/2 requests, allowing an unauthenticated request through an unprotected route to reach protected paths on the same backend. This issue is fixed in 2.11.57 and 3.7.13. | ||||
| CVE-2026-88007 | 1 Traefik | 1 Traefik | 2026-09-14 | 9.1 Critical |
| Traefik is an open source HTTP reverse proxy and load balancer. From 2.11.0 until 2.11.57 and 3.7.13, the HTTP/3 entrypoint ConnContext does not call service.AddTransportOnContext, so kerberosRoundTripper uses a shared backend transport instead of a transport dedicated to each frontend connection. With HTTP/3 enabled, a backend using connection-bound NTLM or Negotiate authentication, and backend keep-alive, an unrelated client can reuse a backend connection authenticated for a victim, read victim-only data, and act as that victim without the victim credentials. This issue is fixed in 2.11.57 and 3.7.13. | ||||
| CVE-2026-69262 | 1 Flowiseai | 1 Flowise | 2026-09-14 | 8.1 High |
| Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, `DELETE /api/v1/chatflows/:id` authorized requests with checkAnyPermission('chatflows:delete,agentflows:delete'), so possession of either permission was sufficient to reach the delete path. The delete logic then resolved the target record only by id and workspaceId and did not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW and a caller with only chatflows:delete to delete an AGENTFLOW in the same workspace. This issue is fixed in version 3.1.3. | ||||
| CVE-2026-70471 | 1 Flowiseai | 1 Flowise | 2026-09-14 | 6.5 Medium |
| Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise injects $vars into the code execution sandbox without requiring variables:view, bypassing the permission-protected Variables API. Variables for the active workspace are fetched at packages/components/src/utils.ts and runtime variables are resolved from server environment variables, while the official variables route enforces variables:view. A user or API key that is denied variables:view can call /api/v1/node-custom-function and receive $vars pre-populated with all variables for the workspace, including Variable.name to Variable.value static variables and Variable.name to process.env[Variable.name] runtime variables. This can expose secrets such as database passwords, JWT secrets, SMTP passwords, and cloud keys, depending on the workspace Variables configuration. This issue is fixed in version 3.1.3. | ||||
| CVE-2026-70472 | 1 Flowiseai | 1 Flowise | 2026-09-14 | 8.8 High |
| Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise openai-assistants-vector-store endpoints accept a client-controlled credential parameter and load credentials by id without checking whether that credential belongs to the caller workspace. Route permissions assistants:* only check feature access. The controller passes req.query.credential straight to the service, and the service uses findOneBy({ id: credentialId }), decrypts the credential, and calls OpenAI APIs without a workspaceId check. If an attacker knows another workspace credentialId, the attacker can use that workspace OpenAI key, read, modify, or delete victim vector stores and files, cause billing impact on the victim OpenAI account, and violate multi-tenant boundaries. This issue is fixed in version 3.1.3. | ||||
| CVE-2026-90806 | 1 Djangocrm | 1 Django-crm | 2026-09-14 | 6.3 Medium |
| A vulnerability has been found in DjangoCRM django-crm up to 1.2. This vulnerability affects the function BulkUpdateCasesView of the file backend/cases/bulk_views.py of the component Bulk Case Update. The manipulation leads to missing authorization. The attack is possible to be carried out remotely. Upgrading to version 1.3.0 is able to resolve this issue. The identifier of the patch is 799bb1210238f402c0c4948c8eedb6e61cd0c8d7. You should upgrade the affected component. | ||||
| CVE-2026-90594 | 1 Wxiaoqi | 1 Spring-cloud-platform | 2026-09-14 | 6.3 Medium |
| A vulnerability was identified in wxiaoqi Spring-Cloud-Platform 3.0.1/3.1.0. This vulnerability affects the function PermissionService.checkUserPermission of the file /rpc/service/PermissionService.java of the component Permission Service. The manipulation leads to missing authorization. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-61907 | 1 Cyrusimap | 1 Cyrus Imap | 2026-09-14 | 4.3 Medium |
| An issue was discovered in Cyrus IMAP before 3.12.4. JMAP snooze bypasses the destination-mailbox ACL. An authenticated user with insert permissions on another user's snoozed mailbox could cause insertion of mail to that user's inbox, or any other of their mailboxes whose id was known to the user, despite having no insert permissions to the target mailbox. | ||||
| CVE-2026-86760 | 2 Grokability, Snipeitapp | 2 Snipe-it, Snipe-it | 2026-09-14 | 5.4 Medium |
| Snipe-IT versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (Api\UsersController::update) and bulk-edit paths are not affected. | ||||