How to Find World-Writable Sockets on Linux

To find world-writable sockets on Linux, search the filesystem for socket files with the "other" write bit set using find, then map each one to the process listening on it with ss. Any socket that is writable by every user and owned by a root process deserves a closer look, because on Linux write permission on a socket file is what allows a process to connect. The whole sweep takes a few minutes per host.

Why look for world-writable sockets now

The exploited Check Point CVE-2026-123039 flaw came down to one socket file: /tmp/dynamic_socket, mode 0777, served by a root daemon that ran any command it received. Check Point's verification step for the fix is simply checking that the socket is now 0660.

The same class of mistake turns up in in-house tools, vendor agents and appliance software. A sweep of your own Linux servers is cheap and finds the obvious cases before someone else does. If the socket concept is new to you, start with what a Unix domain socket is and how its permissions work.

What counts as a world-writable socket?

A world-writable socket is a socket file whose mode grants write permission to "other", meaning every account on the host. In a long directory listing its mode starts with the letter s and has a w in the last permission group.

Examples are srwxrwxrwx (0777) and srw-rw-rw- (0666).

How do you find world-writable sockets with find?

Use GNU find with a type test for sockets and a permission test for the "other" write bit, run as root across each local filesystem. Then map each match to its listening process.

In find, -type s matches sockets. The -perm -mode form matches files that have all the listed bits set, so -perm -o+w matches anything writable by other users.

Step 1: Sweep local filesystems

Run as root so permission errors do not hide results:

find / -xdev -type s -perm -o+w

-xdev keeps find on the root filesystem and stops it from descending into other mounts. Repeat the command for each separate local mount you care about (for example /var or /run if they are separate filesystems), or drop -xdev and accept a slower run.

Step 2: Check the common socket locations

Most services put sockets under /run, /var/run or /tmp. Sockets in /tmp deserve the most suspicion: the directory is shared by every user, which is the opposite of what a privileged service needs. Run a targeted listing:

find /run /tmp -type s -perm -o+w

Step 3: Map each socket to its process

A socket file alone does not tell you what is listening. List listening Unix sockets together with the owning process:

ss -xlp

-x limits output to Unix sockets, -l to listening ones, and -p shows the process. Match the paths from steps 1 and 2 against this output, and note the user each process runs as.

Step 4: Triage the results

Sort what you find into three groups:

1. Expected and safe. Some sockets are world-writable by design because the service authenticates every caller itself. Confirm that in the vendor documentation, not by assumption.
2. Root process, unclear authentication. This is the dangerous group. Ask the vendor or the code owner how the daemon decides who may call it. If the answer is "the file mode", treat it as a finding.
3. Unknown process or orphaned socket. A socket with no listener, or one served by software nobody recognizes, needs investigation. On a server that should be clean, an unexplained root listener in /tmp can be a sign of compromise.

How do you fix a world-writable socket?

Fix it in the service configuration or code: create the socket with mode 0660 or tighter, owned by a dedicated group, inside a private directory. Changing the mode on the live file is only a stopgap, because most services recreate the socket on restart.

The daemon should also check each caller's identity with SO_PEERCRED instead of trusting the file mode alone.

For vendor appliances you cannot reconfigure, follow the vendor's fix. In the Check Point case that means installing the fixed Jumbo Hotfix take, or stopping the dynamic_server daemon as sk1000362 describes until you can.

Make it part of routine checks

• Baseline. Record the expected set of world-writable sockets per server role, so new ones stand out.
• Automate. Run the find sweep from your configuration management or monitoring agent and alert on any path not in the baseline.
• Review vendor agents. Backup, monitoring and EDR agents often run as root and expose local sockets. Ask how they authenticate callers during procurement.
• Include appliances. Firewalls, load balancers and storage appliances run Linux underneath. Where the vendor allows shell access, include them in the sweep.

A root daemon with an open socket turns any local foothold into full control. On network appliances that is a short path, which is why local privilege escalation on firewalls is urgent to patch.