Ensure No World Writable Files Exist: How to Find and Fix World-Writable Files on Linux

“Ensure no world writable files exist” is a CIS benchmark check that fails when any regular file on a local Linux file system lets every user write to it (the “other” write bit, mode 0002). To fix it, list the files with find -perm -0002, confirm no application needs that bit, remove it with chmod o-w, and rescan.

The chmod takes seconds. The real work is the review: files made world-writable by a vendor package, an install script or a loose umask come back after the next update unless you fix the cause.

What the scanner is actually detecting

This finding comes from Tenable’s CIS benchmark audit files, run as a credentialed compliance scan in Nessus or another Tenable product. It is a configuration check that reports PASSED or FAILED, not a vulnerability plugin, so there is no CVE behind it. Item numbers change between distributions and benchmark versions, so search your report by title:

Newer versions titled “Ensure world writable files and directories are secured” also require the sticky bit on world-writable directories. Older versions keep that as a separate item, such as 6.1.2 “Ensure sticky bit is set on all world-writable directories” in CIS CentOS Linux 8 v2.0.0.

A manual equivalent, built the same way as the CIS sticky-bit remediation command but looking for regular files, is:

df --local -P | awk 'NR!=1 {print $6}' | xargs -I '{}' find '{}' -xdev -type f -perm -0002

df –local -P lists local file systems, awk prints each mount point, and find -xdev searches each one without crossing into other mounts. -type f skips symbolic links, directories and device nodes such as /dev/null, and -perm -0002 matches files with the other-write bit set.

Some audit files implement the item with Tenable’s built-in find_world_writeable_files check instead. Tenable documents that it searches recursively from / by default, accepts optional basedir, ignore and timeout keywords, and can run for a couple of hours on a large system. Its scope can therefore be wider than the local-only command above.

Real-world risk, stated honestly

This is a local issue. Someone must already be able to run code as some account on the host, such as a shell user or a compromised web application’s service account. It is not reachable from the network on its own.

How much it matters depends entirely on the file:

• Executed or read by a privileged account: a script run by root from cron or a systemd unit, or a configuration file read by a privileged service. Any local user can edit it and get code running as that account: a straightforward privilege escalation.
• Data and logs: any user can alter or erase the contents, hide activity in a log, or grow the file until the disk fills.
• A symptom: the CIS rationale notes that world-writable files may indicate an incorrectly written script or program, which can matter more than the file itself.

Many hits turn out to be low-value data files, so triage the list rather than treating every entry as an emergency.

How to confirm it on the host

To find world writable files on Linux the way the audit does, run the commands from a root shell (for example sudo -i) so find can read every directory:

# Local file systems, regular files, other-write bit set, with owner and mode
df --local -P | awk 'NR!=1 {print $6}' | xargs -I '{}' find '{}' -xdev -type f -perm -0002 -ls 2>/dev/null

For each result, find out where it came from and whether anything is using it:

# RHEL, CentOS, Rocky, AlmaLinux, SUSE: which package owns the file
rpm -qf /path/to/file
# Verify that package: an "M" in the second column means the mode differs from the package
rpm -V <package>

# Debian, Ubuntu: which package owns the file
dpkg -S /path/to/file

# Processes that have the file open right now
lsof /path/to/file

Sort each file into one of three groups: nobody needs it world-writable (the usual case), several accounts share it (use a group), or the vendor ships it this way (vendor guidance or a documented exception).

How to fix it

Step 1: record the current modes

Save a manifest first so you can undo any single change later:

df --local -P | awk 'NR!=1 {print $6}' | xargs -I '{}' find '{}' -xdev -type f -perm -0002 -printf '%mt%pn' 2>/dev/null > /root/world-writable-before.txt

Step 2: remove the other-write bit

For a single file, as the CIS remediation text recommends:

chmod o-w /path/to/file

For a reviewed list, strip the mode column, delete the lines for any file you must keep, then apply:

cut -f2- /root/world-writable-before.txt > /root/world-writable-fix.txt
# edit /root/world-writable-fix.txt and remove files that must stay as they are
while IFS= read -r f; do chmod o-w -- "$f"; done < /root/world-writable-fix.txt

Step 3: use a group for files that several accounts share

When two service accounts genuinely need to write the same file, give them a common group instead:

groupadd appshare
usermod -aG appshare svc_one
usermod -aG appshare svc_two
chgrp appshare /path/to/shared.file
chmod g+w,o-w /path/to/shared.file

Restart the services afterwards; a running process does not pick up new group membership.

