Adamkorcz

An issue exists when registration is enabled and the `[oauth2 client].ACCOUNT LINKING` setting is configured as `auto`. The link-account sign-up form identifies existing accounts to link based on the username or email provided in the form rather than the identity verified by the OAuth2 provider. This allows an attacker with a valid account on a configured OAuth2 provider to submit another user's name, link their external identity to that account, and gain unauthorized access without a password, potentially including administrative privileges. This link remains active for subsequent logins.

An authentication bypass exists in the Login V2 UI that allows unauthenticated attackers to take over accounts of users who have not yet configured any authentication method. By computing a valid `verificationCheck` cookie using the user ID and browser fingerprint, an attacker can set a password, register a passkey, or link an identity provider for the target account.

An issue exists where the password-redaction regular expression used during API error handling consumes excessive CPU resources when processing long request bodies. Unauthenticated remote attackers can send a small number of large API requests concurrently to exhaust server workers, resulting in a denial of service that makes the system slow or unavailable to legitimate users.

A SQL injection issue exists in the Mautic administration interface at the '/s/ajax' endpoint. The problem occurs because a request parameter used to select the contact field for searching is not properly validated before being included in a database query. Any authenticated user, regardless of their assigned role or permissions, can exploit this using blind techniques—such as boolean-based or time-based methods—to execute arbitrary SQL queries. This allows the attacker to read sensitive information from the database, including user accounts, email addresses, password hashes, contact data, and campaign content.

An SQL Injection issue exists in the dashboard widget data API endpoint '/api/data/{type}'. This occurs because chart filter parameters provided by the client are not properly validated before being used in database queries that generate dashboard chart data. An authenticated user with API access can use blind SQL injection—a technique used to retrieve data from a database by asking true/false questions—to read arbitrary information from the database, including contact details, marketing data, and user account password hashes. Additionally, the injected SQL can be used to slow down queries, potentially impacting availability. Data modification is not possible, and exploitation requires the Mautic API to be enabled.

A stored cross-site scripting issue exists in the file-preview modal. The system re-publishes binary data as an unsandboxed same-origin blob URL. This allows a member to upload a crafted item and execute scripts within the n8n origin of any user who previews the file, such as the owner, enabling the attacker to act using that user's session.

An authentication bypass exists in the SAML identity-provider intent callback. The system verifies the assertion signature using the provider specified in the request URL but resolves the user from the login intent without ensuring they match. This allows attackers with organization-administrator permissions to register a SAML provider using their own signing key to gain authenticated sessions as any user linked to another SAML provider on the instance, regardless of their organization.

The hosted Login V1 UI contains a flaw where the change-username handler processes requests for the account associated with a login flow before verifying any authentication factors. This allows unauthenticated attackers to provide a victim's login name and submit a new username to rename any active human user, including administrators, which results in the users being locked out of their accounts.

The software has a permissive Cross-Origin Resource Sharing (CORS) configuration that trusts all ports on localhost and 127.0.0.1 with credentials, regardless of the `service.publicurl` setting. This allows an attacker controlling a page on any localhost port to send a credentialed request to the token refresh endpoint and retrieve the bearer JSON Web Token (JWT), which is a compact, URL-safe means of representing claims to be transferred between two parties, leading to full account takeover of the logged-in user.

Plane fails to properly validate the `GITEA HOST` variable, checking only the URL scheme and allowing hosts that resolve to private or internal IP addresses. This occurs because the four outbound requests in the Gitea OAuth flow are derived from this unvalidated host and bypass the `validate url()` function. Additionally, the `avatar url` is retrieved from the Gitea user profile, which allows users to configure external URLs. An attacker can set an internal URL as their profile avatar and log in via Gitea, leading the system to fetch the internal target without validation, potentially enabling Server-Side Request Forgery (SSRF).

The `aPITokenLogMiddleware` logs API keys in plaintext, which allows a user with low privileges to steal these keys and escalate their privileges.

A missing authentication flaw exists in the hosted Login V1 UI. The second-factor enrollment and initialization handlers process identify-only sessions before the primary factor is verified. An attacker with knowledge of a victim's login name can enroll attacker-controlled TOTP, OTP-SMS, OTP-Email, or U2F factors, overwrite the verified phone number, and enumerate users by analyzing discrepant error messages.

