[mbtools]

base64_decode did not reject an invalid fourth Base64 character in a 4-character sequence. That let decoding continue and mix -1 into the output byte instead of stopping, so malformed input could yield wrong bytes instead of a clean abort.

Bug

For c1, c2, and c3, the code already breaks when the lookup is -1. After reading c4, there was no equivalent check. An invalid fourth symbol set c4 to -1, but the code still ran o |= c4, corrupting the computed byte and accepting input that should be invalid.

Fix

After resolving c4 from the input, add if (c4 == -1) break; so invalid fourth symbols match the behavior for the other symbols and decoding stops without emitting a bad byte.

Severity

Medium — Incorrect bytes from bad Base64 can affect correctness of anything that depends on this decoder (e.g. salt/hash parsing). Risk is mainly when input is untrusted or malformed; aligned with treating strict decoding as important in a crypto-related path.

[mbtools]

There are fairly limited tests in this repo. Let me know if you want me to add some for decodeBase64.

[mbtools]

Still a bug 😉

[lbesecker195]

Verified: c1, c2, and c3 each break on -1 but c4 did not, so an invalid fourth symbol was OR'd into the output byte as -1. The one-line guard matches the existing pattern. LGTM.

[Gruya13]

Confirmed independently on 1211e9a: the invalid fourth symbol sets c4 = -1, but the byte is still pushed, so you get String.fromCharCode(0xFFFF) (65535) mixed into the output instead of aborting. The -1 check exists for c1-c3 but not for c4, exactly as described here.

I wrote a small test against the current code (invalid base64 with a bad fourth char) - it fails on the current master and passes with the if (c4 == -1) break; line from this PR. The diff looks right to me; no other behaviour changed for valid input.