Judel777

يوجد خلل في التصريح ضمن الدالة `checkPermissionsForCreateOrUpdate()` في فئة `Multitenancy`. في عمليات النشر متعددة المستأجرين المرخصة حيث تتشارك تطبيقات متعددة نطاق URI اتصال غير افتراضي وتستخدم `api keys` منفصلة، يمكن للمهاجم الذي يمتلك مفتاح API صالح لأحد التطبيقات تحديث نطاق URI اتصال الأب. يحدث هذا لأن النظام لا يشترط أن يكون التطبيق والمستأجر المصدر عامين عند التحقق من النطاق أثناء عمليات الإنشاء أو التحديث. نتيجة لذلك، يمكن للمهاجم استبدال المفتاح الأب ومفاتيح التطبيقات الشقيقة، وتعديل المستخدمين الشركاء، واختطاف الجلسات، وتثبيت الوصول عبر مستخدمي لوحة تحكم شقيقة. بالإضافة إلى ذلك، فإن حذف المعرف الاختياري في معالجات الإنشاء أو التحديث من الإصدار v2 يسمح للمهاجم باستهداف المستأجر الأساسي، وتجاوز فروع التصاريح وبوابات الميزات المؤسسية لتعديل `firstFactors` والعوامل الثانوية المطلوبة وأعلام الوصفات المفعلة، مما يؤثر على سلامة تسجيل الدخول وتوافره.

The application fails to validate that principals within `channel permission overrides` are members of the organization. This allows authenticated app or organization administrators to grant channel permissions to users outside the organization by inserting override rows with arbitrary external user UUIDs. This can lead to the unauthorized granting of channel-scoped permissions, such as `channel.promote bundle`.

An incomplete access-control and content-lock enforcement issue exists where the `enforce encrypted bundle trigger` and `check encrypted bundle on insert` locks exempt rows in `app versions` if the previous `storage provider` is `r2-direct`. This allows delivery-critical columns—including `name`, `app id`, `session key`, `key id`, `storage provider`, `r2 path`, `external url`, `checksum`, `manifest`, and `native packages`—to remain mutable. Additionally, the `/updates` endpoint does not exclude `r2-direct` versions, making them selectable for Over-the-Air (OTA) updates. An attacker with an API key possessing bundle write or upload permissions can maintain a bundle in the `r2-direct` state and modify these fields via PostgREST requests, resulting in altered bundle metadata being served to devices.

An authenticated organization member can create a non-expiring app-scoped API key, bypassing the organization's API key expiration policy. This occurs when the owning organization has `require apikey expiration` enabled and a `max apikey expiration days` limit configured. In the 'POST /apikey' endpoint, requests that provide `app id` but omit `org id`, `limited to orgs`, and `expires at` fail to add the app's owner organization to the list of IDs passed to the `validateExpirationAgainstOrgPolicies()` function. Because the list is empty, the validation process returns early without enforcing the expiration policy.

A native build TUS upload proxy at the endpoint `supabase/functions/ backend/public/build/upload.ts` improperly handles authorization. The proxy validates the caller against a specific build job using the `builder job id` and checks the stored `upload path`, but it forwards a user-controlled TUS resource suffix from the path `/build/upload/:jobId/*` to the builder service while injecting a privileged builder API key. Since the forwarded suffix is not bound to the authorized job's `upload path` or `upload session key`, an attacker with a valid 'all' or 'write' Capgo API key and `app.build native` permission for one application can write to the TUS upload resource of a different job, provided the resource suffix is known, leading to the corruption of build artifacts.

An issue exists in the row-level security UPDATE policy on the `public.orgs` table. An authenticated organization administrator with `org.update settings` permissions can bypass the official organization update endpoint `supabase/functions/ backend/public/organization/put.ts` and the private Stripe billing route by sending an update directly to Supabase PostgREST. This allows the user to modify the internal billing pointer column `customer id`, even without the `org.update billing` permission. By nulling or corrupting this value, the user can cause plan and billing checks to fail, effectively moving the organization from a paid plan to an unpaid or no-plan state.

