On Sat, 7 Nov 2026 at 19:43, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19843
> Logged by: Atish Prakash
> Email address: 125atishprak(at)gmail(dot)com
> PostgreSQL version: 19rc1
> Operating system: Linux x86_64
> Description:
>
> decode() with the new base64url format returns a spurious trailing byte
> when
> the input has one '=' where two would be needed:
>
> SELECT decode('ab', 'base64url'); -- \x69
> SELECT decode('ab==', 'base64url'); -- \x69
> SELECT decode('ab=', 'base64url'); -- \x69b0
>
> Expected: the third query returns \x69, like the other two, or raises an
> error.
> The base64 format raises "invalid base64 end sequence" for the same input.
> The extra byte 0xb0 comes from the leftover bits of 'b' and the padding,
> and
> is not data encoded in the input.
>
> Cause: in pg_base64_decode_internal(), the '=' sets end = 1 and advances
> pos
> to
> 3. The input then ends, and the "url && pos == 3" branch emits two bytes
> without looking at end.
>
> A possible patch is attached
> (0001-fix-base64url-decode-short-padding.patch). It
> makes the result \x69. Rejecting the input would also be reasonable, and I
> have
> no preference. Regression tests pass with it on master; it adds no new
> test.
>
> Found with semantic differential tests. I reproduced and checked the result
> myself.
>
>
>