Step 4: fix whatever keeps recreating the file

If a service keeps creating world-writable files, run systemctl edit myapp.service, add the drop-in below, then restart the service:

[Service]
UMask=0027

A umask only affects files created after the change, so existing files still need Step 2. Also check:

• Install scripts and configuration management: tasks that run chmod 666 or chmod 777. A public Wazuh issue, for example, describes Nessus flagging Python files under /var/ossec/framework that a package permission script had set to 777.
• Package-owned files: if rpm -V shows an M, the mode was changed after installation. If the package itself ships the file world-writable, raise it with the vendor.

Directories that must stay world-writable

Shared directories can keep the other-write bit but need the sticky bit. The CIS remediation command for that item is:

df --local -P | awk '{if (NR!=1) print $6}' | xargs -I '{}' find '{}' -xdev -type d ( -perm -0002 -a ! -perm -1000 ) 2>/dev/null | xargs -I '{}' chmod a+t '{}'

For one directory, chmod a+t /path/to/dir is enough. The sticky bit stops unprivileged users from removing or renaming files they do not own. It does not stop anyone writing to a file inside that directory that is itself world-writable.

How to verify the fix and rescan

df --local -P | awk 'NR!=1 {print $6}' | xargs -I '{}' find '{}' -xdev -type f -perm -0002 2>/dev/null
# expected: no output (or only files you have documented as exceptions)

Then rerun the same compliance scan with the same audit file; the item should change from FAILED to PASSED. Check again after the next package update, reboot or configuration management run, when recreated files usually reappear.

What can break and how to roll back

• Processes that write as a different user than the file owner: shared logs, lock files, spool files and legacy applications that run under several accounts start logging “Permission denied”. Move them to the group approach in Step 3.
• Vendor software: some products reapply their own file modes on upgrade. Track those files as exceptions rather than fighting the installer.

To roll back everything from the manifest saved in Step 1:

while IFS=$'t' read -r mode path; do chmod -- "$mode" "$path"; done < /root/world-writable-before.txt

To roll back one file, look up its line in the manifest and run chmod with the recorded octal mode on that path only.

Common false positive reasons

• Symlinks and device nodes in manual checks: ls -l shows lrwxrwxrwx for every symbolic link and crw-rw-rw- for /dev/null. Linux ignores symlink permissions, and neither is a regular file, so they are not real hits for this item.
• Different scope: the built-in Tenable check starts from / unless the audit sets basedir or ignore, so it can list paths, such as network mounts, that the local-only command skips.
• Transient files: a temporary file created with mode 0666 may be gone by the time you look. Fix the process that creates it.
• Accepted vendor files: a true finding, but one to document as an exception if the vendor requires the mode.
• False PASS from a limited account: if the scan account lacks root or sudo, find cannot read every directory and results are incomplete. See our guide to SSH credentials and sudo for Linux authenticated scans.

FAQ

Does this check flag /tmp?

No. /tmp is a directory and this item only looks at regular files. /tmp should be world-writable with the sticky bit set, which the sticky-bit item or the newer combined item covers.

Is find -perm -0002 the same as -perm /0002?

For this check, yes. -perm -mode matches files with all of the listed bits set and -perm /mode matches any of them; with only one bit listed, both find the same files. The symbolic form -perm -o+w also works.

Can I just run chmod -R o-w / instead?

No. That would also remove the bit from directories such as /tmp and /var/tmp and from device nodes such as /dev/null, which non-root programs rely on. Fix the listed files only.

Why does the check take so long or time out?

It walks every file on the host. Tenable notes the built-in check can run for hours and accepts a timeout of up to 7,200 seconds. A timed-out item means the search did not finish, not that the host is clean.

Tracking this finding across many hosts

On a large Linux estate, the same vendor files tend to reappear after updates. If you use SITEY, you can upload the .nessus export from the compliance scan, let its AI triage suggest false positives with evidence for a person to decide on, and have host-specific remediation scripts deployed through its Linux agents only after human approval, followed by a re-test to verify the finding is closed.

Sources

• Tenable: CIS CentOS Linux 8 Server L1 v2.0.0, 6.1.11 Ensure no world writable files exist
• Tenable: CIS CentOS Linux 8 Server L1 v2.0.0, 6.1.2 Ensure sticky bit is set on all world-writable directories
• Tenable Nessus Compliance Checks Reference: find_world_writeable_files
• find(1) Linux manual page: -perm, -xdev, -type and -printf
• chmod(1) Linux manual page: symbolic modes, sticky bit and symbolic links