CVE-2026-75969

In Tugtainer prior to version 1.30.6, an authenticated user can make the backend server send outbound HTTP requests to arbitrary user-supplied URLs through the notification test endpoint. The /settings/test_notification endpoint accepts a urls field and passes it directly to Apprise without restricting protocols, hostnames, localhost, private IP ranges, or cloud metadata addresses. This can be abused as an authenticated blind SSRF.

In Tugtainer Agent prior to version 1.30.4, when AGENT_SECRET is not configured, Docker management APIs are accessible without authentication. The signature verification function in agent/auth.py returns success if Config.AGENT_SECRET is empty, making protected APIs accessible without authentication.

In Tugtainer prior to version 1.30.3, OIDC authentication can still be initiated even when OIDC_ENABLED=false. The /auth/oidc/enabled endpoint correctly reports that OIDC is disabled, but a direct request to /auth/oidc/login still starts the OIDC login flow, returns HTTP 302, sets an oidc_state cookie, and redirects to the OIDC authorization endpoint. This bypasses the intended OIDC disable switch.

In Soft Machine versions 0.2.247 and prior, two authentication helpers in /app/server.js — verifyContainerAuth() and authenticateWorkspaceHttp() — accept the global CONTAINER_SHARED_SECRET as a bearer token without verifying which workspace the caller belongs to. Because that secret is set identically on every container in the Fly app and is reachable from the user-facing process environment, any tenant can use it to authenticate to any other tenant's workspace API. This results in cross-workspace read, write, and destructive-restore primitives.

A remote, unauthenticated TLS client can crash a server or trigger a use-after-free if its sni_callback assigns a different context to SSLSocket.context (the documented way to select a certificate per server name) and nothing else keeps the original ssl.SSLContext alive. Typical cases are servers that create an SSLContext per connection or replace it while connections are open; servers that wrap their listening socket with it are not affected. Mitigation: keep a reference to every SSLContext that sets sni_callback for the lifetime of the server. TLS clients are not affected.

All versions of Zammad including the latest alpha enable the local zammad user to escalate privileges to root.

Zammad versions 6.3.0 to 6.5.4 are vulnerable to a session hijack vulnerability that leads to remote code execution as the zammad user. The vulnerability is also present in version 7.0.0 to version 7.1.3, but not exploitable due to environment conditions.

In Internet2 Grouper before 7.5.1 (in some configurations), a user who is allowed to create or edit rules in the User Interface can escalate privileges.

Joomla Extension - OrdaSoft Joomla CCK before 8.3.16 has unauthenticated remote code execution. The file site/uploader.php is reached through normal frontend routing (task=getContent), with no authentication or ACL check. The handler validates the uploaded file's content with a real magic-byte MIME check, but the extension allow-list is commented out. The saved file's extension is taken directly from the attacker-supplied filename with no validation, and the file is written to a path under the Joomla web root executed by PHP. An image/PHP polyglot passed the content check with a .php extension.

Joomla Extension - JCTables 1.21.1 has unauthenticated SQL injection in read and write queries. The front-end CRUD API controller performs no Joomla token validation and no authentication check on any task. Table names, column names, and values are taken directly from request parameters and concatenated into SQL queries, allowing SQLi for reading and writing queries.