| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| wger is a free, open-source workout and fitness manager. Prior to version 2.6, an authenticated attacker can inject arbitrary workout log entries into any other user's `SlotEntry` by supplying the victim's `slot_entry` ID in a `POST /api/v2/workoutlog/` request. The `slot_entry` foreign key is not included in the ownership verification performed by `WorkoutLogViewSet.get_owner_objects()`, so the server accepts and persists the cross-user reference without error. Because `SlotEntry.get_config_data()` retrieves associated logs via `self.workoutlog_set.all()` with no user filter, the attacker's injected data is silently folded into the victim's progressive-overload calculations, corrupting their auto-generated weight and repetition targets. Version 2.6 contains a patch. |
| The Academy LMS WordPress plugin before 4.0.0 does not verify course enrollment or object ownership when returning a lesson's content through one of its REST API routes, allowing users with a self-registerable student account to read the full content of arbitrary lessons, including lessons of paid or private courses they are not enrolled in. |
| The Academy LMS WordPress plugin before 4.0.0 does not verify that a quiz question belongs to the course the requesting user is authorized to access before returning that question's answer options, allowing any authenticated user with access to a single course, such as an enrolled student, to read the quiz answer options of questions belonging to other courses they are not enrolled in. |
| The Yaad Sarig Payment Gateway For WC WordPress plugin before 2.2.13 does not verify authorization or that the requesting user owns the target order in several of its order payment-processing actions, allowing any authenticated user, including subscribers, to act on and alter orders belonging to other customers. |
| An issue was discovered in Django 6.1 before 6.1.2, 6.0 before 6.0.9, and 5.2 before 5.2.18.
`django.forms.models.BaseModelFormSet.save_existing_objects()` used the presence of a primary key on a submitted form's instance as evidence that the instance belonged to the formset's limiting queryset. An object outside that queryset is represented by a newly constructed instance whose primary key can still be populated from submitted data when the model's primary key is a field accepted by the form, such as a `OneToOneField` or parent link used as the primary key of an inline formset's model, or a natural or UUID primary key included in the form's fields. This allows an authenticated user permitted to submit such a formset to delete rows outside the limiting queryset, without any permission on the targeted object, via forged management-form data marking an out-of-queryset object for deletion. Models using the default AutoField primary key are not affected.
Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected.
Django would like to thank Seonggwon Yoon for reporting this issue. |
| Payload is a free and open source headless content management system. In @payloadcms/db-mongodb versions before 3.87.0 and canary versions before 4.0.0-canary.20, an authenticated user who can update a document can modify fields that field-level write access control does not permit that user to change. The Postgres and SQLite adapters are not affected. This issue is fixed in versions 3.87.0 and 4.0.0-canary.20. |
| External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. Starting in version 0.10.0 and prior to version 1.3.2, a bug in the `webhook` generator initialization order incorrectly cleared the label-enforcement flag (`EnforceLabels`) after it was set, resulting in the provider-side check for `external-secrets.io/type=webhook` being skipped (and the operation to succeed while it should have failed with `secret does not contain needed label 'external-secrets.io/type: webhook'. Update secret label to use it with webhook`. Version 1.3.2 contains a patch. |
| Payload is a free and open source headless content management system. In versions from 3.0.0 before 3.90.0 and canary versions before 4.0.0-canary.34, a user who can query a collection with a polymorphic join to sensitive fields can infer hidden or read-restricted values, including password-reset tokens, through polymorphic join filters. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34. |
| Payload is a free and open source headless content management system. In versions before 3.90.0 and canary versions before 4.0.0-canary.34, an attacker can submit a request to a specific update endpoint that modifies collection documents without enforcing collection or field-level access control when orderable is enabled on a collection or join field. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34. |
| The Gitea API routes for issue attachments (`/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}`) also accepted attachments that belong to comments on the issue. Because the author of an issue may edit and delete the issue's attachments, a user who opened an issue could rename or delete attachments that other users had posted in comments on that issue. The contents of the attachments could not be changed. |
| Backstage is an open framework for building developer portals. Prior to 2.2.4, the @backstage/plugin-techdocs-backend package is affected by improper authorization enforcement for techdocs static content. An authenticated user with access to one TechDocs documentation site could craft a URL able to read documentation belonging to a different entity. This only affects deployments using the external TechDocs builder with an external storage provider (S3, GCS, etc.) and the permission framework enabled. Instances that do not use the permission framework are unaffected, since TechDocs content is visible to all authenticated users by design. This issue is fixed in version 2.2.4. |
| IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to improper authorization. |
| Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana could lead to cross-tenant data interception. In this context, "tenant" refers to a user or team sharing the same Kibana deployment, not a separate Elastic Cloud organization or customer. Kibana's Fleet package installation process allowed a user holding delegated Fleet package-management privileges, without direct Elasticsearch administrative privileges, to claim a data stream identifier already in use by another tenant. Because ownership of that identifier was not verified before Fleet applied the uploaded package's generated index and ingest-pipeline settings to already-existing infrastructure, an attacker could redirect an existing tenant's data stream through infrastructure under their control. This exposed the affected tenant's subsequently ingested data to unauthorized disclosure and modification, and prevented that data from reaching its intended destination. Interception could continue even after the malicious package was removed, requiring separate remediation of the affected infrastructure. |
| Authorization Bypass Through User-Controlled Key (CWE-639) in Elasticsearch can lead to Information Disclosure via a specially crafted cross-cluster search request that references an unauthorized shard identifier. Elasticsearch contains an authorization bypass weakness in its handling of cross-cluster search requests made through the Remote Cluster Security (RCS) 2.0 model. An authorization check validates a request against one identifying attribute of the target shard, while a separate, independently-supplied identifying attribute in the same request determines which shard is actually accessed. A holder of a cross-cluster API key authorized for one index can craft a request whose two identifying attributes refer to different indices, causing the request to be authorized against an index they can access while actually operating against a different, unauthorized index. This can expose that index's document contents, field mappings, and other metadata, and in limited cases allows modification of retention-lease state on the unauthorized index. |
| An insecure direct object reference (IDOR) vulnerability in a CloudVision CUE file-serving interface may allow an authenticated network user, under specific attack conditions, to access another user's transient data. |
| The UPI QR Code Payment Gateway WordPress plugin through 1.4.3 does not verify that a payment-confirmation request actually belongs to the order and customer it claims to confirm, allowing unauthenticated attackers to mark an arbitrary order as paid without making any payment. |
| Joomla Extension - phoca.cz - Authorisation bypass through user-controlled key (IDOR) in Order View in Phoca Cart 5.0.0 - 6.1.8 - Phoca Cart's order-file download endpoint does not verify the download tokens it asks for. The d (download token) and o (order token) parameters are checked for non-emptiness only — they are never compared to the stored download_token / order_token values. As a result, any remote user (including a guest with no account at all) can download any customer's digital goods by enumerating sequential id values and supplying arbitrary non-empty tokens. |
| Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.0.0 until 1.10.1, Langflow did not verify flow ownership in the deprecated POST /api/v1/build/{flow_id}/vertices and POST /api/v1/build/{flow_id}/vertices/{vertex_id} handlers. Through version 1.7.1, an unauthenticated caller who knew another user's flow UUID could reach these handlers; from version 1.7.2 through 1.10.0, callers had to authenticate but needed no elevated privileges. Such a caller could cause retrieve_vertices_order to load and cache the private graph, enumerate its vertex identifiers, and use build_vertex to execute selected vertices and receive their results. build_graph_from_db_no_cache performed a primary-key lookup without an owner filter. This could disclose private flow structure, configured values, and selected outputs and could trigger victim-configured side effects and build-history records, although it did not expose the victim's variable-store credentials or permit modification of the stored flow. This issue is fixed in Langflow 1.10.1 and langflow-base 0.10.1. |
| Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.6.8 until 1.9.1, Langflow authenticated access to the project identifier in a project-scoped MCP connection but did not authorize the resource URI supplied to resources/read. read_resource forwarded the attacker-controlled URI to handle_read_resource, which parsed a flow_id and filename and called storage_service.get_file without verifying that the flow belonged to the authenticated user or current project. A user with access to any project-scoped MCP endpoint could therefore request another user's flow-backed file, while global handle_list_resources and handle_list_tools behavior could disclose flow and file identifiers that made targeting easier. The vulnerability disclosed uploaded documents, structured data, prompts, and other private flow artifacts across tenants but did not modify victim files or stored flows. This issue is fixed in version 1.9.1. |
| A vulnerability has been found in PickMall Lilishop up to 4.2.4. This affects an unknown function of the file /buyer/trade/receipt of the component Buyer Invoice List. Such manipulation of the argument memberId leads to authorization bypass. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet. |