An authentication bypass exists in the hosted Login V1 UI. The issue occurs because the registration endpoint for external accounts not found trusts external identity fields provided by the client without requiring a completed Identity Provider (IdP) callback. An unauthenticated attacker can submit forged `IDPConfigID` and `ExternalUserID` values to pre-create an account linked to a victim's external IdP identity. When the victim subsequently performs a legitimate external login, they are signed into the pre-created account.

An authentication bypass exists in the hosted Login V1 and Login V2 UIs. The system allows the enrollment of a passkey or other authenticator during identify-only login sessions before a primary factor is verified. An unauthenticated attacker who knows a victim's login name can register an attacker-controlled authenticator to gain unauthorized access to the account, bypassing passwords and multi-factor authentication (MFA).

An improper authorization flaw exists during the issuance of passkey or passwordless enrollment codes. The system validates the organization specified in the `x-zitadel-orgid` header but fails to verify the organization of the target user. This allows an attacker with user-write permissions in one organization to obtain an enrollment code for a user belonging to a different organization on the same instance, enabling the attacker to register their own authenticator and take over the account.

An issue exists where links are created between user accounts and external identity providers without verifying a primary factor or the caller's permission. This occurs during identify-only Login V2 sessions and via the User Service V2 'AddIDPLink' endpoint. An unauthenticated attacker who knows a victim's login name can bind their own external identity provider identity to the victim's account to hijack it and sign in as the victim.

A privilege escalation issue exists in the API endpoint `POST /users/{username}/tokens` used for creating Personal Access Tokens. The endpoint is protected by the `reqBasicOrRevProxyAuth` middleware, which is designed to require password-based authentication to prevent a compromised token from being used to generate new ones. However, if a token is provided in the `Authorization: Basic <token>:x-oauth-basic` format, the system incorrectly sets the `AuthedMethod` to `basic` and `IsBasicAuth` to `true`, bypassing the middleware guard. Once the guard is bypassed, the `CreateAccessToken` function fails to enforce a scope ceiling, meaning it does not verify if the requested scopes are a subset of the caller's current scopes. Consequently, an attacker possessing a restricted token (such as one with only `write:user` permissions) can create a new token with the `all` scope, granting full administrative access to the account without knowing the user's password.

An authenticated user can cause a denial of service by submitting a specially crafted RFC 4716 (SSH2) public key to the SSH key ingestion endpoint. The issue stems from a normalization function that uses an O(N²) string concatenation loop without input size limits. When a key contains a large number of short content lines, the server performs a quadratic amount of work in both time and memory allocations because Go strings are immutable, requiring a new array allocation and copy for every concatenation. This can lead to CPU and memory exhaustion, taking the instance offline. **API Endpoints:** '/api/v1/user/keys' **Vulnerable Parameters or Variables:** `key` **Function Names:** `parseKeyString()`, `CheckPublicKeyString()`, `CreateUserPublicKey()`

An issue exists in the Remember-Me token validation logic where the system fails to invalidate all active sessions when a compromised token is detected. Gitea uses a split token design consisting of an ID and a Hash. When a token is used, the Hash is rotated while the ID remains constant. If an attacker steals a token and authenticates, they receive a new rotated token. When the legitimate user subsequently attempts to use their original token, the system detects a hash mismatch. While the `CheckAuthToken()` function identifies this mismatch, the `autoSignIn` process only deletes the local cookie of the victim and does not remove the compromised token from the database. This allows an attacker to maintain persistent access to the account. The affected endpoint is `POST /user/login` and any other endpoint that triggers `autoSignIn` via the Remember-Me cookie.

The Debian package registry parser contains two issues that can lead to a complete denial of service. First, an unbounded decompression flaw exists in the `ParseControlFile()` function. When processing an uploaded `.deb` file, the parser decompresses `control.tar.gz` and copies the stream into a `strings.Builder` without limiting the amount of data read. An attacker can use a decompression bomb—a small payload that expands to a massive size—to exhaust server memory. Second, the parser uses `+=` for string concatenation when processing continuation lines in the Description field, resulting in `O(N²)` allocation and copy operations. This can saturate the CPU and trigger frequent garbage collection cycles. Any authenticated user with write access to the package registry can trigger these issues via a request to the handler at `routers/api/packages/debian/debian.go:146`.