Base64UrlSafe accepts bytes 0x80 to 0xFF when ext-sodium is loaded

Open
  • Is something wrong?
#766 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
php
Domain
backend, security

Research direction

Start with Base64UrlSafe::decodeNoPadding() and compare its sodium path with the pure PHP decoder; the issue says the class handles key material too. Check how the existing code raises RangeException for invalid input, then verify that bytes outside the base64url alphabet are rejected consistently while valid input still decodes. The issue gives a reproduction using QUJ_ and QUJ\xFF; use these to confirm the behavior.

Written by the indexing model from the issue text.

Description

bug
Version(s) affected

3.4.9 to 3.4.12, 4.0.7 to 4.0.8, 4.1.0 to 4.1.10, 4.2.0 to 4.2.5, and the 4.3.x and 5.0.x branches, when ext-sodium is linked against libsodium 1.0.21 or older on a platform where char is signed (x86-64)

Description

When ext-sodium is loaded, Base64UrlSafe::decodeNoPadding() hands its input to sodium_base642bin() and relies on libsodium to reject characters outside the base64url alphabet. Up to 1.0.21, libsodium decodes every byte from 0x80 to 0xFF as _ where char is signed (seen with 1.0.18 on x86-64). This was fixed upstream in 1.0.22 (jedisct1/libsodium@a615d0ed74, "base64: reject signed chars"). The pure PHP decoder of the same class rejects these bytes, so the result depends on the environment.

Every token segment goes through this decoder. Each _ in the signature of a compact JWS, or in the encrypted key, IV, ciphertext or tag of a compact JWE, can be replaced by any byte from 0x80 to 0xFF, and the token still loads with the same header, payload and plaintext. The header and payload segments are used as received, so they cannot be changed this way.

Nothing is forged or disclosed. A token holder can however produce other strings for a token the application accepts, which matters to applications that recognise a token by its string or its hash (deny-list of revoked tokens, replay cache).

The sodium path was added in #636 (4.1.0) and backported in #644 (3.4.9, 4.0.7).

How to reproduce
use Jose\Component\Core\Util\Base64UrlSafe;

echo bin2hex(Base64UrlSafe::decodeNoPadding('QUJ_')), PHP_EOL;    // 41427f
echo bin2hex(Base64UrlSafe::decodeNoPadding("QUJ\xFF")), PHP_EOL; // 41427f with ext-sodium, RangeException without it
Possible Solution

Reject the bytes outside the alphabet on the sodium path too, with the same RangeException as the pure PHP path. The class also decodes key material (k, d…), so the check should not take a time that depends on the characters, which strspn() does before PHP 8.4. Decoding, re-encoding the result with sodium_bin2base64() and comparing with hash_equals() rejects all 128 high bytes, gives the same output on valid input, and keeps most of the speed-up of the sodium path (22 ms on 1.3 MiB, against 12.5 ms today and 409 ms for the pure PHP path).

Additional Context

Found by the Anthropic OSS Scanner (ANT-2026-DYQEQ988).

Dominant language
PHP
Stars
954
Forks
119
Avg merge
48m
Merged PRs (30d)
17

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from web-token/jwt-framework

All issues in web-token/jwt-framework

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.