| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 AI File to Text allows Forceful Browsing. This issue affects AI File to Text versions: from 0.0.0 to 1.0.1. |
| Incorrect Authorization vulnerability in Drupal Fullcalendar View allows Forceful Browsing. This issue affects Fullcalendar View versions: from 0.0.0 to 5.2.6. |
| Incorrect Authorization vulnerability in Drupal Media Bulk Upload allows Forceful Browsing. This issue affects Media Bulk Upload versions: from 0.0.0 to 3.0.6. |
| Incorrect Authorization vulnerability in Drupal Frontend Editing allows Forceful Browsing. This issue affects Frontend Editing versions: from 0.0.0 to 1.9.3. |
| Incorrect Authorization vulnerability in Drupal Simple User Management allows Forceful Browsing. This issue affects Simple User Management versions: from 0.0.0 to 1.11.0. |
| 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. |
| Incorrect Authorization vulnerability in Drupal Dopup allows Forceful Browsing. This issue affects Dopup versions: from 0.0.0 to 1.0.7. |
| Incorrect Authorization vulnerability in Drupal Restrict route by IP allows Forceful Browsing. This issue affects Restrict route by IP versions: from 0.0.0 to 1.3.1, from 2.0.0 to 2.0.1. |
| Incorrect Authorization vulnerability in Drupal SmartLinker AI allows Forceful Browsing. This issue affects SmartLinker AI versions: from 0.0.0 to 1.0.3. |
| Incorrect Authorization vulnerability in Drupal Gutenberg allows Forceful Browsing. This issue affects Gutenberg versions: from 0.0.0 to 2.15.0, from 3.0.0 to 3.0.7. |
| Incorrect Authorization vulnerability in Drupal Inline Entity Form Dialog allows Forceful Browsing. This issue affects Inline Entity Form Dialog versions: from 0.0.0 to 1.0.6. |
| Incorrect Authorization vulnerability in Drupal Actstream allows Forceful Browsing. This issue affects Actstream versions: from 0.0.0 to 2.0.1, from 2.1.0 to 2.1.1. |
| Incorrect Authorization vulnerability in Drupal Entity Reference Manager (Merge entities) allows Forceful Browsing. This issue affects Entity Reference Manager (Merge entities) versions: from 0.0.0 to 1.0.3. |
| Shopify App is a Rails engine for building Shopify applications. From 22.1.0 until 23.0.3, `token-exchange` authenticated controllers can expose a request-derived `shop` context instead of the identity from a verified Shopify ID token or active Shopify session. `current_shopify_domain` can resolve to the sanitized `shop` query parameter, so a request authenticated for one `shop` can cause application code to treat a different requested `shop` as current. Affected applications use `shopify_app` `token-exchange` authentication, accept authenticated requests with a `shop` query parameter, and rely on `current_shopify_domain` or `params[:shop]` for authorization, tenant lookup, stored access-token selection or `shop`-scoped data access. An attacker with a valid Shopify session token for one `shop` can supply another `shop` in that parameter and potentially obtain unauthorized application data or perform `shop`-scoped actions, depending on the application's authorization model. This issue is fixed in version 23.0.3. |
| Incorrect Authorization vulnerability in the single-stage query engine of Apache Pinot.
When broker access control is enabled, the single-stage query engine authorizes only the table named in the query's FROM clause. The lookup() transform function identifies its dimension table with a string literal argument rather than through the FROM clause, so that table was never included in the authorization check. An authenticated user who is authorized for at least one table can therefore read columns from any dimension table in the cluster, including tables they have no access to, and can retrieve arbitrary rows of it by supplying primary key values directly. Per-principal row-level security filters configured on the dimension table are likewise not applied.
The multi-stage query engine is not affected.
This issue affects Apache Pinot: through 1.5.1
Users are recommended to upgrade to version 1.6.0, which fixes this issue. |
| HotCRP is conference review software. Starting with 2.101, the `cmt:` search term checks whether a comment is visible to the searching user but fails to check whether the commenter's identity should be visible. A `cmt:USER` search can therefore match a paper with a visible comment authored by USER even when the comment is supposed to be anonymous. An authenticated user with access to the search can infer the author of an anonymous comment, compromising reviewer anonymity. Comments that the user cannot see remain excluded from search results. The advisory prose identifies 3.3 as fixed, its affected-version metadata excludes 3.3, and the verified repository tag 3.3 already contains the identity-check fix; however, its patched-version metadata instead lists 3.3.1. This fixed-version source conflict remains unresolved. |
| Filecoin Pin is an IPFS Pinning Service API implementation that pins to Filecoin's PDP service. Prior to 1.1.0, the upload GitHub Action's fork detection in `upload-action/src/build.js` checks only `event.pull_request`. In the documented two-workflow pattern, an untrusted fork pull-request workflow produces an artifact and a privileged `workflow_run` workflow downloads and uploads it. Because `workflow_run` has no `event.pull_request`, `isForkPR` becomes false and `uploadStatus` becomes `pending-upload`. The action later resolves `workflow_run.pull_requests` without repeating the fork check before initializing the wallet with `walletPrivateKey` and uploading the artifact. An external contributor can therefore cause attacker-controlled artifacts to be stored using the repository owner's Filecoin wallet, incurring unauthorized storage expenditure, dataset pollution and consumption of configured wallet funds. Disclosure of the wallet private key is not required. The 0.x action line is not receiving a backport and must be migrated to a fixed 1.x release. This issue is fixed in version 1.1.0. |
| In server mode pgAdmin 4 locks an internal account after MAX_LOGIN_ATTEMPTS failed logins (3 by default). The limit could be bypassed, giving an unauthenticated attacker an unlimited number of password guesses against any internal account, including the administrator's, in the default configuration:
- Flask-Security registers its own views next to pgAdmin's. A login submitted to its /login view was checked and logged in without pgAdmin's failed login count or lock. Its /verify view checked a signed-in user's password without limit, its /change view changed a password without pgAdmin's change password permission or re-encrypting the user's saved server passwords, and its /reset views sent and applied password resets for accounts that are not internal or are locked.
- The internal account was looked up by its exact username, while the login form matches the email ignoring case, so a login with the username typed in another case was neither counted nor checked for the lock.
- With LDAP or webserver authentication also configured, a wrong internal password was never counted, and with Kerberos or webserver authentication configured a guess could be answered without being counted.
In addition, where accounts from different authentication sources share an email address, a password reset could be sent for, or applied to, an account from another source, and the About box showed the server configuration to a user whose email was that of an administrator's account.
The fix refuses submissions to Flask-Security's own views, counts every failed internal login however the username is typed and whatever other sources are configured, no longer lets a login that posts a password fall back to an authentication source that does not check it, and locks only internal authentication. Password resets and the About box act only on the user's own internal account. Desktop mode is not affected.
This issue affects pgAdmin 4: before 9.19. |
