Export limit exceeded: 351196 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (351196 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-13874 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 4.3 Medium |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.1 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user with Guest permissions to view issues in projects they were not authorized to access. | ||||
| CVE-2025-12669 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 5.4 Medium |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.11 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user to inject HTML and JavaScript into email notifications sent to other users due to improper input sanitization. | ||||
| CVE-2025-14869 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 7.5 High |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.5 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an unauthenticated user to cause denial of service by sending specially crafted payloads on certain API endpoints. | ||||
| CVE-2025-14870 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 7.5 High |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.5 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an unauthenticated user to cause denial of service by sending specially crafted JSON payloads due to insufficient input validation. | ||||
| CVE-2026-1184 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 6.5 Medium |
| GitLab has remediated an issue in GitLab EE affecting all versions from 11.9 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an unauthenticated user to cause denial of service by uploading a specially crafted file due to improper validation. | ||||
| CVE-2026-1322 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 6.8 Medium |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.0 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user with a read_api scoped OAuth application to create issues and add comments to issues in private projects due to improper authorization. | ||||
| CVE-2026-1338 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 4.3 Medium |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.10 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user with developer-role permissions to delete protected container registry tags due to improper authorization checks. | ||||
| CVE-2026-2900 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 2.7 Low |
| GitLab has remediated an issue in GitLab EE affecting all versions from 16.10 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that when instance-level approval rule editing prevention was enabled, could have allowed an authenticated user with Maintainer permissions to modify or delete project approval rules due to missing authorization checks. | ||||
| CVE-2026-3073 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 4.3 Medium |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.6 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user with developer-role permissions to bypass PyPI package protection rules and upload restricted packages due to improper authorization checks. | ||||
| CVE-2026-3074 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 4.3 Medium |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.7 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an unauthenticated user to download private debugging symbols from inaccessible projects due to improper access control. | ||||
| CVE-2026-3160 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 5.8 Medium |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.7 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user to view Jira issues outside the configured project scope due to an integration filter functioning only as a display control rather than enforcing access boundaries as specified. | ||||
| CVE-2026-6063 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 4.3 Medium |
| GitLab has remediated an issue in GitLab EE affecting all versions from 11.10 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that under certain conditions could have allowed an authenticated user with developer-role permissions to remove code owner approval rules from merge requests due to improper access control. | ||||
| CVE-2026-6073 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 8.7 High |
| GitLab has remediated an issue in GitLab EE affecting all versions from 18.7 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user to execute arbitrary JavaScript in other users' browsers due to improper input sanitization. | ||||
| CVE-2026-6883 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 2.6 Low |
| GitLab has remediated an issue in GitLab EE affecting all versions from 15.7 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that could have allowed an authenticated user to bypass merge request approval requirements due to improper cleanup of orphaned policy records. | ||||
| CVE-2026-7377 | 1 Gitlab | 1 Gitlab | 2026-05-16 | 8.7 High |
| GitLab has remediated an issue in GitLab EE affecting all versions from 18.7 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3 that, in customizable analytics dashboards, could have allowed an authenticated user to execute arbitrary JavaScript in the context of other users' browsers due to improper input sanitization. | ||||
| CVE-2026-44501 | 2 Datahub, Datahub Project | 2 Datahub, Datahub | 2026-05-16 | 4.3 Medium |
| DataHub is an open-source metadata platform. Prior to 1.5.0.3, The DataHub frontend (datahub-frontend-react) deserializes attacker-controlled Java objects from the REDIRECT_URL HTTP cookie during the OIDC callback flow, with no integrity protection (no HMAC, no encryption). This is a Deserialization of Untrusted Data vulnerability (CWE-502) affecting the GET /callback/oidc endpoint. Successful exploitation requires a valid user account in the configured OIDC identity provider This vulnerability is fixed in 1.5.0.3. | ||||
| CVE-2025-64526 | 1 Strapi | 1 Strapi | 2026-05-16 | 5.3 Medium |
| Strapi is an open source headless content management system. In Strapi versions prior to 5.45.0, the rate-limit middleware in the users-permissions plugin derived its rate-limit key in part from `ctx.request.body.email`, including on routes whose body schema does not contain an `email` field (`/auth/local`, `/auth/reset-password`, `/auth/change-password`). An unauthenticated attacker could include an arbitrary `email` value in the request body to obtain a fresh rate-limit key per request, effectively bypassing per-IP throttling on those routes and enabling high-volume credential brute-force, password-reset code brute-force, and credential-stuffing attempts. The rate-limit key was constructed as `${userIdentifier}:${requestPath}:${ctx.request.ip}`, where `userIdentifier = ctx.request.body.email`. On routes that legitimately use email as their identifier (e.g. `/auth/forgot-password`, `/auth/local/register`), this scoping is correct. On routes that use a different identifier (`identifier` for login, `code` for password reset, `currentPassword` for password change), the email field was not part of the route contract, but the middleware still incorporated it into the key, allowing a caller to rotate the value and obtain a unique key on every request. The patch in version 5.45.0 maintains an allow-list of routes that legitimately key on the email field and excludes that key component on every other route the middleware is mounted on. OAuth callback paths (`/connect/*`) are treated identifier-less. On routes outside the allow-list, the middleware now falls back to a fixed identifier-less key, ensuring per-IP throttling remains effective even when the request body is attacker-controlled. | ||||
| CVE-2026-22599 | 1 Strapi | 1 Strapi | 2026-05-16 | 7.2 High |
| Strapi is an open source headless content management system. In versions on the 4.x branch prior to 4.26.1 and on the 5.x branch prior to 5.33.2, a database-query injection vulnerability existed in the Strapi Content-Type Builder write API. An authenticated administrator could inject arbitrary database statements through the `column.defaultTo` attribute when creating or modifying a content type. Setting `defaultTo` as a tuple `[value, { isRaw: true }]` caused the value to be passed directly into Knex's `db.connection.raw()` during schema migration without sanitization, allowing arbitrary statement execution at the database layer. Depending on the database engine, this enabled arbitrary file read via database utility functions, denial of service via forced server crash on schema-migration error, and on engines that permit external program execution, remote code execution against the database server. The patch in versions 4.26.1 and 5.33.2 addresses this by restricting all Content-Type Builder write APIs to development mode only. Production deployments running v5.33.2 or later return 404 for requests against `/content-type-builder/content-types` and related endpoints, removing the network-reachable attack surface entirely. | ||||
| CVE-2026-22706 | 1 Strapi | 1 Strapi | 2026-05-16 | 6.5 Medium |
| Strapi is an open source headless content management system. In Strapi versions prior to 5.33.3, changing or resetting a user's password did not invalidate the user's existing refresh-token sessions by default. The refresh-token invalidation step in the users-permissions and admin authentication controllers was conditional on a caller-supplied `deviceId`. When a password change or reset request did not include a `deviceId`, no refresh tokens were revoked, leaving every prior session active. An attacker who had previously obtained a refresh token could continue minting new access tokens after the legitimate user reset their password, allowing persistent unauthorized access for the lifetime of the refresh token (up to 30 days by default). Rotating credentials no longer terminated an active attacker session, defeating password reset as a containment measure. The patch in version 5.33.3 invalidates all refresh tokens associated with the user on every password change and password reset, regardless of whether a `deviceId` is supplied. A new device-scoped session is then issued to the caller as part of the response. | ||||
| CVE-2026-22707 | 1 Strapi | 1 Strapi | 2026-05-16 | 5.4 Medium |
| Strapi is an open source headless content management system. In Strapi versions prior to 5.33.3, the Upload plugin's Content API endpoints did not enforce the administrator-configured MIME type restrictions (`plugin.upload.security.allowedTypes` and `deniedTypes`). The same restrictions were correctly enforced on the Admin Panel upload path. The upload plugin's `enforceUploadSecurity` security check was invoked in the admin upload controller but was missing from the Content API controller. The Content API handlers `uploadFiles` and `replaceFile` (and the `upload` wrapper that dispatches to them) called the underlying upload service directly, bypassing both the magic-byte MIME detection and the configured allow/deny lists. An authenticated user with the Content API upload permission could therefore upload file types the administrator had explicitly disallowed, including HTML and SVG content. In deployments serving uploaded files from the same origin as the admin panel (default), an attacker could upload an HTML or SVG file that, when opened directly by an admin, executed JavaScript in the admin origin, enabling admin-session hijack and authenticated administrative actions against the admin API. The patch in version 5.33.3 introduces a shared `prepareUploadRequest` helper that wraps `enforceUploadSecurity` and is called from both the Content API and admin upload controllers, ensuring identical security policy enforcement on every upload entry point. | ||||