Theodosis Paidakis

An improper authorization issue exists in the push deletion logic. The system compares `@push.user` against `current user`; when a push is created anonymously, both values are nil. Because Ruby evaluates `nil == nil` as true, the ownership check passes, bypassing the `deletable by viewer` restriction. This allows an attacker with knowledge of the secret URL to permanently delete an anonymous push, even if the creator disabled viewer deletion or if a passphrase was required. This issue only affects deployments that allow anonymous pushes.

A flaw in the Session Cookie Handler component allows for improper authentication via remote manipulation. The issue resides in the `std::strncmp()` function within the `src/tsessioncookiestore.cpp` file. This attack is characterized by high complexity and difficult exploitability.

An authenticated user can cause resource exhaustion by sending requests to the 'GET /loading' endpoint using a malicious `id` query parameter. The issue occurs because the handler lacks a map-lookup validity check and attempts to receive data from a nil channel (a channel that has not been initialized) which blocks indefinitely. Due to the absence of timeouts, context cancellation, and server-side reclamation, each request permanently consumes one goroutine (a lightweight thread managed by the Go runtime), one file descriptor, and approximately 50 kB of memory. This continues until the server reaches its file descriptor limit, causing listener Accept calls to fail and halting all tunnel traffic forwarding for all users.

Authenticated low-privileged users with tunnel-creation permissions can perform a newline injection. By providing a percent-encoded newline character in the `domain` parameter of the tunnel creation endpoint, an attacker can inject arbitrary lines into the server account's SSH authorized keys file. This allows the insertion of an unrestricted public key to obtain persistent shell access, enabling the attacker to read cleartext credentials from the database file, including all user tokens, tunnel private keys, and TLS certificates.

Authenticated API key holders can trigger server-side request forgery (SSRF), a flaw where the server is coerced into making unauthorized requests. By providing a crafted long URL during the short URL creation process while title auto-resolution is enabled, an attacker can force the server to issue arbitrary HTTP GET requests. This can be achieved by using public hosts that redirect to internal targets, such as loopback addresses, link-local ranges, or cloud metadata endpoints like 169.254.169.254. Internal service information can then be exfiltrated through the HTML title element returned in the response.

An authenticated API key holder can perform a blind SQL injection by providing an unvalidated value in the `orderBy` query parameter of the tag statistics endpoint. This occurs because the input flows unsanitized into a Doctrine QueryBuilder ORDER BY clause, allowing the injection of arbitrary SQL fragments. This can lead to the extraction of sensitive data from any tenant, including long URLs, visitor records, IP addresses, geolocation data, user agents, and hashed API key secrets, using time-based, boolean-oracle, or error-based techniques.

An issue exists where unauthenticated remote attackers can inject spreadsheet formulas into exported visit data. By sending a request to any short URL with malicious values in the `User-Agent`, `Referer`, or request path headers starting with characters like `=`, `+`, `-`, or `@`, attackers can embed DDE (Dynamic Data Exchange) or WEBSERVICE formula payloads. These payloads are executed on an administrator's machine when the exported CSV file is opened in a spreadsheet application that evaluates formulas.

A stored cross-site scripting issue exists that allows unauthenticated remote attackers to execute arbitrary JavaScript in an administrator's browser session. This occurs when HTML markup is injected into agent transcript messages processed through the sessions API. Attackers can use inline event handler payloads, such as an `img` tag with an `onerror` attribute, within a 60-character limit. The payload is stored in the session transcript and interpolated unsanitized into `innerHTML` on the default landing page. This can lead to the theft of session tokens and unauthorized calls to authenticated administrative endpoints, including the modification of agent instruction files.

A stored cross-site scripting issue exists where unauthenticated remote attackers can inject arbitrary HTML and script payloads. This occurs when a crafted username is submitted in a failed login POST request, which is then recorded verbatim in the audit log. When an administrator opens the notification panel, the log entry is rendered using innerHTML. Due to a permissive Content-Security-Policy (a security layer that helps detect and mitigate certain types of attacks) that allows inline event handlers, the payload executes within the administrator's session. This allows the attacker to interact with authenticated endpoints, such as editing agent instruction files and modifying configurations.

An HTTP request smuggling issue exists due to improper header forwarding within the proxy implementation located in `src/proxy.rs`. The proxy forwards the client's `Transfer-Encoding` header to upstream backends without modification, even though the request body has already been de-chunked by `tiny http`. This allows for CL.TE desynchronization attacks, where a remote attacker can manipulate the boundaries of HTTP messages to control where the backend server perceives the request body ends.

