Lissy93

A privilege escalation issue allows team owners to obtain administrative rights or ownership of read-only shared projects. An attacker can achieve this by creating a bot, adding it to their team, and then deleting it via the bots endpoint. This process triggers the `ensureProjectAdminUser()` function, which promotes read-only shares and locks out the actual owner.

An information disclosure issue exists where project collaborators with write access can read tasks from inaccessible projects by registering webhooks. This occurs because webhook payloads are constructed using the permissions of the user who triggers the event. Consequently, when another user modifies a linked task, attackers can obtain titles, descriptions, and metadata of `related tasks` from private projects.

The supervisor workload server lacks proper authentication, allowing workloads to manipulate runs from other deployments without ownership verification. An attacker with network access and a valid run/snapshot pair can access the 'attempts/start' endpoint to retrieve resolved environment variables and run JWTs (JSON Web Tokens, which are used for secure transmission of information between parties). Additionally, this allows the attacker to start, complete, or suspend runs belonging to other tenants.

A cross-site request forgery issue exists in the CLI authorization-code flow. The process of loading the '/account/authorization-code/<code>' endpoint mints a Personal Access Token (PAT) without requiring a consent step. An attacker can generate an unauthenticated code and lure an authenticated user to that URL, subsequently retrieving the victim's PAT from the unauthenticated '/api/v1/token' endpoint to achieve account takeover.

Self-hosted installations contain a hardcoded default authentication secret in the `/coordinator` Socket.IO namespace. This allows unauthenticated attackers to connect using the default `coordinator-secret` value. Once connected, attackers can exploit the following: 1. Information Disclosure: By emitting the `READY FOR EXECUTION` event, attackers can retrieve decrypted environment variables for any run if they possess the `runId`. This specifically affects deployments still utilizing Run Engine 1.0. 2. Unauthorized Data Modification: Attackers can send events such as `TASK RUN FAILED TO RUN`, `TASK RUN COMPLETED`, `TASK RUN COMPLETED WITH ACK`, `CHECKPOINT CREATED`, or `CREATE WORKER` to tamper with arbitrary runs using attacker-supplied payloads. This is possible because the system fails to verify if the caller has authority over the `runId` or `attemptId` provided in the message.

Express XSS Sanitizer, middleware for Express 4.x and 5.x, sanitizes user input data in `req.body`, `req.query`, `req.headers`, and `req.params` to prevent Cross-Site Scripting (XSS) attacks. A flaw exists where restrictive sanitization configurations are silently ignored. Specifically, when `allowedTags` is set to an empty array (`[]`) and `allowedAttributes` is set to an empty object (`{}`), the library incorrectly falls back to default permissive settings instead of stripping all HTML tags and attributes. This allows a wide range of HTML elements and attributes, such as `<a href="...">` and `<div>`, to be injected. The issue stems from validation logic that incorrectly interprets empty configurations as not provided, leading to a mismatch between developer intent and actual behavior. The vulnerable component is the sanitization logic within the library.