Filipegaudard

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versões anteriores a 2.6.4 Description Tandoor Recipes é uma aplicação para gerenciar receitas, planejar refeições e criar listas de compras. O endpoint POST `/api/food/{id}/shopping/` lê os valores de `amount` e `unit` diretamente dos dados da requisição e os passa sem validação para `ShoppingListEntry.objects.create()`. Valores de `amount` inválidos (strings não numéricas) causam uma exceção não tratada e um erro HTTP 500. Um ID de `unit` de um Space diferente pode ser associado entre Spaces, expondo referências de chave estrangeira entre limites de locatários. Todos os outros endpoints que criam `ShoppingListEntry` usam `ShoppingListEntrySerializer`, que valida e higieniza esses campos. Recommendations Atualize para a versão 2.6.4 ou posterior.

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versões anteriores a 2.6.4 Description Tandoor Recipes é uma aplicação para gerenciar receitas, planejar refeições e criar listas de compras. O `RecipeBookViewSet` e o `RecipeBookEntryViewSet` usam `CustomIsShared` como uma classe de permissão. A função `CustomIsShared.has object permission()` incorretamente retorna True para todos os métodos HTTP (DELETE, PUT e PATCH) sem verificar se o método da requisição está dentro da lista de métodos seguros (`SAFE METHODS`). Isso permite que qualquer usuário na lista compartilhada de um RecipeBook o exclua ou modifique, apesar do acesso compartilhado ser destinado apenas à leitura. Recommendations Atualize para a versão 2.6.4 ou posterior.

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versões anteriores a 2.6.4 Description A aplicação Tandoor Recipes, utilizada para gerenciar receitas, planejar refeições e criar listas de compras, apresenta uma falha onde o endpoint `PUT /api/recipe/batch update/` permite que usuários autenticados dentro de um Space modifiquem qualquer receita nesse Space, mesmo aquelas marcadas como privadas por outros usuários. Isso contorna as verificações de autorização em nível de objeto, podendo levar à exposição forçada de receitas privadas, acesso não autorizado via listas compartilhadas e adulteração de metadados. Recommendations Atualize para a versão 2.6.4 ou posterior.

Name of the Vulnerable Software and Affected Versions Tandoor Recipes versões anteriores a 2.6.4 Description Tandoor Recipes permite que usuários autenticados injetem tags <style> arbitrárias nas instruções de etapas da receita. O sanitizador `bleach.clean()` lista explicitamente a tag <style>, permitindo que cargas úteis CSS não higienizadas sejam persistidas e servidas através da API. Clientes que consomem `instructions markdown` da API e o renderizam como HTML sem sanitização adicional executarão CSS controlado por um invasor, potencialmente habilitando redirecionamento de interface do usuário, sobreposições de phishing, desfiguração visual e exfiltração de dados baseada em CSS. Recommendations Atualize para a versão 2.6.4 ou posterior.

**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.