Ayushparkara

A validation bypass exists in the community package installation handler for queue mode deployments. Attackers with write access to Redis can circumvent name validation, permission checks, checksum verification, and npm safety checks. This allows the installation of arbitrary npm packages across all cluster instances without authentication.

Stored cross-site scripting occurs when custom font family names are interpolated into a `@font-face` CSS rule and injected into the page as HTML without sanitization. The backend accepts an arbitrary font-family string, and the frontend writes the resulting style using `innerHTML`. A malicious name containing markup, such as a closing style tag followed by a script, can break out of the style element to execute JavaScript on the Penpot origin. This passive attack triggers script execution when a team member opens a file referencing the malicious font, potentially leading to the theft of session cookies, unauthorized actions performed as the victim, and unauthorized access to files and projects.

Stored cross-site scripting occurs when file comments are stored as raw text and rendered into the page using `innerHTML` without sanitization. The backend only performs a length check, allowing a team member to embed HTML or scripts within a comment. When other collaborators open the comments panel, the script executes on the Penpot origin, which can lead to the theft of session cookies, unauthorized actions performed as the victim, and unauthorized access to files and projects.

The SAML source response processor `ResponseProcessor.parse()` fails to validate the Conditions element on assertions. Specifically, `NotBefore`, `NotOnOrAfter`, and `AudienceRestriction` are ignored, which enables the replay of expired assertions and the acceptance of assertions intended for different service providers.

The WS-Federation provider in this open-source identity provider validates the user-supplied `wreply` parameter using a raw string prefix check instead of proper URL parsing. An attacker can craft a login link with a `wreply` value from a different origin that bypasses this check, leading the victim's browser to POST the signed WS-Federation login response to infrastructure controlled by the attacker.

A path validation issue allows crafted repository data to affect files outside the intended checkout target, including the repository's `.git` directory. This occurs because the software drifted from validation checks implemented in upstream Git. Some attack vectors are platform-specific, affecting only Windows or macOS users, while others apply across all supported platforms. Isolation may be provided if non-descendant `go-billy` filesystem instances or different filesystem types are used for the `Storer` and `Worktree`, such as using `memfs` for the `.git` directory and `osfs` for the worktree. However, this isolation may not apply to repositories containing submodules, as submodule dotgit directories may still be materialized within the worktree context.

Gotenberg is a Docker-powered stateless API for PDF files. The Chromium URL-to-PDF endpoint '/forms/chromium/convert/url' lacks default protection against Server-Side Request Forgery (SSRF) for HTTP and HTTPS requests, as the default deny-list only blocks `file://` URIs. This allows an unauthenticated attacker to direct Chromium to internal IP addresses, including loopback, RFC 1918 ranges, and cloud metadata endpoints, receiving the response rendered as a PDF. Additionally, the `downloadFrom` and `webhook` endpoints are also affected by a redirect-based bypass. Even when a custom deny-list is configured, the Chromium instance and other endpoints follow HTTP 302 redirects from attacker-controlled external URLs to internal targets without re-validating the destination against the deny-list.

The `budibase:auth` cookie, which contains the JWT session token, is configured with `httpOnly: false` in the `packages/backend-core/src/utils/utils.ts` file. This allows JavaScript to access the cookie via `document.cookie`, enabling an attacker to steal the JWT and achieve full account takeover if a Cross-Site Scripting (XSS) flaw is present. Additionally, the cookie lacks the `secure: true` flag, meaning it can be sent over plaintext HTTP, and it lacks the `sameSite` attribute, making it susceptible to cross-site request attachment.

During smart-HTTP clone and fetch operations, the library may leak HTTP authentication credentials when following redirects. If a remote repository responds to the initial '/info/refs' request with a redirect to a different host, the session endpoint is updated to the redirected location and the original authentication, such as Authorization headers, is reused for subsequent requests. This allows an attacker controlling the redirect target to capture credentials and potentially access the victim's repositories or other resources. This issue occurs when interacting with untrusted or misconfigured Git servers or when using unsecured HTTP connections.

The authenticated middleware uses unanchored regular expressions to match public endpoint patterns against the `ctx.request.url` variable. Because `ctx.request.url` in Koa includes the query string, an attacker can bypass authentication and access protected endpoints by appending a public endpoint path as a query parameter. For example, using the endpoint '/api/global/users/search' with a query parameter like `x=/api/system/status` allows unauthorized access because the regular expression matches the query string portion of the URL.

Portainer includes a security setting to disable bind mounts for non-administrators, intended to prevent regular users from binding host paths into containers via the Portainer-mediated Docker API. However, the enforcement mechanism only inspected the `HostConfig.Binds` array and ignored the equivalent `HostConfig.Mounts` array. Since both fields are interchangeable on the Docker daemon, an authenticated user with container-creation rights can bypass this restriction by submitting a `bind`-typed entry under `HostConfig.Mounts` at the 'POST /containers/create' endpoint. This allows the user to mount any host path into their container, potentially gaining read or write access to the host filesystem as the Docker daemon user (typically `root`). This can lead to the exposure of sensitive files, compromise of other containers on the same host, or full Docker API access if the Docker socket is mounted.