| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect Authorization vulnerability in Drupal Domain allows Forceful Browsing. This issue affects Domain versions: from 3.0.0 to 3.0.2. |
| Incorrect Authorization vulnerability in Drupal View Unpublished allows Forceful Browsing. This issue affects View Unpublished versions: from 0.0.0 to 1.5.0. |
| The Dokan: AI Powered WooCommerce Multivendor Marketplace Solution WordPress plugin before 5.3.3 does not verify that the acting administrator is authorized to manage each selected user before enabling that user's marketplace seller status, allowing a subsite Administrator on WordPress Multisite to enable selling for users outside their own site, including network-level users they cannot otherwise manage. |
| The File Force Download module for Drupal 7 implements hook_file_download() to add a Content-Disposition header when a file URL carries the download query parameter. In Drupal 7, returning a non-empty header array from that hook is itself a grant of access to the file.
In versions 7.1.0 through 7.1.2, the module only delegated to other modules' hook_file_download() implementations when the file was in the private scheme. For every other scheme it returned its headers without any check. An unauthenticated visitor who appended download=1 to the URL of a file in the temporary:// scheme, or in a stream wrapper supplied by another module, could retrieve the file, overriding the access checks that would otherwise have applied. Files in the public and private schemes are not affected. |
| Incorrect Authorization vulnerability in Drupal Field Permissions allows Forceful Browsing. This issue affects Field Permissions versions: from 0.0.0 to 1.6.0. |
| Incorrect Authorization vulnerability in Drupal Field Permissions allows Forceful Browsing. This issue affects Field Permissions versions: from 0.0.0 to 1.6.0. |
| Incorrect Authorization vulnerability in Drupal Fasttoggle allows Forceful Browsing. This issue affects Fasttoggle versions: from 0.0.0 to 4.1.1. |
| Incorrect Authorization vulnerability in Drupal Commerce Core allows Forceful Browsing. This issue affects Commerce Core versions: from 0.0.0 to 2.41.0, from 3.0.0 to 3.3.13. |
| Incorrect Authorization vulnerability in Drupal Commerce Core allows Forceful Browsing. This issue affects Commerce Core versions: from 0.0.0 to 2.41, from 3.0.0 to 3.2.0. |
| Incorrect Authorization vulnerability in Drupal Rabbit Hole allows Forceful Browsing. This issue affects Rabbit Hole versions: from 0.0.0 to 1.3.0. |
| Incorrect Authorization vulnerability in Drupal Bulk Update User Roles allows Forceful Browsing. This issue affects Bulk Update User Roles versions: from 0.0.0 to 1.0.5. |
| Incorrect Authorization vulnerability in Drupal Commerce Shipping allows Forceful Browsing. This issue affects Commerce Shipping versions: from 0.0.0 to 2.16.0, from 3.0.0 to 3.0.6. |
| Incorrect Authorization vulnerability in Drupal Commerce Shipping allows Forceful Browsing. This issue affects Commerce Shipping versions: from 0.0.0 to 2.16.0, from 3.0.0 to 3.0.6. |
| Incorrect Authorization vulnerability in Drupal Commerce License allows Forceful Browsing. This issue affects Commerce License versions: from 0.0.0 to 3.1.1. |
| In Symfony http-foundation prior to versions 5.4.56, 6.4.50, 7.4.23, and 8.1.11, Symfony\Component\HttpFoundation\RequestMatcher, and RequestMatcher\MethodRequestMatcher which replaces it from 6.2.x on, matches a request against a list of HTTP methods. These compared the request method to the list verbatim, while the router serves a HEAD request with the GET handler, as HTTP semantics require.
This came after the incomplete fix of CVE-2026-45075 https://github.com/advisories/GHSA-6439-2f28-8p8q , which addressed the same gap in the #[IsGranted], #[IsSignatureValid] and #[IsCsrfTokenValid] attributes only.
Security rules configured to apply only to GET requests could therefore be bypassed by sending a HEAD request to the same URL. Although HEAD responses contain no body, attackers could still access response headers and trigger the controller's execution, including any side effects.
This issue also affects firewalls configured with methods: [GET]. A HEAD request would not match that firewall and could instead be handled by another matching firewall or no firewall at all. Applications using these vulnerable request matchers directly, including through a custom firewall request_matcher, could also be affected.
The issue affects symfony/http-foundation through v5.4.55, v6.x through 6.4.49, v7.x through v7.4.22, and v8.x through v8.1.10. |
| Incorrect Authorization vulnerability in Drupal AI (Artificial Intelligence) allows Resource Injection. This issue affects AI (Artificial Intelligence) versions: from 0.0.0 to 1.4.11, from 1.5.0 to 1.5.2. |
| Incorrect Authorization vulnerability in Drupal AI File to Text allows Forceful Browsing. This issue affects AI File to Text versions: from 0.0.0 to 1.0.1. |
| LaraDashboard 1.4.0 before 1.4.9 contains an improper authorization vulnerability that allows authenticated users with read-only email_template.view permission to send arbitrary emails via the MCP send-email tool. Attackers can mint an MCP token and call send-email with any recipient, subject, and raw HTML body to deliver phishing or spam from the site's mailer. |
| The `/{username}` web route accepted personal access tokens over HTTP Basic authentication without checking their scope. A token confined to an unrelated scope, such as `read:issue`, could read its owner's private activity through the user RSS/Atom feed and the profile activity tab, and other members' activity in a private organization through the organization feed; a public-only token could list the owner's private repositories and organizations and render private profile READMEs. For a site administrator's token this applied to every account. Tokens are now accepted on this route only for feeds, which require `read:user` or `read:organization`. |
| A logic error in Epiphany's site permission handling can cause camera and microphone access to be granted when the user only approves a different permission.
In src/ephy-window.c, set_permission() stores the user's Allow/Deny choice after a WebKit permission dialog. Types CLIPBOARD and WEBSITE_DATA_ACCESS are not stored by ephy_permission_is_stored_by_permissions_manager(), so control fell into an else-if that was written as:
} else if (EPHY_PERMISSION_TYPE_ACCESS_WEBCAM_AND_MICROPHONE) {
Because that expression is a non-zero enum constant, the branch always ran for those types and wrote EPHY_PERMISSION_PERMIT for both ACCESS_WEBCAM and ACCESS_MICROPHONE for the site origin. The user only saw a Clipboard or Website Data Access dialog.
A malicious site that obtains approval for clipboard or third-party storage access can afterwards use getUserMedia without a further camera/microphone prompt, exposing audiovisual confidentiality.
Requirements: the victim must visit a malicious page and click Allow on a clipboard or website-data-access prompt.
Affected: Epiphany >= 45.0 (bug present at least through 51.x).
Fixed: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2249 (commit 480c3648).
Upstream: https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2976
Reporter acknowledgment: Fernando Munoz |
