Attack Chain

1. Attacker signs up for a Paperclip account using the default /api/auth/sign-up/email endpoint.
2. Attacker verifies their account and confirms they have no company memberships via GET /api/companies.
3. Attacker identifies the ID of a target agent belonging to a different company, potentially through activity feeds or other exposed APIs.
4. Attacker sends a POST request to /api/agents/:id/keys with a desired name for the API key, targeting the victim agent’s ID.
5. The server responds with a 201 status code, returning a plaintext pcp_* token. No company access check is performed at this stage.
6. Attacker uses the stolen token as a Bearer credential in subsequent API requests.
7. The actorMiddleware resolves the token to an actor with the victim’s company ID, bypassing authorization checks.
8. Attacker can now access sensitive information such as company metadata, issues, approvals, and agent configurations via API endpoints like /api/companies/:victimId, /api/companies/:victimId/issues, and /api/agents/:victimAgentId. They can also pause, terminate, or delete the agent using other vulnerable endpoints.

Impact

This vulnerability allows for a complete bypass of tenancy boundaries in Paperclip. The impact includes:

• Confidentiality: Unauthorized access to sensitive company data, including metadata, issues, approvals, agent configurations, and adapter settings.
• Integrity: Ability to manipulate agent configurations and trigger actions within the victim tenant, potentially leading to data breaches or malicious activities.
• Availability: Ability to pause, terminate, or delete agents belonging to other companies, disrupting their operations.

The severity is high due to the ease of exploitation, default configurations, and the persistence of the stolen tokens. The vulnerability affects all Paperclip instances running in authenticated mode with open sign-up enabled.

Recommendation

• Apply the suggested fix provided in the advisory to server/src/routes/agents.ts by implementing company access checks (assertCompanyAccess) for the /api/agents/:id/keys endpoint.
• Audit and apply similar fixes to the sibling lifecycle handlers at /agents/:id/pause, /resume, /terminate, and DELETE /agents/:id as these share the same vulnerability.
• Conduct a code-wide sweep for assertBoard(req) calls not immediately followed by assertCompanyAccess or assertInstanceAdmin to identify and address other potential cross-tenant access issues.
• Deploy the Sigma rules provided below to your SIEM and tune for your environment to detect unauthorized token minting and API access.
• Monitor Paperclip server logs for unusual API requests to /api/agents/:id/keys from users without company memberships.

Attack Chain

1. An attacker authenticates to the wger application with a low-privileged user account.
2. The attacker navigates to the global configuration edit endpoint at /config/gym-config/edit.
3. The server processes the request via the GymConfigUpdateView which inherits from WgerFormMixin.
4. WgerFormMixin attempts to perform ownership checks but fails because GymConfig does not implement get_owner_object().
5. The application allows the attacker to modify the default_gym setting.
6. The attacker submits the form with a modified default_gym value.
7. The GymConfig.save() method is called, updating UserProfile records with a gym set to null.
8. The attacker has successfully modified installation-wide configuration, potentially bulk-updating user records and violating administrative trust boundaries.

Impact

Successful exploitation of this vulnerability allows a low-privileged user to escalate privileges and modify global configuration settings. This could lead to unauthorized modification of user profiles and tenant assignments, affecting new registrations and existing users lacking a gym. On deployments with multiple gyms, this vulnerability can result in widespread data manipulation and a violation of the intended administrative trust boundary. The vulnerability affects wger deployments, impacting organizations that rely on the application for managing fitness and exercise data.

Recommendation

• Apply the recommended fix by ensuring permission enforcement runs before the form dispatch. Implement the suggested code change in wger/config/views/gym_config.py using the project mixin by updating the inheritance order: class GymConfigUpdateView(WgerPermissionMixin, WgerFormMixin, UpdateView): as described in the advisory.
• Deploy the Sigma rule “wger GymConfig Update by Low-Privilege User” to detect unauthorized modification of the GymConfig object via the /config/gym-config/edit endpoint.
• Monitor web server logs for POST requests to the /config/gym-config/edit endpoint originating from low-privileged user accounts, using the URL as an indicator.

Attack Chain

1. An attacker authenticates to the Genealogy application with valid user credentials.
2. The attacker identifies a target “team” within the application that is not their own.
3. The attacker crafts a malicious HTTP request to the application’s team ownership transfer functionality, specifying the target team and the attacker’s user ID as the new owner.
4. Due to the broken access control vulnerability (CVE-2026-39355), the application fails to validate the attacker’s authorization to perform the ownership transfer.
5. The application incorrectly updates the team’s ownership data, assigning ownership to the attacker.
6. The attacker now possesses full administrative control over the compromised team’s workspace and data.
7. The attacker accesses and exfiltrates sensitive genealogy data, including family trees, personal information, and other confidential records.

