Asadbek Fatullayev

A denial of service issue allows unauthenticated remote attackers to crash the ION process. This occurs when a BPv7 bundle with a zero-length payload is sent. Specifically, the `canonicalizePayloadBlock()` function in bpsec util.c passes the `bundle->payload.length` variable to `zco clone()` without validating if it is zero. This leads to a failed CHKZERO assertion, which triggers `sm Abort()` and terminates the process with SIGABRT. This process happens before any HMAC (Hash-based Message Authentication Code, a mechanism for verifying both the data integrity and the authenticity of a message) verification, meaning no valid keys or credentials are required for exploitation.

An authentication bypass exists that allows unauthenticated attackers to access protected resources. By providing an attacker-controlled URL parameter to the share-link authentication endpoint, the expected resource identifier is omitted from the token verification call. An attacker with a single valid share link for any resource can authenticate against arbitrary resources across different organizations, bypassing SSO, resource passwords, PIN codes, email allowlists, and header authentication.

The POST '/common/load-related-data' endpoint resolves caller-supplied field names to any @TableField column of any entity and returns those values for all rows without a field or entity allowlist. The security guard function `relatedDataSecurityCheck()` returns true unconditionally, allowing any authenticated user, including those with zero roles, to read secret fields annotated with @JsonIgnore, such as `IamAccount.authSecret` and `IamAccount.secretSalt` for all accounts, or other arbitrary secret fields. Because the system uses Shiro's two-iteration MD5 with an 8-character salt, which is easily crackable offline, the disclosure of admin password hashes can lead to full administrative takeover. This endpoint is required by the official diboot-admin-ui frontend. On the development branch, this mechanism was renamed to attachMore*, but the `attachMoreSecurityCheck()` function also returns true unconditionally.

The POST '/download/uploadFromRsByLocal' endpoint fails to validate the `path` parameter, which is passed directly to the `new File(path)` and `file.transferTo(dest)` functions. This allows an attacker to write arbitrary files using the Dinky service account. The endpoint is excluded from the Sa-Token interceptor and relies on a hardcoded `dinkyToken` value for authentication, which is shipped with every deployment. In default Docker installations, the application runs on port 8888 with permissive permissions on /opt/dinky, enabling the overwriting of static assets, launch scripts, and the application classpath. This can lead to the execution of arbitrary code via classpath-shadowing upon the next JVM restart.

The `getAll()` function in the `SysConfigController` contains a method-level `@SaIgnore` annotation that bypasses the class-level `@SaCheckLogin` security check. This allows unauthenticated remote callers to access the `GET /api/sysConfig/getAll` endpoint without a session or role verification. Consequently, the full system configuration is exposed, including sensitive cleartext credentials such as `sys.env.settings.dinkyToken`, `sys.ldap.settings.userPassword`, `sys.resource.settings.oss.accessKey`, `sys.resource.settings.oss.secretKey`, and `sys.dolphinscheduler.settings.token`. This exposure includes hardcoded defaults in fresh installations and live third-party credentials configured by operators. Furthermore, the disclosure of `dinkyToken` compromises the security of the `POST /download/uploadFromRsByLocal` endpoint.