How a Hidden Ternary Operator Triggered Massive Data Deletion in a Java Backend

Background

A system handover was performed by providing only a production‑environment image, without the source code. After restoring the image, the application failed to process business logic, prompting the author to investigate the cause.

Investigation Process

Because only the image was available, the author used the Linux history command to identify which services were started. File modification timestamps revealed that, two hours before the image was created, a core dependency JAR and two class files had been altered.

The modified classes were decompiled. Both contained a suspicious ternary expression that always assigned id=1, regardless of whether the original id was null. This code looked harmless at first glance but forced the subsequent MyBatis query to build a condition where 1=1.

The generated SQL deleted rows from the table T_QUART_DATA. This table stores cron expressions for scheduled tasks, so the deletion removed all scheduled jobs, leaving the business logic in a perpetual intermediate state.

Without the original source code, the author decompiled the entire project, patched the malicious sections, and rebuilt the application.

Further Complications

The next day the system failed again. Checking the Linux crontab with crontab -e and crontab -l revealed three scheduled tasks, one of which was a script named deleteXXX. The script executed commands that removed core dependency JARs and restarted services.

These cron jobs deliberately deleted the JAR files and attempted to restart the application, further sabotaging the system. Fortunately, the previously decompiled JARs served as a backup for restoration.

Conclusion

The case demonstrates that malicious actors can embed subtle code tricks—such as a ternary expression that forces a constant ID—to cause large‑scale data loss, and can use scheduled tasks to erase critical binaries. The detailed forensic steps—examining image histories, file timestamps, decompiled code, and crontab entries—provide a practical guide for diagnosing similar security‑related failures in backend Java services.