Rule Information
Tags
pythonfile-permissionsos-chmodos-fchmodworld-writableworld-readableCWE-732OWASP-A05
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-LANG-SEC-101 --project .1
2
3
4
5
6
7
8
9
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
About This Rule
Understanding the vulnerability and how it is detected
Python's os.chmod() and os.fchmod() functions set the permission bits on files and directories. Setting permissions that are too broad — for example, 0o777 (world-readable, world-writable, world-executable) or 0o666 (world-readable and world-writable) — allows any user on the system to read, modify, or execute the file. This can lead to unauthorized data access, privilege escalation, or injection of malicious content into files that are later executed or interpreted by a privileged process.
Common dangerous patterns include using octal literals like 0o777, 0o666, 0o644 on sensitive files, or using stat constants like stat.S_IWOTH (world-write) and stat.S_IROTH (world-read) on configuration files, temporary files containing secrets, or executable scripts.
The principle of least privilege dictates that files should be given only the minimum permissions necessary. Configuration files should typically be 0o600 (owner read/write only), scripts should be 0o700 (owner execute only), and shared files should not be world-writable.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Sensitive Data Exposure
Files containing credentials, private keys, API tokens, or user data that are made world-readable (permissions including o+r) can be read by any user on the system. In multi-tenant environments or on compromised hosts, this directly exposes secrets to other users or processes.
2
Privilege Escalation via World-Writable Files
World-writable files (permissions including o+w) that are later read and executed by a privileged process — such as a cron job, init script, or SUID binary — can be modified by a low-privilege attacker to inject arbitrary commands. This is a classic Unix privilege escalation vector.
3
Log Tampering and Evidence Destruction
Log files or audit trails set to world-writable permissions allow any user to modify or truncate log content, destroying evidence of malicious activity. Attackers routinely clear or modify logs after compromise to hinder incident response.
4
Configuration Injection
Configuration files with world-write permissions can be modified by any local user to change application behavior, inject malicious settings, or redirect processing to attacker-controlled resources. This is particularly dangerous for web server configs, database connection strings, and application settings files.
How to Fix
Recommended remediation steps
- 1Use 0o600 for files containing secrets, credentials, private keys, or sensitive configuration — owner read/write only.
- 2Use 0o700 for executable scripts that should only be run by their owner, and 0o750 if group execution is needed.
- 3Never use 0o777 or 0o666 in production code; if a file must be shared, use group permissions (e.g., 0o660) rather than world permissions.
- 4Set the umask appropriately at process startup (os.umask(0o077)) to ensure files are created with restrictive defaults.
- 5Audit existing files with overly broad permissions using find with -perm -o+w or equivalent and restrict them.
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule detects calls to os.chmod() and os.fchmod() where the permission argument includes world-write (o+w) bits. Specifically, it flags octal literals where the least significant octet has the write bit set (second bit of the last octal digit), including 0o777, 0o666, 0o776, 0o667, 0o757, and similar patterns. Calls using stat module constants that include stat.S_IWOTH or stat.S_IRWXO are also flagged. The rule matches both the os.chmod() and os.fchmod() forms.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
CWE Top 25
CWE-732 - Incorrect Permission Assignment for Critical Resource
OWASP Top 10
A05:2021 - Security Misconfiguration
NIST SP 800-53
AC-3: Access Enforcement; files must have minimum necessary permissions
PCI DSS v4.0
Requirement 7.2 - Restrict access to system components based on least privilege
CIS Benchmark
Ensure no world-writable files exist on the system
References
External resources and documentation
Similar Rules
Explore related security rules for Python
LOW
UUID Version 1 Leaks MAC Address
uuid.uuid1() embeds the host MAC address in the generated UUID, leaking hardware identity information.
HIGH
Hardcoded Password in Default Function Argument
A function defines a default argument whose name suggests a password or secret but whose value is a hardcoded string literal.
MEDIUM
Logger Credential Leak Risk
Detects logging calls (info, debug, warning, error, critical) that should be audited for accidental credential or secret leakage in log output.
Frequently Asked Questions
Common questions about Insecure File Permissions via os.chmod
Any permission that grants write access to "others" (the world) is considered insecure.
In octal notation, the last digit controls world permissions: digits 2, 3, 6, and 7 all
include world-write. So 0o777, 0o776, 0o666, 0o667, 0o757, 0o646, etc. are all flagged.
World-readable (0o644, 0o444) may be acceptable for public files but is flagged for
sensitive files. The rule focuses primarily on world-writable permissions as the highest risk.
For directories that need to be shared between users, prefer group permissions over world
permissions. Add all relevant users to a shared group and use 0o770 (owner and group
read/write/execute) instead of 0o777. The sticky bit (0o1777) on shared directories
prevents users from deleting each other's files without granting unnecessary write access.
0o644 (owner read/write, group and world read-only) is acceptable for non-sensitive
configuration files that need to be readable by multiple users. However, for files
containing passwords, API keys, TLS private keys, or other secrets, use 0o600
(owner read/write only). The presence of world-readable permissions on secret files
is a security risk in multi-user or shared environments.
Static files served by a web server should typically be owned by the web server user
or a deployment user with group read permission, not world-writable. A common pattern
is 0o644 for files and 0o755 for directories, where the web server runs as a specific
user/group. Avoid making web-served directories world-writable as this allows any
local user to plant malicious files.
Yes. Test code that uses overly permissive permissions to set up test fixtures can
create security risks if the tests run in shared CI environments or leave files behind.
It is good practice to use restrictive permissions even in tests and explicitly set
permissions in setup/teardown to ensure test isolation.
New feature
Get these findings posted directly on your GitHub pull requests
The Insecure File Permissions via os.chmod rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.