Summary
AllData through 0.7.1 exposes a JDBC datasource testing endpoint without authentication, allowing remote users to submit connection parameters. By supplying crafted JDBC URL and driver values, an attacker may connect to arbitrary database services and potentially read files from the data host through database-driver features.
AllData through 0.7.1 exposes a JDBC datasource testing endpoint without authentication, allowing remote users to submit connection parameters. By supplying crafted JDBC URL and driver values, an attacker may connect to arbitrary database services and potentially read files from the data host through database-driver features.
Affected context
The issue occurs in AllData deployments where the data-dts /jobJdbcDatasource/test endpoint is reachable by untrusted clients without an authentication or authorization boundary. Risk increases when the endpoint accepts user-controlled jdbcUrl and jdbcDriverClass values and the host has network access to external database services or contains readable sensitive files.
The issue occurs in AllData deployments where the data-dts /jobJdbcDatasource/test endpoint is reachable by untrusted clients without an authentication or authorization boundary. Risk increases when the endpoint accepts user-controlled jdbcUrl and jdbcDriverClass values and the host has network access to external database services or contains readable sensitive files.
Exploit preconditions
- Attack surface: The remotely reachable
/jobJdbcDatasource/testendpoint - Required access: Network access to the endpoint; no valid credentials may be required
- Trigger point: Submission of attacker-controlled JDBC URL and driver-class parameters
- Why exploitation is possible: The endpoint may initiate database connections using untrusted connection settings without first enforcing authentication, authorization, or sufficient destination and driver restrictions
- Attack surface: The remotely reachable
/jobJdbcDatasource/testendpoint - Required access: Network access to the endpoint; no valid credentials may be required
- Trigger point: Submission of attacker-controlled JDBC URL and driver-class parameters
- Why exploitation is possible: The endpoint may initiate database connections using untrusted connection settings without first enforcing authentication, authorization, or sufficient destination and driver restrictions
Why this happens
The underlying flaw is a missing authentication control around a function that can initiate outbound database connections.
This maps to CWE-306: Missing Authentication for Critical Function, because a sensitive datasource-testing operation is available without verifying the caller's identity or permissions. Accepting arbitrary JDBC drivers and connection URLs also expands the impact by allowing user input to influence network destinations and driver-specific behavior, including file-access features.
The underlying flaw is a missing authentication control around a function that can initiate outbound database connections.
This maps to CWE-306: Missing Authentication for Critical Function, because a sensitive datasource-testing operation is available without verifying the caller's identity or permissions. Accepting arbitrary JDBC drivers and connection URLs also expands the impact by allowing user input to influence network destinations and driver-specific behavior, including file-access features.
Potential impact
- Remote attackers may open connections to arbitrary database services
- Sensitive files readable by the AllData process may be disclosed
- Internal services may be reached through server-side outbound connections
- Database credentials or connection metadata may be exposed
- The host or connected data services could be subjected to unauthorized access attempts
- Remote attackers may open connections to arbitrary database services
- Sensitive files readable by the AllData process may be disclosed
- Internal services may be reached through server-side outbound connections
- Database credentials or connection metadata may be exposed
- The host or connected data services could be subjected to unauthorized access attempts
General mitigation guidance
Mitigation generally focuses on protecting datasource-testing functionality with strong access controls and reducing trust in connection parameters.
Common defensive patterns include:
- Require authentication and authorization before any datasource test operation
- Apply deny-by-default network egress and destination allowlists
- Permit only approved JDBC drivers and validated connection schemes
- Reject or neutralize driver options that enable local-file loading or similar side effects
- Avoid exposing diagnostic and testing endpoints to untrusted networks
- Run the service with least-privilege filesystem, network, and database permissions
- Treat all connection parameters as untrusted and validate them against an explicit schema and policy
Mitigation generally focuses on protecting datasource-testing functionality with strong access controls and reducing trust in connection parameters.
Common defensive patterns include:
- Require authentication and authorization before any datasource test operation
- Apply deny-by-default network egress and destination allowlists
- Permit only approved JDBC drivers and validated connection schemes
- Reject or neutralize driver options that enable local-file loading or similar side effects
- Avoid exposing diagnostic and testing endpoints to untrusted networks
- Run the service with least-privilege filesystem, network, and database permissions
- Treat all connection parameters as untrusted and validate them against an explicit schema and policy
How teams detect issues like this
Organizations can look for:
- Unauthenticated routes that invoke JDBC connection, datasource validation, or diagnostic functions
- Code paths that pass request parameters directly into JDBC URLs, driver-class loading, or connection factories
- Static-analysis findings for missing authentication middleware and unrestricted outbound connection creation
- Code-review signals such as public test endpoints, unrestricted driver selection, and absent destination allowlists
- Web logs showing repeated requests to the datasource test endpoint or unusual JDBC schemes and external hosts
- Network monitoring for unexpected database connections or outbound traffic from the AllData service
Automated security testing and policy-as-code checks can help enforce authentication and egress restrictions during development.
Organizations can look for:
- Unauthenticated routes that invoke JDBC connection, datasource validation, or diagnostic functions
- Code paths that pass request parameters directly into JDBC URLs, driver-class loading, or connection factories
- Static-analysis findings for missing authentication middleware and unrestricted outbound connection creation
- Code-review signals such as public test endpoints, unrestricted driver selection, and absent destination allowlists
- Web logs showing repeated requests to the datasource test endpoint or unusual JDBC schemes and external hosts
- Network monitoring for unexpected database connections or outbound traffic from the AllData service
Automated security testing and policy-as-code checks can help enforce authentication and egress restrictions during development.
