CVE-2026-33430: 
Python vulnerability analysis and mitigation

CVE-2026-33430 is a privilege escalation vulnerability in BeeWare Briefcase, a tool for converting Python projects into standalone native applications. Affecting versions 0.3.0 through 0.3.25, the flaw causes Windows MSI installers generated for per-machine (All Users) scope to create installation directories that inherit permissions from their parent directory rather than enforcing explicit, restricted access controls. This can allow a low-privilege authenticated user to replace or modify installed application binaries; if an administrator subsequently executes the tampered binary, it runs with elevated privileges. The vulnerability was reported by researcher lrandersson, disclosed on March 20, 2026, and published to the GitHub Advisory Database on March 23, 2026. It carries a CVSS v3.1 base score of 7.3 (High) (GitHub Advisory, Briefcase Advisory).

The root cause is classified as CWE-732 (Incorrect Permission Assignment for Critical Resource). The WiX Toolset template (.wxs file) used by Briefcase to generate Windows MSI installers does not configure explicit permissions on the INSTALLFOLDER directory for per-machine installations (ALLUSERS=1). As a result, the directory does not have inheritance disabled (the SE_DACL_PROTECTED flag is absent), causing it to inherit its DACL from the parent directory. Depending on the installation path chosen by the user — particularly non-standard locations outside of Program Files — this can grant Authenticated Users modify or write permissions to the application's executables and libraries, enabling a binary planting attack (GitHub Issue #2759, GitHub Advisory). The attack is local, requires low privileges, and requires an administrator to subsequently run the modified binary (Briefcase Advisory).

Successful exploitation allows a low-privilege authenticated local user to replace or modify application binaries installed by a Briefcase-packaged MSI. When an administrator or privileged service subsequently executes the tampered binary, the attacker's code runs with elevated privileges, resulting in full system compromise with high confidentiality, integrity, and availability impact. The risk is most acute on multi-user Windows systems where applications are installed to non-standard locations outside of Program Files, and where low-privilege users share the machine with administrators (GitHub Advisory, GitHub Issue #2759).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.011% (0th percentile), indicating a very low probability of exploitation in the near term. Exploitation requires local access, low privileges, and user interaction (an administrator must run the modified binary), which limits the practical attack surface (GitHub Advisory, Feedly).

1. Identify a vulnerable installation: Confirm that a target Windows system has an application installed via a Briefcase-generated MSI (versions 0.3.0–0.3.25) with per-machine scope (ALLUSERS=1) to a non-standard location (e.g., C:\MyApp) rather than Program Files.
2. Verify write access: As a low-privilege authenticated user, check the inherited permissions on the installation directory using PowerShell: Get-Acl -Path "C:\MyApp" | Format-List. Confirm the SDDL contains D:AI (Auto-Inherited) and that Authenticated Users have Modify permissions (0x1301bf).
3. Confirm write access: Attempt to write a test file: echo test > "C:\MyApp\test.txt". Success confirms exploitable permissions.
4. Replace or modify a binary: Overwrite or replace a target executable (e.g., the main application .exe or a loaded DLL) in the installation directory with a malicious payload.
5. Wait for privileged execution: Wait for an administrator or privileged service to launch the application. When the tampered binary is executed, the attacker's payload runs with the administrator's elevated privileges, achieving privilege escalation (GitHub Issue #2759, GitHub Advisory).

• File System: Unexpected modification timestamps on application executables or DLLs in the Briefcase MSI installation directory; presence of unknown files (e.g., test files written by non-admin users) in the installation folder.
• Logs: Windows Security Event Log entries (Event ID 4663) showing write or modify access to application binaries by low-privilege user accounts; Event ID 4688 showing unexpected processes spawned from the application's installation directory.
• Access Control: PowerShell Get-Acl output on the installation directory showing D:AI (Auto-Inherited DACL) and Authenticated Users with Modify permissions (0x1301bf) — indicating inherited rather than explicitly restricted permissions (GitHub Issue #2759).

Upgrade Briefcase to version 0.3.26, 0.4.0, or 0.4.1, which include updated WXS templates that explicitly set restricted permissions on the installation directory for per-machine MSI installs. After upgrading, re-run briefcase create on your project to regenerate the WXS file with the corrected template. For existing .wxs files generated by Briefcase 0.3.24 or later, the fix from briefcase-windows-app-template PR #86 can be manually applied as a workaround. Additionally, review and restrict installation directory permissions on already-deployed applications to ensure low-privilege users do not have write access (GitHub Advisory, Briefcase Advisory).

The BeeWare project acknowledged the vulnerability in its March 2026 status update, crediting reporter lrandersson for responsible disclosure via security@beeware.org. The fix was authored and merged by project maintainer freakboy3742 on March 20, 2026, the same day the issue was reported (BeeWare Status Update, Briefcase Advisory). No significant broader media coverage or notable community controversy has been observed.