Summary
Budibase versions before 3.45.0 may allow authenticated builders to read arbitrary local files through the OpenAPI/Swagger import validator. An attacker who can submit an OpenAPI specification may abuse external JSON reference resolution to expose environment variables, JWT secrets, API keys, and database credentials.
Affected context
The vulnerability occurs in Budibase deployments where the OpenAPI/Swagger import validator resolves external JSON references supplied within imported specifications. It is relevant when authenticated users have builder permissions and the validator can access local file resources from the application environment.
Exploit preconditions
- Attack surface: OpenAPI/Swagger specification import functionality
- Required access: Authenticated access with builder-level permissions
- Trigger point: Validation and reference resolution during specification import
- Why exploitation is possible: External references are resolved without sufficiently restricting local file access, allowing attacker-controlled specifications to request files readable by the Budibase process
Why this happens
The underlying issue is insufficient restriction of external reference resolution in an API specification parser.
When attacker-controlled OpenAPI documents can cause the validator to resolve local resources, file contents may be loaded into the processing flow and returned or otherwise exposed.
This maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, because data from protected local files can become accessible through an import operation.
Potential impact
- Sensitive environment variables may be disclosed
- JWT signing secrets, API keys, or database credentials could be exposed
- Application and integration accounts may be compromised
- Attackers could gain information useful for lateral movement
- Confidential local configuration and source files may be revealed
General mitigation guidance
Mitigation generally focuses on preventing untrusted API specifications from accessing local or unintended external resources.
Common defensive patterns include:
- Disable external reference resolution when it is not required
- Permit only approved reference schemes, such as controlled in-memory or application-managed references
- Enforce strict allowlists for permitted hosts, paths, and resource types
- Validate and normalize references before resolution
- Run import validation with minimal filesystem permissions and isolated identities
- Keep secrets outside broadly readable environment and configuration locations where practical
- Apply authorization boundaries that limit who can submit or process imported specifications
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis and dependency reviews for parsers that resolve external references
- Code review checks for unrestricted file or network reference handling
- Tests using local-file, network, and alternate-scheme references in imported specifications
- Runtime monitoring for unusual import activity or access to sensitive filesystem paths
- Policy enforcement that rejects external references unless explicitly approved
- Automated security review tools that flag unbounded resource resolution and excessive process filesystem access
