CVE-2025-10702

Improper Control of Generation of Code (Code Injection) vulnerability in Progress DataDirect Connect for JDBC drivers, Progress DataDirect Open Access JDBC driver and Hybrid Data Pipeline allows Remote Code Inclusion.

The SpyAttribute connection option implemented by the DataDirect Connect for JDBC drivers, DataDirect Hybrid Data Pipeline JDBC driver and the DataDirect OpenAccess JDBC driver supports an undocumented syntax construct for the option value that if discovered can be used by an attacker. If an application allows an end user to specify a value for the SpyAttributes connection option then an attacker can use the undocumented syntax to cause the driver to load an arbitrary class on the class path and execute a constructor on that class.  

This issue affects:

DataDirect Connect for JDBC for Amazon Redshift: through 6.0.0.001392, fixed in 6.0.0.001541

DataDirect Connect for JDBC for Apache Cassandra: through 6.0.0.000805, fixed in 6.0.0.000833

DataDirect Connect for JDBC for Hive: through 6.0.1.001499, fixed in 6.0.1.001628

DataDirect Connect for JDBC for Apache Impala: through 6.0.0.001155, fixed in 6.0.0.001279

DataDirect Connect for JDBC for Apache SparkSQL: through 6.0.1.001222, fixed in 6.0.1.001344

DataDirect Connect for JDBC Autonomous REST Connector: through 6.0.1.006961, fixed in 6.0.1.007063

DataDirect Connect for JDBC for DB2: through 6.0.0.000717, fixed in 6.0.0.000964

DataDirect Connect for JDBC for Google Analytics 4: through 6.0.0.000454, fixed in 6.0.0.000525

DataDirect Connect for JDBC for Google BigQuery: through 6.0.0.002279, fixed in 6.0.0.002410 DataDirect Connect for JDBC for Greenplum: through 6.0.0.001712, fixed in 6.0.0.001727 DataDirect Connect for JDBC for Informix: through 6.0.0.000690, fixed in 6.0.0.0851

DataDirect Connect for JDBC for Microsoft Dynamics 365: through 6.0.0.003161, fixed in 6.0.0.3198

DataDirect Connect for JDBC for Microsoft SQLServer: through 6.0.0.001936, fixed in 6.0.0.001957

DataDirect Connect for JDBC for Microsoft Sharepoint: through 6.0.0.001559, fixed in 6.0.0.001587

DataDirect Connect for JDBC for MongoDB: through 6.1.0.001654, fixed in 6.1.0.001669

DataDirect Connect for JDBC for MySQL: through 5.1.4.000330, fixed in 5.1.4.000364

DataDirect Connect for JDBC for Oracle Database: through 6.0.0.001747, fixed in 6.0.0.001776

DataDirect Connect for JDBC for Oracle Eloqua: through 6.0.0.001438, fixed in 6.0.0.001458

DataDirect Connect for JDBC for Oracle Sales Cloud: through 6.0.0.001225, fixed in 6.0.0.001316

DataDirect Connect for JDBC for Oracle Service Cloud: through 5.1.4.000298, fixed in 5.1.4.000309 DataDirect Connect for JDBC for PostgreSQL: through 6.0.0.001843, fixed in 6.0.0.001856

DataDirect Connect for JDBC for Progress OpenEdge: through 5.1.4.000187, fixed in 5.1.4.000189

DataDirect Connect for JDBC for Salesforce: through 6.0.0.003020, fixed in 6.0.0.003125 DataDirect Connect for JDBC for SAP HANA: through 6.0.0.000879, product retired

DataDirect Connect for JDBC for SAP S/4 HANA: through 6.0.1.001818, fixed in 6.0.1.001858

DataDirect Connect for JDBC for Sybase ASE: through 5.1.4.000161, fixed in 5.1.4.000162

DataDirect Connect for JDBC for Snowflake: through 6.0.1.001821, fixed in 6.0.1.001856

DataDirect Hybrid Data Pipeline Server: through 4.6.2.3309, fixed in 4.6.2.3430

DataDirect Hybrid Data Pipeline JDBC Driver: through 4.6.2.0607, fixed in 4.6.2.1023

DataDirect Hybrid Data Pipeline On Premises Connector: through 4.6.2.1223, fixed in 4.6.2.1339 DataDirect Hybrid Data Pipeline Docker: through 4.6.2.3316, fixed in 4.6.2.3430

DataDirect OpenAccess JDBC Driver: through 8.1.0.0177, fixed in 8.1.0.0183

DataDirect OpenAccess JDBC Driver: through 9.0.0.0019, fixed in 9.0.0.0022

Weakness

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

Potential Mitigations

• Run your code in a “jail” or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
• Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
• This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
• Be careful to avoid CWE-243 and other weaknesses related to jails.
• Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
• To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
• For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/242.html
• https://cwe.mitre.org/data/definitions/35.html
• https://cwe.mitre.org/data/definitions/77.html

References

• https://community.progress.com/s/article/Progress-DataDirect-Critical-Security-Product-Alert-Bulletin-November-2025