Export limit exceeded: 407937 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (4491 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-77361 | 1 The-40-thieves | 1 Obsidian-tc | 2026-10-13 | 4.7 Medium |
| obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, read access-control list (ACL) checks use a lexical vault-relative path while containment checks use the resolved path. An in-vault symlink under an allowed glob that resolves into a denied folder can therefore bypass the read ACL and expose files in the denied folder. Exploitation requires an out-of-band-planted symlink and does not permit an escape from the vault root. Version 1.3.1 fixes the vulnerability by applying ACL checks to the resolved vault-relative path. | ||||
| CVE-2026-109374 | 1 Zitadel | 1 Zitadel | 2026-10-13 | 5.5 Medium |
| ZITADEL 3.0.0 before 4.19.2 contains a privilege escalation vulnerability in OIDC token exchange that allows end-user impersonators to impersonate administrators including IAM_OWNER by bypassing the admin.impersonation check. Attackers holding IAM_END_USER_IMPERSONATOR or ORG_END_USER_IMPERSONATOR roles can sign in to relying applications as administrators with their roles and claims. | ||||
| CVE-2026-108711 | 1 Plastic Labs | 1 Honcho | 2026-10-13 | 4.3 Medium |
| Plastic Labs Honcho through 3.3.0 contains an incorrect authorization vulnerability that allows peer- or session-scoped API key holders to read workspace data because get_or_create_workspace checks only the workspace claim. Attackers can submit their parent workspace name to the POST /v3/workspaces endpoint to retrieve workspace metadata and configuration, including custom_instructions, reserved for workspace or admin keys. | ||||
| CVE-2026-107851 | 1 Contao | 1 Contao | 2026-10-13 | 4.3 Medium |
| Contao is an Open Source CMS. From version 5.7.0 until 5.7.12, TableAccessVoter::hasAccessToModule() in core-bundle/src/Security/Voter/DataContainer/TableAccessVoter.php caches authorization decisions using only $tokenHash, a hash of the user's security token, and omits the table returned by getDataSource(). If one request first checks a table allowed to the user and then a different denied table, the voter can reuse the allowed result, while DefaultDataContainerVoter can convert an incorrect abstention into a grant. A low-privileged backend user can consequently read, create, update, or delete records in tables outside assigned module permissions, including tables containing member or newsletter-subscriber data. This issue is fixed in version 5.7.12. | ||||
| CVE-2026-86684 | 1 Gitea | 1 Gitea | 2026-10-13 | 7.1 High |
| The Gitea push mirror API checked whether the repository owner, instead of the requesting user, may use local file system paths. On instances with `[security] IMPORT_LOCAL_PATHS = true`, a repository administrator who is not allowed to import local paths could add a push mirror to a local path on the server when the repository owner has that permission. Gitea then pushed the repository's refs into an existing Git repository at that path with the permissions of the Gitea process. | ||||
| CVE-2026-89182 | 1 Gitea | 1 Gitea | 2026-10-13 | 5.4 Medium |
| With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected. | ||||
| CVE-2026-97208 | 1 Gitea | 1 Gitea | 2026-10-13 | 4.9 Medium |
| The Gitea API endpoint for creating push mirrors (`POST /api/v1/repos/{owner}/{repo}/push_mirrors`) checked only whether mirroring was enabled and not the `[mirror] DISABLE_NEW_PUSH` setting that the web interface enforces. A repository administrator could therefore create new push mirrors on instances where the site administrator had disabled them. A push mirror pushes all refs of the repository to a remote chosen by the caller, on each commit or on a schedule. | ||||
| CVE-2026-77362 | 1 The-40-thieves | 1 Obsidian-tc | 2026-10-13 | 4.3 Medium |
| obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, bridge tools do not consistently apply the read access-control list (ACL) to every returned field. The tasks_filter tool exposes group counts derived from denied notes, makemd_query passes unfiltered sibling result fields through, and list_templates exposes template paths and parsed user-function bodies without a read-whitelist check. An authenticated caller can consequently infer or read data from notes outside the caller's read ACL. Version 1.3.1 fixes the vulnerability by filtering path-attributable fields and applying the read whitelist to list_templates. | ||||
| CVE-2026-81535 | 2 Wolfssh, Wolfssl | 2 Wolfssh, Wolfssh | 2026-10-13 | 9.1 Critical |
| In wolfSSH through 1.5.0 built with --enable-fwd, DoChannelOpen() in src/internal.c gates only direct-tcpip channel opens with the forwarding policy callback. forwarded-tcpip opens are admitted without an authorization check and are not capped in number, allowing a malicious SSH peer to make an endpoint allocate unbounded per-channel buffers for forwarding channels the application never authorized. A client also does not check a forwarded-tcpip open against the forwards it registered with a tcpip-forward request, as RFC 4254 section 7.2 requires, so a malicious server can open forwarding channels for addresses and ports the client never asked it to forward. | ||||
| CVE-2026-90460 | 1 Openstack | 1 Keystone | 2026-10-13 | N/A |
| An issue was discovered in OpenStack Keystone before 29.0.3. Tokens obtained via delegated authentication methods (EC2 credentials, application credentials, OAuth1 access tokens, and trusts) are not blocked from creating, modifying, or deleting credentials via the /v3/credentials API. EC2-derived tokens can additionally read credential blobs, exposing TOTP MFA seeds and other secrets. Also, PATCH /v3/credentials does not validate the requested post-update project_id, allowing any delegated token to move a credential to an unauthorized project. All Keystone deployments using delegated authentication are affected. | ||||
| CVE-2026-74035 | 1 Wazuh | 1 Wazuh | 2026-10-13 | 7.2 High |
| Wazuh versions from 4.6.0 before 4.14.8 contain an authentication bypass vulnerability where security.update_user places the reserved user guard and password policy inside a falsy truthiness check. A delegated user administrator can send an empty password to the user update endpoint, bypassing the reserved user guard to take over the wazuh superuser account and authenticate with empty credentials. | ||||
| CVE-2026-109559 | 1 Tianma-if | 1 Edgeever | 2026-10-13 | 8.7 High |
| EdgeEver Desktop 1.6.26 through 1.112.0 contains a navigation allowlist bypass that lets attackers load arbitrary origins in the main window via string-prefix URL matching. Attackers can embed a link using userinfo syntax after the dev-server prefix, for example in a note-template preview, to obtain the edgeeverDesktop bridge including session token, sidecar RPC, and ACP channels. | ||||
| CVE-2026-109174 | 1 Mogublog Project | 1 Mogublog | 2026-10-13 | 6.5 Medium |
| MoguBlog through 6.2 contains an information disclosure vulnerability that allows low-privileged front-end users to read system credentials via the getSystemConfig endpoint. Attackers can supply an ordinary reader session token to retrieve unfiltered SystemConfig data, exposing Qiniu and MinIO secret keys and SMTP mailbox passwords. | ||||
| CVE-2026-102832 | 2026-10-13 | 4.2 Medium | ||
| JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From 4.5.7 until 4.5.11 and 4.6.4, the markdownviewer:trust and notebook:trust command-link handlers use tracker.currentWidget to resolve the current Markdown viewer or notebook when the user answers rather than retaining the document whose command button was clicked. If another document becomes current while the prompt is open and the user chooses Trust, JupyterLab marks the second document trusted while leaving the clicked document untrusted. Later command buttons in the incorrectly trusted document run without a prompt, and trusting a notebook marks all cells trusted, saves unsaved edits, and persists the server signature to disk. Applications that bundle JupyterLab, including affected Notebook and JupyterLite releases, inherit the behavior. This issue is fixed in versions 4.5.11 and 4.6.4. | ||||
| CVE-2026-79960 | 1 Gitea | 1 Gitea | 2026-10-13 | 7.1 High |
| When a push was authenticated with a deploy key, Gitea recorded the repository owner as the pusher, so permission checks in the push hook pipeline evaluated the owner instead of the deploy key. A holder of a writable deploy key could create protected tags without being on the tag allow list and change repository visibility through push options, for example making a private repository public. Pull requests created through the AGit flow with a deploy key were also attributed to the owner. | ||||
| CVE-2026-94205 | 1 Gitea | 1 Gitea | 2026-10-13 | 9.8 Critical |
| Gitea Actions decided whether a fork pull request run needed approval based on the user who triggered the event rather than the pull request author. For `pull_request` activity triggered by a maintainer during ordinary triage, such as adding a label, the run was created without requiring approval, while the workflow definition was still taken from the fork head. Where Actions is enabled and a matching runner is registered, fork-controlled workflow code could run on the base repository's runners without an explicit approval. | ||||
| CVE-2026-77366 | 1 The-40-thieves | 1 Obsidian-tc | 2026-10-13 | 9.9 Critical |
| obsidian-tc is a governed, agent-ready Model Context Protocol server for Obsidian vaults. Prior to 1.3.1, tool dispatch does not compare the caller-controlled input.vault value with the vault bound to the caller, the JSON Web Token (JWT) has no vault claim, and the folder access-control list is shared globally. Any valid token can therefore select another configured vault and read, write, or delete its contents through affected tools. Version 1.3.1 fixes the vulnerability by binding tokens and request context to a vault and rejecting mismatched input.vault values before scope checks. | ||||
| CVE-2026-109560 | 2 Continue, Continuedev | 2 Continue, Continue | 2026-10-13 | 7.5 High |
| Continue CLI (@continuedev/cli) through 1.5.47 contains a permission bypass vulnerability that allows attackers to run unapproved commands by chaining them after allowed Bash prefix rules. Attackers can inject instructions into repository files or fetched pages so the agent appends commands after ;, && or | to execute code as the user. | ||||
| CVE-2026-109525 | 1 Girishsaraf | 1 Online-appointment-booking-system | 2026-10-13 | 7.3 High |
| A vulnerability was identified in girishsaraf Online-Appointment-Booking-System up to f427b4757128ca253d33d0cc4e87bbb9c999a4d5. This affects an unknown part of the file changebookingstatus.php of the component submit2 Handler. Such manipulation of the argument username[]/timestamp[]/status[] leads to missing authorization. The attack may be performed from remote. The exploit is publicly available and might be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-109283 | 2 Open-webui, Openwebui | 2 Open-webui, Open Webui | 2026-10-13 | 5.4 Medium |
| Open WebUI from 0.11.1 before 0.11.4 contains an authorization bypass in the OAuth token exchange endpoint, which reads role claims only from the provider's userinfo response and keeps the user's existing role when no roles claim is found, ignoring roles sent only in the ID token. Users with a linked account whose identity provider role no longer satisfies the OAuth role policy can send a valid provider access token to POST /api/v1/auths/oauth/{provider}/token/exchange to obtain a session retaining their previous role. | ||||