Tonghuaroot

Authenticated users with document-note write access can perform a stored cross-site scripting attack via the 'interface/forms/eye mag/report.php' endpoint. By adding unescaped document notes, an attacker can store malicious JavaScript within a retina document note. This script executes when clinicians generate the Eye Exam patient report, which can lead to the exposure of session cookies.

The outbound URL guard fails to recognize IPv4 addresses embedded in NAT64 prefixes, which are used to allow IPv6-only clients to communicate with IPv4-only servers. An authenticated user with connection-management privileges can provide a hostname or redirect that resolves to a NAT64 address containing a private or link-local IPv4 destination. Because the policy incorrectly treats the NAT64 address as public, a NAT64 gateway translates it to the internal IPv4 address after validation. This allows an attacker to read responses from cloud metadata at 169.254.169.254 and other internal IPv4 hosts and ports reachable via the gateway. The issue affects API Data Connection outbound requests routed through `server/modules/outboundTargetPolicy.js` in environments using a NAT64/DNS64 deployment path.

An issue exists where the `isPublicIp()` function within `AppServicesTraitsValidatesUrls` fails to recognize the 64:ff9b::/96 and 64:ff9b:1::/48 NAT64 prefixes. NAT64 is a mechanism that allows IPv6-only clients to communicate with IPv4-only servers. Consequently, an `otpauth` URI image parameter can include an IPv6 literal or DNS64-synthesized address that targets private, link-local, loopback, or cloud metadata IPv4 addresses. When image fetching is enabled and a NAT64 translation path exists, an account holder or an external attacker can use a crafted URI or migration payload to trigger the `buildFromRemoteImage()` function in `IconService`. This results in an HTTP GET request to the internal target, potentially allowing the recovery of image-shaped responses or blind probing of other endpoints.

The AI query tool's PostgreSQL SQL-validation blocklist fails to include sibling PostgreSQL filesystem functions and does not match double-quoted identifier forms of denied functions. This allows a team Owner or Admin with an AI-enabled PostgreSQL connection to bypass the denylist regular expressions. If the database role has permissions to call server-side file functions, such as a PostgreSQL superuser or the `pg read server files` role, they can resolve absolute paths to files readable by the PostgreSQL OS user. Non-superusers are limited to the PGDATA-relative scope. This issue requires AI features to be enabled and elevated user privileges.

An authenticated non-admin user with `run events`, `create events`, or `edit events` privileges can provide undeclared keys in event parameters via the 'api create event', 'api update event', or 'api run event' endpoints. The system validates the parameter object without restricting its keys, and subsequently uppercases these keys and applies them to the child process environment. If a key collides with a security-sensitive environment variable, it can override the plugin execution context, potentially leading to privilege escalation, arbitrary code execution, data access, or service disruption.

Station users with WebHooks permission can bypass the UserUrlFilter guard using the Mastodon, Telegram, GroupMe, and RadioReg connectors. By setting the `instance url`, `api`, or `webhookurl` variables to internal addresses and triggering the webhook test endpoint, an attacker can perform a server-side request forgery (SSRF) to access loopback, private-network, or cloud-metadata services. SSRF is a flaw that allows an attacker to induce the server-side application to make requests to an unintended location.

An issue exists in the `FilteringResolver` `is private ip` check that fails to unwrap NAT64, 6to4, and Teredo IPv6 addresses. Authenticated users can exploit this by triggering outbound HTTP requests via SurrealQL http functions using transition addresses that embed private IPv4 targets. This allows access to localhost, internal services, or cloud metadata endpoints. Server-side request forgery is a flaw that allows an attacker to induce the server-side application to make requests to an unintended location.

In `internal/telegram/bot.go`, Telegram upload sites concatenate document filenames provided by the user into a destination path without proper sanitization. Because `path.Join` collapses parent-directory traversal, a remote Telegram user can write files outside the `uploads/` directory within the persistent agent workspace mounted at `/workspace/agent`. When the `allow from: []` configuration is used, all senders are permitted by default, requiring no authentication. This allows an attacker to overwrite or create files such as `CLAUDE.md`, instructions, skills, hooks, or configuration files, leading to stored instruction injection. The scope of this arbitrary-write is limited to the persistent agent workspace volume.

An authenticated user can trigger server-side requests to internal loopback, private-network, and cloud metadata services. This occurs when the system processes an attacker-controlled RSS feed via the 'POST /api/data/add podcast' endpoint. The `get podcast values` and `add episodes` functions in `rust-api/src/database.rs` store the `<enclosure url>` in `Episodes.episodeurl` without validating the destination host or IP. Subsequently, the 'POST /api/data/download podcast' endpoint triggers `spawn download podcast episode` and `download episode and wait()` in `rust-api/src/services/tasks.rs`, which performs a GET request to the stored URL. Additionally, the `estimate duration from audio url async()` function in `rust-api/src/database.rs` sends an unvalidated HEAD request during feed addition or refresh. Because default redirect following is enabled, external URLs can redirect to internal targets, allowing for internal-service enumeration, disclosure of confidential data, and potential theft of metadata credentials.

