Bugbunny-Research

The API server decompresses uploaded pipeline archives without properly bounding the expanded data during the process of locating or reading the pipeline file. This can allow a small ZIP or gzip-compressed tar archive to consume excessive memory, leading to the exhaustion of API server resources. In multipart pipeline and pipeline-version upload processing, decompression occurs before namespace authorization, meaning a caller can trigger this issue without needing pipeline-create authorization. Conversely, URL-import handlers perform authorization before fetching and decompressing remote archives.

The API server fails to authorize callers when retrieving logs via the 'GET /apis/v1alpha1/runs/{run id}/nodes/{node id}/log' endpoint. An attacker with backend access who knows a victim `run id` and a valid `node id` can read live or archived logs using the API server's permissions. In the case of live logs, the `node id` is accepted as a pod name without verifying its association with the requested run, potentially allowing the reading of main container logs from unrelated pods within the selected namespace. The handler lacks internal authentication, relying on external gates or network policies for access control. This may lead to the exposure of sensitive workload data or credentials.

When `Echo.IPExtractor` is not explicitly set, the `Context.RealIP()` function falls back to reading client-supplied `X-Forwarded-For` or `X-Real-IP` headers without validating the proxy origin. Because the default `RateLimiter()` middleware uses `Context.RealIP()` to identify clients, a remote attacker can rotate arbitrary values in these headers to obtain new rate-limit buckets. This allows the attacker to bypass IP-based throttling used for request-volume protection and security controls such as brute-force prevention on login or password reset endpoints. Technical details include: - **API Endpoints:** Any endpoint protected by the `RateLimiter()` middleware. - **Vulnerable Parameters or Variables:** `X-Forwarded-For` and `X-Real-IP` HTTP headers. - **Function Names:** `Context.RealIP()` and `RateLimiter()`.

In the Proxy middleware, the framework may preserve an attacker-supplied `X-Real-IP` header and forward it to an upstream service when `Echo.IPExtractor` is not configured. This occurs because the `ProxyConfig.ToMiddleware()` function fails to overwrite the header if it is already present and no extractor is defined. A remote client can spoof their client address, which can be used to bypass IP-based access controls, rate limiting, geographic restrictions, or poison audit logs that trust the forwarded identity.

The `MethodOverride` middleware allows a POST request to be rewritten to a safe HTTP method (such as `GET`, `HEAD`, `OPTIONS`, or `TRACE`). When this middleware is registered before the `CSRF` middleware in the post-routing chain, the request method is changed before the `CSRF` middleware evaluates it. Consequently, the `CSRF` middleware skips token validation and `Sec-Fetch-Site` checks for what it perceives as a safe method, while the original state-changing POST handler still executes. This allows an authenticated victim to be tricked into performing state-changing operations via a cross-site request. The issue stems from the `MethodOverrideConfig.ToMiddleware()` function in `middleware/method override.go` lacking a whitelist for target methods, and the `CSRFConfig.ToMiddleware()` function in `middleware/csrf.go` relying on the rewritten method.

The `Context.Scheme` function unconditionally trusts forwarded scheme headers from any client. This allows a client connecting via plaintext HTTP to claim an HTTPS scheme, bypassing the HTTPSRedirect mechanism by making the request appear secure. Additionally, when used behind a TLS-terminating proxy that forwards attacker-controlled headers, a claimed HTTP scheme can suppress the Strict-Transport-Security header, even if the browser receives the response over HTTPS. This occurs because the framework lacks a trusted-source configuration for these headers.

Server-side template injection occurs because user-controlled message fields are not validated before template rendering, which allows expressions to run in an unrestricted context. Authenticated attackers with a common operational role can inject template expressions to read and write arbitrary database data, delete documents, send outbound requests from the server, and send mail from the site.

Missing input validation in certain endpoints allows authenticated attackers with low privileges to perform SQL injection, which is a technique used to manipulate database queries. By sending specially crafted requests, an attacker can extract sensitive information from the database.

A time-of-check time-of-use (TOCTOU) issue exists in the `ImageConfig` component within the `Get()` function of the `pkg/xpkg/client.go` file. This occurs when package signature verification is enabled and packages are installed using tag references instead of digests from registries not controlled by the user. A malicious OCI registry could provide a correctly signed image during the verification step and subsequently serve an unsigned or malicious image during the installation step because the tag reference is resolved separately for each action. This allows for the remote installation of unverified package content.

Authenticated users can perform server-side request forgery (SSRF) by submitting crafted URLs. This issue occurs within the `fetch url()` function of the `ScenarioImport` class, allowing attackers to make arbitrary HTTP requests. This can be used to probe internal network services, enumerate ports through error signatures, and access cloud metadata endpoints to retrieve sensitive credentials.

