ANT-2026-ZZY4987K: wolfCrypt wc_CmacUpdate: 32-bit totalSz wraparound enables CMAC forgery on >4 GiB messages

wolfCrypt's streaming CMAC implementation kept the number of bytes processed in a 32-bit counter (totalSz) and used the test totalSz != 0 to decide whether to XOR the running digest into the next block before encrypting it. After 4 GiB of input the counter wraps back to zero, so wc_CmacUpdate() skips the chaining step a second time and silently discards the accumulated CBC-MAC state. As a result, any two messages that are identical from the 4 GiB offset onward produce the same CMAC tag under the same key, allowing an attacker who holds one valid tag for such a message to substitute the first 4 GiB with arbitrary content (CVE-2026-5477, GHSA-grqc-3vmg-p68x). wolfSSL fixed the issue by making the XOR unconditional; the fix is included in wolfSSL 5.9.1.

Target

Project: wolfSSL
Location: wolfcrypt/src/cmac.c:wc_CmacUpdate
Discovery: static analysis — not yet dynamically reproduced

Technical Details

Component. wc_CmacUpdate() in wolfcrypt/src/cmac.c, and the equivalent block-flush path in wc_local_CmacUpdateAes() in wolfcrypt/src/aes.c.

Root cause. When the internal 16-byte buffer is full and more input remains, the update routine chains the buffered block into the CBC-MAC state and encrypts it:

if (cmac->bufferSz == WC_AES_BLOCK_SIZE && inSz != 0) {
    if (cmac->totalSz != 0) {                       /* removed by the fix */
        xorbuf(cmac->buffer, cmac->digest, WC_AES_BLOCK_SIZE);
    }
    wc_AesEncryptDirect(&cmac->aes, cmac->digest, cmac->buffer);
    cmac->totalSz += WC_AES_BLOCK_SIZE;
    ...

The totalSz != 0 guard was meant only to skip the XOR on the very first block, where digest is all zeros and the XOR is a no-op. totalSz is a word32, however, and after 2^28 block flushes (4 GiB of input) it wraps to zero. On the next flush the guard fires again, the XOR with the live digest is skipped, and the block is encrypted on its own: the CBC-MAC chain is restarted and every preceding block stops contributing to the tag.

Reachability and impact. The defect is reached by processing a single message longer than 4 GiB through the streaming CMAC update API. Any two messages sharing a common suffix beyond the 4 GiB mark then produce identical CMAC tags, so an attacker who observes one valid tag for a message longer than 4 GiB can replace the first 4 GiB with arbitrary data without invalidating the tag — a zero-work prefix-substitution forgery. This is an integrity failure (CWE-190, Integer Overflow or Wraparound); the published advisory rates it High (CVSS 3.1 base score 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N). Messages of 4 GiB or less are not affected.

Fix. Commit 10953f021 ("CMAC: fix wraparound in streaming update", wolfSSL/wolfssl#10102, merged 2026-04-06) removes the guard in both files so the XOR is performed unconditionally; first-block behaviour is unchanged because wc_InitCmac_ex() zero-initialises digest. The fix is included in wolfSSL 5.9.1. Tracked as CVE-2026-5477 / GHSA-grqc-3vmg-p68x.

Reproduction

This finding was identified by static analysis and has not yet been dynamically reproduced. The Technical Details section above describes the code path; a trigger input is not included.

[No reproducer or sanitizer output attached — request from security-cvd@anthropic.com if needed.]

Acknowledgement

This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research. Please direct questions to security-cvd@anthropic.com and reference ANT-2026-ZZY4987K.

Reference: ANT-2026-ZZY4987K
Anthropic CVD Policy: https://www.anthropic.com/coordinated-vulnerability-disclosure