Filipegaudard

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versions prior to 2.6.4 Description Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. The POST `/api/food/{id}/shopping/` endpoint reads the `amount` and `unit` directly from request data and passes them without validation to `ShoppingListEntry.objects.create()`. Invalid `amount` values (non-numeric strings) cause an unhandled exception and HTTP 500. A `unit` ID from a different Space can be associated cross-space, leaking foreign-key references across tenant boundaries. All other endpoints creating `ShoppingListEntry` use `ShoppingListEntrySerializer`, which validates and sanitizes these fields. Recommendations Update to version 2.6.4 or later.

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versions prior to 2.6.4 Description Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. The `RecipeBookViewSet` and `RecipeBookEntryViewSet` use `CustomIsShared` as a permission class. The `CustomIsShared.has object permission()` function incorrectly returns True for all HTTP methods (DELETE, PUT, and PATCH) without verifying if the request method is within the list of safe methods (`SAFE METHODS`). This allows any user in a RecipeBook's shared list to delete or modify it, despite shared access being intended as read-only. Recommendations Update to version 2.6.4 or later.

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versions prior to 2.6.4 Description The Tandoor Recipes application, used for managing recipes, meal planning, and shopping lists, has an issue where the `PUT /api/recipe/batch update/` endpoint allows authenticated users within a Space to modify any recipe in that Space, even those marked as private by other users. This circumvents object-level authorization checks, potentially leading to the forced exposure of private recipes, unauthorized access via shared lists, and metadata tampering. Recommendations Update to version 2.6.4 or later.

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versions prior to 2.6.4 Description Tandoor Recipes allows authenticated users to inject arbitrary <style> tags into recipe step instructions. The `bleach.clean()` sanitizer explicitly whitelists the <style> tag, allowing unsanitized CSS payloads to be persisted and served via the API. Clients consuming `instructions markdown` from the API and rendering it as HTML without additional sanitization will execute attacker-controlled CSS, potentially enabling UI redressing, phishing overlays, visual defacement, and CSS-based data exfiltration. Recommendations Update to version 2.6.4 or later.

**Name of the Vulnerable Software and Affected Versions** Tandoor Recipes versions prior to 2.6.0 **Description** Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Versions prior to 2.6.0 configure Django REST Framework with BasicAuthentication as a default authentication backend. The AllAuth rate limiting configuration only applies to the HTML-based login endpoint at `/accounts/login/`. Any API endpoint accepting authenticated requests can be targeted via `Authorization: Basic` headers without rate limiting, account lockout, or attempt limits. An attacker can perform high-speed password guessing against any known username. The vulnerable API endpoints are susceptible to brute-force attacks due to the lack of rate limiting on the `BasicAuthentication` method. **Recommendations** Update Tandoor Recipes to version 2.6.0 or later.

**Name of the Vulnerable Software and Affected Versions** Statamic versions prior to 5.73.14 Statamic versions prior to 6.7.0 **Description** Statamic is a Laravel and Git powered content management system (CMS). A stored cross-site scripting (XSS) issue exists in SVG asset reuploads. Authenticated users with asset upload permissions can bypass SVG sanitization and inject malicious JavaScript. This JavaScript executes when the asset is viewed. **Recommendations** Update to Statamic version 5.73.14. Update to Statamic version 6.7.0.

**Name of the Vulnerable Software and Affected Versions** StudioCMS versions prior to 0.4.3 **Description** StudioCMS is a server-side-rendered, Astro native, headless content management system. The `POST /studiocms api/dashboard/create-reset-link` endpoint allows any authenticated user with admin privileges to generate a password reset token for any other user, including the owner account. The handler verifies that the caller is an admin but does not enforce role hierarchy, nor does it validate that the target `userId` matches the caller's identity. Combined with the `POST /studiocms api/dashboard/reset-password` endpoint, this allows a complete account takeover of the highest-privileged account in the system. The vulnerable code is located in the file `packages/studiocms/frontend/pages/studiocms api/dashboard/create-reset-link.ts`. The issue stems from a lack of caller identity validation and role hierarchy enforcement during password reset generation, treating it as a generic admin operation instead of a self-service operation with scope restrictions. The generated reset token is returned directly in the HTTP response body, enabling an attacker to use it with the reset-password endpoint to set an arbitrary password for the target account. **Recommendations** Versions prior to 0.4.3 should be updated to version 0.4.3 or later.

**Name of the Vulnerable Software and Affected Versions** StudioCMS versions prior to 0.4.0 **Description** StudioCMS is a server-side-rendered, Astro native, headless content management system. The `/studiocms api/dashboard/api-tokens` API endpoint, in versions prior to 0.4.0, does not properly validate authorization when creating API tokens. This allows any authenticated user with at least Editor privileges to generate API tokens for any other user, including those with Owner or Admin accounts. This can lead to a full privilege escalation. The vulnerable parameter is the `user ID`. **Recommendations** Update to version 0.4.0 or later.

**Name of the Vulnerable Software and Affected Versions** StudioCMS versions prior to 0.4.0 **Description** StudioCMS is a server-side-rendered, Astro native, headless content management system. The DELETE `/studiocms api/dashboard/api-tokens` API endpoint, before version 0.4.0, allows authenticated users with editor privileges or higher to revoke API tokens belonging to any user, including administrator and owner accounts. The handler accepts `tokenID` and `userID` directly from the request payload without verifying token ownership, caller identity, or role hierarchy. This can lead to a targeted denial of service against critical integrations and automations. **Recommendations** Update to version 0.4.0 or later.

**Name of the Vulnerable Software and Affected Versions** StudioCMS versions prior to 0.2.0 **Description** StudioCMS contains a Broken Object Level Authorization (BOLA) vulnerability in the Content Management feature. This allows users with the "Visitor" role to access draft content created by Editor, Admin, or Owner users. The issue stems from insufficient validation within the `/dashboard/content-management/edit?edit={UUID}` endpoint. Specifically, the endpoint does not verify the user's role or content ownership before granting access. A user with the "Visitor" role can access draft content by directly accessing the edit URL with the content's UUID. The vulnerable parameter is `edit`, which accepts a UUID. This can lead to information disclosure, privacy violations, and potential business impacts due to the exposure of unpublished drafts containing sensitive information. **Recommendations** Versions prior to 0.2.0 should be updated to version 0.2.0 or later.