CVE-2026-63401
Coop is an open source review and moderation tool from ROOST. Prior to 1.0.2, `addAccessibleQueuesForUser` and `removeAccessibleQueuesForUse
CVSS
—
Sin CVSS
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 30 oct 2026 · Última mod.: 30 oct 2026 · CWE-639
Sin historial EPSS suficiente todavía.
Coop is an open source review and moderation tool from ROOST. Prior to 1.0.2, `addAccessibleQueuesForUser` and `removeAccessibleQueuesForUser` accepted arbitrary `queueId` and `userId` values without organization scoping. An authenticated user belonging to one organization and holding MRT queue-edit permission could grant or revoke another organization's users' access to manual review queues. The existing queue-edit permission check did not bind the supplied identifiers to the caller's organization. The attacker could not read the other organization's queues or jobs, so this issue did not disclose confidential data. This issue is fixed in version 1.0.2.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-633388.3 ALT—
———IXP Manager is a full-stack web application for managing Internet Exchange Points. Prior to version 7.3.0, an authenticated user can view and edit a resource belonging to another user without authorization. The API-key edit/update path in `ApiKeyController` selects records by identifier without checking that `user_id` matches the caller, allowing access to another user's API-key record. This issue is fixed in version 7.3.0.4hCVE-2026-622776.5 MED—
———LubeLogger is a self-hosted, open-source, web-based vehicle maintenance and fuel mileage tracker. Prior to 1.6.8, `PrintRecordStickers` in `/Controllers/VehicleController.cs` checks through `CollaboratorFilter` that the authenticated caller can view the supplied `vehicleId`, but fetches caller-supplied `recordIds` without checking that each record's `VehicleId` belongs to the authorized vehicle. An authenticated user can submit `POST /Vehicle/PrintRecordStickers` with an authorized `vehicleId`, enumerate other users' integer record IDs and select an `ImportMode` to retrieve records across the service, gas, repair, upgrade, tax, supply, note, odometer, reminder, plan, inspection and equipment stores. Returned information includes descriptions, costs, notes, mileage, extra fields and file attachment metadata, allowing cross-user disclosure of vehicle maintenance records. This issue is fixed in version 1.6.8.5hCVE-2026-629916.5 MED—
———Shopper is a Headless e-commerce Admin Panel. Prior to 2.10.1, the customer detail route `/cpanel/customers/{user}/show` in `packages/admin/src/Livewire/Pages/Customers/Show.php` checks `read_customers` but looks up an arbitrary user ID without applying the `customers` role scope used by the listing. Authenticated staff holding `access_dashboard` and `read_customers` can change the user ID to retrieve administrator or staff profiles despite lacking `view_users`, which protects the separate team-management interface. The flaw exposes account profile data and permits user-ID enumeration through differing success, denial, and not-found responses. If the same role also holds `delete_customers`, `anonymizeAction()` operates on the unrestricted loaded user model and can enable destructive follow-up against non-customer accounts. This issue is fixed in version 2.10.1.6hCVE-2026-1193294.3 MED—
———Immich is a high-performance self-hosted photo and video management solution. Prior to 3.0.0, GET /api/map/markers used server/src/services/map.service.ts to add partner owner identifiers when withPartners=true, while server/src/repositories/map.repository.ts applied Archive visibility to every selected owner when isArchived=true. A view-only partner could therefore enumerate the GPS coordinates and existence of a sharer's archived photos or videos even though the timeline and direct-access paths exclude archived partner assets. The exposure is limited to location metadata and asset identifiers because image bytes remain protected by checkPartnerAccess. This issue is fixed in version 3.0.0.7hCVE-2026-1162398.5 ALT—
———In server mode pgAdmin 4 keeps an account per authentication source, so the same username can exist as, for example, an internal account and an LDAP account. After LDAP or Kerberos authenticated a user, pgAdmin chose the account to log in by username alone, or took the account Flask-Security's login form had looked up, without checking that it came from the source that authenticated the user. The session therefore belonged to another account, with its role, its servers and its saved database passwords:
- An LDAP or Kerberos user whose username matched an internal account was logged in as that internal account, including the administrator account created when pgAdmin is first set up.
- With internal authentication listed before LDAP or Kerberos in AUTHENTICATION_SOURCES, the login form's internal validation looks up the account whose email was typed and keeps it even though its password does not match. A Kerberos user could type another Kerberos user's principal and be logged in as that user, and an LDAP user could do the same with an LDAP account whose email is their username.
Exploitation requires valid credentials for an LDAP directory or Kerberos realm that pgAdmin is configured to use.
The fix looks the account up by the authenticated username and the source that authenticated it, and no longer uses the account the login form found for any source but internal authentication. Internal authentication logs in that account only if it is an internal account. Desktop mode is not affected.
This issue affects pgAdmin 4: before 9.19.7hCVE-2026-1200076.5 MED—
———NodeBB 1.18.0 through 4.16.5 contains an authorization bypass vulnerability that allows unauthenticated visitors to act on other accounts by supplying a uid during POST /register. Attackers can submit an empty email at the /register/complete interstitial to clear a victim's email and confirmation state and revoke all their sessions.7h