Pomerium is an identity and context-aware access proxy. In hosted or stateless authentication deployments, the `/.pomerium/callback` endpoint is reachable without credentials and processes HPKE-encrypted payloads before the sender's identity is validated. The `decodeQueryStringV2` function in `pkg/hpke/url.go` performs zstd decompression of attacker-controlled data without an output-memory limit. An unauthenticated attacker can obtain the receiver public key from `/.well-known/pomerium/hpke-public-key`, provide a matching sender key, and send a compressed payload (a decompression bomb) to the `/.pomerium/callback` endpoint. This can result in the allocation of hundreds of megabytes of memory per request, leading to memory exhaustion, process crashes, or performance degradation, effectively blocking access to protected applications. This issue does not affect stateful deployments as they verify an HMAC signature before decryption and decompression.

An authenticated user can clone resources into destinations owned by other teams and access cross-tenant resources. This occurs because the `cloneTo()` Livewire action in ResourceOperations.php authorizes the source resource but resolves destination resources using unscoped Eloquent lookups, which are database queries that do not apply the necessary ownership or tenant restrictions.

An issue exists where the `executeInDocker()` helper wraps commands in `bash -c '{$command}'` without escaping single quotes. This allows user-controlled fields `docker compose custom build command` and `docker compose custom start command` to be interpolated directly, enabling an attacker to use a single quote to break out of the bash argument and execute arbitrary commands on the managed server host, bypassing the intended Docker container isolation.

A stolen refresh token persists after a password-forgot flow, allowing it to be used to generate new JSON Web Tokens (JWTs) even after a user resets their password. While the `passwordChange()` and `passwordReset()` functions delete user refresh tokens, the `passwordForgot()` function only rotates the `token version` variable and revokes OAuth tokens, failing to call `UserRefreshToken.deleteAllUserToken(user.id)`. Consequently, an attacker with a captured refresh cookie can exchange it for a new access token after the victim completes the recovery process, leading to persistent unauthorized access.

When `NC SECURE ATTACHMENTS` is set to `true`, an authenticated uploader can upload `.html` or `.svg` attachments that the browser renders inline from the NocoDB origin instead of forcing a download. This occurs because the signed attachment handler stores response-header overrides using PascalCase keys (`ResponseContentDisposition`, `ResponseContentType`), whereas the controller serving the file expects lowercase-hyphen names (`response-content-disposition`). This mismatch causes the `Content-Disposition: attachment` header to be dropped, allowing Express to auto-render these files inline. This leads to Stored Cross-Site Scripting (XSS), where a script executing in a victim's browser can read the authentication JWT from `localStorage`.

OAuth access and refresh tokens are not revoked when a user changes, resets, or recovers their password. This occurs because the `revokeAllOAuthTokensByUser()` function in the users service was an empty stub called by `passwordChange()`, `passwordForgot()`, and `passwordReset()`. Consequently, an attacker-issued OAuth grant remains valid even after a user performs these security actions to lock out unauthorized parties, allowing persistent unauthorized access.

An authenticated user with Reader access can retrieve the `ImportedClusterSecrets` resource during the process of importing standalone Talos clusters. This resource contains the full CA secrets bundle, including the Kubernetes CA, etcd CA, and service account keys. An attacker with these private keys can sign certificates for any Kubernetes user or group, such as `system:masters`, granting full cluster-admin access to the imported cluster's Kubernetes, Talos, and etcd APIs independently of the Omni control plane. This allows for complete control over Kubernetes workloads, credentials, and secrets within the affected imported cluster.

A TOCTOU (Time-of-Check to Time-of-Use) race condition exists in the `SAML.getSession` function within `internal/pkg/auth/interceptor/saml.go`. The system checks the `Used` flag of a `SAMLAssertion` resource and subsequently marks it as used in two separate operations. Since these actions are not atomic, concurrent requests using the same `saml-session` token may both pass validation. This allows an attacker who has intercepted a valid `saml-session` token to authenticate as the token owner multiple times, bypassing the one-time-use guarantee. This can lead to session replay, the confirmation of multiple attacker-controlled public keys via the `ConfirmPublicKey` function to establish persistent access, and unauthorized access to gRPC endpoints gated by the SAML interceptor.

An issue exists where the upload-by-URL path fails to enforce the `NC ATTACHMENT FIELD SIZE` limit against the remote file's advertised `Content-Length` or the decoded length of a `data:` URI. This allows authenticated users with upload permissions to bypass configured per-file size limits, potentially exceeding storage and bandwidth caps.

Deleted API tokens continue to authenticate requests until their cache entry expires because the authentication cache is not invalidated by the token value during deletion. The deletion process removes the database row but fails to evict the token-value keyed entry from the cache. Consequently, the authentication middleware accepts the deleted token until the cache entry ages out, creating a window of up to three days between deletion and actual revocation. This breaks the security guarantee that token deletion is immediate.