CVE-2026-65054
MediaCMS 8.2.0 contains an information disclosure vulnerability that allows authenticated users to expose private media metadata belonging t
CVSS
3.1
Low
EPSS
0.3%
p25
KEV
—
Exploit Today
8
0-100
Published: Jul 21, 2026 · Last modified: Jul 23, 2026 · CWE-863
0.2%EPSS · 30 days0.3%
2026-08-172026-09-13
MediaCMS 8.2.0 contains an information disclosure vulnerability that allows authenticated users to expose private media metadata belonging to other users by adding arbitrary media tokens to their own playlist without access control checks. Attackers can issue a PUT request to the playlist API endpoint with a known media token to bypass state and ownership validation, then retrieve the playlist to read private media fields including title, description, view count, like count, file size, author username, and encoding status through the unfiltered playlist owner branch in the playlist detail view.
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-911816.5 MED—
———Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 Fail to sanitize Team objects returned by the data retention teams endpoint which allows an authenticated user holding only the read-only Data Retention Policy permission to obtain a private team's secret invite_id and email, and use it to join the team without authorization, via GET /api/v4/data_retention/policies/{policy_id}/teams.. Mattermost Advisory ID: MMSA-2026-0070214hCVE-2026-908204.3 MED—
———A security vulnerability has been detected in a2aproject a2a-java 1.2.0. The impacted element is the function AuthorizationRequestHandlerDecorator.onListTasks of the file server-common/src/main/java/org/a2aproject/sdk/server/requesthandlers/AuthorizationRequestHandlerDecorator.java. Such manipulation leads to missing authorization. The attack can be launched remotely. Upgrading to version 1.3.0 is sufficient to resolve this issue. The name of the patch is e9a1abf9c90c02b16d17293afdc3cc2f555d63a6. The affected component should be upgraded.14hCVE-2026-198167.1 HIG—
———A flaw was found in PackageKit. PackageKit skips the polkit authorization check for transactions carrying the SIMULATE (dry-run) flag. In the dnf5 backend, the RepoRemove handler ignores that contract and always executes the real transaction because its guard is written as (role == REPO_REMOVE || !SIMULATE), which is always true for RepoRemove. An unprivileged local user can therefore perform a genuine package uninstall while claiming to simulate. This vulnerability only affects systems using PackageKit with the dnf5 backend.16hCVE-2026-909429.6 CRI—
———Casdoor through 4.4.0 fails to properly mask the instance-wide built-in certificate private key in /api/get-certs and /api/get-cert endpoints, allowing organization administrators to retrieve it. Attackers can use the exposed private key to forge JWT tokens for any user in any organization, including global administrators.16hCVE-2026-908066.3 MED—
———A vulnerability has been found in DjangoCRM django-crm up to 1.2. This vulnerability affects the function BulkUpdateCasesView of the file backend/cases/bulk_views.py of the component Bulk Case Update. The manipulation leads to missing authorization. The attack is possible to be carried out remotely. Upgrading to version 1.3.0 is able to resolve this issue. The identifier of the patch is 799bb1210238f402c0c4948c8eedb6e61cd0c8d7. You should upgrade the affected component.15hCVE-2026-558663.7 LOW—
———SpiceDB is an open source database system for creating and managing security-critical application permissions. From 1.34.0 until 1.54.0, SpiceDB can return PERMISSIONSHIP_HAS_PERMISSION instead of PERMISSIONSHIP_CONDITIONAL_PERMISSION or PERMISSIONSHIP_NO_PERMISSION because checkRequestToKey() and checkRequestToKeyWithCanonical() in internal/dispatch/keys/computed.go omit CheckHints when constructing dispatch Check cache keys. The incorrect result requires a permission combining relations with intersection or exclusion, a subject reachable through caveated and non-caveated branches, LookupResources with a context parameter running concurrently with CheckPermission or CheckBulkPermissions for the same resource and subject, and an enabled dispatch result cache. Under these conditions, a result computed for one hint set can poison the cache entry used by a semantically different authorization check, allowing permission without satisfying the caveat. This issue is fixed in version 1.54.0.17h