On October 1, 2025, Palantir discovered that images uploaded through the Dossier front-end app were not being marked correctly with the proper security levels. The regression was traced back to a change in May 2025, which was meant to allow file uploads to be shared among different artifacts (e.g. other dossiers and presentations). On deployments configured with CBAC, the front-end would present a security picker dialog to set the security level on the uploads, thereby mitigating the issue. On deployments without a CBAC configuration, no security picker dialog appears, leading to a security level of CUSTOM with no markings or datasets selected. The resulting markings and groups for the file uploads thus will be only those added by the default authorization rules defined in the Auth Chooser configuration. On most environments, it is expected that the default authorization rules only add the Everyone group.

A security defect was identified in Foundry workspace-server that enabled a user to bypass an authorization check and view settings related to 'Developer Mode'. This enabled users with insufficient privilege the ability to view and interact with Developer Mode settings in a limited capacity. A fix was deployed with workspace-server 7.7.0.

A security defect was discovered in Foundry job-tracker that enabled users to query metadata related to builds on resources they did not have access to. This defect was resolved with the release of job-tracker 4.645.0. The service was rolled out to all affected Foundry instances. No further intervention is required.

In cases where a multi-tenant stack user is operating Foundry’s Linter service, and the user changes a group name from the default value, the renamed value may be visible to the rest of the stack’s tenants.

In multi-tenanted deployments, the application consent management mechanism fails to correctly isolate consent scopes between tenants. Consent granted by a user for a specific SaaS application within one tenant can be incorrectly applied to SaaS applications with the same name in other tenants, leading to unintended cross-tenant consent sharing. This vulnerability may result in the exposure of user data across tenants, enabling SaaS applications in different tenants to access and modify information without explicit user authorization. This can lead to unauthorized data access and privacy violations. This vulnerability has no impact if the deployment does not support multi-tenancy.

Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.0, the Caldav endpoint allows login using Basic Authentication, which in turn allows users to bypass the TOTP on 2FA-enabled accounts. The user can then access standard project information that would normally be protected behind 2FA (if enabled), such as project name, description, etc. Version 2.2.0 patches the issue.

The credentials of the users stored in the system's local database can be used for the log in, making it possible for an attacker to gain unauthorized access. This could potentially affect the confidentiality of the application.

Authentication Bypass Using an Alternate Path or Channel vulnerability in Drupal Login Disable allows Functionality Bypass.This issue affects Login Disable: from 0.0.0 before 2.1.3.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.6 before 18.7.6, 18.8 before 18.8.6, and 18.9 before 18.9.2 that could have allowed an authenticated user to disclose metadata from private issues, merge requests, epics, milestones, or commits due to improper filtering in the snippet rendering process under certain circumstances.

In Zammad 6.4.x before 6.4.2, an authenticated agent with knowledge base permissions was able to use the Zammad API to fetch knowledge base content that they have no permission for.