CVE Vulnerability Catalog

Cap-go capgo.app fails to validate that principals in channel_permission_overrides belong to the organization, allowing authenticated app/org admins to grant channel permissions to non-member users. Attackers with admin privileges can insert override rows with arbitrary external user UUIDs to grant channel-scoped permissions such as channel.promote_bundle to users outside the organization.

capgo.app is an over-the-air update platform for Capacitor apps. In all versions prior to a fix, the row-level security UPDATE policy on the public.orgs table permits an organization admin (a user holding org.update_settings) to update the entire row, including the internal billing pointer column customer_id. By sending an update directly to Supabase PostgREST, an authenticated org admin without org.update_billing can null or corrupt the organization's Stripe customer pointer, causing plan and billing checks to fail.

In Cap-go capgo.app before 12.267.1, the target API key privilege is not properly validated during rotation, allowing an apikey_manager to rotate a higher-privileged org_super_admin sibling key and recover its plaintext credential.

Capgo before 12.244.1 contains a cross-tenant integrity vulnerability in the metadata-cleaning worker that trusts image object keys from mutable database rows without validating ownership.

capgo.app is an over-the-air (OTA) update platform for Capacitor apps. In all versions up to and including the current release (no patch available), the transfer_app() database function transfers an app, its channels, versions and related records to a destination organization without deleting or revalidating existing rows in channel_permission_overrides. As a result, a user who held a channel permission override in the source organization retains it after the transfer, even without membership or RBAC binding in the destination organization.

Capgo (capgo.app) through version 12.261.0 contains an incomplete access-control fix for the public.sso_providers table. Migration 20260826100000_sso_providers_block_direct_active_insert.sql installs a BEFORE UPDATE guard (enforce_sso_provider_client_update_guard()) that freezes only the dns_verified_at, domain, status and enforce_sso columns, leaving provider_id (as well as metadata_url and attribute_mapping) writable. Because the table is granted ALL to the anon and authenticated roles with no column-level restriction, and PostgreSQL row-level security policies such as allow_org_admins_update_sso_providers constrain only which row may be updated and not which columns, a user holding the org_admin tier permission org.update_settings can PATCH provider_id over PostgREST to an identity provider under their control. Since provider_id is the trust anchor binding an email domain to an authorized IdP, the attacker can then authenticate through their own IdP while asserting the org owner's email; the server-side provider match succeeds and the merge routine attaches the attacker's SSO identity to the existing owner account, nulls its password, and deletes its other identities and sessions. This results in vertical privilege escalation from org_admin to org owner/super_admin, account takeover, and lockout of the legitimate owner. Exploitation requires that the target organization has an active SSO provider configured and that the attacker already holds org_admin in that organization. No patched version is available.

Capgo (capgo.app backend, versions ≤ 12.261.0) improperly restricts which roles the apikey_manager organization role may bind to newly created API keys. When an authenticated user holding only apikey_manager calls POST /apikey, the only checks applied are the org.manage_apikeys permission, a fixed deny-list of assignable role names, and a priority-rank comparison, but no check verifies that the caller actually holds the permissions conferred by the role being assigned. Because the deny-list omits deploy roles and apikey_manager has priority_rank 78 higher than those roles, the rank check also passes.

Flowise through 3.1.4 exposes GET /api/v1/upsert-history/:id and PATCH /api/v1/upsert-history without route-level permission checks, and the backing service performs no workspace or ownership validation.

Flowise (npm packages flowise and flowise-components) through 3.1.4 looks up credentials by ID without filtering on the requesting user's workspace in several code paths, including getAllOpenaiAssistants/getSingleOpenaiAssistant, uploadFilesToAssistant, deleteAssistant, and the shared helper used by getVoices. An authenticated user of one workspace can supply a credential UUID belonging to another workspace, causing the server to decrypt and use that workspace's OpenAI or ElevenLabs API key on the attacker's behalf.

Flowise through 3.1.4 does not enforce authorization on the BullMQ admin dashboard. When running in queue mode with the dashboard enabled, any authenticated user can access /admin/queues.

Flowise through 3.1.4 resolves SSO and local-password users solely by email without storing provider or subject identifier bindings, allowing attackers to authenticate as any existing user by claiming their email.

Flowise through 3.1.4 contains an authentication bypass in the SSO login path when an SSO callback arrives with an email matching an INVITED user, allowing takeover of the invitation.

Flowise through 3.1.4 contains missing route-level RBAC checks on chat message endpoints, allowing low-privileged API keys to read and delete chat history.

ClawHub (openclaw/clawhub) contains an incorrect authorization vulnerability: an organization-owned skill retains the ownerUserId of its original publisher, and transfer and lifecycle authorization checks trust that historical user before requiring current organization privileges. An authenticated user who originally published an organization skill can therefore transfer, delete, or restore that skill even after their organization privileges have been revoked or downgraded.

ClawHub (openclaw/clawhub) application/backend contains a flaw in the skill report moderation flow: four distinct ordinary authenticated accounts can report a visible skill and trigger automatic hiding (moderationStatus: hidden) of that skill from the catalog without any moderator decision. Because the reporter quota counts only reports filed against visible targets, the same accounts can repeat the process against additional skills; official skills are not exempt.

ClawHub (openclaw/clawhub application/backend) contains a missing authorization check in the changelog preview feature. A signed-in caller can invoke the public skills:generateChangelogPreview action for a skill they are not authorized to access; the previous version is read without the file-read authorization enforced on normal content access, and up to 8,000 characters of quarantined content may be submitted to the AI provider and reflected in the preview returned to the caller, disclosing restricted skill content.

ClawHub (openclaw/clawhub) application/backend contains a server-side request forgery vulnerability in the public profile preview's image fetching. The preview accepts a user-supplied image URL and checks the textual hostname against private-address patterns, but does not validate or pin the resolved network destination, so a public-looking hostname can resolve to an internal address or change resolution between validation and connection (DNS rebinding).

ClawHub (the openclaw/clawhub application/backend) does not bind anonymous HTTP API requests to a trusted caller identity, so all direct anonymous API requests share a single default quota allowance. A remote, unauthenticated caller can drain that shared allowance and thereby deny or degrade API access for unrelated visitors. In addition, when the TRUST_FORWARDED_IPS option is enabled without an authenticated edge/proxy, clients can supply arbitrary forwarded IP headers to select quota identities of their choosing and evade rate limiting.

A vulnerability was detected in mathurvishal CloudClassroom-PHP-Project up to a specific commit, with SQL injection in mydetailsfaculty.php via the myfid argument. The attack can be launched remotely.

A security vulnerability has been detected in mathurvishal CloudClassroom-PHP-Project up to a specific commit, with SQL injection in updatedetailsfromstudent.php via the eno argument. The attack can be initiated remotely.