Export limit exceeded: 17819 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (17819 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-61610 | 1 Lycheeorg | 1 Lychee | 2026-10-20 | N/A |
| Lychee is a free, open-source photo-management tool. Prior to 7.6.1, when photos_star_visibility is set to anonymous, POST /api/v2/Photo::highlight can fetch and modify a photo without confirming that the caller can see it. BaseApiRequest::validateResolved() invokes SetPhotosHighlightedRequest::processValidatedValues() before authorization, and PhotoPolicy::canHighlight() returns true for anonymous callers without a canSee check. An unauthenticated attacker who can guess photo identifiers can distinguish existing private photos through differing success and not-found responses and can change their is_highlighted state, including for photos in private or password-protected albums. The issue is limited to installations using the non-default anonymous star-visibility setting. This issue is fixed in version 7.6.1. | ||||
| CVE-2026-104108 | 1 Error311 | 1 Filerise | 2026-10-20 | 8.1 High |
| FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.23.0, FileRise maps an authenticated OIDC identity to a local account using mutable preferred_username or email claims and does not require email_verified for email-based naming. An attacker who can obtain provider-issued claims colliding with an existing local username can be logged in as that account, including the built-in administrator, even when automatic provisioning is disabled. Exploitability depends on the configured identity provider allowing the colliding claim. This issue is fixed in version 3.23.0. | ||||
| CVE-2026-84636 | 1 Apple | 6 Ios And Ipados, Ipados, Iphone Os and 3 more | 2026-10-20 | 5.5 Medium |
| An authorization issue was addressed with improved state management. This issue is fixed in iOS 27 and iPadOS 27, tvOS 27, visionOS 27, watchOS 27. An app may be able to access sensitive user data. | ||||
| CVE-2026-28930 | 1 Apple | 1 Macos | 2026-10-20 | 7.5 High |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.8, macOS Tahoe 26.5. An app may be able to access protected user data. | ||||
| CVE-2026-104627 | 1 Gitea | 1 Gitea | 2026-10-20 | 5.4 Medium |
| The Gitea OpenID association callback in the security settings accepted a positive OpenID 2.0 assertion without checking that the signed-in user had started the linking. Because OpenID 2.0 allows unsolicited assertions, an attacker-controlled OpenID provider could attach the attacker's identity to the account of a signed-in victim who opened a crafted link, and the attacker could then sign in as the victim through OpenID login, which does not apply the local TOTP or WebAuthn checks. The callback now requires a time-limited `state` value bound to the user. | ||||
| CVE-2026-101306 | 1 Freebsd | 1 Freebsd | 2026-10-20 | 9.8 Critical |
| SCM_RIGHTS file descriptor passing did not preserve FD_RESOLVE_BENEATH when a descriptor was transferred. A process could clear the restriction by sending the descriptor to itself over a Unix domain socket. A process in a jail that has received a directory file descriptor from another jail can use these techniques to escape the jail's filesystem root restriction. | ||||
| CVE-2026-108766 | 2 Apache, Apache Software Foundation | 2 Apache Kylin, Apache Kylin | 2026-10-19 | N/A |
| Missing authorization on jdbc source config update in Apache Kylin. Impact most to the kylin services that are directly exposed to public network, which is not common. In-house kylin deployments are mostly not impacted. This issue affects Apache Kylin: from 4.0.0 through 5.0.4. Users are recommended to upgrade to version 5.0.5, which fixes the issue. | ||||
| CVE-2026-72053 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: ipip: require CAP_NET_ADMIN in the device netns for changelink ipip_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. | ||||
| CVE-2026-68300 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally. | ||||
| CVE-2026-111913 | 1 Admidio | 1 Admidio | 2026-10-19 | 4.3 Medium |
| Admidio from 5.0.0 before 5.0.16 contains an authorization bypass vulnerability that allows authenticated users to export lists despite export restrictions by requesting mode=pdfl. The groups_roles_export check in modules/groups-roles/lists_show.php omits pdfl, which later runs the pdf export, letting users with list view rights download member lists as PDF files. | ||||
| CVE-2026-84181 | 1 Apache | 2 Apache Camel, Camel | 2026-10-19 | 5.9 Medium |
| Improper Authentication vulnerability in Apache Camel Shiro component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. The Shiro security processor skipped credential verification when the subject already bound to the current thread carried the same principal as the incoming exchange. Because the thread that carries a Camel exchange is drawn from a pool and reused across exchanges, a subject left bound by an earlier authenticated exchange could satisfy the check for a later one that presented no valid credentials of its own. The password on the incoming exchange was, in that case, never verified. The condition depends on thread reuse and on the principal matching, which is why it is not reached on every request, but it requires nothing of the attacker beyond sending a request naming a principal that is in active use. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. The processor now verifies the presented credentials on every exchange rather than accepting a subject already bound to the thread. Setting alwaysReauthenticate=false restores the previous behaviour for deployments that depend on it. For deployments that cannot upgrade immediately, ensure the Shiro subject is cleared from the thread at the end of every exchange so that no subject can be inherited by a later one. | ||||
| CVE-2026-53188 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate the passed in fops for ib_get_ucaps() Sashiko pointed out it is not safe to rely only on the devt because char/block alias so if the user finds a block device with the same dev_t it can masquerade as a ucap cdev fd. Test the f_ops to only accept authentic cdevs. | ||||
| CVE-2026-52908 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: RDMA: During rereg_mr ensure that REREG_ACCESS is compatible If IB_MR_REREG_ACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ib_umem_check_rereg() function that each driver has to call before processing IB_MR_REREG_ACCESS. mlx4 has to retain its duplicate ib_access_writable check because it implements IB_MR_REREG_ACCESS | IB_MR_REREG_TRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination. | ||||
| CVE-2026-46150 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: fanotify: fix false positive on permission events fsnotify_get_mark_safe() may return false for a mark on an unrelated group, which results in bypassing the permission check. Fix by skipping over detached marks that are not in the current group. | ||||
| CVE-2026-46054 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: selinux: fix overlayfs mmap() and mprotect() access checks The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. | ||||
| CVE-2026-31773 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the local side requested HIGH security. Use the established MITM state when storing the responder STK so the key metadata matches the pairing result. This also keeps the legacy path aligned with the Secure Connections code, which already treats JUST_WORKS/JUST_CFM as unauthenticated. | ||||
| CVE-2025-10149 | 1 Wso2 | 6 Identity Server, Wso2 Carbon Scim 2.0 Common Component, Wso2 Carbon Scim Common Component and 3 more | 2026-10-19 | 8.2 High |
| The SCIM endpoint does not sufficiently validate authorization for federated users when performing operations against the local user store. This occurs when a local and a federated user share the same username, allowing a federated user to perform actions intended for a local user, including arbitrary operations. A malicious actor authenticated as a federated user may perform arbitrary operations on local user accounts via the SCIM 2.0 or SCIM 1.1 endpoints when local and federated users share the same username. This could lead to user account takeover. Deployments that do not support user self-registration are considered medium severity. | ||||
| CVE-2026-31392 | 1 Linux | 1 Linux Kernel | 2026-10-19 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix krb5 mount with username option Customer reported that some of their krb5 mounts were failing against a single server as the client was trying to mount the shares with wrong credentials. It turned out the client was reusing SMB session from first mount to try mounting the other shares, even though a different username= option had been specified to the other mounts. By using username mount option along with sec=krb5 to search for principals from keytab is supported by cifs.upcall(8) since cifs-utils-4.8. So fix this by matching username mount option in match_session() even with Kerberos. For example, the second mount below should fail with -ENOKEY as there is no 'foobar' principal in keytab (/etc/krb5.keytab). The client ends up reusing SMB session from first mount to perform the second one, which is wrong. ``` $ ktutil ktutil: add_entry -password -p testuser -k 1 -e aes256-cts Password for testuser@ZELDA.TEST: ktutil: write_kt /etc/krb5.keytab ktutil: quit $ klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ---------------------------------------------------------------- 1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96) $ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser $ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar $ mount -t cifs | grep -Po 'username=\K\w+' testuser testuser ``` | ||||
| CVE-2026-112105 | 1 Passy | 1 Passy | 2026-10-19 | 3.7 Low |
| A vulnerability has been found in GlitterWare Passy up to 1.10.1. The affected element is the function MyHttpOverrides in the library lib/main.dart of the component TLS Handler. Such manipulation leads to improper certificate validation. The attack may be launched remotely. This attack is characterized by high complexity. The exploitability is described as difficult. Upgrading to version 1.10.2 is sufficient to fix this issue. The name of the patch is 3d48df7cce05e39fa4de1e42768492307f26882e. The affected component should be upgraded. | ||||
| CVE-2026-112775 | 1 Craftcms | 1 Craft Cms | 2026-10-19 | 7.5 High |
| Craft CMS from 5.0.0 before 5.11.0 contains an authentication bypass vulnerability that allows attackers to reuse verification codes because users/verify-email does not invalidate them for active users. Attackers who obtain a victim's emailed code can submit it to users/set-password after the victim verifies an email change, resetting the password and taking over the account. | ||||