🚨 CVE-2026-100623 Capgo (capgo.app) exposes the legacy membership table public.org users directly through Supabase PostgREST. The table's row-level security policies "Allow org admin to insert" and "Allow org admin to update" only verify that the caller has admin rights in the target organization (public.check min rights('admin', ...)); they do not require a pending invitation in tmp users, acceptance of an invite token via /private/accept invitation, any action by the target user, or the membership/role-consistency and anti-escalation checks enforced by the RBAC role-binding path. As a result, an authenticated user who is an admin of an organization can INSERT or UPDATE org users rows directly to add any existing public.users account as an active member of that organization with user right="admin", bypassing the invitation and role-assignment workflow entirely. In testing, an account with no prior access to the organization or its apps could, after such a direct insert, read the organization and app and pass check min rights. All versions are affected and no patch was available at the time of publication. 🎖@cveNotify

The `transfer app()` database function fails to delete or revalidate existing rows in `channel permission overrides` when transferring an app, its channels, versions, and related records to a destination organization. This allows a user who had a channel permission override in the source organization to retain that override after the transfer, despite having no membership or Role-Based Access Control (RBAC) binding in the destination organization. An attacker can use an authenticated JSON Web Token (JWT) against the PostgREST API to modify the destination-owned channel to point to a different bundle, leading the `/updates` endpoint to serve an unauthorized application version to devices.

An indirect bypass of the row-level security policy exists in the `public.manifest` table. A user or principal with app-scoped upload, write, or all API keys, or an authenticated user with write+ rights, can update `public.app versions.manifest` for versions using the `r2-direct` storage provider, as these are not covered by the bundle content-lock check. The `on version update` async worker trusts the `record.manifest` and uses a service-role Supabase client to insert attacker-controlled `file name`, `file hash`, and `s3 path` variables into the `public.manifest` table. Consequently, the `/updates` endpoint returns this entry as a client-facing `download url`, allowing for Over-the-Air (OTA) manifest poisoning. OTA refers to the wireless delivery of updates to a device.

An authorization flaw exists in the app icon update process. The 'PUT /app/:id' endpoint accepts a user-controlled `icon` value and stores it in `public.apps.icon url` without verifying if the image path belongs to the target app's image namespace. Updating this value triggers the `on app update` trigger, which executes the `cleanStoredImageMetadata()` function using service-role credentials. This process downloads and re-uploads the referenced storage object with `upsert: true`. Consequently, an authenticated user with an app-limited write API key can force the privileged worker to overwrite private image objects, such as organization logos, that the user cannot normally access under Supabase Storage Row Level Security (RLS), a security feature that restricts data access based on user roles.

The '/build/upload/:jobId' TUS proxy endpoint fails to enforce upload expiry or build lifecycle state. While native build requests include an `upload expires at` timestamp and a 'pending' status, the upload proxy only verifies the `app.build native` permission before forwarding POST, PATCH, and HEAD requests to the internal builder. Consequently, an authenticated user with the `app.build native` permission can continue writing to a build upload session after the expiry time has passed or after the build has progressed beyond the upload phase, provided the internal builder service does not independently reject the request.

The backend fails to validate parent-child delegation when processing the `x-limited-key-id` header. The function `checkKeyByIdPg()` in `supabase/functions/ backend/utils/hono middleware.ts` resolves the numeric API key ID using only the key ID, expiration state, and the authenticating key's `user id`. Simultaneously, `hasLimitedRbacSubkeyScope()` accepts any key with a non-organization RBAC binding, and `validateSubkeyUser()` only compares owning user IDs. This allows an authenticated `apikey manager` API key without application access to provide the numeric ID of a more privileged key owned by the same user. The middleware then uses `setSubkeyAuthContext` to replace the authenticated principal and secret with that of the privileged key, enabling the user to exercise `app admin` permissions without knowing the secret.

Capgo (capgo.app) fails to restrict direct write access to the public.sso providers table exposed through Supabase PostgREST. A holder of an ordinary Capgo full API key can insert a row with status='active' and enforce sso=true, bypassing the intended backend SSO provisioning route (supabase/functions/ backend/private/sso/providers.ts) and its controls: the Enterprise plan requirement, SSO provider creation via the Supabase Management API, DNS TXT domain-ownership verification, the pending verification → verified → active status transition, and issuance of a trusted provider ID by Supabase Auth. The forged row is trusted by SSO discovery and enforcement logic, including the unauthenticated login preflight endpoint /private/sso/check-domain, which then reports {"has sso": true, "enforce sso": true} for domains that were never verified, allowing attacker-controlled SSO enforcement to be asserted for arbitrary domains and disrupting normal login. All versions are affected; at the time of the advisory no patch was available.

Capgo fails to clean up channel permission overrides when a user's last organization role binding is deleted, which leaves stale overrides active. This allows attackers to retain channel-specific permissions even after their base Role-Based Access Control (RBAC) access has been revoked, enabling unauthorized actions such as modifying production Over-the-Air (OTA) versions.

