Coral Server is open collaboration infrastructure that enables communication, coordination, trust and payments for The Internet of Agents. Prior to 1.1.0, Coral Server did not enforce strong authentication between agents and the server within an active session. This could allow an attacker who obtained or predicted a session identifier to impersonate an agent or join an existing session. This vulnerability is fixed in 1.1.0.
Coral Server is open collaboration infrastructure that enables communication, coordination, trust and payments for The Internet of Agents. Prior to 1.1.0, Coral Server allowed the creation of agent sessions through the /api/v1/sessions endpoint without strong authentication. This endpoint performs resource-intensive initialization operations including container spawning and memory context creation. An attacker capable of accessing the endpoint could create sessions or consume system resources without proper authorization. This vulnerability is fixed in 1.1.0.
StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.0, the /studiocms_api/dashboard/api-tokens endpoint allows any authenticated user (at least Editor) to generate API tokens for any other user, including owner and admin accounts. The endpoint fails to validate whether the requesting user is authorized to create tokens on behalf of the target user ID, resulting in a full privilege escalation. This vulnerability is fixed in 0.4.0.
StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.0, the DELETE /studiocms_api/dashboard/api-tokens endpoint allows any authenticated user with editor privileges or above to revoke API tokens belonging to any other user, including admin and owner accounts. The handler accepts tokenID and userID directly from the request payload without verifying token ownership, caller identity, or role hierarchy. This enables targeted denial of service against critical integrations and automations. This vulnerability is fixed in 0.4.0.
OneUptime is a solution for monitoring and managing online services. Prior to 10.0.21, a low‑privileged user can bypass authorization and tenant isolation in OneUptime v10.0.20 and earlier by sending a forged is-multi-tenant-query header together with a controlled projectid header. Because the server trusts this client-supplied header, internal permission checks in BasePermission are skipped and tenant scoping is disabled. This allows attackers to access project data belonging to other tenants, read sensitive User fields via nested relations, leak plaintext resetPasswordToken, and reset the victim’s password and fully take over the account. This results in cross‑tenant data exposure and full account takeover. This vulnerability is fixed in 10.0.21.
OneUptime is a solution for monitoring and managing online services. Prior to 10.0.21, OneUptime Synthetic Monitors allow a low-privileged authenticated project user to execute arbitrary commands on the oneuptime-probe server/container. The root cause is that untrusted Synthetic Monitor code is executed inside Node's vm while live host-realm Playwright browser and page objects are exposed to it. A malicious user can call Playwright APIs on the injected browser object and cause the probe to spawn an attacker-controlled executable. This is a server-side remote code execution issue. It does not require a separate vm sandbox escape. This vulnerability is fixed in 10.0.21.
OneUptime is a solution for monitoring and managing online services. Prior to 10.0.21, an unauthenticated path traversal in the /workflow/docs/:componentName endpoint allows reading arbitrary files from the server filesystem. The componentName route parameter is concatenated directly into a file path passed to res.sendFile() in orker/FeatureSet/Workflow/Index.ts with no sanitization or authentication middleware. This vulnerability is fixed in 10.0.21.
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 8.6.12 and 9.5.1-alpha.1, the requestKeywordDenylist security control can be bypassed by placing any nested object or array before a prohibited keyword in the request payload. This is caused by a logic bug that stops scanning sibling keys after encountering the first nested value. Any custom requestKeywordDenylist entries configured by the developer are equally by-passable using the same technique. All Parse Server deployments are affected. The requestKeywordDenylist is enabled by default. This vulnerability is fixed in 8.6.12 and 9.5.1-alpha.1. Use a Cloud Code beforeSave trigger to validate incoming data for prohibited keywords across all classes.
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 8.6.13 and 9.5.1-alpha.2, an unauthenticated attacker can crash the Parse Server process by calling a Cloud Function endpoint with a prototype property name as the function name. The server recurses infinitely, causing a call stack size error that terminates the process. Other prototype property names bypass Cloud Function dispatch validation and return HTTP 200 responses, even though no such Cloud Functions are defined. The same applies to dot-notation traversal. All Parse Server deployments that expose the Cloud Function endpoint are affected. This vulnerability is fixed in 8.6.13 and 9.5.1-alpha.2.
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 8.6.14 and 9.5.2-alpha.1, NoSQL injection vulnerability allows an unauthenticated attacker to inject MongoDB query operators via the token field in the password reset and email verification resend endpoints. The token value is passed to database queries without type validation and can be used to extract password reset and email verification tokens. Any Parse Server deployment using MongoDB with email verification or password reset enabled is affected. When emailVerifyTokenReuseIfValid is configured, the email verification token can be fully extracted and used to verify a user's email address without inbox access. This vulnerability is fixed in 8.6.14 and 9.5.2-alpha.1.