Export limit exceeded: 30018 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (30018 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-101259 | 1 Apache | 2 Apache Camel, Camel | 2026-11-06 | 5.3 Medium |
| Generation of Error Message Containing Sensitive Information vulnerability in Apache Camel CoAP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2. When the CoAP consumer could not build its response once the route had completed, CamelCoapResource caught the resulting exception and sent its message back to the CoAP client as the payload of a 5.00 Internal Server Error response. The typical case is a type conversion failure: the consumer converts the final message body to the byte[] payload, and the CamelCoapMaxAge and CamelCoapETag headers to their types, after the route has returned, and therefore outside the route's error handler. On the affected releases the message of such a failure names the class of the value being converted, carries the value's string form, and ends with the class name and message of the underlying cause, so a remote CoAP client could read internal detail about the deployment: class and package names, the string form of the value, such as the path of a file body, and whatever the cause carries, which in practice can include paths, host names and connection detail of a backend. The consumer had no option to suppress this, unlike the HTTP consumers, which offer a muteException option for that purpose. The exception raised by a failing route was not sent: the consumer did not check whether the exchange had failed, and answered a route failure with 2.05 Content and whatever body the message held at that point. Reaching the disclosure therefore requires a route whose completed response a remote client can make unconvertible, which depends on how the route is written. 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.14.x releases stream and earlier, and the 4.15.x to 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. The upgrade is enough on its own: the new muteException consumer option defaults to true on all three fixed release lines, so the error response carries no payload without any configuration change. For deployments that cannot upgrade immediately, make sure the response can always be built once the route has completed: convert the body to byte[] or String as the last step of each route that consumes from a coap endpoint, for example with convertBodyTo, give the CamelCoapMaxAge and CamelCoapETag headers only values of their own types, and add an onException handler that marks the failure as handled and sets the response body explicitly, so that a conversion failure is raised and replaced inside the route rather than in the consumer. | ||||
| CVE-2026-28578 | 1 Google | 1 Android | 2026-11-06 | 5.5 Medium |
| In multiple functions of DevicePolicyManagerService.java, there is a possible desync from persistence due to improper input validation. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-35114 | 1 Hcltech | 1 Aion | 2026-11-06 | 3.7 Low |
| HCL AION is affected by a vulnerability where the X-Content-Type-Options header was missing or insecure, allowing browsers to MIME-sniff responses. This may cause content to be interpreted as an unintended type, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35111 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.8 Medium |
| HCL AION is affected by a vulnerability where the Cross-Origin-Resource-Policy (CORP) header was missing or insecure, allowing application resources to be loaded by other origins. This may expose resources to cross-origin data leakage, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35113 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.8 Medium |
| HCL AION is affected by a vulnerability where the Cross-Origin-Opener-Policy (COOP) header was missing or insecure, allowing cross-origin documents to share a browsing context with the application. This may enable cross-window attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-35112 | 1 Hcltech | 1 Aion | 2026-11-06 | 4.2 Medium |
| HCL AION is affected by a vulnerability where the Cross-Origin-Embedder-Policy (COEP) header was missing or insecure, so embedded cross-origin resources were not required to explicitly grant permission. This weakens cross-origin isolation, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-0078 | 1 Google | 1 Android | 2026-11-06 | 7.8 High |
| In setGlobalProxy of DevicePolicyManagerService.java, there is a possible desync in persistence due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-0070 | 1 Google | 1 Android | 2026-11-06 | 5.5 Medium |
| In multiple functions of DevicePolicyManagerService.java, there is a possible way to hide a system critical package due to improper input validation. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-0051 | 1 Google | 1 Android | 2026-11-06 | 6.5 Medium |
| In multiple functions of ubsan_throwing_runtime.cpp, there is a possible way to cause a system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-119533 | 1 Gitea | 1 Gitea | 2026-11-06 | 7.5 High |
| Repository and organization project boards listed the pull requests that reference each issue on the board without checking whether the viewer can read them. When a private pull request mentions an issue on a board the viewer can open, the board revealed the private repository's path and the pull request's number, title and state, to anonymous visitors in the case of a public board. The pull request body, diff and files were not exposed. Boards now skip linked pull requests in repositories where the viewer cannot read pull requests. | ||||
| CVE-2026-117649 | 1 Gitea | 1 Gitea | 2026-11-06 | 3.5 Low |
| The issue timeline API and the web issue page hid cross-reference events that point at issues the reader cannot access, but not "dependency added" and "dependency removed" events. When a readable issue had been linked as a dependency to an issue in a repository the reader cannot access, for example a private repository, any reader of the first issue, including anonymous users of a public repository, received the linked issue's current title, body, state, labels, poster and attachment names through the API, and its repository, number and title on the web page. Creating the link requires access to both issues; comments and attachment downloads of the linked issue stayed protected. Dependency events are now filtered with the same read permission check; a related exposure of unlinked attachment metadata through hidden dependency placeholders was already fixed in 28.2.0. | ||||
| CVE-2026-117646 | 1 Gitea | 1 Gitea | 2026-11-06 | 4.3 Medium |
| The repositories, stars and watching tabs of user profiles and the repository list of organization home pages included private repositories for every signed-in request without checking whether the request used a personal access token restricted to public resources (`public-only`). A holder of such a token could list the private repositories visible to the token's owner, and that user's stars and watches of private repositories. The API and the profile activity tab already applied the restriction. The impact is disclosure of repository names and metadata, not of repository content. | ||||
| CVE-2026-114199 | 1 Gitea | 1 Gitea | 2026-11-06 | 5.3 Medium |
| `GET /api/v1/users/{username}/heatmap` computed the contribution heatmap with the repository access of the token owner and ignored the public-only restriction of the access token, unlike the activity feed endpoints. A holder of a user's public-only token could read contribution counts and their 15-minute time buckets that stem from that user's activity in private repositories. Repository names and contents were not disclosed. For public-only tokens the heatmap now only counts activity visible to anonymous users. | ||||
| CVE-2026-112887 | 1 Gitea | 1 Gitea | 2026-11-06 | 4.3 Medium |
| Gitea Actions task tokens authenticate to the REST API as a shared system user with a negative ID, which repository, organization, project and key filters treated as having no owner restriction, and the token carried no API scope to restrict user-scoped routes. A user who can run a workflow could use the job's token with `GET /api/v1/user/repos` to list every repository on the instance, including private repositories of other users and organizations, with their metadata. Repository contents remained protected by per-repository permission checks. System users now own nothing, and `/api/v1/user` routes other than `GET /api/v1/user` accept only individual and bot accounts. | ||||
| CVE-2026-118565 | 1 Drupal | 1 Groupex Pro ( Daxko ) Integration | 2026-11-06 | 7.2 High |
| Vulnerability in Drupal GroupEx PRO ( Daxko ) integration. This issue affects GroupEx PRO ( Daxko ) integration versions: *.*. | ||||
| CVE-2026-118564 | 1 Drupal | 1 Payumoney For Drupal Commerce | 2026-11-06 | 6.6 Medium |
| Vulnerability in Drupal PayUmoney for Drupal Commerce. This issue affects PayUmoney for Drupal Commerce versions: *.*. | ||||
| CVE-2026-90963 | 2026-11-06 | 5.3 Medium | ||
| The Essential Real Estate WordPress plugin before 5.3.5 does not perform any authorization or publication-status check in one of its AJAX actions, allowing unauthenticated users to read the full contents of property listings that have not been published, together with the private name, email address, phone number and office address of the listing agent. | ||||
| CVE-2026-66984 | 2026-11-06 | 3.1 Low | ||
| HCL AION is affected by a vulnerability where certain application responses revealed internal server file system paths. This information could help an attacker understand the application structure and plan further attacks, potentially resulting in unintended behavior or security impact under certain conditions. | ||||
| CVE-2026-118394 | 1 Gitea | 1 Gitea | 2026-11-06 | 4.3 Medium |
| The OAuth2 userinfo endpoint (`/login/oauth/userinfo`) decided whether to limit the `groups` claim to public organizations by re-parsing the `Authorization` header as an OAuth2 access token instead of using the scope of the credential that authenticated the request. When a public-only OAuth2 token was sent as a query parameter or form field, or a public-only personal access token was used, that scope came back empty and the claim listed the token owner's private organizations, teams and concealed memberships. The disclosure is limited to the owner's organization and team names and memberships; no repository content is exposed. The endpoint now uses the scope of the authenticating token. | ||||
| CVE-2026-121971 | 1 Sensiolabs | 1 Symfony | 2026-11-06 | 7.5 High |
| The component ScopingHttpClient in Symfony HttpClient merges the options of its default scope (such as auth_bearer or auth_basic) into a request before resolving a relative URL against the base_uri, allowing a network-path reference such as "//evil.example/steal" to be sent to another origin together with the default scope’s credentials, and resulting in potential disclosure of those credentials to an attacker-controlled server. This affects Symfony in versions 5.x prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11. The resolved URL falls outside the origin of the base URI, yet it keeps the merged options, whereas the absolute spelling "https://evil.example/steal" receives none. The same happens with a different port or user-info part on the same host. This is reachable whenever an attacker controls the beginning of a URL passed to a client built with a base_uri and credentials, including those created with HttpClient::createForBaseUri() or configured under framework.http_client.scoped_clients. To solve the issue, after resolving a relative URL against the base URI of the default scope, ScopingHttpClient now compares the scheme and authority of the result with those of the base URI, parsed the way the request is sent. | ||||