Impact

Successful exploitation of CVE-2026-39355 allows an attacker to gain complete control over targeted teams within the Genealogy application. This leads to unauthorized access to sensitive genealogy data, potentially impacting all users and families represented within the compromised teams. The impact includes data exfiltration, modification, or deletion, potentially causing significant reputational damage and legal liabilities. While the exact number of affected installations is unknown, all organizations running versions prior to 5.9.1 are vulnerable.

Recommendation

• Immediately upgrade the Genealogy application to version 5.9.1 or later to patch CVE-2026-39355.
• Monitor web server logs for suspicious POST requests to team management endpoints, specifically those related to team ownership transfer. Use the provided Sigma rule Detect Suspicious Genealogy Team Ownership Transfer to detect unauthorized attempts.
• Implement strict access control policies within the Genealogy application, ensuring that users can only access and modify data related to teams they are authorized to manage.
• Enable detailed logging for all user authentication and authorization events within the Genealogy application to facilitate incident investigation.

Attack Chain

1. An attacker gains a low-privileged account on the Open WebUI platform, either by registering an account if allowed or compromising an existing user.
2. The attacker analyzes the Open WebUI web application to identify the API endpoints or data structures used to manage “tool values.”
3. The attacker crafts malicious HTTP requests targeting the “tool values” API endpoint, attempting to modify a tool value associated with a higher-privileged function or user.
4. Due to the broken access control, the application fails to properly validate if the attacker’s account has the authorization to modify the target tool value.
5. The attacker successfully modifies the tool value.
6. The attacker triggers the functionality associated with the modified tool value.
7. The application executes the functionality with the modified tool value, potentially granting the attacker unauthorized access.
8. The attacker leverages this access to escalate privileges within the system, for example, by executing commands with elevated permissions or accessing sensitive data.

Impact

Successful exploitation of this vulnerability allows an attacker with a low-privileged account to bypass intended access controls within the Open WebUI platform. This could allow unauthorized modifications to the AI platform’s configuration, access to restricted tools or features, and potentially lead to complete compromise of the system. The CVE has a CVSS v3.1 score of 7.7, indicating a high severity. The number of potential victims is dependent on the deployment size of vulnerable Open WebUI instances.

Recommendation

• Upgrade Open WebUI to version 0.8.11 or later to patch the CVE-2026-34222 vulnerability.
• Implement the Sigma rule “Detect Open WebUI Tool Value Modification” to monitor for suspicious activity related to tool value changes.
• Review and enforce strict access control policies within the Open WebUI application to minimize the impact of potential access control vulnerabilities.
• Monitor web server logs for suspicious POST requests to API endpoints associated with tool configuration and management, as indicated in the attack chain.

Attack Chain

1. An attacker authenticates to the Avo admin panel with low-level privileges.
2. The attacker identifies a sensitive action class, such as Avo::Actions::ToggleAdmin.
3. The attacker identifies a target record ID, such as a user ID they wish to manipulate.
4. The attacker crafts a POST request to a resource endpoint where the target action is NOT registered (e.g., /admin/resources/posts/actions).
5. The POST request includes a payload containing the action_id parameter set to the sensitive action class (Avo::Actions::ToggleAdmin).
6. The POST request also includes a fields[avo_resource_ids] parameter set to the target record ID.
7. Due to the insecure action lookup in Avo::ActionsController, the server executes the ToggleAdmin action on the specified user ID.
8. The attacker’s privileges are escalated, or unauthorized data manipulation occurs due to the successful execution of the unintended action.

Impact

The exploitation of this broken access control vulnerability can have severe consequences. A successful attack can lead to privilege escalation, allowing attackers to gain administrative control over the application. Unauthorized operations can be performed, leading to data breaches or data manipulation. Sensitive actions designed for restricted resources can be triggered against any record ID, potentially compromising the integrity and confidentiality of data. The impact includes unauthorized deletion, archival, or updates to records, causing reputational damage and potential financial losses.

Recommendation

• Upgrade to Avo version 3.31.2 or later, which contains the necessary fix to restrict action lookup to registered actions for the current resource context.
• Deploy the Sigma rule Detect Avo Unauthorized Action Execution to monitor for attempts to execute actions on resources where they are not registered.
• Review and audit existing Avo action registrations to ensure that actions are appropriately mapped to resources within the application.