Total
2632 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-64961 | 2026-08-28 | N/A | N/A | ||
| ATutor is vulnerable to authentication bypass . Although a token validation check is present in the auto-login functionality, the values required for token validation remain uninitialized in certain code paths. An unauthenticated attacker who can determine a user's identifier and registration timestamp can generate a valid token and authenticate as an existing user, including administrator, without knowing the password. Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. | |||||
| CVE-2026-64969 | 2026-08-28 | N/A | N/A | ||
| ATutor is vulnerable to Insecure Direct Object Reference (IDOR) attack in profile picture related endpoints. Any authenticated user, including a student, can supply another user's member_id in a POST request to the profile album endpoint and permanently delete that user's profile picture, including those of instructors and administrators. Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. | |||||
| CVE-2026-77145 | 2026-08-27 | N/A | N/A | ||
| The permission check for the frontend management update flow verified a different event than the one the request went on to modify. A user with frontend event management access could therefore modify events belonging to other organizers. | |||||
| CVE-2026-77142 | 2026-08-27 | N/A | N/A | ||
| The frontend company self-service editing feature relies on a template-level visibility flag to hide the edit form for company records a visitor does not own, but the corresponding write operation does not repeat this ownership check on the server side. As a result, a visitor who knows the identifier of a company record from the public directory can submit a modified update request for that record directly and overwrite its data, without the application ever confirming that the visitor owns it. | |||||
| CVE-2026-77141 | 2026-08-27 | N/A | N/A | ||
| The extension resolves the targeted club record from a user-supplied request argument in its frontend edit, update, and activate actions, but performs no ownership check in any of them. An unauthenticated visitor who knows the UID of a club record can send a direct request to the update or activate action and overwrite that record, or publish one still awaiting approval, without owning it. | |||||
| CVE-2026-77140 | 2026-08-27 | N/A | N/A | ||
| The extension validates the HMAC of a frontend employee edit link only in the action that renders the edit form, not in the action that persists the change. An unauthenticated visitor who knows the UID of a visible employee record can send a direct POST request to the update action and overwrite that record without a valid edit link or any ownership check. | |||||
| CVE-2026-66878 | 2026-08-27 | N/A | 7.7 HIGH | ||
| A flaw was found in multicloud-operators-subscription. A privileged user, specifically a namespace administrator capable of creating Channel and Subscription resources, can exploit this vulnerability. By manipulating the Channel.Spec.SecretRef.Namespace field, the user can cause the system to copy sensitive Secret contents from other namespaces into their own, leading to information disclosure. | |||||
| CVE-2026-76263 | 1 Splunk | 1 Splunk | 2026-08-26 | N/A | 5.4 MEDIUM |
| In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user who does not hold the "admin" or "power" Splunk roles could delete Splunk Processing Language version 2 (SPL2) modules belonging to other users through the data management orchestrator interface. The vulnerability does not affect Splunk Enterprise versions below 10.2. The broken object level authorization is possible because the data management orchestrator does not verify that the requesting user owns the target resources before it deletes the modules. For more information see Manage SPL2-based apps (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/meet-splunk-apps/manage-spl2-based-apps) in the Splunk documentation. | |||||
| CVE-2026-78144 | 2026-08-26 | 6.5 MEDIUM | 6.3 MEDIUM | ||
| A vulnerability was identified in code-projects Barangay Resident Profiling Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /boarders.php of the component Boarder Management Module. Such manipulation of the argument ID leads to authorization bypass. The attack can be executed remotely. The exploit is publicly available and might be used. | |||||
| CVE-2026-66764 | 2026-08-26 | N/A | 4.3 MEDIUM | ||
| Reprocess Bank Statement Items in SAP S/4HANA does not perform the necessary authorization checks for authenticated users, allowing them to use rules that have not been shared with them, resulting in privilege escalation.This vulnerability has a low impact on confidentiality, with no impact on integrity and availability of the application | |||||
| CVE-2026-77769 | 2026-08-26 | N/A | 6.5 MEDIUM | ||
| The report.list procedure in packages/trpc/src/routers/report.ts accepted a projectId and a dashboardId and returned getReportsByDashboardId(dashboardId). The enforceAccess middleware in packages/trpc/src/trpc.ts verified membership for the supplied projectId, but nothing verified that the supplied dashboardId belonged to that project, and getReportsByDashboardId in packages/db/src/services/reports.service.ts selects reports by dashboardId alone with no project scoping. An authenticated user could therefore pair a projectId from their own organization, which satisfies the middleware, with a dashboardId belonging to another organization and receive every report in that dashboard. A correctly scoped helper, listReportsCore, already existed in the same service file and resolves the dashboard through getDashboardById(dashboardId, projectId) before returning reports, but the router did not use it. | |||||
| CVE-2026-72689 | 2026-08-26 | N/A | 7.5 HIGH | ||
| A broken object-level authorization vulnerability in OpenSignLabs opensignserver through 2.37.0 allows an unauthenticated remote attacker to read complete contract records via the getDocument Parse cloud function. The function fetches documents using useMasterKey, bypassing the object ACL, and returns full records including sender and signer PII and a pre-signed document download URL whenever the document's IsEnableOTP flag is unset, which is the default configuration. | |||||
| CVE-2026-72690 | 2026-08-26 | N/A | 7.1 HIGH | ||
| An improper authorization vulnerability in Attendize through commit 9289acb allows an authenticated remote attacker to inject persistent mandatory survey questions into another organizer's events via the POST /event/{event_id}/question/create endpoint. The postCreateEventQuestion method loads the target event without the tenant-isolation scope, enabling cross-tenant writes; the injected question cannot be removed by the victim because the victim's account-scoped delete path cannot resolve a question owned by another tenant. | |||||
| CVE-2026-78203 | 2026-08-26 | N/A | 7.1 HIGH | ||
| Ghostwriter before 7.1.2 fails to validate template ownership in the report template swap endpoint, allowing attackers to attach client-scoped templates from other clients to their own reports. Attackers can exploit sequential template primary keys to enumerate and attach foreign templates, then generate reports to disclose template contents including letterhead, boilerplate, and methodology text. | |||||
| CVE-2026-76073 | 2026-08-26 | N/A | 8.8 HIGH | ||
| Label Studio does not scope the annotation detail endpoint to the requesting user's organization. AnnotationAPI in label_studio/tasks/api.py declares queryset = Annotation.objects.all() and provides no get_queryset override, so the default lookup retrieves any annotation by primary key. The view's permission_required entries name annotations.view, annotations.change and annotations.delete, and label_studio/core/permissions.py registers every permission with rules.is_authenticated, so the check is satisfied by any logged-in account and no object-level organization test runs. The sibling task endpoint does constrain its queryset with project__organization set to the requester's active organization, which is the boundary this path omits. Annotation identifiers are sequential integers, so an authenticated user of one organization can enumerate identifiers to read, modify and delete annotations belonging to other organizations on the same instance. The same unscoped queryset appears on AnnotationConvertAPI in the same file. | |||||
| CVE-2026-77143 | 2026-08-26 | N/A | N/A | ||
| The frontend topic editing flow does not verify on the server side that the requesting visitor owns the topic being modified. As a result, a visitor who knows the identifier of a topic from the public forum can submit a modified update request for that topic directly and overwrite its content, without the application confirming ownership. Topic identifiers are visible in the public forum listing, and exploitation requires no privileged access or non-default configuration. | |||||
| CVE-2026-77135 | 2026-08-26 | N/A | N/A | ||
| The extension's user detail view fails to verify that a requested user record matches the configured or logged-in target, allowing any visitor with access to the Detail or List plugin to retrieve another frontend user's profile data, including name, email, date of birth and address, by supplying an arbitrary user ID. | |||||
| CVE-2026-77127 | 2026-08-26 | N/A | N/A | ||
| The extension fails to restrict a backend AJAX endpoint for inline editing to fields the current user is permitted to see or edit. An authenticated, low-privileged backend user can supply arbitrary table, field and record parameters, and trigger an error response that discloses the current database value of the requested field, leading to disclosure of sensitive information such as backend and frontend user password hashes. Exploitation requires a valid, authenticated TYPO3 backend user account with access to the extensions backend module. | |||||
| CVE-2026-71251 | 2026-08-26 | N/A | 6.5 MEDIUM | ||
| Akaunting's shared download route (app/Http/Controllers/Common/Uploads.php::download, reachable at uploads/{id}/download behind only generic auth middleware) fetched the requested Media record by ID with no verification that it belonged to the requesting portal customer's own company, allowing any authenticated portal customer to download any other company's uploaded files by guessing or enumerating media IDs. | |||||
| CVE-2026-71242 | 2026-08-26 | N/A | 8.3 HIGH | ||
| Crater's NotePolicy checks only a blanket Bouncer ability (manage-all-notes / view-all-notes) with no company-ownership comparison, unlike InvoicePolicy and other sibling policies which additionally verify ->hasCompany(->company_id). Any authenticated user of one company can read, edit, or delete another company's notes by ID. | |||||