CVE-2026-33430
Insecure Permissions in Briefcase MSI Installer Enables Privilege Escalation
Publication date: 2026-03-26
Last updated on: 2026-04-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| beeware | briefcase | From 0.3.0 (inc) to 0.3.26 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-732 | The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33430 is a privilege escalation vulnerability in the Briefcase tool used to create Windows MSI installers. When a developer uses Briefcase versions from 0.3.0 up to but not including 0.3.26 to produce an MSI installer for a project installed for all users (per-machine scope), the installation directory inherits permissions from its parent directory instead of having explicit restrictive permissions set.
This improper permission inheritance can allow a low-privilege but authenticated user to modify or replace the installed application binaries if the installation location permits such access (for example, if installed outside protected directories like Program Files). If an administrator later runs the altered binary, it executes with elevated privileges, leading to local privilege escalation.
The root cause is the Windows Installer XML (WXS) template used by Briefcase, which did not disable permission inheritance properly. The issue was fixed starting with Briefcase version 0.3.26 by updating the templates to restrict permission inheritance on the installation directory.
How can this vulnerability impact me? :
This vulnerability can allow a low-privilege but authenticated local user to modify or replace application binaries installed by a Briefcase-generated MSI installer when installed for all users.
If an administrator or higher-privileged user subsequently runs the modified binary, it will execute with elevated privileges, potentially allowing the attacker to escalate their privileges on the system.
This can lead to a full compromise of the affected system, impacting confidentiality, integrity, and availability of the system and data.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking the permissions of the installation directory created by the Briefcase MSI installer when installed with per-machine (ALLUSERS=1) scope. Specifically, you should verify if the directory inherits permissions from its parent directory and if "Authenticated Users" have modify or write permissions.
One way to detect this is by inspecting the Access Control List (ACL) of the installation folder using PowerShell commands.
- Use PowerShell to get the ACL of the installation folder, for example: Get-Acl -Path 'C:\Path\To\InstalledApp' | Format-List
- Check the SDDL string in the ACL output for the presence of auto-inherited permissions (e.g., D:AI) instead of protected permissions (D:P).
- Verify if "Authenticated Users" have Modify permissions (e.g., 0x1301bf) on the installation directory.
If non-admin users can write or modify files in the installation directory, the system is vulnerable.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should update your Briefcase project to use the patched templates that fix the permission inheritance issue.
- Re-run the command `briefcase create` on your project to regenerate the Windows MSI installer files with the updated templates starting from Briefcase version 0.3.26.
- If you have existing .wxs files generated by Briefcase 0.3.24 or later, manually apply the patch changes from the relevant pull requests to disable permission inheritance on the installation directory.
- Ensure that MSI installers are installed in protected directories like Program Files to reduce the risk of unauthorized modification.
These steps prevent the installation directory from inheriting overly permissive access rights, thereby blocking low-privilege users from modifying installed binaries and mitigating the risk of privilege escalation.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows low-privilege authenticated users to modify installed application binaries, which can then be executed with elevated privileges by an administrator. This privilege escalation risk can lead to unauthorized access, modification, or disruption of critical application components.
Such unauthorized modification and potential privilege escalation can compromise the confidentiality, integrity, and availability of systems and data, which are core principles in standards and regulations like GDPR and HIPAA.
Therefore, if exploited, this vulnerability could lead to non-compliance with these regulations due to failure to adequately protect sensitive data and maintain secure system operations.