An unauthenticated user can cause a Denial of Service (DoS) by sending a specially crafted HTTP request. The `LanguageMiddleware` (registered as a global gin middleware) processes the `Accept-Language` header using `language.ParseAcceptLanguage` without imposing size or character filters. While a guard exists to limit the number of `-` characters, it does not account for ` ` characters, which the internal scanner aliases to `-` before parsing. An attacker can bypass this guard by using ` ` separators in a long list of malformed language tags, triggering quadratic-time behavior in the parser. For example, a 256 KiB payload can consume approximately 27 seconds of server CPU, and a 1 MiB payload can exceed 120 seconds. This allows a single attacker with limited bandwidth to pin server CPU cores indefinitely. The issue is further amplified by the `GetLanguagePreference()` function and the `resource.CheckErr()` call, which formats the entire malicious input into a log line upon failure.

The `JaegerPropagator.extract()` function in `opentelemetry-propagator-jaeger` processes inbound `uberctx-*` baggage values without enforcing entry, per-entry byte, or total-byte limits. When an untrusted carrier provides numerous or oversized values, it can lead to excessive CPU usage and short-lived heap allocations. This can result in a denial of service if transport-level limits do not constrain the input. The risk is increased for non-HTTP transports, custom `TextMapGetter` implementations, or environments where server and gateway header limits have been raised or disabled.

The `admissionHandler` in `webhook/admission.go` decodes an attacker-supplied AdmissionReview using `json.NewDecoder(io.TeeReader(r.Body, &bodyBuffer))` within an `http.HandlerFunc` without implementing an `http.MaxBytesReader` or a similar body-size limit. A pod-network client can send an oversized POST request to an admission webhook, leading the decoder and `bodyBuffer` to retain amplified copies of the request. This can result in the controller pod exhausting its memory and being OOM-killed (Out-Of-Memory killed), which is a state where the operating system terminates a process because it has consumed too much RAM. Downstream consumers using the shared webhook server, such as Knative, Tekton, KEDA, Sigstore policy-controller, and Kpack, inherit this behavior. Depending on the `failurePolicy` configuration, this can either interrupt admission if set to `Fail` or make the affected webhook unavailable if set to `Ignore`.

A resource exhaustion issue allows API clients to bypass the video/jpeg frame-count limit. By overriding the `num frames` variable through `media io kwargs`, an attacker can set `num frames` to -1 while providing a large inline video. This causes the `VideoMediaIO.load base64()` function to decode every frame, leading to memory exhaustion and a crash of the API frontend.

Authlib is a Python library used to build OAuth and OpenID Connect servers. The `OctKey.import key()` function and the HMAC signing and verification path accept zero-length key material. If an application's secret lookup returns an empty string or empty bytes, a remote attacker can compute deterministic HS256, HS384, or HS512 signatures for arbitrary token claims, leading the library to treat the token as authentic.

A missing authentication flaw exists for a critical function, which may allow remote code execution and unauthenticated path traversal in the legacy pipe sendFile RPC.

A heap out-of-bounds read occurs in the `smb2 decode file all info()` function. This issue allows a malicious SMB server or an attacker performing a man-in-the-middle attack on unsigned sessions to crash the client by sending a crafted FileAllInformation reply with an unchecked `FileNameLength` variable during `smb2 stat` or `smb2 fstat` calls.

An account takeover issue exists in the customer password reset flow within the 'system/controllers/forgot.php' endpoint. Unauthenticated attackers who know a customer username can brute-force the 6-digit `otp code` because the system lacks attempt limits or lockout mechanisms. Upon successfully guessing the code, the attacker can retrieve the newly set password directly from the HTTP response to hijack the account.

An authorization bypass allows authenticated users to perform unauthorized operations on workflow schedules, workflow definitions, and task instances across different projects. The system verifies permissions against the provided `projectCode` but does not confirm if the target resource actually belongs to that project. Consequently, a user with permissions in one project can use that project's code alongside a resource identifier from another project to bypass access restrictions. This allows attackers to alter workflow availability and interfere with task execution in unauthorized projects via the following endpoints: - 'POST /projects/{projectCode}/schedules/{id}/online' - 'POST /projects/{projectCode}/schedules/{id}/offline' - 'POST /projects/{projectCode}/workflow-definition/{code}/release'

An issue exists in the `app.util.ssrf/blocked-address?` endpoint where Java InetAddress predicates fail to classify NAT64, 6to4, or Teredo addresses and only apply CIDR checks to IPv4 values. This allows a user controlling a media import URL or an administrator controlling a webhook URL to use an IPv6 transition address to embed cloud-metadata, loopback, link-local, or private IPv4 targets, bypassing Server-Side Request Forgery (SSRF) restrictions. SSRF is a vulnerability where an attacker can force a server to make requests to an unintended location. In this case, media imports can disclose response bodies, and webhook delivery can be used as a network-probing side channel to expose response statuses. Exploitation requires routing through a NAT64 gateway or an attacker-controlled DNS AAAA record, making cloud environments with NAT64 gateways directly exploitable.

An unauthenticated attacker can perform a server-side request forgery (SSRF) by bypassing the SSRF guard using 6to4, NAT64, or IPv4-compatible IPv6 addresses. This is possible through the `validateKeyIdUrl()` function. By sending a crafted `Signature keyId` to the public actor inbox route, an attacker can access cloud metadata, loopback services, or internal hosts.