Export limit exceeded: 16424 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (16424 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-119038 | 1 Perl | 1 Business::gocardless | 2026-11-06 | 6.1 Medium |
| Business::GoCardless versions before 1.01 for Perl complete redirect flows without checking the session token, letting a leaked redirect flow ID create payments against another customer's mandate. confirm_resource takes no session token from the caller. It reads the redirect flow back from the GoCardless API and completes it with the token from that response, so the check that the flow is completed by the session that started it always passes. It then creates the requested payment or subscription against the flow's mandate. Since version 1.00, a flow that already has a mandate is returned as confirmed without being completed again, so the same ID creates a new payment on every call. A remote attacker who obtains another customer's redirect flow ID can create payments or subscriptions against that customer's mandate. | ||||
| CVE-2026-118995 | 1 Perl | 1 Callbackery | 2026-11-06 | 9.1 Critical |
| CallBackery versions before 0.62.0 for Perl accept unintended values in form fields checked by createRxValidator. createRxValidator() is documented to anchor the supplied pattern at both ends, but builds /^${rx}$/ without grouping the pattern. An alternation such as yes|no then accepts any value starting with yes or ending with no, and $ also accepts a value with one trailing newline. An authenticated user can submit values the pattern was meant to reject, which an application may then write into generated configuration files. | ||||
| CVE-2026-116130 | 1 Perl | 1 Http::parser::xs | 2026-11-06 | 9.1 Critical |
| HTTP::Parser::XS versions before 0.18 for Perl truncate PATH_INFO at an encoded NUL byte in parse_http_request. The XS parser URL-decodes the request path and measures the result with strlen(), so PATH_INFO ends at the first byte decoded from %00. The pure-Perl backend is not affected. A remote attacker can send a path that a proxy or filter checks in full while the application routes on a shorter one. | ||||
| CVE-2026-98682 | 1 Linux | 1 Linux Kernel | 2026-11-06 | 2.5 Low |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: drain and invalidate before server-side copy/clone cifs_file_copychunk_range() and the clone (FICLONE) path of cifs_remap_file_range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() and smb3_insert_range()) do. cifs_file_copychunk_range() invalidates the destination range with filemap_invalidate_inode(), which takes and drops the mapping's invalidate_lock internally, so the lock is no longer held when the copychunk ioctl is issued. It also never drains in-flight netfs I/O on the target. The clone path never takes the invalidate_lock at all (only i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not drain outstanding I/O. As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file. This is the same class of corruption as commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole") and has been seen randomly in generic/363 against Windows Server. Fix both paths to follow the established ordering: hold the target mapping's invalidate_lock across the flush and invalidation of the destination and the server ioctl, and call netfs_wait_for_outstanding_io() on the target to drain in-flight writes before the ioctl is issued. Only the target inode's invalidate_lock is required, as the source is merely flushed and not invalidated; i_rwsem (already held via lock_two_nondirectories()) is acquired before the invalidate_lock, matching the VFS lock ordering. Since filemap_invalidate_inode() takes that same lock internally, replace it with its own unmap/flush/invalidate steps instead of calling it, and return early on a zero-length copy to avoid a range underflow. | ||||
| CVE-2026-123624 | 1 Zhimaai | 1 Chatwiki | 2026-11-06 | 5.4 Medium |
| ChatWiki before 2.10.0 contains an insecure direct object reference vulnerability that allows authenticated users to modify other tenants' fast commands by supplying arbitrary sequential ids to POST /manage/saveFastCommand. Attackers can overwrite another tenant's command title, type, content and robot binding, redirecting webpage-jump commands to attacker URLs and reassigning the record to their own tenant. | ||||
| CVE-2026-123782 | 1 Zhimaai | 1 Chatwiki | 2026-11-06 | 4.3 Medium |
| ChatWiki before 2.10.0 contains an insecure direct object reference vulnerability in SaveFormField and UpdateFormRequired that allows authenticated users to modify other tenants' form fields. Attackers can pass their own form_id to satisfy the ownership check alongside another tenant's sequential form_field id to alter field names, descriptions, types and required flags, disrupting how submitted entries are stored. | ||||
| CVE-2026-34157 | 1 Wailsapp | 1 Wails | 2026-11-06 | 7.5 High |
| Wails is a framework for building desktop applications using Go and web technologies. From 2.0.0 until 2.13.0, BindingsAllowedOrigins in v2/internal/frontend/originvalidator/originValidator.go passes wildcard patterns to wildcardPatternToRegex, which expands every asterisk to an unrestricted regular-expression match. When an application configures a trailing or partial-label wildcard immediately after an allowed domain, an attacker-controlled lookalike origin can match the allowed suffix and invoke bound Go methods through IPC. A complete-component subdomain wildcard is an unaffected configuration. The resulting confidentiality, integrity, and availability impact depends on the file, database, command, credential, or other operations exposed by the application's bound methods. This issue is fixed in version 2.13.0. | ||||
| CVE-2026-114421 | 1 Seppmail | 1 Seppmail Secure Email Gateway | 2026-11-06 | N/A |
| SEPPmail Secure Email Gateway before 15.1.1 permits password recovery for a created but unregistered GINA account whose initial password is empty without adequately verifying ownership. A remote unauthenticated attacker who identifies such an account can set a new password, authenticate as that account, and prevent the intended recipient from using it until recovery. | ||||
| CVE-2026-123315 | 1 Jetbrains | 1 Junie | 2026-11-06 | 7 High |
| In JetBrains Junie CLI before 26.8.24 command execution was possible via the Allow Similar Commands option | ||||
| CVE-2026-35102 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.7 Medium |
| HCL AION is affected by an open redirect vulnerability in the navigation bar of the GenAI web interface (Navbar component). The switch-version action redirected the browser to a dynamically constructed URL (window origin + '/workspace') without validating the redirect destination. This may be used in phishing attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35103 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.7 Medium |
| HCL AION is affected by an open redirect vulnerability on the role assignment pending page (RoleAssignPending component). The redirect to the login page used a URL taken from build configuration (NEXT_PUBLIC_LOGIN_URL) without validating the redirect destination. This may be used in phishing attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35104 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.7 Medium |
| HCL AION is affected by an open redirect vulnerability on the user registration page (Signup component). The redirect performed after registration used the value of the 'redirect' query parameter without validation, so a crafted registration link could send a user to an untrusted external site. This may be used in phishing attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35105 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.7 Medium |
| HCL AION is affected by an open redirect vulnerability in the session-handling logic of the GenAI web interface (UserContext component, line 78). The redirect to the login page used a URL taken from build configuration (NEXT_PUBLIC_LOGIN_URL) without validating the redirect destination. This may be used in phishing attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35106 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.7 Medium |
| HCL AION is affected by an open redirect vulnerability in the session-handling logic of the GenAI web interface (UserContext component, line 89). A second redirect to the login page in this component used a URL taken from build configuration (NEXT_PUBLIC_LOGIN_URL) without validating the redirect destination. This may be used in phishing attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35107 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.7 Medium |
| HCL AION is affected by an open redirect vulnerability in the user menu of the GenAI web interface (UserMenu component). The redirect to the login page on logout used a URL taken from build configuration (NEXT_PUBLIC_LOGIN_URL) without validating the redirect destination. This may be used in phishing attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-17615 | 1 Redhat | 22 Apache Camel Quarkus, Apicurio Registry, Build Keycloak and 19 more | 2026-11-06 | 7.5 High |
| A flaw was found in RESTEasy's SourceProvider. This vulnerability allows an unauthenticated attacker to perform an unauthenticated remote file read. By sending a specially crafted XML body with a DOCTYPE declaration referencing external entities to an endpoint that accepts application/xml and returns Source or StreamSource, the server can be tricked into resolving the entity and including sensitive file contents in the HTTP response. This is due to the SourceProvider.writeTo() method creating a SAXParser without disabling external entity resolution, leading to an XML External Entity (XXE) vulnerability. | ||||
| CVE-2026-95663 | 1 Apache | 2 Apache Camel, Camel | 2026-11-06 | 4.8 Medium |
| Insufficient Session Expiration vulnerability in Apache Camel Keycloak component. This issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2. When token introspection is enabled on the camel-keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), the security processor validates the access token of a request by sending it to Keycloak's OAuth 2.0 token introspection endpoint, and accepts the token while the response reports it as active. The introspection endpoint reports a token as inactive once its exp (expiration) time has passed, so on this path the active flag is what enforces token expiry. Introspection results are cached by default (introspectionCacheEnabled=true, introspectionCacheTtl=60 seconds), and both cache implementations shipped with the component, ConcurrentMapTokenCache and CaffeineTokenCache, expired an entry a fixed time after it was inserted, without bounding that lifetime by the exp claim that the cached response already carried. KeycloakSecurityProcessor in turn checked only the active flag of the result, on every path that uses introspection, and never compared exp with the current time. A response cached shortly before the token expired was therefore served to later requests carrying the same token for up to the configured time-to-live after the token's expiry, and those requests were admitted with the roles and permissions the expired token had carried, although RFC 7662, which defines token introspection, states that a response containing exp must not be cached beyond that time. The access token is supplied by the caller with each request, typically as a bearer token in the Authorization header, so a caller holding a token that was valid moments earlier could keep using it after it expired, for as long as the cached entry lived. The window is bounded by introspectionCacheTtl, which is 60 seconds by default and 300 to 600 seconds where the documentation's recommendation for internal services was followed, and it opens only for a token that the same Camel process introspected and cached while the token was still active. The issue grants nothing beyond what the token already carried: it allows no token forgery and no privilege escalation, and token introspection is not enabled by default, which is why the severity is assessed medium. The local JWT verification path, used when introspection is disabled, is not affected by this issue. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.16.x, 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it. | ||||
| CVE-2026-120263 | 1 Gitea | 1 Gitea | 2026-11-06 | 9.8 Critical |
| When `[oauth2_client].ACCOUNT_LINKING` is set to `auto` (not the default) and registration is enabled, the link-account sign-up form looked up the existing account to link by the user name or email submitted in the form instead of the identity asserted by the OAuth2 provider. An attacker with an account on a configured OAuth2 provider could submit another user's name, link their external identity to that Gitea account and be signed in as it without its password, including as an administrator. The link persisted for later sign-ins. Automatic linking now only happens when the existing account matches the provider's email or provider-derived user name; otherwise the account password is required. | ||||
| CVE-2026-80301 | 2026-11-06 | N/A | ||
| Improper isolation in the Avast sandbox on Windows allows a local, low-privileged attacker executing inside the sandbox to access COM interfaces to the Task Scheduler service, escape containment, and execute code with elevated privileges outside the sandbox. The sandbox virtualizes file system and registry access but does not adequately restrict COM interface access to Task Scheduler. A process inside the sandbox can instantiate COM objects bound to Task Scheduler functionality and invoke methods to schedule and execute tasks on the host system. The Task Scheduler COM pathway is not blocked by the sandbox policy, allowing arbitrary code execution in the host security context. This escape vector bypasses the sandbox's intended process and file isolation boundaries and can be chained with other host-level privilege escalation techniques. | ||||
| CVE-2026-80302 | 2026-11-06 | N/A | ||
| Insufficient isolation in the Avast sandbox file virtualization layer on Windows allows a local, low-privileged attacker executing inside the sandbox to write arbitrary files outside sandbox containment and execute code on the host. The sandbox virtualizes file system operations by intercepting write requests to protected system directories. However, the virtualization implementation fails to properly validate write targets in certain edge cases, allowing writes to bypass the virtualization redirection and reach the actual host file system in protected locations. An attacker can exploit this to overwrite executable files, system libraries, or startup configurations with arbitrary content, leading to code execution with host privileges on subsequent system operations or reboot. | ||||