[1.6.0-beta] productKeyIsValid() regex missing letter 'N' — rejects valid Windows Enterprise product keys

[servicedesk.pianezza]

Hi all, @Tom-Elliott @Sebastian-Roth

I found a bug in the Windows product key validation introduced in the Channel Beta | Version 1.6.0-beta.5384.

Issue:
A legitimate corporate Windows 11 Enterprise volume-license product key (containing the letter N) was rejected on the Host Management “General” tab with the error “Invalid Windows product key” (HTTP 400). The same key was accepted without issue on older FOG versions (pre-1.6.0-beta strict validation).

Root cause:
File: src/Base/FOGBase.php, function productKeyIsValid() (around line 2758)

public static function productKeyIsValid($val)
{
    return (bool)preg_match(
        '/^[BCDFGHJKMPQRTVWXY2346789]{25}$/',
        self::productKeyStrip($val)
    );
}

The allowed character class BCDFGHJKMPQRTVWXY2346789 is missing the letter N, which IS a valid character in the official Windows product key alphabet.

Evidence N is valid:
Many official Microsoft KMS Client Setup Keys contain N, e.g.:

• Windows 10/11 Pro: W269N-WFGWX-YVC9B-4J6C9-T83GX
• Windows 10/11 Enterprise: NPPR9-FWDCX-D2C8J-H872K-2YT43
• Windows 10/11 Pro N: MH37W-N47XK-V7XM9-C7227-GCQG9

Source: https://learn.microsoft.com/en-us/windows-server/get-started/kmsclientkeys

Steps to reproduce:

1. Host Management → edit a host → General tab
2. Enter a valid Windows Enterprise/volume product key containing the letter N
3. Click Update
4. FOG rejects it as “Invalid Windows product key”

Suggested fix:
Add N to the character class:
‘/^[BCDFGHJKMNPQRTVWXY2346789]{25}$/’

Workaround applied locally (via sed) while waiting for an official fix:

sudo sed -i “s/[BCDFGHJKMPQRTVWXY2346789]/[BCDFGHJKMNPQRTVWXY2346789]/” /var/www/fog/src/Base/FOGBase.php

Confirmed working after this change.

Environment:

• FOG Version: 1.6.0-beta.5384 (Channel Beta, branch working-1.6)
• OS: Ubuntu 26.04.1 LTS “Resolute”

Thanks!

[Tom Elliott]

@servicedesk-pianezza Confirmed, and your fix is the right one. Thanks for the clear report.

The check was using the 24-character Base24 alphabet. That set is what you use to decode an older key into its binary form, and N is not one of its digits. It is not the set of characters a key is printed with. Windows 8 and later put N in the key itself, so any key carrying one was refused at entry.

There was a second half of the same bug. The browser keeps its own copy of that character list, for the masked display of a saved key. So even where a key with an N got stored, the page showed it as five groups of dots instead of keeping the first and last group. Both copies now say the same thing, and a test compares them character for character so they cannot drift apart again.

The test also runs Microsoft’s published KMS client keys through the validator, and checks that the characters Windows leaves out (A E I O U L S Z 0 1) are still rejected and the length is still exactly 25.

It is in PR #1773 against working-1.6: https://github.com/FOGProject/fogproject/pull/1773

It will be in the next beta build. If you would rather not wait, the one-character edit you already made is exactly what landed.