VYPR
← All advisories
High severity7.7NVD Advisory· Published May 27, 2026· Updated May 27, 2026

CVE-2026-46427

CVE-2026-46427

Description

Budibase is an open-source low-code platform. Prior to 3.38.3, removeSecrets at packages/server/src/sdk/workspace/datasources/datasources.ts masks only datasource config fields whose schema type is DatasourceFieldType.PASSWORD. The Snowflake integration types its privateKey field as SENSITIVE_LONGFORM, which the filter skips. GET /api/datasources/:datasourceId lives on authorizedRoutes guarded by PermissionType.TABLE + PermissionLevel.READ. An authenticated BASIC user with any app role and call the endpoint and receive the full Snowflake PEM in plaintext. This vulnerability is fixed in 3.38.3.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Budibase before 3.38.3 exposes Snowflake private keys in plaintext to BASIC users via the datasource API due to incomplete secret masking

Vulnerability

A flaw in Budibase versions prior to 3.38.3 allows authenticated users with a BASIC role to retrieve the Snowflake integration's private key in plaintext via GET /api/datasources/:datasourceId. The removeSecrets function in packages/server/src/sdk/workspace/datasources/datasources.ts only masks fields typed as DatasourceFieldType.PASSWORD, but the Snowflake schema defines the privateKey field as DatasourceFieldType.SENSITIVE_LONGFORM. This type was introduced for long textarea inputs and was not covered by the masking logic. The same gap affects Firebase (privateKey), Oracle (TNS path config fields), and any other integration using SENSITIVE_LONGFORM for secrets [1].

Exploitation

An attacker needs only a valid Budibase session with any app role (BASIC or higher) because the endpoint /api/datasources/:datasourceId is guarded by PermissionType.TABLE and PermissionLevel.READ, and the BASIC role on a published app grants READ permission on tables. No special privileges or user interaction beyond authentication are required. The attacker simply sends an authenticated GET request to the affected API endpoint for a datasource that uses the Snowflake integration; the response returns the full PEM-encoded private key unmasked [1].

Impact

Successful exploitation results in the disclosure of the Snowflake integration's private key (PEM) in plaintext. An attacker can then use this key to authenticate to the linked Snowflake account, potentially gaining unauthorized access to sensitive data managed by the Snowflake warehouse. The confidentiality of the database connection is fully compromised, and further lateral movement or data exfiltration from Snowflake becomes possible depending on the permissions of the exposed key [1].

Mitigation

The vulnerability is fixed in Budibase version 3.38.3, released on 2026-05-27 [1]. Organizations running an affected version (prior to 3.38.3) should upgrade immediately. No official workaround has been provided other than upgrading. As of the publication date, this CVE is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog.

References
  1. Snowflake private key returned unmasked from datasource API to BASIC users

AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Budibase/Budibaseinferred2 versions
    <3.38.3+ 1 more
    • (no CPE)range: <3.38.3
    • (no CPE)range: <3.38.3

Patches

1
330c1c9c2984

Mask sensitive longform datasource fields

https://github.com/Budibase/budibasePeter ClementMay 12, 2026Fixed in 3.38.3via llm-release-walk
commit
2 files changed · +29 −2
  • packages/server/src/api/routes/tests/datasource.spec.ts+25 −0 modified
    @@ -422,6 +422,31 @@ describe("/datasources", () => {
         "{{ env.USERNAME }}"
       )
     })
+
+    it("scrubs sensitive longform fields in get response", async () => {
+      const privateKey = [
+        "-----BEGIN PRIVATE KEY-----",
+        "secret-material",
+        "-----END PRIVATE KEY-----",
+      ].join("\n")
+      const created = await config.api.datasource.create({
+        type: "datasource",
+        name: "Snowflake longform secret",
+        source: SourceName.SNOWFLAKE,
+        config: {
+          account: "test-account",
+          username: "test-user",
+          privateKey,
+          warehouse: "test-warehouse",
+          database: "test-database",
+          schema: "test-schema",
+        },
+      })
+
+      const fetched = await config.api.datasource.get(created._id!)
+
+      expect(fetched.config!.privateKey).toBe(PASSWORD_REPLACEMENT)
+    })
   })
 
   describe("auth config password preservation", () => {
  • packages/server/src/sdk/workspace/datasources/datasources.ts+4 −2 modified
    @@ -255,10 +255,12 @@ export async function removeSecrets(datasources: Datasource[]) {
           }
         }
       }
-      // remove general passwords
+      // remove general secrets
       for (let key of Object.keys(datasource.config)) {
+        const fieldType = schema.datasource?.[key]?.type
         if (
-          schema.datasource?.[key]?.type === DatasourceFieldType.PASSWORD &&
+          (fieldType === DatasourceFieldType.PASSWORD ||
+            fieldType === DatasourceFieldType.SENSITIVE_LONGFORM) &&
           !useEnvVars(datasource.config[key])
         ) {
           datasource.config[key] = PASSWORD_REPLACEMENT

Vulnerability mechanics

Root cause

"The removeSecrets masking function only checks for DatasourceFieldType.PASSWORD, missing the SENSITIVE_LONGFORM type used by Snowflake's privateKey field."

Attack vector

An authenticated BASIC user with any app role calls `GET /api/datasources/:datasourceId`, which is guarded by `PermissionType.TABLE + PermissionLevel.READ` [ref_id=1]. The endpoint returns the datasource config after `removeSecrets` runs, but because the Snowflake `privateKey` field uses type `SENSITIVE_LONGFORM` instead of `PASSWORD`, the masking loop skips it and returns the full PEM in plaintext [ref_id=1]. The BASIC role on a published app grants the required READ permission, and datasource IDs are obtainable through the builder UI or `/api/applications/:appId` metadata [ref_id=1].

Affected code

The masking function `removeSecrets` at `packages/server/src/sdk/workspace/datasources/datasources.ts:259-266` only checks for `DatasourceFieldType.PASSWORD` when filtering datasource config fields. The Snowflake integration schema at `packages/server/src/integrations/snowflake.ts:49-53` types its `privateKey` field as `DatasourceFieldType.SENSITIVE_LONGFORM`, which is not covered by the filter [ref_id=1]. The same gap affects Firebase and Oracle integrations [ref_id=1].

What the fix does

The patch [patch_id=2725533] extends the `removeSecrets` function to also check for `DatasourceFieldType.SENSITIVE_LONGFORM` alongside `DatasourceFieldType.PASSWORD`. This ensures that long-form secret fields like the Snowflake private key are masked with the placeholder value instead of being returned in plaintext. The fix also covers Firebase private keys, Oracle TNS path config fields, and any other integration that uses `SENSITIVE_LONGFORM` for secret material [ref_id=1].

Preconditions

  • authAttacker must be an authenticated BASIC user with any app role on a published app that has a Snowflake (or Firebase/Oracle) datasource configured
  • configThe datasource must have a privateKey (or other SENSITIVE_LONGFORM secret field) configured
  • inputAttacker must know or be able to obtain the datasource ID (obtainable via builder UI or /api/applications/:appId)

Reproduction

Step 1: Admin creates an app with a Snowflake datasource containing both a password and a privateKey, then publishes the app. Step 2: Admin creates a BASIC user and assigns them a role on the app. Step 3: The BASIC user logs in and calls `GET /api/datasources/:datasourceId` with the app ID header. The response returns the privateKey in plaintext while the password is masked [ref_id=1].

Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

1

News mentions

0

No linked articles in our index yet.