DataEase CVE-2026-55631

Exploitation requires an authenticated account (CVSS PR:L) able to reach the font management module and create then delete font records; the attacker must supply a malicious fileTransName value at record-creation time, and the arbitrary deletion only fires when that record is subsequently deleted. Impact is bounded to files that are writable/deletable by the DataEase application process inside its container - files owned by other users or on read-only mounts are out of reach. Limiting factors: valid credentials with font-management access are mandatory (not unauthenticated), only the delete operation triggers the sink, and the effective damage depends on which files the container process can delete, which containerization and non-root execution can constrain.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N, score 7.2) indicates a remotely reachable, low-complexity attack requiring only low-privilege authentication and no user interaction, with high integrity and availability impact but no confidentiality loss - consistent with an arbitrary file deletion primitive rather than data theft or code execution. No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit is identified at time of analysis, so real-world exploitation pressure appears limited to environments where untrusted or low-trust accounts exist. The primary risk driver is the PR:L requirement: this is not an unauthenticated internet-facing bug, so realistic risk concentrates on multi-tenant or broadly-provisioned DataEase deployments where a low-privilege user could delete configuration, data, or supporting files to cause denial of service or tamper with application state. Priority is moderate - a genuine integrity/availability concern for internet-exposed or shared instances, but the authentication requirement and absence of exploitation signals argue against emergency-level urgency.

A low-privilege but authenticated DataEase user creates a font record with a crafted fileTransName containing directory traversal sequences (e.g. '../../..' pointing at a critical writable file), then triggers deletion of that record. The backend appends the malicious value to the font storage directory and calls FileUtils.deleteFile(), removing the targeted file and enabling tampering or denial of service. The network attack vector and low complexity make this straightforward for any account holder, though no public POC is currently identified.