CVE-2026-1463 Exploit & Vulnerability Analysis

The Exploit

An authenticated WordPress user with Author-level access or above can include and execute arbitrary PHP files from the server by injecting directory traversal sequences into the template parameter of a NextGEN Gallery shortcode.

POST /wp-admin/post.php HTTP/1.1
Host: target.local
Content-Type: application/x-www-form-urlencoded
Cookie: wordpress_logged_in=<valid_author_session>

post_ID=42&post_type=post&action=edit&content=[ngg_images+template="../../../../../../var/www/html/wp-content/plugins/malicious-plugin/shell.php"]

When this shortcode is rendered (either during post save or on front-end view), the plugin attempts to locate and include the template file specified by the template parameter. Because no directory traversal validation occurs before file loading, the attacker can traverse the directory tree using ../ sequences and reach any .php file readable by the web server process—including user-uploaded files, plugin code, or theme files containing attacker-controlled PHP. The response either executes the included PHP (if it's valid) or reveals file contents in error messages.

What the Patch Did

Before

// LegacyTemplateLocator.php, lines 132-139
// No validation of $custom_template for directory traversal patterns
// Template file is loaded directly from user-supplied path
$template_path = $this->locate_template( $custom_template );
// ... later, file_get_contents() or include() is called on $template_path

After

// SECURITY: Check for directory traversal patterns in ALL cases BEFORE processing.
// This prevents LFI attacks via shortcode template parameters like "../../../../../../poc".
// Normalize slashes first to catch mixed separator bypass attempts.
$normalized_for_check = str_replace( [ '/', '\\' ], DIRECTORY_SEPARATOR, $custom_template );
if ( preg_match( '#\.\.' . preg_quote( DIRECTORY_SEPARATOR, '#' ) . '#', $normalized_for_check ) ) {
	// Directory traversal attempt detected - do not load this template.
	return false;
}

The patch adds an explicit directory traversal validator that normalizes all path separators (/ and \) to the platform-native separator, then checks for the pattern .. followed by a directory separator using preg_match(). This is a whitelist-adjacent control: rather than enumerating safe characters, it blacklists the canonical directory traversal sequence. The normalization step prevents attackers from bypassing the check using mixed separators (e.g., ..\/..\/) on Windows systems.

Root Cause

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The template parameter in the NextGEN Gallery shortcode ([ngg_images template="..."]) is user-controlled by any authenticated Author-level user. The value flows directly into the template locator function without any sanitization or validation of path components. The LegacyTemplateLocator::locate_template() method calls file_get_contents() or include() on the resolved path, crossing a trust boundary: the attacker-supplied filename becomes a file system operation without confinement. No realpath verification, realpath() canonicalization, or directory escape detection occurs, allowing sequences like ../ to navigate outside the intended template directory.

Why It Works

The load-bearing line is the preg_match() call that detects .. followed by a directory separator. Without this check, the normalization step does nothing—an attacker can still pass ../../shell.php through and the file will be loaded. The additional normalization step (str_replace() of / and \ to DIRECTORY_SEPARATOR) is essential defence-in-depth: on Windows, an attacker could bypass a naive check that only looks for forward slashes by using backslashes, or vice versa on systems where path parsing is permissive. The preg_quote() call around the separator ensures the regex literal matches the actual separator character, preventing regex metacharacter injection. Together, these ensure that no combination of slash styles and sequence variations can slip past the check—but the regex itself is the critical gate.

Hardening Checklist

• Use wp_safe_remote_get() with allowed hostnames, or wp_kses_allowed_html() for file path construction: Never accept raw file paths from user input. Instead, accept only a filename or ID, then look it up in a whitelist array of safe template names stored in options or a constant.

• Apply realpath() confinement on all file operations: After resolving any user-influenced path, call $safe_path = realpath( $user_path ); $allowed_dir = realpath( PLUGIN_DIR . '/templates' ); if ( strpos( $safe_path, $allowed_dir ) !== 0 ) return false; to ensure the final path never escapes the designated directory.

• Reject paths containing .. or // before any file operation: Use the exact pattern from the patch—normalize separators, then reject any preg_match( '#\\.\\.\\' . preg_quote( DIRECTORY_SEPARATOR ) . '#' ) match—on all user-supplied file path inputs, including those in shortcode parameters and POST requests.

• Audit all include(), require(), file_get_contents(), and wp_remote_*() calls: Search your codebase for these functions and trace the source of their arguments. If any argument is derived from $_REQUEST, shortcode attributes, post meta, or options, add the directory traversal check immediately before the call.

• Maintain a capability check at the shortcode handler level: Ensure only current_user_can( 'edit_pages' ) or higher can submit shortcodes containing dynamic file paths. In NextGEN's case, the Author check exists, but pairing it with realpath confinement would have prevented the bypass.

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-1463