javascript-obfuscator 5.8.1: fixes for flattening that broke short-circuit evaluation

What happened on 2026-09-30

At 09:16 UTC on 2026-09-30, javascript-obfuscator published 5.8.1 on GitHub. The release notes contain just two fixes. First, transformObjectKeys could cause objects used as default parameters to be shared across calls; this was fixed (#1455). Second, controlFlowFlattening could break short-circuit evaluation of &&, || and ??; this was also fixed (#1456). Both are semantic bugs. With the relevant options enabled, obfuscated code could behave differently from the source. The release came only ten days after 5.8.0 on 2026-09-20. The notes do not say which earlier versions were affected, so anyone who enabled these options in recent builds should check their own release history rather than assume they were safe.

What it means for obfuscation practice

Obfuscation rests on the premise that it changes readability, not behavior, and these two fixes show the premise does not always hold. Short-circuit evaluation is often used as a null guard, for example checking that an object exists before reading a property. If the right-hand side runs when it should not, you can get exceptions that appear only in obfuscated builds, or logic running that should have been skipped. Default-parameter objects shared across calls can let state that should be independent bleed between calls, and that kind of bug is often hard to reproduce. For teams that use obfuscation to protect web front ends, Electron or hybrid apps, the real risk is that such defects show up only in release builds, while day-to-day development and unit tests run against the source. None of this argues against obfuscation. It shows that obfuscation is a build step that changes the artifact and should be treated with the same care as a compiler upgrade.

Checks to run on your own builds

First, if you enable controlFlowFlattening or transformObjectKeys, upgrade to 5.8.1 promptly, and check whether earlier production releases showed exceptions that appeared only in release builds. Second, run end-to-end or integration tests against the obfuscated output, not only the source. Third, add targeted test cases that cover null guards written with &&, || and ??, and functions with default-parameter objects that are called repeatedly. Fourth, pin the obfuscator version and treat every upgrade as a change that needs regression testing. Fifth, keep the unobfuscated build of each release so behavior differences can be compared directly when a bug report arrives.

Your checklist

• Upgrade to 5.8.1 if those options are on and review past production errors
• Run end-to-end tests against obfuscated output
• Add tests for short-circuit null guards and default-parameter objects