An HTTP request smuggling issue exists where remote attackers can bypass access controls by injecting bare line feed characters (0x0A) into client-supplied request header values. These values are copied verbatim to upstream connections without validation. This allows an attacker to craft a header value containing a complete additional HTTP request that backends, such as Go net/http and Python http.server, interpret as a separate request. Consequently, the backend processes a smuggled request with an attacker-chosen method, path, and headers, bypassing the access control logic of the rouille handler.

An unauthenticated remote attacker can crash worker processes by sending a malformed HTTP request line containing an invalid version string. The `HttpParser::execute()` function fails to allocate the `Url` object when version parsing fails, leaving the `url` pointer as NULL. Subsequently, the `buildResponse()` function dereferences this NULL pointer without verifying the `valid requ` flag, resulting in a SIGSEGV (a segmentation fault that occurs when a program attempts to access a memory location it is not allowed to). If this action is repeated across all worker processes, the server remains offline until a manual restart is performed.

An issue allows unauthenticated attackers to read arbitrary files by submitting `../` sequences in the URL path. These sequences are concatenated directly to the configured web root in the `buildResponse()` function of `HttpBuilder` without normalization, dot-segment removal, or boundary checks. Attackers can craft requests that pass through the URL parser unchanged and reach the filesystem call via the `setFile()` function of `HttpFile`, potentially exposing sensitive files like credential stores and private keys if the server process runs as root.

Unauthenticated attackers can exhaust available memory by sending standard well-formed HTTP requests. This occurs because the `HttpParser::execute()` function allocates `Url` objects, `HttpHeaders` objects, and `HttpHeader` instances using raw new expressions that are never freed due to missing destructors and unreachable delete calls. Consequently, worker resident memory increases by approximately 20 to 28 kB per request until the worker process is terminated.

An HTTP response splitting issue exists where remote attackers can inject arbitrary response headers by embedding carriage return (0x0D) or line feed (0x0A) bytes into input they control. This can occur through percent-decoded query parameters reflected in response headers or by injecting line feed characters into Cookie header values that are interpolated directly into Set-Cookie response headers. Such actions can lead to cache poisoning, session fixation, and the override of security headers, which may allow attackers to bypass Content Security Policy (CSP) or Cross-Origin Resource Sharing (CORS) policies.

An authenticated remote code execution issue exists where users with `custom fields` manage permissions can execute arbitrary Ruby code. This occurs when a malicious expression is supplied through the `select eval` custom field type. An attacker can store a controlled Ruby expression in the `command` parameter of the field options, which is then evaluated via the `instance eval()` function within an ERB view during the rendering of a post edit page. This allows for server-side code execution with the privileges of the web server process.

An issue exists where authenticated attackers can cause a server crash by providing a valid 24-character hex string for the `room` parameter that does not correspond to any document in the database. This leads to a null dereference, resulting in an uncaught TypeError within an asynchronous Mongoose callback that terminates the Node.js server process. This flaw is accessible via the 'GET /messages' endpoint and other code paths, including the socket.io interface.

Broken access control allows authenticated attackers to download file attachments from private and password-protected rooms they are not members of. This occurs because the system fails to perform room membership checks during file retrieval. An attacker can enumerate adjacent MongoDB ObjectIds—unique identifiers used by MongoDB to reference documents—derived from a known file ID to recover files uploaded by other users. The issue exists in the `GET /files/:id/:name` endpoint within `app/controllers/files.js`, which only verifies login authentication and ignores the `Room.canJoin()` check.

An improper authorization issue allows authenticated users to archive any room on the server. This occurs because the rooms handler does not verify ownership when processing a DELETE request. Attackers can identify room IDs through the rooms listing endpoint to permanently archive private or password-protected rooms they are not authorized to access. Once archived, these rooms cannot be recovered through the application and require direct database intervention to restore.

An issue exists where the library improperly parses the `Transfer-Encoding` header. By sending this header with any value, including non-chunked codings, the library unconditionally applies chunk-decoding and ignores the `Content-Length` header. This creates a discrepancy between the library and a correctly implemented front-end proxy, allowing remote attackers to desynchronize request framing and perform request smuggling. Additionally, sending non-chunked bodies with non-chunked `Transfer-Encoding` values can lead to failed body reads, which consumes worker threads and ties up connections without notifying clients of the error.