AzuraCast versions before 0.23.8 have a broken access control vulnerability in the GET /api/station/{id}/vue/profile endpoint. This flaw allows authenticated users with only View Station Page permission to access Icecast/Shoutcast admin, source, and relay passwords in plaintext. Attackers can use the exposed admin password to authenticate to the Icecast admin interface without needing Broadcasting permission.
AzuraCast versions before 0.23.8 contain a server-side request forgery (SSRF) vulnerability in the station webhook URL validation. The validation incorrectly rejects only literal link-local IP addresses but allows loopback and private network addresses, enabling a user with station-scoped WebHooks permission to configure webhooks targeting internal or private network resources. This can cause the server to send HTTP POST requests with station data to unintended internal endpoints. The vulnerability can be triggered on demand via a specific test endpoint. No patch was available at the time of the advisory.
AzuraCast versions through 0.23.x have a command injection vulnerability in the Liquidsoap configuration generation for live recording. The vulnerability arises because the streamer username is not properly quoted in process.run calls, allowing authenticated station users with Streamers and Profile permissions to execute arbitrary commands as the Liquidsoap process user when recording ends.
AzuraCast versions prior to 0.23.8 have a DQL injection vulnerability in the sortOrder API parameter of AbstractSearchableListAction.php. This flaw allows attackers to inject arbitrary Doctrine Query Language expressions, potentially exposing sensitive database information such as user credentials and station settings.
AzuraCast versions before 0.23.8 have a vulnerability in the public On-Demand download endpoint that does not properly enforce playlist-level access controls. This flaw allows unauthenticated users to download media files that are meant to be excluded from On-Demand-enabled playlists, bypassing intended access restrictions and exposing private or restricted audio content.
AzuraCast versions prior to 0.23.6 have a vulnerability where the Liquidsoap API endpoint lacks the RequireInternalConnection middleware and incorrectly derives the AutoDJ flag from header presence instead of a validated value. This allows users with View station permission to inject arbitrary now-playing metadata, disrupt live broadcasts, and disclose filesystem paths.
AzuraCast versions prior to 0.23.6 contain a code injection vulnerability in the remote relay password field. This arises from incomplete migration from the vulnerable cleanUpString method to toRawString. Attackers with RemoteRelays station permission can exploit this to inject nested Liquidsoap interpolation syntax, enabling arbitrary code execution within the Liquidsoap process, disclosure of internal API keys, or disruption of station operations.
AzuraCast versions before 0.23.8 have a server-side request forgery (SSRF) and local file read vulnerability in the AutoDJ remote playlist fetch functionality. A user with Media permission can craft a playlist referencing a file:// URL or internal HTTP endpoints, causing the backend to read local files or internal resources without proper restrictions. This can disclose sensitive files such as /etc/passwd or application environment files to users with Broadcasting permission. No patch was available at the time of publication.
AzuraCast versions prior to 0.23.6 have a missing permission check vulnerability in the GET /api/station/{station_id}/file/{id}/play endpoint. This flaw allows authenticated users to download media files from any station, including those they do not have permission to access. Attackers can enumerate media files using sequential IDs and exfiltrate entire media libraries of unauthorized stations.
AzuraCast versions before 0.23.8 have a vulnerability where the 'Remote Relay' URL is only validated for syntax and scheme, without host or IP restrictions. This allows users with station-scoped RemoteRelays permission to set URLs pointing to internal or sensitive addresses, causing the server to make repeated HTTP requests to these addresses. This results in server-side request forgery (SSRF). No patch is currently available for this issue.
Contrast (Edgeless Systems) through 1.20.0 performs unanchored suffix matching when selecting per-registry configuration in the imagepuller. Config.registryFor strips a single trailing dot and then uses strings.HasSuffix(hostname, fqdn) without requiring a DNS label boundary, so a registry entry such as [registries."ghcr.io."] is also applied to any host whose name merely ends in that byte sequence, including attacker-registered domains such as evilghcr.io. When an image or layer is pulled from such a sibling domain, the imagepuller sends the configured Authorization header (basic auth, registry token, or identity token), trusts the configured custom CA bundle, follows the configured mirror, and honours insecure-skip-verify (disabling TLS verification) for that host. Image integrity is not affected, as image bytes remain pinned by digest in the policy and are validated after the pull. Configurations that use a leading dot (e.g., [registries.".example.registry"]) are unaffected.
Contrast is a confidential-computing runtime for Kubernetes. In versions before 1.19.1, the Kata agent policies generated by the Contrast CLI contained a flaw in the CopyFile verification that allowed arbitrary writes to the guest root filesystem. A malicious process on the untrusted host able to connect to the Kata agent VSOCK could issue a series of CopyFile requests to overwrite security-critical files in the guest or trick the workload into disclosing sensitive data, effectively amounting to a full guest takeover. Users unable to upgrade can apply an equivalent rego policy fix passed to 'contrast generate --policy'.
A stack-based buffer overflow vulnerability exists in the Wireless Wizard Handler component of Edimax BR-6428nC version 1.16. The flaw can be triggered remotely by manipulating specific arguments in the /goform/formWizSurvey file. This vulnerability has a CVSS 3.1 score of 6.3, indicating medium severity. A public exploit has been disclosed. No patch or official remediation information is provided.
Contrast before 1.16.0 is susceptible to remote attestation relay attacks. Contrast accepted any TEE attestation report that verified correctly and contained the expected firmware patch levels and software measurements, regardless of which machine produced it, so attestation was not bound to specific, physically trusted hardware. An attacker who can both intercept network traffic between the CLI and the Coordinator (or between the Coordinator and an attested component) and forge reports or extract secrets from any single TEE machine under their physical control can relay such a report to impersonate a Contrast Coordinator or a Contrast workload, defeating identity verification in Contrast's attested TLS (aTLS).
Contrast (edgelesssys/contrast) versions 1.14.0 before 1.23.1 generate runtime policies that fail to detect all container image substitutions. A bad rebase during a Kata Containers update accidentally introduced an `allow_storage` rule that accepts storage entries using the `image_guest_pull` driver without verifying the image digest. An attacker with access to the Kata agent API — for example, a Kubernetes cluster administrator in Contrast's threat model — can therefore substitute a container image with an exploit payload, provided the substituted image satisfies the remaining policy rules, undermining the confidential container's integrity guarantees.
Contrast is a confidential-computing runtime for Kubernetes. In versions before 1.18.0, the guest kernel's ACPI/AML handling is vulnerable to an AML injection attack ("BadAML"). ACPI tables containing AML bytecode are passed from the untrusted host (QEMU) to the guest firmware (OVMF) and on to the Linux kernel, whose AML interpreter executes them. An attacker controlling the host — an assumed adversary in Contrast's threat model — can craft a table with malicious, Turing-complete AML bytecode that the guest kernel interprets with access to the full guest memory, including private pages, resulting in arbitrary code execution and disclosure or modification of confidential guest data. The issue affects the AMD SEV-SNP platforms Metal-QEMU-SNP and Metal-QEMU-SNP-GPU; Metal-QEMU-TDX is not affected because ACPI table contents are measured into RTMR 0 by OVMF on Intel TDX. Version v1.18.0 mitigates the attack by sandboxing the kernel AML interpreter so that it cannot read or write private memory pages. This weakness is not specific to Contrast but is generic to Confidential Computing setups that expose the ACPI interface to the host.
http4k's Digest authentication module before versions 6.48.0.0, 5.42.0.0, and 4.51.0.0 has a vulnerability where the nonceVerifier parameter defaults to accepting every nonce. This means applications using the default setting lack replay protection for Digest authentication, allowing attackers who capture a valid Digest authorization response to replay it indefinitely against the same resource.
Contrast versions up to 1.20.0 contain a medium severity vulnerability (CVE-2026-100836) in the transit-engine endpoint's ciphertextContainer.UnmarshalJSON function. The flaw is due to improper validation of the length of decoded ciphertext before slicing, which can cause a runtime panic. An authenticated workload with a valid mesh certificate can exploit this by submitting a short base64-encoded ciphertext, resulting in log spam and request failures. The process does not crash, and no confidentiality or integrity impact is reported.
Contrast, Edgeless Systems' runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application's core functionality. Version 1.9.1 fixes the issue by disallowing this configuration in `contrast generate`.
Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets — normally accessible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner — to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider. Deployments that do not use workload secrets are unaffected.