Note: The vendor's fix (stripping newline characters) is incomplete — the same field remains vulnerable to stored Cross-Site Scripting (XSS) because no output encoding or character allowlist is applied.

2. Root Cause Analysis

2.1 The Injection Point

The secure-proxy-user field is defined in the PAN-OS schema (schema.xml) as a plain string with no input sanitization:

Note: secure-proxy-server has a regex constraint (regex="^([0-9a-zA-Z.:/_-])+$"), but secure-proxy-user has none. There is a 31-character length limit, but no character restrictions.

2.2 The Vulnerable Config Writer

During commit, PAN-OS regenerates /etc/nginx/nginx.conf from a template (/etc/nginx/nginx.conf.tmpl). The template contains:

The %s placeholder is filled by the libpanmp_mp.so library function that concatenates proxy server, username, and encrypted password into a single string. On the vulnerable version, newline characters in the username are passed through verbatim.

2.3 The Resulting nginx.conf Corruption

When secure-proxy-user contains a\naccess_log /tmp/pwn3;\n#, the generated nginx.conf becomes:

Line 1 is a comment. Line 2 is a valid nginx directive at the http block level. Line 3 is neutralized by the attacker's # character.

2.4 Why This Is Dangerous

The nginx master process runs as root. The access_log directive causes nginx to open/create the target file as root. This enables:

1. Arbitrary file creation anywhere on the filesystem
2. Arbitrary file write (HTTP access log content is appended)
3. DoS if an invalid directive is injected (nginx refuses to reload)

3. The Fix (and its Limitations)

On the fixed version (11.1.13), the config writer strips newline characters from the proxy username before writing it to nginx.conf. The same malicious value produces:

Everything stays on one line, safely inside the # comment.

However, this fix is incomplete. It only addresses newline injection. The secure-proxy-user field still accepts arbitrary characters (including ", <, >) without output encoding, leaving the stored XSS vector wide open. See unit-43-xss.

4. Proof of Concept

Prerequisites

• Authenticated admin access to PAN-OS management (API or web UI)
• A configured secure-proxy-server (required for the proxy comment to appear)

Step 1: Obtain API Key

Step 2: Configure Proxy Server (if not set)

Step 3: Inject Malicious Proxy Username

Step 4: Commit Configuration

Step 5: Verify

After commit completes (~30s):

• /tmp/pwn3 is created with root ownership
• nginx -t -c /etc/nginx/nginx.conf reports: syntax is ok
• nginx reloads successfully with the injected directive

5. Propagation Analysis

The unsanitized secure-proxy-user value propagates to multiple files:

The curlrc (/root/.curlrc) and wgetrc (/root/.wgetrc) writers do strip newlines, even on the vulnerable version. The nginx.conf writer was the only path that didn't sanitize.

6. RCE Assessment

Extensive testing of 11 attack vectors confirmed that standalone OS-level RCE from CVE-2025-4615 alone is not achievable on PAN-OS 11.1.6-h7 with nginx 1.20.1. The three critical blockers:

1. nginx \x0A escaping — prevents raw newline injection into log files, blocking cron injection despite vixie-cron's tolerance of garbage lines (lab-confirmed: cron does execute valid lines surrounded by garbage)
2. 31-character limit — prevents combining log_format + access_log to gain content control over written files
3. curlrc/wgetrc newline stripping — eliminates the secondary file-write channel

The advisory's "execute arbitrary commands" most likely refers to arbitrary nginx directives, not OS-level command execution. This is consistent with the CVSS VC:N (no confidentiality impact) and the nature of the fix.

If any of the three blockers were absent, RCE would be trivially achievable via cron injection.

Analysis performed on isolated lab environment with PAN-OS 11.1.6-h7 (vulnerable) and PAN-OS 11.1.13 (fixed).