Capgo (Cap-go/capgo.app) contains an authentication bypass affecting all versions (no patched version available at time of publication). The Edge authorization path allows a password-only Supabase aal1 session to exercise privileged RBAC permissions even when the account has a verified MFA factor that has not been used for the session: the Edge JWT middleware (foundJWT() in supabase/functions/ backend/utils/hono middleware.ts) accepts the JWT without validating its assurance level, and the direct RBAC path (checkPermission()/checkPermissionPg() in supabase/functions/ backend/utils/rbac.ts calling public.rbac check permission direct()) authorizes by user ID without passing or checking the session aal, unlike the public.verify mfa() control which correctly requires aal2. An attacker who knows only the victim's password can therefore authenticate, mint a persistent app-scoped app admin API key that remains valid after the aal1 session is logged out, and perform privileged operations such as modifying production OTA channel configurations (validated by changing a public production channel from bundle 1.0.0 to 1.0.1), defeating the protection provided by MFA.

توجد مشكلة تتعلق بالكشف عن المعلومات في دالة Supabase PostgREST SECURITY DEFINER RPC المسماة `public.rescind invitation()`. يمكن للمهاجمين غير المصادق عليهم، الذين يستخدمون مفتاح API قابل للنشر فقط، تحديد وجود المنظمات. ويحدث ذلك لأن الدالة تُرجع رسائل خطأ مميزة، وتحديدًا `NO ORG` و`NO RIGHTS`، مما يسمح للمهاجمين بتحديد معرّفات المنظمات الصالحة. ويمكن استخدام هذا الاكتشاف لتسهيل حملات التصيد الاحتيالي أو الهندسة الاجتماعية المستهدفة.

توجد مشكلة تتمثل في أن المستخدمين الذين تم تخفيض مستواهم من دور `super admin` يحتفظون بوصول غير مصرح به إلى وظائف محددة. ويحدث ذلك لأن العمود `org users.user right` لا يتم مسحه أثناء حذف ارتباطات الأدوار، مما يؤدي إلى بقاء أذونات قديمة. يمكن للمهاجم استغلال هذه الثغرة لتعداد الحزم غير المتوافقة وحذفها بشكل جماعي على مستوى المؤسسة بأكملها. الوظائف المتأثرة هي RPCs `delete non compliant bundles` و`count non compliant bundles`.

توجد مشكلة تتعلق بالكشف عن المعلومات في نقطة النهاية `global stats` لـ Supabase PostgREST. يمكن للمهاجمين غير المصادق عليهم استخدام مفتاح `apikey` العام للاستعلام عن نقطة النهاية ’/rest/v1/global stats‘، مما يؤدي إلى الكشف عن المقاييس المالية والتشغيلية الحساسة، بما في ذلك الإيرادات الشهرية المتكررة (MRR)، وإجمالي الإيرادات، وتفاصيل الإيرادات حسب فئات الخطط، وعدد العملاء، وبيانات القياس التشغيلية عن بُعد.

توجد مشكلة في عزل النطاق في نقطة النهاية ’POST /webhooks/test‘. تسمح هذه الثغرة للمستخدمين الذين يمتلكون مفاتيح API على نطاق التطبيق بتنفيذ عمليات ويبهوك على نطاق المؤسسة، متجاوزين بذلك فحص التفويض `limited to apps`. ونتيجة لذلك، يمكن للمهاجم الذي يستخدم بيانات اعتماد على نطاق التطبيق تشغيل عمليات تسليم webhook صادرة موقعة لـ webhooks عشوائية تابعة للمؤسسة تقع خارج حدود التطبيق المحددة له.

توجد مشكلة تعطيل الحسابات عبر المؤسسات في نقطة نهاية prelink الخاصة بـ SSO. يمكن لمسؤولي المؤسسات الذين يمتلكون إذن `org.update settings` ومزود SSO نشط استخدام نقطة نهاية `prelink-users` لحذف هويات كلمات مرور المستخدمين المنتمين إلى مؤسسات أخرى بشكل دائم، شريطة أن يتطابق المستخدمون مع نطاق البريد الإلكتروني الخاص بالمزود. يفرض هذا الإجراء على المستخدمين المتأثرين إما استخدام مزود SSO الخاص بالمهاجم أو الخضوع لعملية استعادة إعادة تعيين كلمة المرور.