Summary
RisingWave contains a missing authorization vulnerability that may allow low-privileged SQL users to read from or write to arbitrary server-side directories through filesystem-backed sources and sinks. The issue becomes risky when a user has schema CREATE privilege and the database permits filesystem paths to be configured without adequate authorization checks.
RisingWave contains a missing authorization vulnerability that may allow low-privileged SQL users to read from or write to arbitrary server-side directories through filesystem-backed sources and sinks. The issue becomes risky when a user has schema CREATE privilege and the database permits filesystem paths to be configured without adequate authorization checks.
Affected context
This vulnerability occurs in RisingWave deployments that expose posix_fs sources or fs sinks to SQL users whose privileges are not sufficiently constrained. It is relevant when filesystem path settings can reference directories outside an explicitly approved application data area and when database authorization does not verify whether the requesting user may access those locations.
This vulnerability occurs in RisingWave deployments that expose posix_fs sources or fs sinks to SQL users whose privileges are not sufficiently constrained. It is relevant when filesystem path settings can reference directories outside an explicitly approved application data area and when database authorization does not verify whether the requesting user may access those locations.
Exploit preconditions
- Attack surface: SQL interfaces that support filesystem-backed sources or sinks
- Required access: A low-privileged SQL account with schema CREATE privilege
- Trigger point: Creation or configuration of a posix_fs source or fs sink
- Why exploitation is possible: Server-side path values may be accepted without an authorization check that limits access to approved directories
- Attack surface: SQL interfaces that support filesystem-backed sources or sinks
- Required access: A low-privileged SQL account with schema CREATE privilege
- Trigger point: Creation or configuration of a posix_fs source or fs sink
- Why exploitation is possible: Server-side path values may be accepted without an authorization check that limits access to approved directories
Why this happens
The underlying bug is an authorization failure: RisingWave permits a user with limited SQL privileges to configure filesystem operations without adequately checking whether that user is authorized to access the selected server-side path. This maps to CWE-862, Missing Authorization, because a protected operation is reachable without an effective permission decision for the target resource.
The underlying bug is an authorization failure: RisingWave permits a user with limited SQL privileges to configure filesystem operations without adequately checking whether that user is authorized to access the selected server-side path. This maps to CWE-862, Missing Authorization, because a protected operation is reachable without an effective permission decision for the target resource.
Potential impact
- An attacker may read credentials, private keys, or other sensitive server files.
- An attacker may write or overwrite files accessible to the database process.
- Written content could alter application behavior or affect operational data.
- The database host or connected services could be exposed to further compromise.
- Confidentiality, integrity, and availability of server-managed resources may be reduced.
- An attacker may read credentials, private keys, or other sensitive server files.
- An attacker may write or overwrite files accessible to the database process.
- Written content could alter application behavior or affect operational data.
- The database host or connected services could be exposed to further compromise.
- Confidentiality, integrity, and availability of server-managed resources may be reduced.
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the point where
filesystem-backed operations are created and executed.
Common defensive patterns include:
- Restricting filesystem sources and sinks to explicitly approved directories.
- Applying server-side authorization checks independently of SQL object-creation privileges.
- Using secure-by-default storage abstractions instead of exposing arbitrary host paths.
- Reducing input trust by canonicalizing and validating paths against an allowlist.
- Running database services with a dedicated, least-privileged operating-system account.
- Preventing access to credentials, keys, system directories, and other sensitive locations.
- Separating database data paths from host-level administrative and application directories.
Mitigation generally focuses on enforcing authorization at the point where
filesystem-backed operations are created and executed.
Common defensive patterns include:
- Restricting filesystem sources and sinks to explicitly approved directories.
- Applying server-side authorization checks independently of SQL object-creation privileges.
- Using secure-by-default storage abstractions instead of exposing arbitrary host paths.
- Reducing input trust by canonicalizing and validating paths against an allowlist.
- Running database services with a dedicated, least-privileged operating-system account.
- Preventing access to credentials, keys, system directories, and other sensitive locations.
- Separating database data paths from host-level administrative and application directories.
How teams detect issues like this
Detection approaches may include:
- Reviewing code and configuration paths that authorize filesystem-backed source or sink creation.
- Using static analysis to identify file operations whose paths originate from SQL-controlled input.
- Auditing whether path canonicalization, directory allowlists, and permission checks occur before access.
- Monitoring database catalog changes for unexpected posix_fs sources or fs sinks.
- Alerting on database processes reading or writing outside approved storage directories.
- Enforcing policy checks that prohibit database-managed filesystem access to sensitive paths.
Detection approaches may include:
- Reviewing code and configuration paths that authorize filesystem-backed source or sink creation.
- Using static analysis to identify file operations whose paths originate from SQL-controlled input.
- Auditing whether path canonicalization, directory allowlists, and permission checks occur before access.
- Monitoring database catalog changes for unexpected posix_fs sources or fs sinks.
- Alerting on database processes reading or writing outside approved storage directories.
- Enforcing policy checks that prohibit database-managed filesystem access to sensitive paths.
