CVE-2016-1247

What it actually does

Allows local users with access to the nginx web server account to escalate privileges to root via a symlink attack on the configured error log file.

Why it matters to the business

Attackers who already have limited access on affected systems can gain full root control, enabling data theft, persistence, or further compromise across nginx deployments that have remained unpatched for years.

How an attack unfolds

An attacker with access to the nginx user account identifies the error log path, replaces it with a symlink to a root-owned file such as a cron job or shadow file, triggers a write operation through an error condition, and leverages the resulting file modification to execute code as root.

How to fix it

Upgrade nginx packages on all affected distributions to versions that eliminate the symlink vulnerability in error log handling.

How to confirm the fix worked

Confirm nginx is running a patched release, verify that error log paths cannot be replaced with symlinks by non-root users, and audit file creation permissions under the nginx account.

Typical attack path

1. Obtain access as the nginx web server user account
2. Locate the configured error log file path
3. Replace the log path with a symlink pointing to a privileged target file
4. Induce an error that forces nginx to write to the log
5. Abuse the overwritten privileged file to achieve root execution

How to detect it

Review nginx error log directories and system audit logs for symlink creations or ownership changes performed by the nginx user account, and look for subsequent root-level processes or file modifications originating from that account.

What your security team should do

• Prioritize patching all nginx instances to current fixed releases
• Restrict the nginx service account to the minimum required permissions
• Enable filesystem protections such as immutable flags on critical log directories
• Scan systems for unexpected symlinks created by the nginx user