C++20 exploit code is not a vulnerability scanner
PrettyPrague is a C++20 proof of concept for a claimed Avast Sandbox privilege-escalation flaw. The source opens an Avast driver endpoint, starts a process inside the sandbox, watches for privileged registry material, and tries to turn that access into local account control and a SYSTEM console. It does not inspect a host and return a safe exposed-or-fixed result. Running the program is the exploit attempt, which changes the decision from "should I install it?" to "do I have authorization and a disposable target?"
What happened when we ran it
Our lab did not run commit 5e7e168. The harness does not support this C ecosystem, and the repository supplies no Dockerfile that could provide a supported route. There are therefore no measured install, build, test, dependency, or audit results to report. The absence of a run should not be read as a failure or a pass. It means MrKeyoor has no independent execution evidence for the README's compatibility and success claims.
The repository offers no test directory or CI workflow, and it publishes a prebuilt x64/Release/PrettyPrague.exe beside its source and PDB. A committed executable shows that someone produced a binary; it does not document the compiler environment or prove the binary corresponds to the visible source. We did not execute it. Researchers who need reproducibility should build from reviewed source on an isolated Windows image, record the toolchain, and compare their artifact before considering any behavioral result.
Windows 11 25H2 is named, but the Avast version is not
The README says the proof of concept worked with fully patched Windows 11 25H2 and fully patched Avast Antivirus. It also claims compatibility with any Avast version. No product edition, Avast build number, driver version, observation date beyond the commit history, or failure boundary accompanies that statement. Those omissions make the widest claim impossible to verify from the page. A result on one configuration would not establish that every older and newer release is affected.
The author adds that other GenDigital products such as AVG and Norton may be affected, while explicitly framing that as a belief. The repository contains no source path for either product, no reproduction note, and no vendor confirmation. That distinction must survive a retelling: PrettyPrague demonstrates code aimed at Avast, while cross-product exposure remains speculation in the README. There is also no linked CVE, disclosure timeline, GenDigital response, or fixed-version notice to settle current risk.
The 38,912-byte EXE can change account credentials
The checked-in x64 executable is 38,912 bytes, but the important detail is the source behavior. PrettyPrague parses the offline SAM hive, derives account password hashes, prints account data, and attempts to use local credentials. The main path also interacts with an Avast device and sandbox directory before copying the registry material into a temporary transaction. This is credential-access and privilege-escalation code, even though the repository labels it a proof of concept and licenses it under MIT.
One function sets other local accounts to a hard-coded temporary password, signs in with each changed account, checks for an administrator token, and attempts to create a service that relaunches the program with higher privileges. It then tries to restore each original hash. A restoration attempt is not a safety boundary: interruption, a code defect, or a changed Windows behavior could leave credentials altered. The same routine prints NTLM material, so console logs and screen captures become sensitive artifacts too.
Visual Studio v145 is specified, while dependency provenance is missing
The project file requests Windows SDK 10.0, C++20, and Visual Studio platform toolset v145 across Win32 and x64 configurations. Source pragmas name several Windows libraries, and the repository includes Microsoft Offline Registry headers plus a compiled offreg.lib. That is more build information than the README gives, yet it is still an input inventory rather than a reproducible procedure. No Visual Studio edition, exact compiler build, or expected warning set is recorded.
Three commits on one day show publication, not maintenance
All 3 commits landed on August 30, 2026, and the last push was that day. GitHub showed 210 stars, 58 forks, and 0 open issues or pull requests when fetched on September 23, 2026. The repository is not archived, but there is no visible issue history to show how maintainers handle failed reproduction, false claims, vendor changes, or cleanup problems. The star count records attention around the disclosure; it cannot substitute for those missing conversations.
The lack of later pushes does not prove abandonment after a few weeks, especially for a proof of concept that may be intentionally static. It does set the buying boundary. There is no release stream to follow and no patch-status feed inside the project. If you are responsible for an Avast fleet, use vendor channels and controlled validation for remediation decisions rather than treating a public exploit repository as a current compatibility table.
Version 2 analysis tools are a safer first step
Google Project Zero's Sandbox Attack Surface Analysis Tools version 2 is the closest alternative for studying exposed Windows sandbox objects without beginning from this Avast-specific exploit. PrivescCheck focuses on auditable Windows configuration findings, while PEASS-ng searches for a broader set of local escalation paths. None confirms or disproves the PrettyPrague claim by itself. They fit defenders who need inventory and evidence before deciding whether exploit reproduction is necessary.
PrettyPrague is useful as a narrow source artifact because it makes the claimed consequence concrete: SAM access, password-hash disclosure, account changes, and a SYSTEM-shell attempt. Its 3-commit history and 657-byte README leave the rest of the work to the researcher. Read the code, preserve the sample, and reproduce only under explicit authorization on a disposable image. A live employee endpoint is the wrong place to discover whether the password restoration path works.